Zero-token replay economics
A concrete look at what repeated agent work actually costs — and what happens to the bill when you capture the result once and replay it for free.
If your team uses coding agents for operational work — deploys, data refreshes, environment setup — you are paying for the same reasoning over and over. The agent figures out the steps, runs them, and then forgets. Next week, same task, same tokens, same latency. The bill scales with how often you do the work, not with how hard the work was to solve.
That is backwards. The hard part is solving it the first time. Every run after that is just executing a known recipe. This post puts numbers on the difference.
Where the cost actually goes
A single agent-driven operational task isn't one model call. It's a loop: read the request, inspect the repo, propose a command, read the output, propose the next one, recover from a surprise, verify. Each turn is input tokens (growing as context accumulates) plus output tokens. A genuinely multi-step task — say a weekly data refresh with extract, transform, load, and a verification — burns through a real chunk of context across a dozen turns.
Call that "solving it." You pay it once and it's worth every token, because the agent is doing something hard: adapting to your actual environment.
The problem is the re-runs. The task didn't get harder. The agent just doesn't remember, so it re-derives the same answer at full price.
The capture move
OrchStep's capture skill collapses the solved session into a workflow. The weekly refresh that took a dozen reasoning turns becomes this:
name: weekly-data-refresh
defaults:
dataset: events
target: staging
tasks:
refresh:
steps:
- name: extract
func: shell
do: echo "extracting {{ vars.dataset }}"
- name: transform
func: shell
do: echo "transforming {{ vars.dataset }}"
- name: load
func: shell
do: echo "loading {{ vars.dataset }} into {{ vars.target }}"Now the re-run is a binary executing three steps:
orchstep run refresh --var dataset=events --var target=productionZero model calls. Zero tokens. The reasoning was paid for once, during capture; replay rides for free.
The cost table
Here is the shape of the bill for a repeated task, before and after capture. The exact token counts depend on your task and model, so treat the relative columns as the point — the absolute numbers will be your own.
| Per re-run, agent each time | Per re-run, after capture | |
|---|---|---|
| Model calls | full reasoning loop, every run | none |
| Token cost | input + output, every run | zero |
| Latency | seconds to minutes of inference | binary execution speed |
| Determinism | re-derived, may vary | identical every run |
| Reviewable artifact | none | the captured orchstep.yml |
For work you repeat, the variable cost of each run drops to roughly nothing. The one-time capture is the only model cost you keep paying — and you pay it once. For a task run weekly, that's the difference between paying fifty-two times a year and paying once.
How much you actually save
The honest answer: it depends entirely on the repeat rate. The framing we use is that repeated agent work runs about eighty percent cheaper once captured — but that figure only makes sense for work you genuinely do again. The math is mechanical:
- A task run once and never again: capture saves nothing. Don't bother.
- A task run weekly: you pay reasoning cost once, then replay fifty-one more times for free. The savings approach the full per-run cost.
- A task run in CI on every push: replay was never going to be agent-driven anyway, but capture is what makes a CI-runnable version exist at all.
So the rule for an EM watching the bill is simple: capture the things you do more than once, leave the one-offs alone. The savings track your repeat rate, and the repeat work is exactly where agent spend quietly piles up.
What you don't lose
You keep the agent for the part that's worth paying for — understanding new problems, exploring unfamiliar code, recovering from surprises. Capture only removes the dumb tax of re-solving solved problems. And because the captured workflow is a reviewable, version-controlled file, you arguably gain governance: the operational task that used to live in an ephemeral chat is now a recipe in your repo.
Where to go next
- Capture skill — how a session becomes a replayable workflow
- The replay layer for AI coding agents — the thesis behind the numbers
- LLM Agent Integration — running captured workflows with agents
Watching agent spend climb on routine ops? Capture the routine ones — the re-runs stop costing tokens.
curl -fsSL https://orchstep.dev/install.sh | sh