Problem or Use Case

In long-lived gateway sessions (multi-day Telegram/Discord topics), the agent loses accurate sense of the current date and time. The system prompt's date is set once at session start and never refreshed. After 24-48h the agent can confidently reference the wrong day e.g. treating late Monday as Sunday because the session started Sunday.

This is a silent failure: the agent doesn't know it's wrong, and the user only notices when the agent says something temporally inconsistent.

Prior Art in the Codebase

_prepare_inbound_message_text() in gateway/run.py already prepends contextual metadata to inbound messages:

if _is_shared_thread and source.user_name:
    message_text = f"[{source.user_name}] {message_text}"

A timestamp prefix follows the exact same pattern.

Proposed Solution

Add a config option that prepends a compact timestamp to every inbound message:

gateway:
  message_timestamp_prefix: true   # default: false

When enabled, every message becomes:

[04-14 23:47] hey, what day is it?

Format: [MM-dd HH:mm] in UTC, or optionally timezone-aware if gateway.timezone is already configured.

This gives the model an accurate, always-fresh temporal anchor on every turn without:

• Extra API calls
• Session resets
• Prompt cache busting (it's in the user turn, not the system prompt)
• Any hook/plugin complexity

Implementation Sketch

In _prepare_inbound_message_text(), after the sender attribution block:

if self.config.get("gateway", {}).get("message_timestamp_prefix", False):
    from datetime import datetime, timezone
    _ts = datetime.now(timezone.utc).strftime("%m-%d %H:%M")
    message_text = f"[{_ts}] {message_text}"

~4 lines. The config key follows existing gateway config conventions.

Alternatives Considered

• Midnight cron injecting date into active sessions - works but requires infrastructure, still leaves up to 24h gap for idle sessions
• Refreshing system prompt date on each turn - busts Anthropic prompt cache, adds cost
• Hook/plugin approach - hooks are fire-and-forget with no return value, can't mutate message_text; would require injecting an extra history entry instead, which is less clean

Feature Type

Gateway / messaging improvement

Scope

None

Contribution

• I'd like to implement this myself and submit a PR

Debug Report (optional)