Problem
The current system prompt order places variable content (user's project context, memory, task-specific instructions) before stable content (tool definitions, behavior rules). This means the prefix cache is invalidated on every turn — each new user message changes the prompt prefix, so no two turns share a cached prefix.
Proposed solution
Rearrange the system prompt assembly so that stable, repeating content comes first:
- Tool definitions / behavior rules (stable across turns)
- Task/project context (changes per conversation)
- Per-turn user message (changes every turn)
This way, turns 2+ in a conversation share the same prefix cache from the tool definitions block. On providers that support prefix caching (Anthropic, some OpenAI tiers, certain local backends), this can reduce prompt processing time by 30-50% on turns after the first.
Implementation is a simple reordering in the system prompt assembly function — no logic changes, no new features. The functional output is identical; only cache locality changes.
I've been running this locally for ~2 weeks. The observable effect is that second and subsequent turns feel noticeably faster on local backends with KV caching. On cloud APIs the token savings are invisible to the user but reduce billed prompt tokens.
Open to discussion on whether the reordering has any side effects on model behavior (none observed in my testing, but the team may know edge cases).
Problem
The current system prompt order places variable content (user's project context, memory, task-specific instructions) before stable content (tool definitions, behavior rules). This means the prefix cache is invalidated on every turn — each new user message changes the prompt prefix, so no two turns share a cached prefix.
Proposed solution
Rearrange the system prompt assembly so that stable, repeating content comes first:
This way, turns 2+ in a conversation share the same prefix cache from the tool definitions block. On providers that support prefix caching (Anthropic, some OpenAI tiers, certain local backends), this can reduce prompt processing time by 30-50% on turns after the first.
Implementation is a simple reordering in the system prompt assembly function — no logic changes, no new features. The functional output is identical; only cache locality changes.
I've been running this locally for ~2 weeks. The observable effect is that second and subsequent turns feel noticeably faster on local backends with KV caching. On cloud APIs the token savings are invisible to the user but reduce billed prompt tokens.
Open to discussion on whether the reordering has any side effects on model behavior (none observed in my testing, but the team may know edge cases).