Claude effort and task budgets: controlling agent quality and cost

The most expensive model setting is not automatically the best workflow setting. Support classification needs the right category quickly. A disputed invoice needs supporting evidence. Both need a stopping rule and someone responsible for exceptions.

Updated October 6, 2026: this revision corrects the original claim of a guaranteed spending ceiling. Task budgets provide no such guarantee. The earlier client examples and savings figures are not substantiated here and have been removed as evidence.

The prompt for this update was AI s rozumem’s October 5 video on reasoning effort. Its description refers to the creator’s own tests; this article does not treat them as an independently verified benchmark.

Three controls with different jobs

The effort documentation describes a control over model work, including responses and tool use. It is not a fixed token allowance. Supported levels depend on the model. Test higher settings rather than treating them as quality guarantees.

A task budget advises the model how much work to spend across an agent loop; it can be exceeded. max_tokens caps generated tokens per request. The current beta uses output_config.task_budget with the task-budgets-2026-03-13 header, replacing the incorrect task_budget_tokens example previously shown here. Check model compatibility in the documentation.

I would enforce the overall operating limit outside the model. The scheduler must decide whether another request may start. A sequence of individually bounded calls can still become expensive.

An invoice pilot: validation before more reasoning

For n8n or Make, I would begin with 60 anonymized documents. This is a proposed pilot, not a completed experiment. Include ordinary invoices, missing purchase orders, incorrect totals, duplicates and unreadable fields.

1. Label the correct outcome and its supporting evidence beforehand. Escalation should be the right answer for cases that cannot be resolved.
2. Keep the model, prompt, tools and inputs fixed. Change only effort, using levels supported by that model.
3. Validate document identity, required fields and totals in code. More reasoning cannot replace a missing purchase order.
4. Reserve higher effort for cases where the evidence exists but interpreting it is difficult.
5. Roll out a change only after checking errors and the cost of a completed, verified task.

“I cannot determine this without the purchase order” may be better than a long, convincing explanation. Put missing business rules into the specification; do not expect a higher effort setting to invent them.

What the orchestrator should enforce

Before each new step, I would check spend, attempts, elapsed time and the reserve needed for the next request. Calculate cost from billed categories and the prices of the services used, including paid tools. Multiplying one combined token count by one rate is not a universal accounting method.

Concurrent workers need atomic budget reservations. Otherwise several runs can see the same balance and each spend it. Once the limit is reached, stop admitting work, save a checkpoint and record why a human is needed. In-flight requests may still finish, so leave headroom.

Test recovery as carefully as model quality. A retry must not book the invoice twice or send the same customer email again. Record a stable operation ID and inspect the destination system before repeating an uncertain write.

Choose using verified outcomes

I would compare errors, appropriate escalations, human corrections, cost per successful case and p95 completion time. Count unnecessary escalations too: a cheap model that hands everything to a person has merely moved the work.

Look at specific failures. Higher effort may be worthwhile if it catches a missed relationship between an invoice and an order. If it only adds explanation to the same support category, leave it out of that step.

Start with a limited queue and a measurable result. Effort tunes the model’s work; budgets and operating rules must govern the whole process. The loop engineering article explains that surrounding structure.