Summary

OpenClaw appears to inject a volatile Current time: ... line into heartbeat, cron, and post-compaction prompt content in a way that likely reduces prompt-cache reuse for those turns.

The main concern is not timezone metadata, but exact wall-clock time being inserted into cache-sensitive prompt prefixes.

Why this matters

Prompt caching works best when the front of the prompt remains stable.
If a changing Current time: ... line is included early in the prompt body on every heartbeat/cron/event turn, it can invalidate cache reuse for everything that follows.

This likely causes unnecessary cache churn and higher cost / latency for recurring automated runs.

What I found

Stable timezone in system prompt

There is a stable section in the system prompt builder:

• ## Current Date & Time
• Time zone: ...

That part looks fine and likely remains cacheable.

Volatile current-time helper

There is a helper at:

• /app/dist/current-time-BkqyYDci.js

It generates a line like:

• Current time: ... (userTimezone) / ... UTC

Where the volatile line is appended

I found this exact wall-clock line being appended in at least these flows:

• heartbeat runner
• cron/system-event execution
• post-compaction context refresh

Relevant built artifacts observed locally:

• /app/dist/current-time-BkqyYDci.js
• /app/dist/heartbeat-runner-dPEnJvN2.js
• /app/dist/server.impl-B-xK231T.js
• /app/dist/model-context-tokens-BFDIhVvJ.js

Recommendation

Best fix

Keep stable timezone metadata in the static/system prompt, but move per-turn wall-clock time out of cache-sensitive prompt prefixes.

In practice:

1. Keep Time zone: ... in stable prompt context
2. Inject exact Current time: ... as late as possible
3. Only include exact wall-clock time when the turn truly needs it
4. Avoid baking fresh time into post-compaction injected blocks unless necessary

Expected benefit

• Better prompt cache reuse on heartbeat/cron/automation turns
• Lower token cost
• Lower latency
• No loss of timezone awareness

Possible implementation principle

Keep stable user timezone in the static prompt, but move per-turn wall-clock time out of cache-sensitive prompt prefixes and into late-bound runtime/event content only when needed.

Notes

This may not be harming cache reuse for the entire main chat prompt, but it does look like a legitimate optimization target for recurring automation/event turns.