Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
No
Summary
Prompt-cache read tokens can drop sharply on repeated Azure OpenAI Responses turns even when OpenClaw reports no tracked cache input change.
Steps to reproduce
- Run repeated same-session OpenClaw agent turns against Azure OpenAI Responses with prompt-cache observability enabled.
- Keep the tracked cache inputs unchanged between adjacent calls.
- Observe
[prompt-cache] cache read dropped ...; no tracked cache input change in the gateway logs.
Expected behavior
When the same session keeps the tracked prompt-cache inputs stable, OpenClaw should keep the OpenAI-compatible request payload prefix stable so cache-read tokens do not sharply drop for an untracked payload-order change.
Actual behavior
Gateway logs show prompt-cache read drops even though the diagnostic reports no tracked cache input change.
OpenClaw version
NOT_ENOUGH_INFO
Operating system
NOT_ENOUGH_INFO
Install method
NOT_ENOUGH_INFO
Model
azure-openai-responses/gpt-5.3-codex
Provider / routing chain
OpenClaw -> Azure OpenAI Responses
Additional provider/model setup details
The observed request route was boundary-aware:openai-responses. Private session, job, and local setup identifiers are omitted.
Logs, screenshots, and evidence
[prompt-cache] cache read dropped 793472 -> 649216 for azure-openai-responses/gpt-5.3-codex via boundary-aware:openai-responses; no tracked cache input change
[prompt-cache] cache read dropped 822400 -> 325888 ...; no tracked cache input change
[prompt-cache] cache read dropped 1228160 -> 414336 ...; no tracked cache input change
Impact and severity
Affected: same-session OpenAI-compatible Responses runs using prompt caching.
Severity: Medium.
Frequency: 44 observed log lines matching prompt-cache in the local evidence bundle.
Consequence: cache efficiency can drop sharply without an actionable tracked-input explanation, increasing latency/cost and hiding the request payload ordering cause from diagnostics.
Additional information
Current code tracked the tool set as sorted names, but OpenAI Responses and Chat Completions payload builders serialized tools in caller order. If the same tool set arrived in a different order, request bytes changed while the prompt-cache diagnostic still reported no tracked cache input change.
Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
No
Summary
Prompt-cache read tokens can drop sharply on repeated Azure OpenAI Responses turns even when OpenClaw reports no tracked cache input change.
Steps to reproduce
[prompt-cache] cache read dropped ...; no tracked cache input changein the gateway logs.Expected behavior
When the same session keeps the tracked prompt-cache inputs stable, OpenClaw should keep the OpenAI-compatible request payload prefix stable so cache-read tokens do not sharply drop for an untracked payload-order change.
Actual behavior
Gateway logs show prompt-cache read drops even though the diagnostic reports no tracked cache input change.
OpenClaw version
NOT_ENOUGH_INFO
Operating system
NOT_ENOUGH_INFO
Install method
NOT_ENOUGH_INFO
Model
azure-openai-responses/gpt-5.3-codex
Provider / routing chain
OpenClaw -> Azure OpenAI Responses
Additional provider/model setup details
The observed request route was
boundary-aware:openai-responses. Private session, job, and local setup identifiers are omitted.Logs, screenshots, and evidence
Impact and severity
Affected: same-session OpenAI-compatible Responses runs using prompt caching.
Severity: Medium.
Frequency: 44 observed log lines matching
prompt-cachein the local evidence bundle.Consequence: cache efficiency can drop sharply without an actionable tracked-input explanation, increasing latency/cost and hiding the request payload ordering cause from diagnostics.
Additional information
Current code tracked the tool set as sorted names, but OpenAI Responses and Chat Completions payload builders serialized tools in caller order. If the same tool set arrived in a different order, request bytes changed while the prompt-cache diagnostic still reported no tracked cache input change.