The following comment was made by an LLM, it may be inaccurate:

Potential related PRs found:

1. fix: split system prompt into 2 messages for proper Anthropic prompt caching #14203 - "fix: split system prompt into 2 messages for proper Anthropic prompt caching"

   • fix: split system prompt into 2 messages for proper Anthropic prompt caching #14203
   • Directly related: This appears to address the same system prompt splitting approach that is a core fix in PR fix(cache): improve Anthropic prompt cache hit rate with system split and tool stability #14743.

2. feat(provider): add provider-specific cache configuration system (significant token usage reduction) #5422 - "feat(provider): add provider-specific cache configuration system (significant token usage reduction)"

   • feat(provider): add provider-specific cache configuration system (significant token usage reduction) #5422
   • Related: This PR deals with provider-specific cache configuration and token usage optimization, which aligns with the cache improvements in fix(cache): improve Anthropic prompt cache hit rate with system split and tool stability #14743.

3. feat: add experimental compaction prompt and preserve prefix support #11492 - "feat: add experimental compaction prompt and preserve prefix support"

   • feat: add experimental compaction prompt and preserve prefix support #11492
   • Related: Addresses prefix preservation during compaction, which relates to the cache stability goals.

Note: PR #14203 appears to be the most directly related, as it's specifically about the system prompt splitting strategy that is a key component of PR #14743's improvements.

Thanks for updating your PR! It now meets our contributing guidelines. 👍

Reviewer's guide — supplementary context not covered in the PR description. Uses same terminology (S1/S2, M1/M2) defined there.

AI SDK cache marker mechanics

Ref: Anthropic prompt caching docs | Anthropic engineers' caching best practices (Feb 19 2026): Thariq Shihipar, R. Lance Martin

Max 4 cache_control markers per request. The AI SDK already places markers on the first 2 system blocks and the last 2 conversation turns. That part works — the problem is OpenCode mutating blocks before these markers, cascading hash changes downstream.

Key subtlety: before this PR, OpenCode had a single system block. M1 covered it, but M2 was unused — it fell through to conversation. The system split (commit 3) is what activates both markers, letting S1 (stable) cache independently from S2 (dynamic).

Since M1 covers the tool block too (tools hash before system in Anthropic's ordering), any tool instability (commits 4–5) completely invalidates M1 — the entire cached prefix up to that marker is lost.

Related open PRs

Several open PRs address parts of this (#5422, #14203, #10380, #11492). This PR addresses the root causes directly.

Update (post-rebase, Mar 21 2026)

• Skill ordering commit dropped (covered by fix: stabilize agent and skill ordering in prompt descriptions #18261)
• Global skills now placed in S1 (stable block) alongside provider prompt and global AGENTS.md. Project skills remain in S2. This was needed because fix: stabilize agent and skill ordering in prompt descriptions #18261 added SystemPrompt.skills() to the system prompt during the rebase.
• Added splitSystemPrompt provider option (default: on). Providers that reject multiple system messages can set splitSystemPrompt: false in their provider config to get single-block behavior.

CI failure seems pre-existing — same NotFoundError affecting all PRs since the Windows path fixes landed in dev. Unrelated to this PR. All other checks pass.

I pulled this into my fork and it's working beautifully. Unfortunately I only found this after getting a huge bill from Anthropic. Thanks OpenCode!

@bhagirathsinh-vaghela could you check this with SLMs like Qwen3 or Nemotron or Kimi-Linear or GPT-OSS? Or providers using the OpenAI-compatible APIs (e.g. OpenRouter)?
Also why are some of the E2E tests failing in OpenCode PR?

Bonus ask: would Speculative Decoding work with this fork? I am looking at this from the lens of vLLM-MLX and MLX-OpenAI-Server (for non-MLX there is vLLM).

@bhagirathsinh-vaghela could you check this with SLMs like Qwen3 or Nemotron or Kimi-Linear or GPT-OSS? Or providers using the OpenAI-compatible APIs (e.g. OpenRouter)? Also why are some of the E2E tests failing in OpenCode PR?

Bonus ask: would Speculative Decoding work with this fork? I am looking at this from the lens of vLLM-MLX and MLX-OpenAI-Server (for non-MLX there is vLLM).

@TomLucidor

The fixes are provider/model-agnostic — they stabilize the request prefix so it is byte-for-byte identical across calls. Any provider with server-side prefix caching benefits automatically. See my reviewer's guide comment above for the full breakdown of each fix.

The specific model behind the provider does not matter — the changes are purely at the request layer. You can verify with any provider using OPENCODE_CACHE_AUDIT=1 to see hit/miss per call.

E2E failures — pre-existing upstream issue, since fixed. CI is green now.

Speculative decoding — orthogonal. This PR only changes what is sent in the request, not how the server processes it.

Looking forward to seeing less prompt re-processing with opencode. Unfortunately it seems currently this patchset breaks llama.cpp support:

[60919] srv operator(): got exception: {"error":{"code":400,"message":"Unable to generate parser for this template. Automatic parser generation failed: \n------------\nWhile executing CallExpression at line 85, column 32 in source:\n...first %}↵ {{- raise_exception('System message must be at the beginnin...\n ^\nError: Jinja Exception: System message must be at the beginning.","type":"invalid_request_error"}}

Tested with and without the new autoparser. Maybe I'm using it wrong?

So, after partially reverting fix(cache): split system prompt into 2 blocks for independent caching, or rather naively ensuring llama.cpp gets just one system prompt (revert.patch) opencode now flies with this patchset using a llama.cpp endpoint (openai api though).

No more "erased invalidated context checkpoint" for all checkpoints and reprocessing of the entire context seemingly whenever I send a new query.

Checkpoint reuse happens usually at around 99 %, sometimes drops to 93 % - lowest was in the 70 % with > 60k tokens.

Much appreciated!

Wonder whether the split system message is something @pwilkin would be willing to support or whether it should be guarded to only be sent to Antrophic endpoints.

Any chance the system message could be moved to the top of the messages list? We could possibly do this for the Anthropic API, but technically the system prompt should be the first message.

Thanks @pwilkin. Given this is actually coming from the model template (Qwen 3.5) and not the parser:

    {%- if message.role == "system" %}
        {%- if not loop.first %}
            {{- raise_exception('System message must be at the beginning.') }}
        {%- endif %}
    {%- elif message.role == "user" %}

this should probably best be handled on OpenCode's end.

When will this PR make it into a release? We are seeing lower cache hit rates (Anthropic) across users using the same repo with a standard workflow based on opencode. -> higher token costs

Even more important now to get it into release with the general rollout of 1M Context windows for Max subscribers. The price remained as if it was 200K window, so it's up to caching to cut costs.

https://claude.com/blog/1m-context-ga

Would love to see this get in as well. Caching is much less efficient in OpenCode with Claude models. We are pushing internal users to OpenCode for better general model supports, but the caching issue is a blocker.

we are looking at it

I think most of these changes prolly make sense, but it seems like the primary 2 things that are gained:

• option for 1H ttl
• tool prompt cache won't bust between projects as frequently.

In my experience #2 prolly won't have much impact for most ppl but we may as well do that

We actually resolved some of the ordering things in separate pr, ill look at the rest of this and then we will ship a cleaned up version

@fkroener The system split can now be disabled per-provider via config. For your llama.cpp setup, add to your opencode.json:

{
  "provider": {
    "<your-llama-provider-id>": {
      "options": {
        "splitSystemPrompt": false
      }
    }
  }
}

This builds a single system message (pre-PR behavior) while still benefiting from the other prefix stability fixes (tool schema, skill ordering).

@rekram1-node Thanks for the feedback. Updates since your comment:

• Skill ordering commit dropped — already covered by fix: stabilize agent and skill ordering in prompt descriptions #18261
• System split commit now also separates global vs project skills (global skills in S1 for cross-repo reuse)
• Added splitSystemPrompt provider config option for providers that reject multiple system messages (llama.cpp/Qwen)

+1, was creating a draft PR for this and bot directed me to this. It's not just for Anthropic, this busts cache for every single LLM implementation that uses prefixing to preserve model output quality (all of them?)

I do hope this gets merged in, it's useful overall, and while support was removed for Anthropic Plus/Max plans, it would still be good for API as well as all the people who are just going to use a plugin to provide more Claude support.

Yeah today Ill merge this in, I am gonna split it up into separate commits/prs and resolve the conflicts but ill add the author of the PR as a coauthor on the commits so he gets credit for helping out.

@rekram1-node did you manage to get this split up and merged?