I was using OpenClaw to run a daily blog pipeline. One session handled the path from seed to research to outline to draft to review. The output looked fine, but the bill did not.
My first assumption was that I had picked the wrong model. After tracing the run step by step, I realized the workflow around the model was the real problem.
Most of the bill came from repeated context, retries, oversized tool payloads, and a session that carried too much history.
The problem showed up in one specific workflow
This was one concrete pipeline.
The important detail was that the agent did all five stages inside one long-lived OpenClaw session.
That looked efficient on the surface, but the session kept dragging old history forward, retries resent large prompts, and tool calls pulled in more text than the model needed. None of that was visible in the final post. It only showed up in the bill.
That is the first lesson I would keep. Do not start by asking whether the model is too expensive. Start by asking what your workflow keeps making the model reread.
The fastest diagnostic was the input-to-output ratio
The first number I check now is input versus output.
In this pipeline, output quality looked stable after I fixed some compaction pressure, but cost still went up. The input-to-output ratio jumped to 3.49:1.
That number told me the system was paying too much to set up turns compared with what it produced.
The gateway logs made the cause clear. Two turns hit the 120 second timeout. Two more got retried because the assistant narrated an action instead of taking it. Another tool loop failed mid-flight and retried. Every rerun resent the full prompt.
That left me with two useful rules. Track input-to-output ratio early. When it spikes, look for setup waste before you touch model quality. Also count retries by cause. A timeout, a bad tool loop, and a planning-only retry are different problems.
Most of the waste came from five mistakes in the pipeline
Once I knew the waste was structural, the causes were not hard to find.
1. I rebuilt context too often
My earliest OpenClaw baseline had contextInjection configured in a way that effectively re-injected bootstrap context on every user message. The workspace rules, skill guidance, and setup text kept coming back into the prompt instead of staying stable across turns.
The effect was ugly. Bootstraps per user message sat around 1.04. Cache invalidation stayed high because fresh markers kept changing the prefix. I was paying the model to reread rules it already had.
2. I exposed more tool data than the model needed
This is the hidden token tax of tools. Tool schemas are prompt text, and tool results are prompt text too.
In my pipeline, some waste came from reading full notes when only one section mattered. Thirty read_note calls in one measured pass averaged around 11K characters each. That is manageable once. It gets expensive when the same workflow retries and drags that text back in.
3. The workflow retried for behavioral reasons
One of the strangest leaks had nothing to do with infra. The model would sometimes say what it planned to do next instead of calling the tool immediately. OpenClaw treated that as an incomplete turn and retried it.
That meant I was paying for prose about action, then paying again for the action.
The fix was one paragraph in AGENTS.md: act, do not announce. That small rule eliminated planning-only retries in the next run.
4. The session was too long for the work pattern
A long session feels efficient because it preserves continuity. It also keeps hauling history forward.
My final clean run still processed prompts above 100K tokens. It worked because the cache hit rate climbed to 94.6 percent and the failure loops were gone. Even then, the next obvious improvement was to stop carrying so much session history at all.
That is why per-stage /new discipline moved to the top of my remaining opportunities list.
5. The prompt shape changed too much for caching to help enough
Prompt caching is real. In my OpenClaw optimization run, cache hit rate moved from 78.3 percent to 94.6 percent. That helped, but it did not rescue a messy workflow.
A cache works best when the stable prefix stays stable. In my case, timestamps and other dynamic markers near the top of the prompt kept breaking reuse. If you prepend changing tool surfaces or bulky one-off reads near the top, you cut the value of caching before the model even starts the real work.
Across all five mistakes, the pattern was the same. The workflow shape mattered more than the model choice.
What reduced the cost
Once the waste was visible, the fix order became clearer.
I made six changes:
- I stopped re-injecting context every turn.
- I slimmed the skill files so the agent loaded less guidance on demand.
- I moved durable blog-writing guidance into workspace files so the agent did not keep rereading the same style material from the vault.
- I raised context headroom from 60K to 200K so compaction stopped firing every few minutes.
- I raised timeout from 120 seconds to 180 seconds because large draft turns needed more room.
- I tightened post word targets so drafts stayed dense instead of sprawling.
Those changes were not glamorous, but they worked. Projected monthly cost moved from roughly $75 to $85 down to roughly $45 to $55 at one post a day. Per-pass cost on the measured clean run landed at about $1.96 for a five-stage seed-to-ready workflow. More important, the telemetry made sense because dashboard delta and session logs nearly matched.
The failed ideas were useful too. I tried a sub-agent pattern with lighter context for MCP-dependent work, but it broke because the stripped context also removed the tools that workflow needed. I also considered section-by-section parallel drafting, but that likely would have doubled cost for the same final draft because each branch would lose prefix sharing.
In this pipeline, one config line and one paragraph of guidance beat the fancy option.
The tips I would carry into the next build
If I were setting up another agent tomorrow, these are the rules I would keep:
- start by measuring input cost, not model price
- track input-to-output ratio on real runs
- count retries by cause
- keep stable context stable
- shrink tool payloads
- shorten sessions around artifact boundaries
- design for prefix reuse
Pay premium rates for premium answers, not for orchestration sludge.
Build cost visibility before you need it
The worst time to investigate agent cost is after finance asks why the bill jumped.
In my OpenClaw run, I knew something was off when the dashboard delta did not match what the session logs seemed to show. The session logs looked reasonable, but the dashboard still moved more than expected. That mismatch sent me into the gateway logs, where the hidden retries and reruns finally showed up.
That is the level of visibility you want. Log token usage by workflow and by step. Separate interactive turns from background work. Track retries and their causes. Keep dashboard totals as the source of truth, then compare them with step-level or session-level usage so hidden activity stands out quickly.
Once you have that visibility, cost work stops feeling mystical. You can see which workflow got cheaper, why it got cheaper, and what changed: better cache stability, fewer timeout retries, lower read volume, or shorter sessions.