Runner economics: cold-start token cost of claude -p workers — trial pi as a subscription-backed runner (feedback from @holsee)

Feedback from @holsee on thrawn's cost model, plus analysis and a proposed experiment.

The feedback

Claude -p will never benefit from caching. That's required to not blow the bank.

I'd recommend you check out Pi harness — it's bare bones but you can tailor it to be like thrawn, it knows how to hack itself into doing that. Then you can use GPT (Sol or something) on subscription, no worries, and it's great.

Get the tools to work to your standards and needs.

Analysis

The caching claim — half right, and the right half matters

Not literally true: a single claude -p run is a full agentic session with dozens of model calls, and prompt caching works within it — each tool-use turn reuses the cached prefix of the conversation so far. Without that, no agentic CLI would be affordable at all.

What is true: there is zero reuse across invocations. Every thrawn worker starts cold — full price for the system prompt, the injected recon brief, and its own repo exploration — and thrawn multiplies that by N workers + a planner + integrators per run. The recon cache reduces re-exploration but those tokens are still re-sent on every spawn. The cold-start tax per pane is architectural.

Billing regime decides whether this "blows the bank"

• API pay-per-token: parallel opus workers is genuinely the expensive way to do anything. The warning is fair.
• Max subscription: headless claude -p draws from plan quota; the calculus is rate limits, not dollars.

Action: confirm which regime the claude CLI here is actually billed under before optimising anything.

pi is already a thrawn runner

runners.toml already defines pi as a runner. Thrawn's orchestration layer is runner-agnostic argv templates — the thesis was always: planner on fable, integrator on opus, workers on whatever earns its seat. If pi harness driving a subscription-backed GPT model is effectively free per task, the move is routing, not rewriting: send low/medium-complexity tasks to pi, keep the strong model where judgement lives (planning, integration, conflict resolution).

"Bare bones but tailorable" is how everyone ends up rebuilding their own thrawn from scratch. The worktree isolation, exit-0-without-commits salvage checks, and the ship gate are the parts pi doesn't give you — they're not the cost, they're the value. The economics question is real; the answer is which runner gets the traffic.

Proposed experiment (ledger decides, not enthusiasm)

1. Configure a proper pi runner in runners.toml (or a GPT-via-pi variant): correct argv for headless/non-interactive use, output format thrawn's activity ticker can read, notes written so the planner routes low/medium tasks to it.
2. Trial via swarm first — zero-risk A/B: thrawn swarm <issues…> --runner pi produces branches that can simply not be merged if the work is poor.
3. Then let the planner route to it for a fortnight of mechanical tasks.
4. Measure in the ledger: cost (or quota burn) per shipped task, retry rate, adopt rate, and failure modes vs haiku on the same class of task.
5. Decide from the numbers.

Possible follow-ons

• Cross-invocation context reuse for retries: claude -p --resume <session> on thrawn retry instead of a cold session, so a rerun keeps the original exploration.
• Record per-task token/quota usage in state.json (claude's stream-json result event includes usage) so the ledger captures cost without manual bookkeeping.

🤖 Generated with Claude Code