Description
SystemPrompt.environment() emits Today's date: ${new Date().toDateString()} at packages/opencode/src/session/system.ts:78. That string is the first entry in the system[] array assembled in session/prompt.ts (~l.983), so it lands in the first role: "system" message.
applyCaching() in provider/transform.ts (~l.192) takes the first two system messages and marks them with cacheControl/cachePoint. The date therefore sits inside the cache-controlled prefix.
The date string changes at local midnight. A session that stays within the cache TTL but crosses midnight produces a different system prefix on the next request, so the cached prefix misses and the entire (large) system block is re-billed as a cache write instead of a read. For long-running sessions and providers billing cache writes higher than reads this is a recurring, avoidable cost — and it defeats caching precisely when a session is long enough to benefit most.
The date is the only daily-changing token in that block; everything else (model id, cwd, platform, git status) is stable for the session.
Steps to reproduce
- Start a session with a model/provider that supports prompt caching (e.g. an Anthropic-family model).
- Keep it active across local midnight, within the cache TTL.
- Observe the next request reports a cache write rather than a read for the system prefix.
Suggested fix
Move the date out of environment() and carry it in the trailing user message (after the cache breakpoint). The model still receives the date; the cached system bytes become date-invariant.
Operating System
macOS / Linux (platform-independent)
Description
SystemPrompt.environment()emitsToday's date: ${new Date().toDateString()}at packages/opencode/src/session/system.ts:78. That string is the first entry in thesystem[]array assembled in session/prompt.ts (~l.983), so it lands in the firstrole: "system"message.applyCaching()in provider/transform.ts (~l.192) takes the first two system messages and marks them withcacheControl/cachePoint. The date therefore sits inside the cache-controlled prefix.The date string changes at local midnight. A session that stays within the cache TTL but crosses midnight produces a different system prefix on the next request, so the cached prefix misses and the entire (large) system block is re-billed as a cache write instead of a read. For long-running sessions and providers billing cache writes higher than reads this is a recurring, avoidable cost — and it defeats caching precisely when a session is long enough to benefit most.
The date is the only daily-changing token in that block; everything else (model id, cwd, platform, git status) is stable for the session.
Steps to reproduce
Suggested fix
Move the date out of
environment()and carry it in the trailing user message (after the cache breakpoint). The model still receives the date; the cached system bytes become date-invariant.Operating System
macOS / Linux (platform-independent)