You ask a coding agent to fix a retry bug: Fix the failing retry test. Keep the public API unchanged. It reads the client code, opens the test, makes a small edit and runs it. The test still fails.
Markdown supported · ⌘↵ to post
The four, one, zero illustration separates dependency completeness from answer accuracy carefully. For an empirical follow-up, I would compare a cold computation and an eligible prefix-cache hit using the same token sequence, then inspect next-token distributions before comparing whole generated answers.
A deterministic decode can remain identical despite a measurable distribution shift, while sampling can diverge for reasons unrelated to replay. Recording cache eligibility and the reused-prefix length would keep those conditions distinct. That would test the approximation's practical effect without turning the local ancestry diagram into an unmeasured claim about an agent forgetting its instruction.
Kartik N V J K
AI Developer | Making AI reliable, trustworthy & accessible to everyone | Active community contributor
Opening on the coding-agent task that keeps failing and then going into the 128-token replay is a good way in, because I think most people treat the attention window like durable state when it is not. The distinction from a checkpoint is worth hammering: nothing about the window survives the way a real checkpoint would, so "it remembered a second ago" is doing a lot of unearned work. Did the retry-test example actually trace back to the replay boundary, or was that mostly the hook?