600K
input tokens for one 25-step run
Every call re-sends the history, say a 6,000-token prefix plus 1,500 tokens a step. Double to 50 steps and it’s 2.14M, 3.6×.
Where does the loop run?
Bad: In the web request
A deploy kills it halfway; a restart refunds the customer twice.
Good: A durable workflow
Each model and tool call is recorded. A crash means replay, not restart.
A worker dies after the dispute is raised. What runs again?
Nothing that finished. A new worker replays the loop against the event history, getting recorded results back. Only model call 3 runs again.
A refund over ₹10,000 waits for a supervisor. At peak, about 1,250 runs are waiting.
The trick
Each sleeps on a signal and a 24-hour timer, holding no worker. Waiting costs a row; silence is “no”.
A ticket’s text tells the agent to email card numbers to evil.example.
Assume the model is fooled. The policy check, in code outside it, sees a tainted run and denies external email.
Controls live outside the model
- Credentials join after the model writes a call
- Tokens never exceed the user’s own rights
- Tainted runs need a human to send out
- Code runs in throwaway microVMs, behind egress allowlists
No caching, a 25-step run costs ≈ ₹112 (Claude Sonnet 5, October 2026 prices).
The trick
Keep instructions and tools first and identical. Each token is written once, then read at a tenth. ≈ ₹26, 77% less.
Remember
Each run is a durable workflow, so a crash means replay. Tool calls pass checks outside the model. A stable prefix tames the cost.