Long-horizon tasks

Wat zijn long-horizon tasks?

Een long-horizon task is een opdracht waar een mens uren of dagen aan werkt, en die alleen lukt als een lange keten van stappen na elkaar goed gaat. Een klantenbestand overzetten van het ene CRM naar het andere, een reeks rapporten herbouwen na een ERP-wissel, uitzoeken waarom de marge van vorige maand niet klopt: geen van die dingen is een handeling. Het zijn er vijftig of vijfhonderd, en stap veertig hangt af van stap twaalf.

De "horizon" in de naam is een tijdshorizon: hoe ver een AI-agent zelfstandig vooruit kan werken voor de kans op een proper resultaat onder jouw ondergrens zakt. Een model dat een losse vraag goed beantwoordt, kan halverwege een taak van drie uur de draad kwijtraken. Hoe lang een opdracht mag zijn die het model tot het einde draagt, is een aparte capaciteit, los van hoe slim het oogt in een chatvenster.

De onderzoeksgroep METR heeft daar in 2025 een getal van gemaakt. Hun time horizon is de lengte van een taak, gemeten in de tijd die een ervaren mens ervoor nodig heeft, die een model met een bepaald slaagpercentage afwerkt. De versie die iedereen citeert, gebruikt 50 procent. Heeft een model een 50-procent-horizon van twee uur, dan werkt het ongeveer de helft af van de taken waar een expert twee uur voor nodig heeft, en veel meer dan de helft van de taken van tien minuten.

METR vat het zelf zo samen: de hoeveelheid opeenvolgend mensenwerk die een model kan overnemen met een slaagkans van 50 procent. Opeenvolgend is het woord dat telt. Het gaat over hoeveel stappen een model achter elkaar kan zetten zonder te ontsporen, niet over hoeveel het weet.

Hoe METR de tijdshorizon meet

De methode is belangrijk, want je gaat dat getal tegenkomen in verkoopmateriaal. Een cijfer dat je niet kan lezen, kan je ook niet tegenspreken.

Eerst de mensen. METR betaalt ervaren professionals uit software, machine learning en security, gemiddeld zo'n vijf jaar ervaring, om elke taak uit te voeren met dezelfde instructies en dezelfde tools als de agents. De lengte van een taak is het meetkundig gemiddelde van de geslaagde menselijke tijden. Mislukte pogingen van mensen tellen niet mee, en METR geeft zelf aan dat de taken daardoor wat te kort ingeschat kunnen zijn.

Dan de agent, meerdere keren per taak. Op een reeks van een paar honderd software- en onderzoekstaken, van enkele seconden tot meer dan acht uur mensentijd, krijgt elke agent verschillende onafhankelijke pogingen per taak. Dat geeft een slaagpercentage per taak.

Dan een curve. METR zet het slaagpercentage uit tegen de logaritme van de menselijke taakduur en past daar een curve op. Waar die curve door 50 procent gaat, ligt de 50-procent-horizon. Waar ze door 80 procent gaat, ligt de 80-procent-horizon.

Daar volgt één ding uit voor wie de cijfers leest: de horizon is een statistische fit over veel taken, dus de foutmarges zijn breed. METR zelf spreekt over ruwweg een factor twee in beide richtingen bij recente modellen. Een model dat op acht uur staat, kan op dezelfde data ergens tussen vier en zestien zitten.

Hoe snel de horizon groeit

Afgerond zien de cijfers die METR publiceerde er zo uit.

• In maart 2025 had het beste model, Claude 3.7 Sonnet, een 50-procent-horizon van ruwweg 50 minuten tot een uur.

• In augustus 2025 mat METR GPT-5 op een 50-procent-horizon van zowat twee uur en een kwart.

• In januari 2026, op een uitgebreide takenset, kwam Claude Opus 4.5 uit op ongeveer vijf uur.

• In mei 2026 rapporteerde METR minstens 16 uur voor een vroege versie van Claude Mythos Preview, met een betrouwbaarheidsinterval van ongeveer 8 tot 55 uur, en met de waarschuwing dat alles boven 16 uur onbetrouwbaar is met de huidige takenset, omdat er te weinig taken van die lengte in zitten.

Over 2019 tot 2025 verdubbelde die horizon ongeveer elke zeven maanden. Sinds 2024 gaat het sneller: de update van METR van januari 2026 zet de verdubbelingstijd sinds 2024 op ruwweg drie maanden, en op zowat vier als je vanaf 2023 begint te tellen. Wie dat doortrekt, komt binnen een paar jaar bij taken van een maand uit. METR noemt dat soort extrapolatie zelf wankel, omdat niemand goed kan zeggen voor welk soort taken de set eigenlijk staat.

Voor een bedrijf is de richting nuttiger dan de exacte curve. Wat een agent vorig jaar niet afkreeg, krijgt hij volgend jaar misschien wel af. Hou dus een lijstje bij van opdrachten die je geprobeerd en weggelegd hebt, en test ze om de paar maanden opnieuw.

50-procent-horizon versus 80-procent-horizon

De 50-procent-horizon is het cijfer dat geciteerd wordt. De 80-procent-horizon is het cijfer waar een bedrijf naar moet kijken, en dat ligt een stuk lager.

In de data van METR is de 80-procent-horizon van een model doorgaans vier tot acht keer korter dan zijn 50-procent-horizon. GPT-5 is een zuiver voorbeeld uit het rapport van METR zelf: ongeveer twee uur en een kwart op 50 procent, ongeveer 25 minuten op 80 procent. De vroege meting van Mythos Preview heeft dezelfde vorm: minstens 16 uur op 50 procent, iets meer dan drie uur op 80 procent.

Zet de twee naast elkaar op de as die voor jou telt: hoe betrouwbaar een resultaat moet zijn voor je stopt met controleren.

De 50-procent-horizon zegt wat een model soms voor elkaar krijgt. Dat is een goed cijfer om te beslissen waarmee je experimenteert. Het is een muntje opgooien of een bepaalde run lukt, dus een proces bouw je er niet rond.

De 80-procent-horizon zegt hoe lang een opdracht mag zijn die het model vier keer op vijf juist doet. Voor werk waar toch iemand het resultaat naleest, is dat bruikbaar: een misser op vijf is een nazichtkost, geen ramp.

Geen van beide is 99 procent, en METR zegt duidelijk dat het een 99-procent-horizon niet kan meten: daarvoor zou het zo'n 300 gevarieerde taken nodig hebben in elke lengteklasse. Kan een proces geen misser op vijf verdragen, dan zegt de horizon niet dat een agent het kan draaien. Hij zegt hoe lang een stuk van dat proces mag zijn dat een agent opneemt voor jouw controle komt.

Waarom lange taken mislukken

De vaststelling van METR die het meeste verklaart: agents hebben het lastiger met het aaneenrijgen van lange reeksen handelingen dan met de losse stappen. De losse stap lukt meestal. De ketting is wat breekt.

Fouten stapelen op. Een model dat vroeg een kleine fout maakt, een verkeerde kolomkoppeling in een migratie of een verkeerde aanname over een datumformaat, bouwt daar zestig stappen op verder. Niets later herstelt dat, tenzij iets het controleert. METR merkt op dat de winst in tijdshorizon van de laatste twee jaar vooral komt doordat modellen beter hun eigen fouten opvangen in plaats van ze te herhalen. Dat zegt hoe centraal dit probleem is.

Rommelige omgevingen wegen zwaarder dan lange. Bij gelijke lengte doen modellen het slechter op taken die METR als rommeliger scoort: taken zonder duidelijke feedback, of waar de agent zelf op zoek moet naar informatie die hij niet meekreeg. Het meeste echte bedrijfswerk is precies in die zin rommelig. De opdracht luidt "breng de leveranciersstamdata in orde", niet "hernoem deze 40 velden".

De tussenstand gaat verloren. Een lange opdracht levert veel tussenresultaten op, en de agent moet die allemaal meedragen in zijn context. Vroegere beslissingen vervagen, het model herleest en herinterpreteert zijn eigen notities, en na drie uur heeft het niet meer hetzelfde beeld als na tien minuten. Context rot en de grenzen van het context window zijn de mechaniek daarachter.

Geen van de drie lost een slimmer model op zijn eentje op. Je houdt ze in toom door hoe je het werk opdeelt.

Wat dit betekent voor wat je aan een agent geeft

De metriek geeft je een praktische regel: geef een agent stukken werk die korter zijn dan zijn 80-procent-horizon, en zet tussen die stukken een controle.

Neem een maandafsluiting die een boekhouder drie uur kost. In een keer aan een agent gegeven, zit dat rond de rand van de 80-procent-horizon van de beste modellen van vandaag, en je komt pas op het einde te weten of het gelukt is. Knip het in plaats daarvan in vier stukken van ongeveer 45 minuten, bankmatching, openstaande facturen, intercompany, nota's voor het nazicht, met na elk stuk een controle: de totalen kloppen, de rijtellingen kloppen, de lijst met uitzonderingen is er en is uitgelegd.

Zonder die controles staat de rekenkunde tegen je. Slaagt elk stuk negen keer op tien, dan is de kans dat alle vier ongecontroleerd goed gaan 0,9 tot de vierde, ruwweg twee op drie. Met een controle na elk stuk kost een misser je een herstart van 45 minuten in plaats van een opdracht van drie uur die je van nul herbegint.

Het patroon dat daaruit volgt:

1. Begin met taken onder een uur mensentijd. Dat is het bereik waar de huidige modellen betrouwbaar genoeg zijn dat een nazicht een formaliteit is en geen reddingsactie.

2. Geef elk stuk een controle die de agent zelf kan draaien. Een rijtelling, een totaal dat met de bron moet kloppen, een test die moet slagen. Zonder zo'n controle is "ziet er af uit" het enige signaal dat de agent heeft, en word jij de controle.

3. Bewaar de tussenstand bij elk checkpoint. Schrijf het tussenresultaat weg naar een bestand of een tabel, zodat het volgende stuk vertrekt van iets tastbaars en niet van wat de agent zich herinnert.

4. Zet een menselijk nazicht op mijlpalen, niet op elke stap. Bekijk de veldkoppeling voor de migratie loopt, bekijk de uitzonderingen voor er iets geboekt wordt. Daartussen laat je de controles het werk doen.

5. Hou de lange versie voor later. Draait dezelfde opdracht een paar maanden proper in stukken, probeer dan twee stukken samen te voegen. Je eigen logs zijn een betere gids dan om het even welke gepubliceerde curve.

Waar moet je op letten bij claims over long-horizon tasks

Vraag welke horizon. Zegt een leverancier "kan taken van een dag aan", vraag dan of dat het cijfer op 50 of op 80 procent is, en op welke taken. Een dag op 50 procent is een paar uur op 80 procent.

De metriek is gemeten op softwarewerk. METR meldt dat de horizons vergelijkbaar zijn voor wiskundetaken, maar 40 tot 100 keer korter voor taken waarbij het model visueel een computer moet bedienen, zoals doorklikken door schermen. Loopt jouw proces via een webportaal zonder API, ga er dan niet van uit dat het kopcijfer geldt.

De taken zijn proper. Elke taak in de set staat op zichzelf, heeft duidelijke instructies en een duidelijk einde, en vraagt geen samenwerking. Een leverancier die een horizon van 16 uur citeert voor een agent die door jouw mailbox, jouw ERP en een telefoontje naar een leverancier moet, leent een cijfer dat in een heel andere omgeving gemeten is.