Skip to main content

Token Burn Rate

A critical engineering and financial metric for the rate of consumption of contextual and generative tokens (and dollars per hour) in agent-based development sessions, factoring in prompt caching.

1. Concept Overview & Systemic Problem

In conventional chatbots, token consumption is minimal: a single question and answer consume a few hundred tokens. However, in vibe coding and autonomous agent cycles (Cursor Composer, Claude Code, OpenHands), the dynamics of token consumption change radically. The agent loads project rules, codebase snippets via indexing, tool schemas, and terminal logs into context, sending 50,000–150,000 tokens at each iteration.

If the agent takes 25 steps to fix a bug, the total volume of input tokens can easily reach several million. If an engineer does not understand the metric Token Burn Rate, the project quickly faces financial shock: hundreds of dollars per day for a single workstation or hitting corporate API key limits in the middle of the workday.

2. Architectural Taxonomy & Mental Model

The structure of token costs in modern agent systems is divided into four unequal categories:

┌─────────────────────────────────────────────────────────────┐
│                 TOKEN BURN RATE COST BREAKDOWN              │
├─────────────────────────────────────────────────────────────┤
│ 1. Cached Input Tokens (Prompt Caching Hit) ➔ -90% cost     │
│    Static repository rules, base files, system prompt        │
├─────────────────────────────────────────────────────────────┤
│ 2. Fresh Input Tokens (Uncached Cache Miss) ➔ 100% cost     │
│    New files, terminal logs, fresh engineer messages         │
├─────────────────────────────────────────────────────────────┤
│ 3. Generation Tokens (Output / Code Blocks) ➔ 3-5x rate     │
│    Generated code, tool calls in JSON format                │
├─────────────────────────────────────────────────────────────┤
│ 4. Thinking / Reasoning Tokens (Extended CoT) ➔ Premium     │
│    Internal hidden reasoning of Claude 3.7 / o1 models      │
└─────────────────────────────────────────────────────────────┘
  1. Base Input Consumption (Context Ingestion):
    • The volume of context the model reads at each step. The longer the dialogue, the greater the weight of each subsequent request.
  2. Cached Context (Cached Prefix):
    • Tokens stored in the provider's GPU KV cache. They have reduced costs (e.g., $0.30 per 1M instead of $3.00 in Claude Sonnet) if the request prefix remains unchanged for several minutes.
  3. Output Tokens (Generation Tokens):
    • Code returned by the model. It is charged significantly more than input tokens (3–5 times) as it requires sequential autoregressive computation on the GPU.
  4. Thinking Tokens (Extended Thinking):
    • Internal reasoning chains of next-generation models. A complex task can generate 10,000 thinking tokens before the model writes the first line of code.

3. Technical Pipeline & Internal Mechanics

The lifecycle of monitoring and controlling Token Burn Rate:

  1. Pre-inference Token Counting: A local tokenizer (e.g., tiktoken or the provider's tokenization library) calculates the length of the formed prompt before sending.
  2. Limit Checking (Circuit Breaker & Guardrails): The system compares current expenditures with the established budget: if the current session exceeds the threshold of $5.00, a warning is sent to the engineer.
  3. Optimizing Prompt Structure for Cache Preservation: The architecture of the request is arranged so that static data (rules, tool manifests) comes first, while dynamic data (fresh terminal output) comes last. This prevents invalidating the provider's cache.
  4. Telemetry Retrieval Post-Response: Exact metrics are read from the API response headers: prompt_tokens, completion_tokens, cache_read_input_tokens, cache_creation_input_tokens.
  5. Current Burn Rate Calculation: The rate of expenditure ($/minute or $/task) is computed and displayed in the IDE or terminal status bar.

4. Production Engineering Scenarios

01. Architectural Structuring of Prompts for 90% Cache Discount Preservation

An engineer configures work with Claude 3.7 Sonnet:

  • Placing a dynamic timestamp or variable logs at the beginning of the system prompt causes the entire 100k context to be treated as new, burning $0.30 at each step.
  • By moving variable elements to the last block of the request, the engineer ensures a 95% cache hit, reducing the cost of a 20-step cycle from $6.00 to $0.80.

02. Corporate Gateway for Developer Budget Control

The company's CTO implements a proxy server (LiteLLM / Portkey):

  • Each engineer receives a personal daily limit of $15.
  • Upon reaching 80% of the limit, the developer receives a notification in Slack.
  • At 100%, the tool automatically switches non-critical tasks to ultra-cheap models (DeepSeek V3 or Claude Haiku).

03. Infinite Loop Detection

An autonomous agent gets caught in a cyclical attempt to install an incompatible library:

  • The Token Burn Rate detector notices that 8 requests have been sent in the last 3 minutes without any change in resulting code, burning 1.2M tokens.
  • The process is aborted, saving company funds.

5. Pitfalls, Common Mistakes & Security

  • Accidental Cache Prefix Invalidation: Adding random UUIDs or the current time at the beginning of the conversation invalidates the entire KV cache, increasing the financial bill by 10 times.
  • Invisible Overdraft on Thinking Models (Thinking Budget Overflow): If the max_thinking_tokens parameter is not limited, the model may reason for 30,000 tokens over a trivial change like renaming a button, burning funds without added value.
  • Leftover Background Sessions in Terminal: Running multiple CLI agents in different terminal tabs without monitoring can lead to unnoticed depletion of corporate balance if one of the processes hangs.
  • Incorrect Provider Notification Settings: Lack of configured hard limits in Anthropic or OpenAI dashboards creates a risk of unexpected charges of thousands of dollars from the linked credit card.
/ Frequently Asked QuestionsSchema.org FAQPage

FAQ: Token Burn Rate

At each step of the ReAct loop, the agent must resend the entire previous history of thoughts, file diffs, and compiler errors to the API. A 20-step session with an 80k context generates over 1.6 million input tokens in mere minutes.
/ Internal links
All terms