Repository navigation
framework: a turn's continuation records no undo checkpoint, so an undo after a budget restart takes the whole turn - #1017
Conversation
…do after a restart takes the whole turn A budget restart at a tool boundary, a tool-result-guard retry, the direct API's tool_results_ready and a held call's retry (TURN_RETRY) each start a stream of their own at attempt 0, and each recorded a turn checkpoint; only the guard retry was excepted. An undo after one took back the rows since that start, the reply, and left the round's tool call and its result in the window, which the next request still carried (anima-research#1013, reproduced by nissa-seru on main and on our host). A start that carries the logical turn on (isTurnContinuation, or isTurnRetry) records none now, so undoLastTurn walks back to the turn's first checkpoint. The redo stack is still cleared on every attempt-0 start, as new work. A budget refusal of a continuation has no checkpoint of its own to drop, which holdForBudgetRefusal already allows for. Test on turn-continuation's restartTurn harness: after the restart and the reply, one checkpoint; the undo leaves the window where it stood before the turn, three or more rows gone, and the next request carries neither the tool round nor the reply. Fixes anima-research#1013. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SkepYxcPem6pmgRxKd2RBY
|
Automatic review of About these findingsThe findings below came from reading this PR and relevant code; not a holistic understanding of the project's functional intent and its architecture choices. Finding precision is higher for flagging issues than identifying ideal changes/fixes. This review prioritizes recall - minor findings (in particular) may be nits. Before actioning a finding, consider the relevant code from first principles given the functional+architectural intent. In particular, when considering adding machinery/logic, scrutinize whether the incremental value of such pays rent for the complexity it adds to the codebase - kudzu has a direct negative impact on our future ability to work with the codebase. Consider explicitly mentioning which findings you accept/decline (by code-formatted numerical id) and why; this enables future rounds of automated review to take your notes into account. Findings, most severe first:
|
|
Automatic context view of What a context view runs and what its checks judge: CHECKS.md. The records of 1 of the 80 runs differ between the base and this head. All 4 of this change's changed source lines that map to code ran in at least one profiled drive. 9 changed source lines map to nothing the host runs: 9 of Parts left out where an arm's stack doesn't bring what they need: Separately, 1 of the checks' flags differs between the base and the head, in 1 run; it's listed under "Checks' flags that differ", below. Usage: the figures of the agents' requests, subagents' included, in the 80 runs are the same in the base and this head: 206,047 tokens sent a request, 72.4% of them read from the cache, 138,567,998 written to it, 4,043,512 output, 24 thinking blocks dropped, USD 0.5446 at list price a priced request and 123 requests with no list price. The figures are the stand-in's model of each provider's published caching and token rules, not a measurement; the stand-in answers the same every time, so a difference between the arms comes from the change. A list price is what each arm's host prices those figures at with its own table (connectome-host's Context in the 80 runs: in each run, the number of seams, the tokens in the parts they changed or took out, the most one agent request held and the number of summariser requests stayed the same. What these count. No model read these records for this view, which started on its own. A view asked for with a Runs whose records differ: 1 of 80
Checks' flags that differ (1)
Upgraded runs beside their fresh twins
A run that writes its own history first, as a fresh twin does, is shown without that history's requests, so its figures are its workload's alone, as the upgraded runs' are. Changed source lines and deletions not seen to run, by file
Held the same in base and head: connectome-host |
Fixes #1013.
A budget restart at a tool boundary, a tool-result-guard retry, the direct API's
tool_results_readyand a held call's retry (TURN_RETRY) each start a stream of their own atattempt === 0, and each recorded a turn checkpoint; only the guard retry was excepted. An undo after one took back the rows since that start, the reply, and left the round's tool call and its result in the window, which the next request still carried: William's reproduction onmain, and ours on connectome-host 0.24.1 / openai-codex, where every tool-calling turn restarts at every boundary against the 150k stream budget.Change. A start that carries the logical turn on (
isTurnContinuation(reason), orisTurnRetry(trigger)) records no checkpoint, soundoLastTurnwalks back to the turn's first. The redo stack is still cleared on every attempt-0 start, as new work. A budget refusal of a continuation has no checkpoint of its own to drop, whichholdForBudgetRefusalalready allows for (checkpoint !== undefined).This takes the first of the two shapes we asked about in #1013 (the restart's start as a continuation of the logical turn for undo). If "
/undotook the last round only" is the behaviour you'd rather keep and say, this PR is easy to turn into that instead.Test, on
turn-continuation.test.ts'srestartTurnharness (wait: false, run toinference:turn_ended): two streams, one checkpoint; the undo leaves the window at its pre-turn length with three or more rows gone; the next request carries neithertool_usenortool_resultnor the reply. Without the change the same test readsundoDepth: 2and one row retracted.Changelog fragment included.
🤖 Generated with Claude Code
https://claude.ai/code/session_01SkepYxcPem6pmgRxKd2RBY