TLDR; The cheapest tokens are the ones the model never sees. I halved the cost of an agent-run monthly reporting workflow by moving everything deterministic into scripts: data pulls became one digest command (15 MB of raw API output in, 36 KB of computed metrics out), report rendering became a JSON payload instead of hand-typed HTML, and document scaffolding became generators. The model now spends its tokens on the one thing scripts can’t do: interpretation.
I run monthly SEO reports for clients through Claude Code. The pipeline pulls Search Console, GA4 and competitive data, computes the month’s movement, and writes a long analytical report plus a client-facing HTML version. It works well. It was also expensive.
When I broke down where the tokens went, most of the spend wasn’t the interpretive writing a client pays for. It was mechanics: the agent reading raw CLI output across a dozen round-trips, re-deriving the same arithmetic every month, and retyping boilerplate markup that never changes. It’s the same class of waste I covered in ten ways to optimise Claude Code token usage, except here the fix isn’t better context hygiene: it’s taking the work off the model entirely.
So I did a pass with one rule: if two runs of a step should produce identical output, that step becomes a script. The model keeps everything that requires judgement. Here’s what moved, and what it saved.
The two ways agents waste tokens
Everything I found fell into two buckets.
Reading what they don’t need. A monthly report needs about a dozen data pulls. Run by an agent, each pull is a tool call whose output lands in context, and the derived metrics (week-over-week trends, brand splits, movers between periods) get computed by the model across several more write-code-read-output round trips. Every round trip carries the full conversation behind it.
Typing what a script could type. My report templates were markdown files instructing the model to reproduce specific HTML and CSS. One 29 KB template was 60% literal markup inside code fences. The agent read all of it, then typed all of it back out, every report. On Anthropic’s published pricing, output tokens cost five times input tokens at every tier. Retyped boilerplate is the most expensive text an agent can produce. The economics of Claude Code token pricing are worth understanding before you optimise anything else.
Neither of these is a model-capability problem. A better model reads the same bloat and types the same boilerplate.
What moved into scripts
Data pulls became one digest command. A single script now runs the full pull sequence (13 CLI calls against Search Console and GA4), archives the raw responses to disk, and emits one compact digest with the derived metrics precomputed: month-over-month deltas, impression-weighted positions, weekly series with trend indicators, brand versus non-brand splits, matched-query movers, striking-distance candidates, anomaly flags. On a real month, that’s 15.4 MB of raw API output compressed to a 36 KB digest, in one command, in about thirty seconds. The agent reads the digest. It never sees the raw data, but the raw data is on disk if anyone wants to verify.
Rendering became data, not markup. I replaced the HTML report templates with a stylesheet, a renderer script, and a JSON payload schema. The model now emits a few kilobytes of structured content (KPIs, findings, table rows) and the script handles markup, chart geometry, status colours and delta arrows. Around 51 KB of template context shrank to 8 KB of editorial rules, and the typed-out HTML disappeared entirely.
Structure became scaffolding. Campaign folder trees, tracker shells, content brief skeletons, report skeletons: all generated by small stdlib-only Python scripts that refuse to overwrite existing files. The conventions used to live in prose that the model re-read and re-applied each time; now they live in code, and drift stopped being a review item.
The validation step that made it trustworthy
Scripting the mechanics is only a win if the numbers are right, so I validated the digest script against a monthly report the agent had previously assembled by hand over many round-trips.
Every headline metric matched exactly on the first run:
- totals
- month-over-month percentages
- the weighted position
- all thirteen weekly rows, including the partial-week edge case
Two things differed. The brand split was off by about 1% because the original run’s brand pattern included staff names the script’s config didn’t have (a config gap, now documented). And the trend-indicator column didn’t match because the hand-built version had quietly editorialised past its own documented rule. The script applies the rule as written. In both cases the deterministic version was the more defensible one.
It’s not just cheaper: it removes a whole class of reconciliation work. Arithmetic done in code doesn’t need a second agent to check it, which is a cheaper quality gate than any review pass.
The numbers
- Pull-and-derive phase: roughly 25–50k tokens across 15–25 agent turns, down to about 10k tokens in 2 turns. A 60–80% cut on the phase.
- Rendering: hand-typed HTML replaced by a JSON payload, roughly 90% fewer output tokens on the report artifact, at 5x price per token.
- Full monthly cycle: approximately half the original token cost, with the remaining spend concentrated in analysis and writing, which is where you want it.
- Side effect: the paid-API bill dropped too. The pull sequence is now a fixed list of 13 calls, where the agent would sometimes decide to run one more exploratory query.
Where the line is
The principle was already written down in the reporting skill: automate the data, never automate the interpretation.
The scripts own arithmetic, aggregation, markup, file structure and sequencing. The model owns why the numbers moved, what to recommend, what to say to the client, and when something in the data smells wrong. The anomaly detection is a good example of the boundary: the script flags the four documented threshold signals mechanically, and the model investigates and explains the flags. Neither side does the other’s job.
If you’re running your own agent workflows, the candidates are easy to spot. Look for any step where the agent retypes something it read, re-derives the same formula each run, follows a fixed sequence of tool calls, or applies a template described in prose. Each of those is a script wearing an agent costume, and every one you convert pays back on every run afterwards.
Waiting for a better model wouldn’t have fixed any of this. Nothing in the expensive half of that workflow was a reasoning problem, so nothing in it got cheaper when the reasoning got better.
The fix has a cost: every script is something you now maintain. A digest schema and a renderer are code that breaks when an API changes, where a prose template just gets re-read. That’s a fair price when the step runs monthly for a dozen clients, and a bad one for something you’ll run twice. Convert the steps that repeat.
If you’re weighing where this fits in your own operations, that’s the kind of problem I work on as an applied AI consultant. Happy to discuss a related problem if you’re partway into one.
Related reading
- Top 10 ways to optimise Claude Code token usage
- The deeper economics of Claude Code pricing
- Quality gates for AI-assisted work
Common questions
How do deterministic scripts reduce AI agent token costs?
They remove the two biggest hidden costs: tokens the agent spends reading raw tool output it doesn’t need, and tokens it spends typing boilerplate a script could produce. In my monthly SEO reporting workflow, a pull-and-digest script compressed 15 MB of raw API output into a 36 KB digest, and a renderer replaced hand-typed HTML with a small JSON payload. The interpretation still comes from the model; the mechanics don’t.
What parts of an agent workflow should be scripted?
Anything where two runs should produce identical output: fixed sequences of tool calls, derived arithmetic (deltas, aggregations, splits), document templates, file scaffolding, and rendering. Keep the model for judgement calls: what the numbers mean, what to recommend, what to write. A useful test is whether you could code-review the step; if yes, it probably belongs in a script.
Do scripted data pipelines make AI agents more accurate?
For arithmetic, yes: it’s exact on the first pass, so the reconcile-and-retry loop disappears. When I validated the digest script against a report the agent had previously assembled by hand, every headline metric matched exactly, and the one column that differed turned out to be the hand-built version editorialising, not the script. The failure mode moves rather than vanishing: a script can still be misconfigured, and mine was, so the config needs reviewing like any other code.