Background
Every request to an agent resends its full system prompt to the model provider, and that system prompt is frequently the same or nearly the same text across many requests — it's read from a fixed file per node. Several model providers offer prompt caching: a way to mark reused content so the provider charges less (and responds faster) on subsequent requests that repeat it, instead of billing full price for the same tokens every time.
Purpose
Let a node opt into provider-side prompt caching for its system prompt, so repeated requests to the same agent don't pay full input-token cost for content that hasn't changed.
Proposed YAML
model:
provider: anthropic
name: claude-sonnet-4-6
cache_system_prompt: true # default true
Nests next to model's other fields (same place #25's fallback field lives), usable wherever a model is defined — per-agent, per-orchestrator, or defaults.model. Default on: most agents send the same system prompt repeatedly, so caching should be the default, not something every spec has to opt into.
Research
- Cross-provider, not just Anthropic. Extra supports Anthropic, Bedrock, Gemini, and OpenAI-compatible providers (
src/agent_engine/models/factory.py) — caching mechanics differ across all of them, not just in whether it's supported. Some cache automatically server-side with no flag at all; some need explicit opt-in markup; some charge a premium on the write and only save on a hit, which matters for low-traffic agents. Needs a provider-by-provider pass, not an Anthropic-shaped assumption applied everywhere.
- Only
system (and orchestrator) prompts apply. prompts.user exists in the YAML schema but isn't read anywhere by the engine at runtime today — the live user message always comes from the actual conversation, never from a file. There's currently nothing to cache there.
- Caching part of one message is possible, but the prompt isn't built that way today. Several providers cache at a content-block level — a message's content can be a list of blocks, with the cache boundary marked on one of them, so a static prefix can be cached separately from dynamic content that follows it. Today's system prompt is built by interpolating resolver values inline into the template text (
render_prompt()), producing one merged string rather than separate static/dynamic blocks. Achieving prefix caching means restructuring how the message is assembled, not just adding a client-side flag.
Background
Every request to an agent resends its full system prompt to the model provider, and that system prompt is frequently the same or nearly the same text across many requests — it's read from a fixed file per node. Several model providers offer prompt caching: a way to mark reused content so the provider charges less (and responds faster) on subsequent requests that repeat it, instead of billing full price for the same tokens every time.
Purpose
Let a node opt into provider-side prompt caching for its system prompt, so repeated requests to the same agent don't pay full input-token cost for content that hasn't changed.
Proposed YAML
Nests next to
model's other fields (same place #25'sfallbackfield lives), usable wherever a model is defined — per-agent, per-orchestrator, ordefaults.model. Default on: most agents send the same system prompt repeatedly, so caching should be the default, not something every spec has to opt into.Research
src/agent_engine/models/factory.py) — caching mechanics differ across all of them, not just in whether it's supported. Some cache automatically server-side with no flag at all; some need explicit opt-in markup; some charge a premium on the write and only save on a hit, which matters for low-traffic agents. Needs a provider-by-provider pass, not an Anthropic-shaped assumption applied everywhere.system(andorchestrator) prompts apply.prompts.userexists in the YAML schema but isn't read anywhere by the engine at runtime today — the live user message always comes from the actual conversation, never from a file. There's currently nothing to cache there.render_prompt()), producing one merged string rather than separate static/dynamic blocks. Achieving prefix caching means restructuring how the message is assembled, not just adding a client-side flag.