I thought a cheaper model would fix my agent bill, then I found the 34k-character system prompt

I’ve seen this same debugging pattern too many times now.

Agent costs spike. Everyone blames the model. Someone says, “Move from Claude Opus to Claude Sonnet.” Someone else says, “Cap the context window.” Then the team spends two days arguing about whether GPT-5 is worth it.

Sometimes that helps.

But a lot of the time, the real problem is way less glamorous: nobody knows what actually happened inside the run.

That’s why I think agent tracing matters more than model shopping.

One OpenClaw debugging case made this painfully obvious. Preflight estimated 10,698 prompt tokens and overflowed. Compaction then reported 0 messages to summarize. The run kept failing anyway.

That is not a pricing problem.

That is an observability problem.

The bill is scary. The mystery is worse.

If all you have is a final token total, you’re basically debugging from a receipt.

But an agent run is not one prompt.

It’s usually some combination of:

• system prompt injection
• conversation history
• tool schemas
• retrieved docs
• browser output
• exec output
• retries
• summarization
• memory writes
• the final LLM call

If you can’t see those as separate steps, you’re guessing.

And guessing is how teams end up “optimizing” the model while the real cost driver is a bloated context assembly pipeline.

The OpenClaw case that changed how I think about agent spend

I came across a thread on r/openclaw where a user said:

It started doing insane looping and used up a bunch of credit.

That sentence is basically the shared trauma of agent engineering in 2026.

The interesting follow-up was a separate OpenClaw debug thread where the logs showed this:

• Compacting context (0 messages)...
• Auto-compaction could not recover this turn.

And then the numbers:

• systemPromptChars=34,549
• estimatedPromptTokens=10,698
• contextTokenBudget=40,960
• reserveTokens=32,960
• promptBudgetBeforeReserve=8,000
• overflowTokens=2,698
• historyTextChars=0

That mismatch is the whole story.

Preflight saw a giant prompt and said, “we’re over budget.”

Compaction looked at conversation history only, saw zero messages to summarize, and said, “nothing to do here.”

So you had two subsystems looking at different slices of the same request.

That’s exactly why end-to-end tracing matters.

This is what “hidden context cost” looks like

The most useful part of OpenClaw’s docs is that they make the overhead visible.

Here’s the kind of context breakdown they show:

• system prompt: 38,412 chars (~9,603 tokens)
• project context: 23,901 chars (~5,976 tokens)
• tool schemas: 31,988 chars (~7,997 tokens)
• browser schema: ~2,453 tokens
• exec schema: ~1,560 tokens
• session tokens cached: 14,250 / ctx=32,000

This is why “the model is expensive” is often the wrong diagnosis.

Sometimes the expensive thing is not Claude Opus, GPT-5, or Grok.

Sometimes it’s your own baggage:

• giant system prompts
• too many tools
• verbose tool schemas
• injected files the agent barely needs
• browser dumps that never get trimmed
• retry loops that keep replaying all of the above

Compaction is useful, but it won’t save a bad context strategy

A lot of teams treat compaction like a magic cleanup button.

It isn’t.

OpenClaw separates compaction from session pruning.

Compaction summarizes older conversation turns. Pruning trims old tool results from active memory.

That helps when the problem is chat history growth.

It does not help much when the real problem is:

• a 34k-character system prompt
• 8k tokens of tool schema
• unnecessary workspace injection
• browser and exec tools dumping huge outputs every turn

If compaction only sees message history, it can’t shrink what it never touched.

First thing I would run in OpenClaw

If you suspect hidden context bloat, these are the commands I’d start with:

/status
/context list
/context detail
/context map
/usage tokens
/compact

That gives you a fast way to inspect what’s actually being included.

If you want to change the compaction model, you can do that too:

{
  "agents": {
    "defaults": {
      "compaction": {
        "model": "openrouter/anthropic/claude-sonnet-4-6"
      }
    }
  }
}

Useful? Yes.

A full explanation of where the spend came from? No.

For that, you need tracing.

Trace the run, not just the model call

My opinion: the right unit of analysis for agents is one request with nested spans.

Not one prompt.

That means tracing:

• context assembly
• retrieval steps
• tool calls
• tool outputs
• retries
• summarization
• downstream LLM calls
• final response generation

If the agent loops, you want to know:

1. what caused the first retry
2. what got replayed on each retry
3. which step exploded token usage
4. whether the expensive part was actually the model call at all

That’s where tools like LangSmith, Helicone, and OpenTelemetry-style tracing become useful.

Practical observability options

Option	What it’s good for
OpenClaw built-in inspection	Fast inspection of context contributors like system prompts, files, skills, tool schemas, and token usage. Good for local debugging. Not full end-to-end tracing.
LangSmith observability	Full traces with nested spans across LLM calls, tools, and higher-level functions. Best when you need to debug multi-step agent workflows.
Helicone gateway/observability	Good gateway-style visibility across OpenAI, Anthropic, OpenRouter, and others with logging, retries, caching, and request metadata.

If you want a quick LangSmith setup, it’s straightforward:

export LANGSMITH_TRACING=true
export LANGSMITH_API_KEY="<your-langsmith-api-key>"
export OPENAI_API_KEY="<your-openai-api-key>"

Then wrap your model client and your tool functions so one agent run shows up as one trace tree.

That’s when debugging gets a lot less philosophical.

What to fix after tracing

Tracing won’t reduce cost by itself.

It just tells you where to cut.

The fixes are usually boring, which is probably why they work.

1. Shrink the system prompt

If your system prompt is 34,549 or 38,412 characters, start there.

That is a huge tax on every single turn.

2. Cut tool schema bloat

Tool schemas are easy to ignore because they feel like infrastructure.

They still cost tokens.

If browser schema is ~2,453 tokens and exec schema is ~1,560 tokens, that overhead adds up fast.

3. Inject fewer files and skills

Don’t give the agent 15 capabilities if the task needs 3.

Context should be assembled per task, not by habit.

4. Prune tool output aggressively

Browser content and shell output are repeat offenders.

If you keep replaying giant results back into the next turn, your context window will disappear fast.

5. Kill retry loops early

If a tool is failing or the agent is stuck, unlimited retries are not resilience.

They are a billing strategy, just a bad one.

A hard turn limit is often the simplest protection.

The model still matters. It’s just not the first question.

I’m not saying model pricing is irrelevant.

It matters a lot.

Claude Opus 4.6, Claude Sonnet 4.6, GPT-5, Grok 4.20, Qwen, and Llama all have different cost/performance tradeoffs.

And yes, cheaper models can absolutely reduce spend.

But if your workflow is replaying a giant system prompt, huge tool schemas, and stale context on every retry, switching models is just making the same bug slightly cheaper.

That’s not optimization. That’s damage control.

Why this matters even more for automation teams

If you’re running agents inside n8n, Make, Zapier, OpenClaw, or a custom automation stack, the problem gets worse because the agent isn’t isolated.

It’s part of a workflow.

So one bad loop can trigger:

• repeated tool calls
• repeated API requests
• repeated LLM calls
• repeated browser sessions
• repeated summarization

That’s exactly why per-token pricing gets painful at scale.

You’re not just paying for one clever answer.

You’re paying for every invisible retry, every oversized prompt, and every step your pipeline replays.

That’s also why I think flat-rate AI infrastructure is becoming more attractive for teams running real automations. If your agents run all day, predictable pricing is a relief.

Standard Compute is interesting here because it gives you an OpenAI-compatible API with flat monthly pricing instead of per-token billing. So if your team is already using OpenAI SDKs or wiring models into n8n/Make/Zapier/custom agents, you can swap the endpoint without rebuilding everything.

That does not replace tracing.

But it does remove a lot of the token anxiety while you fix the actual workflow problems.

And honestly, that combination is what most teams want:

• visibility into what the agent is doing
• predictable cost while it runs

My practical rule now

Before changing models:

• inspect context assembly
• trace tool calls
• trace retries
• measure schema overhead
• find the span that exploded

Then decide whether the model is actually the problem.

Because a surprising number of “LLM cost problems” are really:

• context assembly problems
• retry policy problems
• tool design problems
• observability problems

The OpenClaw example is memorable because the numbers are so absurd.

A 34k-character system prompt was enough to push preflight over budget, while compaction saw 0 messages and had nothing to summarize.

If you only looked at the final bill, you’d probably blame the model.

If you traced the run, you’d know exactly where to start.

That’s the difference.

And once you can see the sequence, runaway agent costs stop feeling random.