Effort a task budgets v Claude: jak řídit kvalitu a náklady agentů

Nejdražší nastavení modelu není automaticky nejlepší nastavení workflow. U klasifikace supportu potřebujete správnou kategorii a rychlou odpověď. U sporné faktury potřebujete dohledat důkazy. U obou potřebujete vědět, kdy se práce zastaví a kdo převezme výjimku.

Aktualizace 6. října 2026: opravuji původní tvrzení o garantovaném finančním stropu. Task budget takovou záruku nedává. Dřívější klientské příklady s konkrétními úsporami nemám doložené, proto je nepoužívám jako důkaz.

Podnětem je video AI s rozumem z 5. října o volbě intenzity přemýšlení. Popis uvádí vlastní testy autora; jejich výsledky zde nepřebírám jako nezávislý benchmark.

Tři ovladače, tři různé úlohy

Podle dokumentace effort tento parametr ovlivňuje množství práce modelu, včetně odpovědí a nástrojů. Není to pevný tokenový limit. Dostupné úrovně závisí na modelu. Vyšší nastavení tedy testujte, nepovažujte je za záruku kvality.

Task budget je orientační rozpočet celé agentní smyčky; model jej může překročit. Naproti tomu max_tokens omezuje generované tokeny jednoho požadavku. Aktuální beta používá output_config.task_budget a hlavičku task-budgets-2026-03-13, nikoli původně uvedené task_budget_tokens. Podporu konkrétního modelu ověřte v dokumentaci.

Celkový provozní limit bych vynucoval mimo model. Plánovač má rozhodnout, zda další požadavek vůbec vznikne. Jinak se i série jednotlivě omezených volání může prodražit.

Pilot na fakturách: nejdřív pravidla, potom další přemýšlení

Pro n8n nebo Make bych začal dávkou 60 anonymizovaných dokladů. To je návrh pilotu, nikoli provedený test. Do dávky patří běžné faktury, chybějící objednávky, nesouhlasící součty, duplicity i nečitelné položky.

1. Předem určete správný výsledek a doklad, který jej potvrzuje. U neřešitelných případů má být správným výsledkem eskalace.
2. Držte stejný model, prompt, nástroje a vstupy. Měňte pouze effort, v úrovních podporovaných zvoleným modelem.
3. Identifikaci dokumentu, povinná pole a součty ověřujte kódem. Další reasoning nenahradí chybějící objednávku.
4. Vyšší effort přidělte případům, kde existují potřebné podklady, ale jejich vyhodnocení je složité.
5. Změnu nasaďte teprve po kontrole chyb a ceny dokončené, ověřené úlohy.

Výstup „nevím, chybí objednávka“ může být správnější než dlouhé přesvědčivé vysvětlení. Chybějící obchodní pravidlo doplňte do zadání; nečekejte, že ho vyšší effort vymyslí za vás.

Co má hlídat orchestrátor

Před spuštěním dalšího kroku bych kontroloval spotřebu, počet pokusů, uplynulý čas a rezervu pro dokončení aktuálního požadavku. Náklady počítejte podle účtovaných kategorií a cen použitých služeb, včetně placených nástrojů. Jeden tokenový součet vynásobený jednou sazbou není univerzální účetní model.

U souběžných workerů rezervujte rozpočet atomicky. Jinak může několik běhů současně vidět stejný zbývající zůstatek a každý jej utratit. Po dosažení limitu další práci nezařazujte; uložte stav a konkrétní důvod eskalace. Rozběhnutá volání mohou ještě doběhnout, proto limit nenastavujte bez rezervy.

Obnovu testujte stejně jako kvalitu modelu. Opakovaný běh nesmí podruhé zaúčtovat fakturu ani odeslat zákazníkovi stejný e-mail. Zapisujte stabilní ID operace a před opakováním ověřte stav v cílovém systému.

Rozhodujte podle ověřeného výsledku

Porovnal bych chybovost, správné eskalace, počet lidských oprav, cenu úspěšně dokončeného případu a p95 času. Přidejte i zbytečné eskalace: levný model, který všechno předá člověku, práci jen přesunul.

Důležité jsou konkrétní chyby. Když vyšší effort odstraní přehlédnutou vazbu mezi fakturou a objednávkou, může se vyplatit. Pokud jen prodlouží zdůvodnění stejné kategorie supportu, do tohoto kroku jej nezavádějte.

Začněte omezenou frontou a měřitelným výsledkem. Effort dolaďuje práci modelu; rozpočet a provozní pravidla musí zároveň hlídat celý proces. Na návrh takové smyčky navazuje článek o loop engineeringu.