<current_datetime> at byte 0 of every user message prevents cache_control reuse

[pmella]

Summary

The Copilot CLI auto-prepends <current_datetime>...</current_datetime> with millisecond precision at byte 0 of every user message. Because this single field changes every request, it makes consumer-set cache_control: ephemeral on the user-message block ineffective for cross-request cache reuse: the prefix never matches a prior request's cached entry beyond the system-block boundary.

Filed as a separate follow-up to #1296 (per the maintainer's suggestion in that issue).

Observed behavior

Three consecutive user messages from the same session-style flow show the byte-0 injection:

<current_datetime>2026-05-14T18:10:44.758+00:00</current_datetime>...
<current_datetime>2026-05-14T18:17:06.648+00:00</current_datetime>...
<current_datetime>2026-05-14T18:21:22.717+00:00</current_datetime>...

Each value is unique to within milliseconds. The injection happens unconditionally and at the start of every user-message text block, regardless of what the consumer passes as the prompt.

Why this matters

Anthropic prompt caching (cache_control: ephemeral) requires byte-exact prefix match. When the first bytes of a cache-marked block are guaranteed to differ on every request, the cache_control marker on that block becomes a cache-write-only event:

• Every request writes a new cache entry (paying the cache-write surcharge of 1.25x the input rate)
• Subsequent requests never read that entry because the prefix mismatches at byte ~18

For consumers like ours that try to place cache_control on stable per-user or per-session content (user profile, locale, session metadata) within the user message, the SDK's byte-0 injection of mutable content makes that strategy impossible. We can't put cache_control before the SDK's prepended content; we can only have it after.

We've worked around the value being too precise by adding a separate hour-rounded datetime block of our own in our user prompt content, but that doesn't help with the byte-0 issue: the SDK still prepends its own per-request datetime ahead of everything we add.

Source location

yUr function in node_modules/@github/copilot/sdk/index.js line 3942 (CLI 1.0.40), template renderer field:

return template.with({
    ...,
    current_datetime: q0t(),  // unconditional injection
    ...
}).asXML().trim();

q0t() returns the current timestamp in ISO 8601 format with millisecond precision.

Proposed fixes (ranked)

1. Config option to disable the auto-prepended datetime (preferred)

client.createSession({
    autoInjectCurrentDateTime: false,
    // ...
});

When false, the SDK omits <current_datetime> from user messages. Consumers who want the model to know the current time can pass it themselves in their preferred format and position.

2. Move it to the end of the user message block

Rather than byte 0, append after the user's prompt text. This way consumer-set cache_control on the block at least has a chance of matching across requests where everything before the datetime is identical (e.g., same user + same prompt).

3. Reduce precision to hour-level rounding

Match the format the related <local_datetime> block uses (hour-rounded). Within a given hour, requests would share bytes; across hours, cache misses are bounded.

Any of these would unlock cross-request cache_control reuse for high-volume consumers.

Related issues

• SDK 0.3.0 regression: per-turn mutating state in <system_reminder> block defeats Anthropic prompt cache #1296: the broader regression on per-turn mutating session state inside <system_reminder>. Maintainer suggested this <current_datetime> concern be tracked separately.

Versions

• Confirmed in: @github/copilot-sdk 0.3.0 + @github/copilot 1.0.40
• Last verified unfixed in: SDK 1.0.0-beta.4 + CLI 1.0.47