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

New issue

Closed

opened 2026-08-23 19:21:08 +00:00 by john · 0 comments

john commented

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

Owner

Blocked by #242. Do not start this until the trace records cache figures. The fix here is one line, but shipping it unmeasured reproduces the exact problem #242 describes: a change argued from byte layout, with no before/after to confirm it recovered anything.

The rung label at line 2 of every agent body places a per-rung divergence ahead of the role's ~11 KB contract, so no two rungs of a role can share a cached prefix.

Measured

Every non-base rung differs from its role's base rung by exactly one changed line, in all six roles:

< Your rung is `high`.
---
> Your rung is `xhigh`.

Its position is the defect, not its existence. It sits at line 2 of a 177-byte agent body, and the contract below it is 11,235 bytes (skills/cad-planner-contract/SKILL.md). The divergence therefore falls roughly 100 bytes into the assembled prefix, and the ~11 KB of identical contract beneath it is byte-for-byte a different prefix in every rung of the same role.

Verified clean alongside it: no agent file or contract carries a run-varying construct (no @-include, shell substitution, date, or absolute path); concatenated hash is stable at ee05ec19d28862867d4399d55668262a5032b7f2e5ddd22d47c1c65a97540525. tools: is byte-identical within every role. Every rung references exactly one contract, its own role's.

Why this is latent, not live

Over the last 400 trace events every role dispatches exactly one rung, so no two rungs of a role currently run and the divergence costs nothing today. The full 1,858-event record shows two or three rungs per role, but that spread is historical - config changed across milestones - and a whole-file count cannot tell that from alternation happening now.

It becomes live under either of two configuration changes:

model.escalate_on_failure: true, which makes a failed dispatch retry on a different rung file - a fully cold ~11 KB prefix on top of an already-failed dispatch, which is the worst moment to pay for one.
changing any model.effort.<role> pin mid-cycle, which strands whatever the previous rung had warmed.

Fix

Move the rung label below the contract reference, or delete it. One line, six roles, no behavior change: the frontmatter's effort: already carries the rung, and nothing in the contracts branches on the prose line.

Scope note

This is a structural claim - the byte layout forecloses sharing - and not a measured hit rate. Whether the harness would otherwise attempt cross-agent prefix reuse is not observable from the repository. See the companion issue on recording cache figures in the trace.

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

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

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

> **Blocked by #242.** Do not start this until the trace records cache figures. The fix here is one line, but shipping it unmeasured reproduces the exact problem #242 describes: a change argued from byte layout, with no before/after to confirm it recovered anything. The rung label at line 2 of every agent body places a per-rung divergence ahead of the role's ~11 KB contract, so no two rungs of a role can share a cached prefix. ## Measured Every non-base rung differs from its role's base rung by exactly one changed line, in all six roles: ``` < Your rung is `high`. --- > Your rung is `xhigh`. ``` Its position is the defect, not its existence. It sits at line 2 of a 177-byte agent body, and the contract below it is 11,235 bytes (`skills/cad-planner-contract/SKILL.md`). The divergence therefore falls roughly 100 bytes into the assembled prefix, and the ~11 KB of identical contract beneath it is byte-for-byte a different prefix in every rung of the same role. Verified clean alongside it: no agent file or contract carries a run-varying construct (no `@`-include, shell substitution, date, or absolute path); concatenated hash is stable at `ee05ec19d28862867d4399d55668262a5032b7f2e5ddd22d47c1c65a97540525`. `tools:` is byte-identical within every role. Every rung references exactly one contract, its own role's. ## Why this is latent, not live Over the last 400 trace events every role dispatches exactly one rung, so no two rungs of a role currently run and the divergence costs nothing today. The full 1,858-event record shows two or three rungs per role, but that spread is historical - config changed across milestones - and a whole-file count cannot tell that from alternation happening now. It becomes live under either of two configuration changes: - `model.escalate_on_failure: true`, which makes a failed dispatch retry on a different rung file - a fully cold ~11 KB prefix on top of an already-failed dispatch, which is the worst moment to pay for one. - changing any `model.effort.<role>` pin mid-cycle, which strands whatever the previous rung had warmed. ## Fix Move the rung label below the contract reference, or delete it. One line, six roles, no behavior change: the frontmatter's `effort:` already carries the rung, and nothing in the contracts branches on the prose line. ## Scope note This is a structural claim - the byte layout forecloses sharing - and not a measured hit rate. Whether the harness would otherwise attempt cross-agent prefix reuse is not observable from the repository. See the companion issue on recording cache figures in the trace. Spike record: `.planning/spikes/agent-prefix-cache-fragmentation/SPIKE.md` (commit 77b50148). --- **Moved to GitHub: https://github.com/crenshawdev/cadence/issues/91** This project's tracker is now GitHub; this repository remains the public archive. Closed here as migrated, not as resolved.