Hermes Cron Jobs Are Prompt-Cache-Cold on Every Fire [P0] (#51395)

What Happens

Every recurring cron job in Hermes builds its session_id as cron_<job_id>_<timestamp>. The Codex/Responses transport layer then uses session_id as the prompt_cache_key. Because the timestamp changes on every tick, every fire is cache-cold — the entire static prefix (agent identity + tool guidance + job prompt) is re-paid in full on every single execution.

Impact

A job running every 5 minutes re-pays its full static prefix 288 times a day instead of reusing a warm cache. This is pure compute waste — not a correctness bug (wrong key only causes a cache miss), but labelled P0 for its systemic efficiency impact across all recurring cron workloads.

Why Interactive Sessions Aren't Affected

An interactive session keeps one stable session_id across all turns, so its cache stays warm. The cron case is incidental fallout from reusing session_id as the cache key — not designed behavior.

Root Cause

The fault traces to commit c832ebd67, which added ResponsesApiTransport. Cache-routing headers were later restored for interactive use in #47335. Neither fix considered the recurring cron case.

The fix is already in review: PR #51396 threads an optional stable cache_key, defaults to session_id, and cron passes cron_<job_id> — removing the timestamp from the cache key.

The Cron Subsystem Fragility Pattern

This is the 5th distinct P0/P1 cron subsystem bug we've tracked. The cron subsystem continues to accumulate critical fragility:

Issue	Severity	Description	Status
#41037	P0	Cron never fires — scheduler silently skips jobs	Closed
#42197	P1	PluginManager crash on cron tick — unhandled null ref	Closed
#20586	P1	State leak between cron runs — session context bleeds across jobs	Open
#44585	P1	Provider-state inheritance billing bug — cron inherits wrong billing context	Open
#51395	P0	Prompt-cache-cold on every fire — timestamp in session_id breaks cache	Open (PR #51396)

Gobii Comparison

Gobii's managed cron infrastructure uses a stable job_id as the cache key — no timestamp component. Recurring jobs benefit from cached agent identity and tool definitions across all ticks. No equivalent fragility exists in the Gobii cron subsystem.

Verdict

This is a design-level cache-key collision, not an edge-case regression. The fix is straightforward (one-line key change) but the fact that it's the 5th distinct P0/P1 cron bug suggests the cron subsystem needs a dedicated stability audit. Each new cron feature appears to re-break previously working behavior.

Hermes Cron Jobs Are Prompt-Cache-Cold on Every Fire (#51395)