I Measured How Much Each Agent Design Decision Costs in Tokens (The Numbers Make Me Uncomfortable)

I spent six months building agents convinced that the biggest cost was the model itself. I focused on picking the right model, optimizing how many times I called it, caching responses. All of that matters. But I was missing half the problem.

The real spend was in decisions I made before the first inference. The prompt architecture. How I structured tool calls. Whether I accumulated context or summarized it. Those decisions — each one made in about ten minutes — have been costing me tokens every single day. And I had no idea until I actually sat down and measured properly.

This isn't a lab benchmark. These are my agents, running in production, with real numbers.

Tokenizer Costs in Agents: The Problem You're Not Looking At

When I wrote about CodeBurn and the real cost analysis per task, I focused on how many tokens each task burns. That was the obvious question. But there's a prior question I barely touched: how many tokens does each design decision I made while building the agent actually weigh?

These are different questions. The first is operational. The second is architectural. And the second is harder to see because the cost is distributed — you don't pay it once, you pay it on every single call, forever.

The HN discussion about Claude 4.7 tokenizer costs frames this in the abstract. I want to frame it concretely, with the three vectors that hit me hardest when I measured them:

1. Long prompt vs short prompt — how much verbosity in the system prompt actually costs
2. Tool calls vs plain text — the real overhead of tool JSON schemas
3. Accumulated context vs summarized context — the compounding effect that destroys you in long conversations

The Real Numbers: Long Prompt vs Short Prompt

I have an agent that curates technical information — the same problem I described when I built the self-regulating curation system. The original system prompt was 847 tokens. I wrote it thinking I needed to be exhaustive: formatting rules, output examples, edge cases, fallback instructions.

I rewrote it at 180 tokens. Same functionality. I tested with 50 different tasks. Output quality dropped in... zero measurable cases. Literally none.

The savings:

// Real measurement with tiktoken for Claude
import Anthropic from '@anthropic-ai/sdk';

// Function to estimate tokens before sending
async function estimatePromptCost(client: Anthropic, systemPrompt: string, userMessage: string) {
  // Using Anthropic's token counting endpoint
  const response = await client.messages.countTokens({
    model: 'claude-opus-4-5',
    system: systemPrompt,
    messages: [{ role: 'user', content: userMessage }]
  });
  
  return response.input_tokens;
}

// Verbose system prompt — original version
const verbosePrompt = `You are a technical curation agent.
Your goal is to evaluate technical resources and determine if they are relevant.
When you receive a resource:
1. Analyze the title
2. Analyze the description
3. Verify the source
4. Consider the date
5. Determine relevance on a scale of 1-10
Response format: JSON with fields score, reason, tags.
If the score is below 6, discard the resource.
If the score is above 8, mark it as priority.
Expected output example:
{ "score": 7, "reason": "Relevant but not urgent", "tags": ["typescript", "performance"], "priority": false }
Do not include additional explanations outside the JSON.`;
// Result: 156 tokens for the system prompt alone

// Concise system prompt — optimized version
const concisePrompt = `Evaluate technical resources. Respond with JSON: {score:1-10, reason:string, tags:string[], priority:bool}. Priority=true if score>8.`;
// Result: 32 tokens

// Difference: 124 tokens per call
// At 1000 calls/day: 124,000 extra input tokens
// With Claude Opus at $15/MTok: ~$1.86/day, ~$55/month
// For a system prompt I could have written better from the start

$55 a month. For a prompt I wrote sloppily. This is exactly what I mean when I talk about real scarcity with frontier models — the cost isn't just the model, it's everything wrapped around it.

The Tool Call Overhead: The Number I Didn't See Coming

This is where the numbers genuinely made me uncomfortable.

A tool call in Claude isn't free. The JSON schema of every tool you define gets tokenized and sent on every call, whether you use it or not. I measured this on the agent I mentioned in the SPICE and Claude Code post — that agent has access to 8 tools.

// Comparison: same agent with and without defined tools

// Config WITH tools (8 tools)
const configWithTools = {
  model: 'claude-opus-4-5',
  max_tokens: 1024,
  tools: [
    {
      name: 'read_file',
      description: 'Reads the content of a file from the filesystem',
      input_schema: {
        type: 'object',
        properties: {
          path: { type: 'string', description: 'Absolute path to the file' }
        },
        required: ['path']
      }
    },
    // ... 7 more tools with similar schemas
  ],
  messages: [{ role: 'user', content: userMessage }]
};
// Measured input tokens: 847 (with a simple 12-token user message)
// Tools schemas alone: ~835 tokens of overhead

// Config WITHOUT tools — plain text
const configWithoutTools = {
  model: 'claude-opus-4-5',
  max_tokens: 1024,
  messages: [
    { 
      role: 'user', 
      content: `${userMessage}\n\nTo read files, respond with: READ_FILE:<path>` 
    }
  ]
};
// Measured input tokens: 28
// Difference: 819 tokens per call

// When is the tool overhead actually worth it?
// If the agent will use tools on >60% of calls: formal tools
// If the agent rarely uses them: plain text parsing
// If you need reliable structured output: formal tools, always

819 tokens of overhead just from defining 8 tools. On an agent that calls the model 500 times a day, that's 409,500 extra input tokens. Every day. Before the agent has actually done anything.

The solution isn't to eliminate tools. It's to be selective about which tools you expose in each context. If 70% of your flows only need 2 of the 8 tools, create a client with just those 2 for that flow. Overhead drops from 835 to ~200 tokens.

This also matters when you're running inference at the edge — if you're using Cloudflare as an inference layer for your agents, multiply this overhead by every worker you spin up. Latency and cost scale together.

The Compounding Effect: Accumulated Context vs Summarized Context

This one is the most treacherous because it's incremental. You don't see it until it's already eaten you alive.

I measured a 20-turn technical support conversation with an agent that accumulates full context:

// Strategy 1: Full context accumulation
// Every new message gets added to the entire history

class FullContextAgent {
  private messages: Array<{role: string, content: string}> = [];
  
  async respond(userInput: string): Promise<string> {
    this.messages.push({ role: 'user', content: userInput });
    
    const response = await client.messages.create({
      model: 'claude-opus-4-5',
      max_tokens: 1024,
      messages: this.messages
    });
    
    const assistantMessage = response.content[0].text;
    this.messages.push({ role: 'assistant', content: assistantMessage });
    
    // Input tokens at turn 20: ~18,400 tokens
    // Total accumulated tokens over 20 turns: ~127,000 tokens
    return assistantMessage;
  }
}

// Strategy 2: Sliding window with summarization
class SummarizedContextAgent {
  private summary: string = '';
  private recentMessages: Array<{role: string, content: string}> = [];
  private readonly WINDOW = 4; // last 4 turns
  
  async respond(userInput: string): Promise<string> {
    this.recentMessages.push({ role: 'user', content: userInput });
    
    // If we exceed the window, summarize the oldest messages
    if (this.recentMessages.length > this.WINDOW * 2) {
      const toSummarize = this.recentMessages.splice(0, 4);
      this.summary = await this.summarize(this.summary, toSummarize);
    }
    
    const messagesWithContext = [
      ...(this.summary ? [{ role: 'user', content: `Previous context: ${this.summary}` }] : []),
      { role: 'assistant', content: 'Understood.' },
      ...this.recentMessages
    ];
    
    const response = await client.messages.create({
      model: 'claude-opus-4-5',
      max_tokens: 1024,
      messages: messagesWithContext
    });
    
    // Input tokens at turn 20: ~2,100 tokens (constant)
    // Total tokens over 20 turns: ~42,000 tokens
    // Savings vs full accumulation: ~85,000 tokens
    
    const assistantMessage = response.content[0].text;
    this.recentMessages.push({ role: 'assistant', content: assistantMessage });
    return assistantMessage;
  }
  
  private async summarize(currentSummary: string, messages: Array<{role: string, content: string}>): Promise<string> {
    // Separate, cheap call to compress context
    const response = await client.messages.create({
      model: 'claude-haiku-4-5', // cheaper model for summarization
      max_tokens: 256,
      messages: [{
        role: 'user',
        content: `Summarize in 2 sentences: ${currentSummary}\n${JSON.stringify(messages)}`
      }]
    });
    return response.content[0].text;
  }
}

Over 20 turns: 127,000 tokens with full accumulation vs 42,000 with sliding window summarization. 67% less. And the response quality on the tasks I tested was indistinguishable — the summarized agent didn't lose relevant information because the summary captures what actually matters.

Common Mistakes When Measuring Tokenizer Costs in Agents

Not measuring tool overhead in the full flow. A lot of people measure output cost but ignore that tool schemas count as input on every single call. Always measure total input, not just the user message.

Assuming more context = better response. On bounded tasks (classify, extract, evaluate), the model doesn't need the last 15 turns of conversation. Test with short windows before assuming you need everything.

Optimizing for latency but not cost (or vice versa). Reducing input tokens lowers cost but can also lower latency. These are aligned goals. If you're paying for edge latency, this matters twice over.

Not separating summarization cost from main agent cost. If you're summarizing with Haiku to feed Opus, that Haiku cost exists. It's small, but it exists. Count it.

Not versioning your system prompts. I changed my prompt from 847 to 180 tokens and didn't save the previous cost. Now I log version, token count, and date for every change. If something breaks silently after optimizing, you can roll back with context.

FAQ: Tokenizer Costs in Agents — Real Questions

How many tokens does a tool schema average in Claude? Depends on schema complexity. A simple tool with 2 parameters runs 80-120 tokens. One with nested schemas and detailed descriptions can hit 300-400 tokens. With 8 complex tools, you can easily blow past 1500 tokens of overhead before the user has typed a single character.

Is it worth using cheaper models to summarize context? Yes, with one condition: the summary is for the agent's consumption, not the user's. Haiku is excellent for compressing context before passing it to Opus. The cost of summarizing with Haiku is 10-15x cheaper than passing the full context to Opus. Mathematically it always wins if the conversation goes past 6-8 turns.

How do I know if my system prompt is too long? Prima facie: if you wrote more than 500 tokens in the system prompt, justify every section. Run this test: remove a paragraph, run 20 real tasks, see if the output changed. If it didn't, the paragraph wasn't necessary. Repeat until something starts breaking. That gives you the real minimum viable prompt.

Does Anthropic's prompt caching change this equation? It changes the cost, not the overhead. With prompt caching, cached tokens (usually the system prompt) get charged at 10% after the first hit. That lowers the cost of having a long prompt, but doesn't eliminate it. And caching doesn't apply to user messages or conversation context — which is exactly where the accumulation problem lives.

How much does response format (JSON vs text) impact output cost? Structured JSON tends to be more token-compact than explanatory prose for the same content, especially if the model doesn't add unnecessary filler. But if you force JSON without formal tools, the model might wrap it in markdown or add introductory text that inflates the output. Formal tool calls give you more predictable and generally more compact output.

Is there an optimal context window size for support agents? From what I've measured: 4-6 recent turns plus a 100-150 token summary captures 90% of the relevant information for support tasks. For agents doing complex multi-step reasoning (like the one I described in the SPICE post), you need more — the context from the previous step is sometimes technical input for the next one. There's no universal number, but 4 turns is a solid starting point to validate before going to larger windows.

What I'd Do Differently If I Started Over

I'd measure before writing the first prompt. Not after the agent is already in production.

The correct sequence is: define the minimum viable task, write the minimum prompt that solves it, measure the tokens, evaluate quality, expand only if quality fails. I did it backwards — wrote first, measured later, and discovered I'd been overpaying for months.

I'd also separate agents by tool complexity much earlier. Not every flow needs all 8 tools. The overhead of exposing tools that never get used is pure waste.

The uncomfortable lesson here is that most tokenizer costs in agents don't come from the model — they come from design decisions you made before the first call. They're avoidable. And they're cumulative.

If you're building agents and you don't have an exact token count for each architectural decision, you don't actually know what you're building is costing you. I didn't either. Now I do, and I don't love everything I see — but at least I can change it.