trace.jsonl records no cache figures, so prompt-cache claims cannot be measured #242

New issue

Closed

opened 2026-08-23 19:21:12 +00:00 by john · 1 comment

john commented

2026-08-23 19:21:12 +00:00

Owner

trace.jsonl records tokens and turns on a dispatch bracket but no cache figures, so no claim about prompt-cache behavior in this repository can be measured before or after a change.

The gap

The bracket close carries --tokens <figure on the subagent return> and --turns <tool-call count>. A cache hit rate is computed from cache_read_input_tokens and cache_creation_input_tokens, and Cadence stores neither.

The consequence is not abstract. The companion issue on the rung-label position argues from byte layout alone, because that is the only kind of evidence available: it can show that a shared prefix is foreclosed, and it cannot show what that costs, or whether the fix recovered anything. The same applies to every future claim about dispatch cost - workflow.max_dispatch_tokens reads a terminal-window proxy and says nothing about what was re-sent versus re-read from cache.

What would close it

Capture the two cache fields on the same return the tokens figure already comes from, and carry them on trace close beside --tokens. The existing omission rule applies unchanged: a return carrying no cache figures omits the flags rather than passing zeroes, since a dispatch that reported none is different from one that read nothing from cache.

trace render then has the inputs for a per-role hit rate, which is what makes a layout change like the companion issue's falsifiable rather than argued.

Spike record: .planning/spikes/agent-prefix-cache-fragmentation/SPIKE.md (commit 77b50148).

Moved to GitHub: https://github.com/crenshawdev/cadence/issues/92

This project's tracker is now GitHub; this repository remains the public archive. Closed here as migrated, not as resolved.

`trace.jsonl` records `tokens` and `turns` on a dispatch bracket but no cache figures, so no claim about prompt-cache behavior in this repository can be measured before or after a change. ## The gap The bracket close carries `--tokens <figure on the subagent return>` and `--turns <tool-call count>`. A cache hit rate is computed from `cache_read_input_tokens` and `cache_creation_input_tokens`, and Cadence stores neither. The consequence is not abstract. The companion issue on the rung-label position argues from byte layout alone, because that is the only kind of evidence available: it can show that a shared prefix is foreclosed, and it cannot show what that costs, or whether the fix recovered anything. The same applies to every future claim about dispatch cost - `workflow.max_dispatch_tokens` reads a terminal-window proxy and says nothing about what was re-sent versus re-read from cache. ## What would close it Capture the two cache fields on the same return the `tokens` figure already comes from, and carry them on `trace close` beside `--tokens`. The existing omission rule applies unchanged: a return carrying no cache figures omits the flags rather than passing zeroes, since a dispatch that reported none is different from one that read nothing from cache. `trace render` then has the inputs for a per-role hit rate, which is what makes a layout change like the companion issue's falsifiable rather than argued. Spike record: `.planning/spikes/agent-prefix-cache-fragmentation/SPIKE.md` (commit 77b50148). --- **Moved to GitHub: https://github.com/crenshawdev/cadence/issues/92** This project's tracker is now GitHub; this repository remains the public archive. Closed here as migrated, not as resolved.

john added the

enhancement

label

2026-08-23 19:21:12 +00:00

john referenced this issue

2026-08-23 19:24:59 +00:00

Rung label at body line 2 forecloses cross-rung prefix sharing (latent) #241

john commented

2026-08-23 19:24:59 +00:00

Author

Owner

Sequencing: this gates #241. #241's fix is one line and its benefit is argued entirely from byte layout - moving a divergent line above an 11 KB contract - with no measured hit rate behind it, because the record cannot currently produce one. Landing #242 first is what makes #241 verifiable instead of plausible.