Effort a task budgets v Claude: ako riadiť kvalitu a náklady agentov

Najdrahšie nastavenie modelu nie je automaticky najlepším nastavením workflow. Pri triedení podpory potrebujete správnu kategóriu a rýchlu odpoveď. Pri spornej faktúre potrebujete dohľadať dôkazy. V oboch prípadoch potrebujete vedieť, kedy sa práca zastaví a kto prevezme výnimku.

Aktualizácia 6. októbra 2026: opravujem pôvodné tvrdenie o garantovanom finančnom strope. Task budget takúto záruku neposkytuje. Predchádzajúce klientské príklady s konkrétnymi úsporami nemám doložené, preto ich nepoužívam ako dôkaz.

Podnetom je video AI s rozumem z 5. októbra o intenzite premýšľania. Popis uvádza vlastné testy autora; ich výsledky tu nepreberám ako nezávisle overený benchmark.

Tri ovládače, tri rôzne úlohy

Podľa dokumentácie effort parameter ovplyvňuje množstvo práce modelu vrátane odpovedí a nástrojov. Nejde o pevný tokenový limit. Dostupné úrovne závisia od modelu. Vyššie nastavenia preto testujte, nepovažujte ich za záruku kvality.

Task budget je orientačný rozpočet agentnej slučky; model ho môže prekročiť. max_tokens obmedzuje generované tokeny jednej požiadavky. Aktuálna beta používa output_config.task_budget a hlavičku task-budgets-2026-03-13, nie pôvodne uvedené task_budget_tokens. Podporu modelu overte v dokumentácii.

Celkový prevádzkový limit by som vynucoval mimo modelu. Plánovač musí rozhodnúť, či ďalšia požiadavka vôbec vznikne. Aj séria jednotlivo obmedzených volaní sa môže predražiť.

Pilot na faktúrach: najprv pravidlá, potom ďalšie premýšľanie

Pre n8n alebo Make by som začal dávkou 60 anonymizovaných dokladov. Ide o návrh pilotu, nie o vykonaný test. Zaraďte bežné faktúry, chýbajúce objednávky, nesúhlasiace súčty, duplicity aj nečitateľné položky.

1. Vopred určte správny výsledok a podklad, ktorý ho potvrdzuje. Pri neriešiteľných prípadoch má byť správnym výsledkom eskalácia.
2. Zachovajte rovnaký model, prompt, nástroje a vstupy. Meňte iba effort v úrovniach podporovaných modelom.
3. Identitu dokumentu, povinné polia a súčty kontrolujte kódom. Ďalšie premýšľanie nenahradí chýbajúcu objednávku.
4. Vyšší effort prideľte prípadom, kde podklady existujú, ale ich vyhodnotenie je náročné.
5. Zmenu nasaďte až po kontrole chýb a ceny dokončenej, overenej úlohy.

Výstup „neviem, chýba objednávka“ môže byť správnejší než dlhé presvedčivé vysvetlenie. Chýbajúce obchodné pravidlo doplňte do zadania; nečakajte, že ho vyšší effort vymyslí za vás.

Čo má kontrolovať orchestrátor

Pred ďalším krokom by som overil spotrebu, počet pokusov, uplynulý čas a rezervu na nasledujúcu požiadavku. Náklady počítajte podľa účtovaných kategórií a cien použitých služieb vrátane platených nástrojov. Jeden tokenový súčet vynásobený jednou sadzbou nie je univerzálny účtovný model.

Súbežní workeri potrebujú atómovú rezerváciu rozpočtu. Inak môže viac behov naraz vidieť rovnaký zostatok a každý ho minúť. Po dosiahnutí limitu ďalšiu prácu nezaraďujte; uložte stav a konkrétny dôvod eskalácie. Rozbehnuté volania môžu ešte dobehnúť, preto nechajte rezervu.

Obnovu testujte rovnako ako kvalitu modelu. Opakovaný beh nesmie druhýkrát zaúčtovať faktúru ani odoslať rovnaký e-mail. Zaznamenávajte stabilné ID operácie a pred opakovaním neistého zápisu overte stav v cieľovom systéme.

Rozhodujte podľa overeného výsledku

Porovnal by som chybovosť, správne eskalácie, počet ľudských opráv, cenu úspešne dokončeného prípadu a p95 času. Sledujte aj zbytočné eskalácie: lacný model, ktorý všetko odovzdá človeku, prácu iba presunul.

Rozhodujú konkrétne chyby. Ak vyšší effort odhalí prehliadnutú väzbu medzi faktúrou a objednávkou, môže sa oplatiť. Ak iba predĺži vysvetlenie rovnakej kategórie podpory, do tohto kroku ho nezavádzajte.

Začnite obmedzeným radom úloh a merateľným výsledkom. Effort dolaďuje prácu modelu; rozpočet a prevádzkové pravidlá musia strážiť celý proces. Na návrh takejto slučky nadväzuje článok o loop engineeringu.