[Go Provider] Dynamic "Current date:" in system prompt resets cache at local midnight, causing unexpected billing spike (~$0.5 per session)

[laozhoulaile]

Description

When using OpenCode Go with DeepSeek v4 pro, I observed that an ongoing session consistently loses its prompt cache immediately after local midnight (00:00).

Before midnight, cache hit ratio is high. After midnight, the next request in the same session incurs a full cache_creation_input_tokens cost, resulting in a billing spike of approximately $0.5 per active session (depending on the length of the session history). If multiple sessions are active simultaneously, each triggers its own spike.

This happens every night and is reproducible.

Expected Behavior

Prompt cache for an ongoing session should not be invalidated solely due to the passage of local midnight. The cache should persist based on session lifetime or TTL, not a calendar date boundary.

Actual Behavior

Cache resets at local midnight, causing repeated unexpected costs.

Environment

• OpenCode Version: 1.14.39
• Provider: DeepSeek v4 pro (via OpenCode Go)
• OS: Linux x86_64
• Subscription: OpenCode Go
• Timezone: [e.g., UTC+8] – issue occurs at local 00:00

Investigation Note

I have verified that the OpenCode client (v1.14.39) and all active plugins (opencode-visual-cache, engram, session-env) do not inject any time/date variables into system prompts or request payloads. The issue most likely originates from the OpenCode Go provider itself — please check whether it injects a Current date or timestamp into the system prompt or any request-level variable that changes at local midnight, breaking prompt cache prefix matching.

.opencode/plugins/session-env.js:
export const SessionEnv = async () => {
  return {
    "shell.env": async (input, output) => {
      if (input.sessionID) {
        output.env["OPENCODE_SESSION_ID"] = input.sessionID;
      }
    },
  };
};

Additional Context

• The spike size (~$0.5) matches the cost of creating a new cache entry (full input token cost).
• This issue is not observed at UTC midnight – only at local midnight of the user's machine.
• I have attached a screenshot of the session cost breakdown showing the jump (see attachment).

Suggested Investigation Direction

Please check whether OpenCode injects any session-local variable that depends on current system time (e.g., timestamp, date) into the request payload – especially in the system prompt or at the beginning of the message sequence. A change in such a variable at midnight would break cache prefix matching.

Plugins

opencode-visual-cache, engram, session-env

OpenCode version

1.14.39

Steps to reproduce

1. Start a session with OpenCode Go + DeepSeek v4 pro before your local midnight.
2. Exchange several messages to establish a high cache hit ratio.
3. Wait until after local midnight (e.g., 00:01).
4. Send another message in the same session.
5. Check the cost breakdown – you will see a one-time spike of about $0.5, and cache reads drop to near zero for that request.

Screenshot and/or share link

Operating System

Linux x86_64

Terminal

zellij -> bash

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• [FEATURE]: Modify system prompt to improve cache hit rate #29672: [FEATURE]: Modify system prompt to improve cache hit rate — this issue explicitly identifies the today's date field in the system prompt as causing cache misses at midnight, which is the same root cause described here.

If your issue is already covered by #29672, consider adding a comment there with your findings (especially the ~$0.5 billing spike cost data, which is useful supporting evidence).