Custom baseURL providers report zero prompt cache tokens for subagent sessions

[ThreeIce]

Description

When using a custom OpenAI-compatible baseURL, prompt cache accounting stays at zero for subagent sessions.

I tested both provider configurations:

• npm: "@ai-sdk/openai" with a custom baseURL
• npm: "@ai-sdk/openai-compatible" with a custom baseURL

In both cases, after running a subagent task and exporting the subagent session with opencode export <sessionID>, the exported subagent session reports:

"tokens": {
  "cache": {
    "read": 0,
    "write": 0
  }
}

Each assistant message in the exported subagent session also reports tokens.cache.read = 0 and tokens.cache.write = 0.

The same custom endpoint does report prompt cache normally in the main conversation. The zero cache accounting appears specific to subagent sessions.

This looks related to, but not identical to:

• setCacheKey sends promptCacheKey (wrong) instead of cache_control on content blocks for openai-compatible Bedrock proxies (Bifrost, LiteLLM) #25984, which covers @ai-sdk/openai-compatible sending the wrong caching shape for some custom/proxy backends.
• Prompt Caching Not Working for Xiaomi/MiMo Models #26460, which reports zero cache hits for a direct custom API using @ai-sdk/openai-compatible.

The difference here is that the issue reproduces with both @ai-sdk/openai and @ai-sdk/openai-compatible, while the main conversation cache works normally. The observed symptom is specifically exported subagent sessions reporting zero cache read/write tokens.

Plugins

None

OpenCode version

1.15.13

Steps to reproduce

1. Configure a custom provider with a custom OpenAI-compatible baseURL using @ai-sdk/openai.
2. Run a normal main conversation and confirm prompt cache accounting is non-zero.
3. Run a simple subagent task, for example an explore subagent that reads a few repository files.
4. Export the subagent session:

opencode export <subagent-session-id>

5. Observe that the exported subagent session has tokens.cache.read = 0 and tokens.cache.write = 0.
6. Repeat with the same custom baseURL configured through @ai-sdk/openai-compatible.
7. Observe the same zero cache accounting in the exported subagent session.

Expected behavior: if prompt caching is enabled and reported for the custom endpoint in the main conversation, subagent sessions should report cache read/write token counts consistently as well.

Actual behavior: both provider paths report zero cache read/write tokens for exported subagent sessions, while the main conversation cache works normally.

Operating System

Windows / win32

Terminal

PowerShell / Windows terminal environment

[ulises-jeremias]

I investigated this path and prepared a fix.

Root cause: cache token extraction in Session.getUsage() was mostly usage-field driven (usage.cacheReadInputTokens / usage.cacheWriteInputTokens) with provider-specific metadata fallback for Anthropic/Vertex/Bedrock/Venice only.

For custom OpenAI-compatible endpoints, cache counts can arrive in provider metadata under an OpenAI-style payload (usage.prompt_tokens_details.cached_tokens) instead of normalized usage fields. In that case, session token accounting records cache read/write as zero, which matches the symptom reported for exported subagent sessions.

Fix approach:

• Add metadata fallback parsing in Session.getUsage() for OpenAI-style metadata usage payloads.
• Extract prompt_tokens_details.cached_tokens as cache read fallback.
• Keep existing provider-specific write-token fallbacks and add generic metadata write fallbacks (cache_creation_input_tokens / cacheWriteInputTokens).

I’m opening a PR with this now.

[ThreeIce]

I'll test it after the pr is merged. But I suspect the issue might be a cache failure, rather than just a stats error. I'm charged as if there is no cache.
Image 1 shows the scenario where the requests failed to be cached. Image 2 shows the expected scenario.

[Necmttn]

I would make the regression compare main and subagent usage provenance directly.

For each exported session, keep parent session id, child session id, provider raw usage path, normalized usage fields, metadata fallback path used, cache read/write tokens, and cache_status (reported_zero, not_reported, parsed_from_metadata, provider_absent). That separates an actual cache miss from a subagent export/parser path that dropped the cache fields.

Generated with ax - https://github.com/Necmttn/ax

[ulises-jeremias]

Reopened the fix PR after automated cleanup closure: #36861

@nexxeln could you please take a look when you get a chance? Thanks!