openclaw - 💡(How to fix) Fix Allow cron payloads to specify a stable prompt_cache_key independent of per-run sessionId [1 comments, 2 participants]

curoda · 2026-05-02T18:57:23Z

[openclaw] When a cron job runs against an OpenAI responses-API model e.g. openai/gpt-5.5 , OpenClaw sets prompt cache key = options.sessionId provider-stream-… When a cron job runs against an OpenAI responses-API model (e.g. `openai/gpt-5.5`), OpenClaw sets `prompt_cache_key = options.sessionId` (`provider-stream-CiQISJm-.js:1376`). Cron runs are spawned with isolated session ids of the form `agent: :cron: :run: `, where ` ` is unique per execution. Result: every cron run gets a fresh `prompt_cache_key`, OpenAI's prompt cache (24h TTL) never matches across runs, and the same recurring prompt is billed at full input price every time. By contrast, Anthropic's automatic prefix caching IS hit across runs (because it works on prefix hash, not session id), so the same cron costs ~10% as much on Anthropic vs paid OpenAI. ## Fix / Workaround ## Workarounds (each has drawbacks) ## Summary When a cron job runs against an OpenAI responses-API model (e.g. `openai/gpt-5.5`), OpenClaw sets `prompt_cache_key = options.sessionId` (`provider-stream-CiQISJm-.js:1376`). Cron runs are spawned with isolated session ids of the form `agent: :cron: :run: `, where ` ` is unique per execution. Result: every cron run gets a fresh `prompt_cache_key`, OpenAI's prompt cache (24h TTL) never matches across runs, and the same recurring prompt is billed at full input price every time. By contrast, Anthropic's automatic prefix caching IS hit across runs (because it works on prefix hash, not session id), so the same cron costs ~10% as much on Anthropic vs paid OpenAI. ## Concrete impact In one user's environment, 2 high-frequency crons (`*/15 * * * *` with `lightContext: true`) were observed at: - Anthropic Opus 4.7: ~9 to 11 input tokens billed per run (rest cached). - OpenAI GPT-5.5 (responses API): ~104K to 125K input tokens billed per run, 0% cache reuse. That is roughly a 10,000x billable-input ratio for the same prompt. Combined with reasoning tokens billed at output rate, this drove ~$70 of unintended OpenAI spend across 2 days from cron jobs that the user expected to be cheap. ## Workarounds (each has drawbacks) 1. `sessionTarget: "session: "` to keep the sessionId stable across runs. Side effect: conversation history accumulates inside that session over time, defeating the clean-state intent of cron jobs. 2. Pin every cron to a non-OpenAI provider. Works, but loses the option of using OpenAI for crons that genuinely benefit from it. 3. Avoid making OpenAI the agent defaults primary while any cron uses it. ## Proposed feature Allow cron payloads (and ideally any `agentTurn` payload) to set an explicit `promptCacheKey` (or `cacheKey`) value that overrides the default `sessionId`-based key. The intended pattern: a cron job sets `promptCacheKey: "cron: "` once, and every run of that job hits the same OpenAI cache entry as long as the prompt prefix is stable. This should compose with the existing `cacheRetention` controls and respect provider compatibility (`compat.supportsPromptCacheKey`). ## Optional second improvement Consider warning at config-validation time when a cron payload pins a model id that isn't in the registered model catalog. Today such pins silently fall back to agent defaults (`[cron] payload.model 'X' not allowed, falling back to agent defaults` only appears in gateway.err.log at runtime), which made the cost incident much harder to predict and diagnose. ## Environment - OpenClaw 2026.4.25 - macOS 25.3.0 arm64 - Models involved: `openai/gpt-5.5` (responses API), `anthropic/claude-opus-4-7`, `anthropic/claude-sonnet-4-6`

openclaw2026-05-02 18:57:23

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#76218•Fetched 2026-05-03 04:40:34

View on GitHub

Comments

Participants

Timeline

Reactions

Author

curoda

Participants

clawsweeper[bot]

curoda

Timeline (top)

commented ×1cross-referenced ×1

When a cron job runs against an OpenAI responses-API model (e.g. openai/gpt-5.5), OpenClaw sets prompt_cache_key = options.sessionId (provider-stream-CiQISJm-.js:1376). Cron runs are spawned with isolated session ids of the form agent:<agent>:cron:<jobId>:run:<runId>, where <runId> is unique per execution. Result: every cron run gets a fresh prompt_cache_key, OpenAI's prompt cache (24h TTL) never matches across runs, and the same recurring prompt is billed at full input price every time.

By contrast, Anthropic's automatic prefix caching IS hit across runs (because it works on prefix hash, not session id), so the same cron costs ~10% as much on Anthropic vs paid OpenAI.

Root Cause

By contrast, Anthropic's automatic prefix caching IS hit across runs (because it works on prefix hash, not session id), so the same cron costs ~10% as much on Anthropic vs paid OpenAI.

Fix Action

Fix / Workaround

Workarounds (each has drawbacks)

RAW_BUFFERClick to expand / collapse

Summary

By contrast, Anthropic's automatic prefix caching IS hit across runs (because it works on prefix hash, not session id), so the same cron costs ~10% as much on Anthropic vs paid OpenAI.

Concrete impact

In one user's environment, 2 high-frequency crons (*/15 * * * * with lightContext: true) were observed at:

Anthropic Opus 4.7: ~9 to 11 input tokens billed per run (rest cached).
OpenAI GPT-5.5 (responses API): ~104K to 125K input tokens billed per run, 0% cache reuse.

That is roughly a 10,000x billable-input ratio for the same prompt. Combined with reasoning tokens billed at output rate, this drove ~$70 of unintended OpenAI spend across 2 days from cron jobs that the user expected to be cheap.

Workarounds (each has drawbacks)

sessionTarget: "session:<stable-id>" to keep the sessionId stable across runs. Side effect: conversation history accumulates inside that session over time, defeating the clean-state intent of cron jobs.
Pin every cron to a non-OpenAI provider. Works, but loses the option of using OpenAI for crons that genuinely benefit from it.
Avoid making OpenAI the agent defaults primary while any cron uses it.

Proposed feature

Allow cron payloads (and ideally any agentTurn payload) to set an explicit promptCacheKey (or cacheKey) value that overrides the default sessionId-based key. The intended pattern: a cron job sets promptCacheKey: "cron:<jobId>" once, and every run of that job hits the same OpenAI cache entry as long as the prompt prefix is stable.

This should compose with the existing cacheRetention controls and respect provider compatibility (compat.supportsPromptCacheKey).

Optional second improvement

Consider warning at config-validation time when a cron payload pins a model id that isn't in the registered model catalog. Today such pins silently fall back to agent defaults ([cron] payload.model 'X' not allowed, falling back to agent defaults only appears in gateway.err.log at runtime), which made the cost incident much harder to predict and diagnose.

Environment

OpenClaw 2026.4.25
macOS 25.3.0 arm64
Models involved: openai/gpt-5.5 (responses API), anthropic/claude-opus-4-7, anthropic/claude-sonnet-4-6

extent analysis

TL;DR

Set an explicit promptCacheKey value in cron payloads to override the default sessionId-based key and enable cache reuse across runs.

Guidance

Consider implementing the proposed feature to allow cron payloads to set an explicit promptCacheKey value, such as promptCacheKey: "cron:<jobId>", to enable cache reuse across runs.
Evaluate the workarounds provided, such as setting sessionTarget: "session:<stable-id>", pinning crons to non-OpenAI providers, or avoiding OpenAI as the primary provider for agents with cron jobs.
Review the cron job configuration to ensure that the prompt prefix remains stable across runs to maximize cache reuse.
Monitor the cost impact of cron jobs and adjust the configuration as needed to minimize unintended spend.

Example

// Example cron payload with explicit promptCacheKey
const cronPayload = {
  // ...
  promptCacheKey: `cron:${jobId}`,
  // ...
};

Notes

The proposed feature requires implementation and testing to ensure compatibility with existing cacheRetention controls and provider compatibility.

Recommendation

Apply workaround: Set sessionTarget: "session:<stable-id>" to keep the sessionId stable across runs, despite the side effect of accumulating conversation history. This is a temporary solution until the proposed feature is implemented.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

#api #conversation history #authentication setup #request error #file not found

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Data

Security

Network

Code

UI/UX

Text

System

Multimedia

Protocol

API

Engineering

openclaw - 💡(How to fix) Fix Allow cron payloads to specify a stable prompt_cache_key independent of per-run sessionId [1 comments, 2 participants]

Recommended Tools

GitHub issue graph ai analysis

Root Cause

Fix Action

Fix / Workaround

Workarounds (each has drawbacks)

Summary

Concrete impact

Workarounds (each has drawbacks)

Proposed feature

Optional second improvement

Environment

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

Still need to ship something?

TRENDING

openclaw - 💡(How to fix) Fix Allow cron payloads to specify a stable prompt_cache_key independent of per-run sessionId [1 comments, 2 participants]

Recommended Tools

GitHub issue graph ai analysis

Root Cause

Fix Action

Fix / Workaround

Workarounds (each has drawbacks)

Summary

Concrete impact

Workarounds (each has drawbacks)

Proposed feature

Optional second improvement

Environment

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

Still need to ship something?

RELATED_DISCOVERY

TRENDING