AI Agent Token Budget Management: Four Production Patterns

Most UK service businesses discover their AI agent costs the hard way: a workflow that costs £3 to run occasionally becomes a £90-per-day liability the moment a retry loop fires or a user triggers it twelve times in an hour. Token costs are not linear at agent scale — they compound with every tool call, every context window reload, every sub-agent spawn. The firms keeping their AI operating systems profitable in production are not the ones with the cheapest models. They are the ones with token budget engineering built into the stack.

Why Agent Token Costs Are Not Like API Costs

A standard API call has predictable cost: input tokens plus output tokens, one request at a time. An AI agent is different. A single user request can trigger four to twelve tool calls, each with its own input context. Every step in a multi-step workflow reloads the full conversation history into the context window. A retry loop at step three does not cost three extra tokens — it costs the entire context window times the number of retries.

LangChain's 2026 State of Agent Engineering report found that teams switching from single-call LLM use to multi-step agents see average per-task token consumption increase by 4x to 11x, depending on workflow complexity. That multiplier is not a failure — it is the cost of genuine task completion. But without controls, it scales with every user, every retry, and every edge case your workflow encounters.

Three specific patterns drive unexpected cost spikes in production:

• Context accumulation. An agent that passes the full message history to each tool call consumes 2x to 4x more tokens per step than one that passes compressed summaries. The context engineering post covers the compression patterns in detail — but the budget layer is what enforces them under load.
• Retry amplification. A tool that returns a 429 or a timeout and triggers an automatic retry does not just cost one extra call — it costs one extra call at full context width. Three retries on a long-context workflow can cost more than the original ten successful steps.
• Sub-agent spawning. Multi-agent architectures are powerful. They are also the fastest way to multiply token costs by the number of agents you spawn. Without per-agent budgets, a planner that spawns eight executor agents passes costs through to production unbounded.

The firms with profitable AI operating systems are not running cheaper models. They are running the same models with token budget engineering that prevents runaway costs before they reach the invoice.

Pattern One: Per-Agent Budget Caps with Graceful Degradation

The most important control is a per-run token budget: a maximum number of tokens an individual agent execution is allowed to consume before it wraps up with whatever it has.

Anthropic's Claude API supports this natively via the budget_tokens parameter in extended thinking, but for general agent budget control, the pattern is implemented at the orchestration layer. In n8n, a global variable passed through the workflow tracks cumulative token count. Each LLM node adds its input and output tokens to the running total. When the total approaches 80% of the budget, the workflow switches to a summarisation mode: rather than continuing to work, the agent produces a structured partial result with a flag indicating budget near-limit. At 100%, it returns what it has with a graceful handoff prompt rather than a hard error.

The key design decision is graceful degradation, not hard failure. An agent that crashes at budget limit gives your client an error. An agent that returns partial work with a clear status — "here is what I completed within processing limits, three items require follow-up" — gives your client a useful output and a clear signal. For UK service businesses, a partial result that clearly explains its limits is almost always preferable to a silent failure or an error message.

For a practical implementation: set your per-run budget at three times your median successful run cost for that agent type. The median successful run cost is easily read from Langfuse or whatever observability tool you are using. Three times that median covers the 95th percentile of legitimate usage while catching the runaway 1% before it inflates the invoice.

Pattern Two: Retry Budgets Separate from Token Budgets

Retry logic is standard engineering practice. The risk with AI agents is that retries are not just retries — each one consumes a full context window worth of tokens. A tool call that fails and retries three times before succeeding has consumed four times its expected token cost, even though the final result was correct.

The engineering fix is a retry budget that is tracked separately from the token budget and depletes faster. A workflow with a token budget of 50,000 tokens might have a retry budget of two per tool call and a total of five retries across the run. When either budget is exhausted, the fallback is not to try again — it is to flag the failed step, return the partial result, and log the failure for your Layer 4 test set (see the CI/CD post for how the production feedback loop works).

For Anthropic's Claude API, when you receive a rate_limit_error response with a Retry-After header, your retry logic should respect the header exactly and decrement the retry budget by one. Do not implement a fixed retry interval — fixed intervals compound under load. The exponential backoff pattern works for occasional failures; for systematic rate limit errors, the Retry-After header is the authoritative signal.

The fault tolerance post covers the full circuit breaker and retry logic implementation. The addition here is tracking retries against a finite budget rather than treating retry attempts as free.

Pattern Three: Token-Aware Model Routing

Not every step in an agent workflow needs a frontier model. Classification, extraction, formatting, and simple summarisation can be handled by a smaller, cheaper model at a fraction of the token cost and with comparable quality for those specific task types.

The planner-executor post covered the architectural pattern. The budget dimension adds a routing rule based on task complexity score: steps that score below a complexity threshold — measured by number of distinct entities, required reasoning steps, and instruction ambiguity — are routed to a smaller model. Steps that score above it use the frontier model.

In practice, for a UK service business AI operating system, this means:

• Email classification → smaller model (claude-haiku-5-5 or equivalent)
• CRM data extraction from a document → smaller model with structured output
• Proposal drafting, complex document analysis, nuanced client communication → frontier model
• Final quality check on a high-stakes output → frontier model, once only

Teams implementing this pattern consistently report 60 to 70% reduction in token spend on full workflows, with no measurable quality degradation on tasks routed to smaller models. The key is having a reliable complexity classifier — which itself should be a fast, cheap heuristic (keyword count, entity count, instruction word count) rather than an LLM call, to avoid spending tokens on deciding where to spend tokens.

Pattern Four: Cost Attribution per Workflow and Client

Budget caps prevent runaway costs. Attribution reveals where costs are going — and that visibility is what turns token cost management from reactive firefighting into proactive system design.

The attribution pattern is simple: every agent run is tagged with three dimensions — workflow ID, client ID, and agent type. These tags are passed in the metadata of every LLM API call and logged to your observability layer alongside token counts. In Langfuse, these become filterable session properties. In a spreadsheet export from your observability tool, they become the basis for a per-client cost breakdown.

Why does this matter for UK service businesses specifically? Three reasons:

1. Chargebacks. If you are building AI workflows for clients, token costs should be part of your service pricing. Attribution data shows you exactly what each client's workflow costs to run monthly — the foundation for usage-based pricing or client-specific budget controls.
2. Identifying runaway agents. When a specific workflow is consuming 40% of your monthly token budget, you need to see that in a dashboard, not in an invoice. Attribution makes the outlier visible before it becomes a financial surprise.
3. Build order decisions. The capability stack post covered which agents to build first. Attribution data from running agents tells you which workflows have the highest cost-per-run and whether the business value justifies that cost — the data your next build decision should be based on.

A One-Day Budget Engineering Sprint

For a UK service business running two to five agents in production, a working token budget layer can be implemented in a focused day:

1. Morning: Add token logging to every LLM call in your n8n workflows. Pass the response's usage object to a Set node and accumulate it in a workflow-level variable. This takes 30 minutes and gives you visibility you do not currently have.
2. Mid-morning: Set per-run budget thresholds — 80% soft limit triggers graceful wrap-up, 100% returns partial result with status flag. Two hours to implement across your workflows.
3. Afternoon: Implement a separate retry counter. When a tool returns a 429 or timeout, decrement the retry budget, log the failure, and — on the third failure — route to graceful partial completion rather than trying again.
4. End of day: Tag every LLM call with workflow ID and client ID and push those tags to Langfuse. Create a saved view in Langfuse filtered by client ID showing weekly token cost. That view is your attribution dashboard.

The model routing optimisation is a separate sprint — get the visibility and controls in place first, then identify which steps are candidates for routing to cheaper models based on real usage data.

The businesses building AI operating systems that compound in value are engineering the cost layer the same way they engineer the quality layer: systematically, with observable metrics and clear controls. Token budget management is not the most exciting part of agent engineering. It is the part that determines whether your AI operating system stays profitable at scale.

If you want help designing the cost and budget layer for your AI operating system — whether that is token routing, attribution dashboards, or per-client budget controls — book a free 30-minute call with the Quantum Flow team. We build AI operating systems for UK service businesses, and the firms we work with treat cost engineering as a first-class concern from day one.