Summary
The architect's request prefix is large (about 100K tokens: tool schemas, agent prompt, skills) and mostly stable, so it should hit the provider's prompt cache on every call. It does not, because the plugin rewrites system[1] per step and unshifts directive carrier messages ahead of the history. The stable prefix moves, and the provider re-tokenizes it.
Version
opencode-swarm@7.179.1 on OpenCode 1.18.21, provider OpenRouter (GLM-5.3 as architect). The relevant file is byte-identical on the 7.180.0 release branch.
Measurement
From one 25-minute run with 40 architect calls (token counts from the OpenCode session database, prices from the provider's list):
- Prefix per call about 100K tokens, history on top of that.
- 22 of 40 calls cached only about 100K tokens; the rest of the prompt was billed as uncached input.
- Uncached input was about 61% of the architect's spend for the run.
A zero-spend capture against a local fake provider showed the same request shape: the system[1] content differs step to step, and directive messages are inserted before the conversation history rather than appended after it.
Where it happens
src/hooks/system-guidance-carrier.ts (around line 171): the carrier is unshifted into the message list.- The per-step
system[1] rewrite in the same area.
Expected
Keep everything stable at the front of the request (tool schemas, agent prompt, instructions) and put per-step guidance after the history, or in the newest user turn, so the provider's prefix cache can match. Where the provider supports explicit cache breakpoints, place one after the stable prefix.
Impact
For a long orchestration session the architect's input cost is dominated by re-sending a prefix that could be cached. In our run that was the single largest cost line.
Summary
The architect's request prefix is large (about 100K tokens: tool schemas, agent prompt, skills) and mostly stable, so it should hit the provider's prompt cache on every call. It does not, because the plugin rewrites
system[1]per step and unshifts directive carrier messages ahead of the history. The stable prefix moves, and the provider re-tokenizes it.Version
opencode-swarm@7.179.1on OpenCode 1.18.21, provider OpenRouter (GLM-5.3 as architect). The relevant file is byte-identical on the 7.180.0 release branch.Measurement
From one 25-minute run with 40 architect calls (token counts from the OpenCode session database, prices from the provider's list):
A zero-spend capture against a local fake provider showed the same request shape: the
system[1]content differs step to step, and directive messages are inserted before the conversation history rather than appended after it.Where it happens
src/hooks/system-guidance-carrier.ts(around line 171): the carrier is unshifted into the message list.system[1]rewrite in the same area.Expected
Keep everything stable at the front of the request (tool schemas, agent prompt, instructions) and put per-step guidance after the history, or in the newest user turn, so the provider's prefix cache can match. Where the provider supports explicit cache breakpoints, place one after the stable prefix.
Impact
For a long orchestration session the architect's input cost is dominated by re-sending a prefix that could be cached. In our run that was the single largest cost line.