Ruiteng Huang · Updated October 28, 2026 · Kernel engineering and research
-Inside the LoopX control-plane kernel
-Useful continuation, faithful recovery, and complete cost
-Running longer should produce useful later work and retain its results. The control plane’s own cost has to earn its place.
-Long EdgeBench traces exposed control-plane problems: work changed direction before its original Turn closed; a smaller context entry increased full recovery delivery; one read repeatedly checked the same runtime. This article follows three repairs through their shared semantic owners, what they resolve, and what remains unproven.
-1. What should the kernel improve?
+Ruiteng Huang · October 29, 2026
What does an agent achieve with ten more hours?
How EdgeBench reshaped the LoopX control plane
A research run can start ahead, then barely improve for ten hours. It can keep changing code and lose its best result. These failures made us revisit goals, feedback, experiment size and recovery.
The work began with trace diagnosis in early October: repair evaluation and continuation, follow evidence into the next experiment, then charge the control plane for its own cost. This account follows that progression, including results that challenged the approach.
Here, kernel means LoopX’s shared goal, admission, transaction and recovery rules. LoopX keeps the original goal, acceptance conditions, work ownership and evidence durable across sessions and hosts. Its control plane constrains state transitions and supplies feedback for the model’s next choice. It does not certify that the choice is insightful. A recorded finding, a read receipt and a replan entry are intermediate evidence; the relevant chain ends in actual work and a validated outcome.
-The TypeScript refactor article explains ownership and model-assisted semantic repair. Below, we examine continuation correctness, complete delivery cost and host read cost separately.
+The TypeScript refactor article explains ownership and model-assisted semantic repair. Below, we follow how these rules affect actual research work.
- GoalAcceptance and scope
- EvidenceResults and limitations
- DecisionContinue or change course
- WorkExecute and validate
- RetentionKeep the best valid result
We separate three observations: an initial advantage, an improvement obtained later, and retention of the best validated artifact. A higher final score can come almost entirely from a stronger starting point. A better intermediate candidate can disappear from the terminal workspace. More runtime, Todos or graph nodes establish none of these outcomes.
-2. A new route exists. What closes the original work?
-A review can conclude that a route lacks evidence and create a successor validation task. That task now exists, but the review itself still needs writeback and settlement. If another admission read immediately selects the successor, the model receives conflicting identities: the completed review belongs to the old Turn, while the new task appears to own the current work. Another model wake does not resolve that conflict.
-#7269 converges the control plane’s continuation semantics. Creating a successor proves a route was recorded; it neither settles the original Turn nor authorizes the successor’s execution. The existing TypeScript replan-transition and quota-settlement owners retain the creation receipt, original obligation and Turn binding. A same-Turn reread returns the original settlement steps. After writeback, only settlement remains; after settlement, this Turn stops. The successor stays open for fresh admission.
-This also requires separating must_attempt from delivery_allowed. The former requires addressing this Turn’s work obligation; the latter describes permission for ordinary delivery. A required replan can have legitimate planning work while ordinary delivery remains closed. Opening ordinary execution merely to make the agent act would be an authority bug. Leases, budgets, stops and admission for the successor retain their existing owners.
Real File / SQLite CLI regressions create a successor and execute the returned writeback and settlement commands unchanged. Premature spending is rejected, repeated settlement produces one debit, and the successor does not replace the original Turn. A later Turn selects the new task. Negative cases change ownership, defer the task or remove its claim; an invalidated creation receipt cannot settle the original result. These checks exercise the state transition and real entrypoint, beyond one field or ACK.
-The repair keeps model attention on the next useful test and removes opportunities for repeated identity negotiation and admission. It does not guarantee insightful subsequent research. We still follow evidence through a decision, actual work and native outcomes. The same-checkpoint observations provide limited positive evidence and contrary results.
-3. Does a smaller context cost less to deliver completely?
+1. The research progression
| Period | Focus | Change | Implementation |
|---|---|---|---|
| Early October | Feedback and starting conditions | Repair blind-run prompts, ledger and recovery defects; establish original-task, scoring and continuation boundaries. | #5586, #5844 |
| October 9–11 | Original goals and useful feedback | Preserve full evaluation responses, candidate identity and original requirements; implementation or submission is not Goal acceptance. | #6031, #6039, #6133, #6199 |
| October 12–16 | Experiment size and recovery points | Replace mechanical shrinking with grow / switch / verify; jointly preserve conversation, candidates, evaluation opportunities and budget; switch context before replanning. | #6298, #6321, #6305, #6622, #6649 |
| Mid-to-late October | Later progress and best retention | Separate starting advantage, subsequent gain and retained best in common windows; Schema exposes high cost and stalled progress. | #6440, #6532, #6671 |
| October 22–28 | Complete control-plane cost | Reduce passive polling and repeated reads; inspect original-Turn closeout, full context, invalid-baseline fallback and recovery cost. | #6983, #7013, #7036, #7197, #7269 |
Cases are selected for mechanism changes and intelligible failures. PRs anchor phases rather than form an exhaustive daily release log. Dates describe research phases; linked records retain creation, merge and historical qualification details.
2. First make the feedback trustworthy
+The first Portfolio experiments exposed measurement and execution defects before they could tell us much about strategy. A blind wrapper had removed iterative optimization guidance along with the judge entrypoint. A ledger check attributed earlier market returns to holdings bought only at the closing price. Both confounded the intended comparison; repairing them required new attempts while preserving the old results.
+One small oracle made the accounting error clear. Start with 100,000 cash, buy 100 units at a closing price of 200, and pay 10 commission. Immediate equity is 99,990 and NAV is 0.9999; the new holding did not earn the preceding rise from 100. Independent reconciliation then matched all 243 days in each of two frozen samples, with equity residual below 4×10⁻⁹ and no share-count difference. This established ledger consistency, not investment skill. The versioned repair is documented in EdgeBench #14.
+Continuation had a related failure: an outer process could wake repeatedly after a work item ended without recovering a useful next action. The governing question must return to the original goal. Completing a Todo can justify another experiment, waiting, or completion; it cannot by itself settle goal acceptance. Correct recovery and feedback make subsequent research interpretable.
+Early system progress was measurable
+| Blind Lean raw score | Early Resume v14 | Later Resume (#5844) | Early Explore v14 | Later Explore (#5844) |
|---|---|---|---|---|
| 180 minutes | 0.1103 | 0.3478 | 0.1134 | 0.4019 |
| 450 minutes | 0.1882 | 0.5243 | 0.1996 | 0.5605 |
These single-run common windows show roughly 2.8–3.5 times the earlier raw scores. Prompts, task entry, runner reliability and LoopX mechanisms changed together. The observation supports progress in the overall system; it does not identify one mechanism’s causal effect or guarantee terminal performance elsewhere.
+Comparison boundaries
Historical studies include Official, single-call, native Goal, LoopX Resume and LoopX Explore. Explore adds optional evidence capture and planning to continued work. Blind runs retain public tasks, training data and local validators but receive no hidden judge scores or diagnostics; background operator evaluation is not solver feedback. Later native-feedback studies use agent-requested evaluation, a one-hour accepted-submission cooldown and no periodic grading. These are different studies, not one pooled treatment.
Models, effort, prompts, runners and budgets co-evolved. Early studies primarily used Sol/xhigh; later Sol/max and Astra/xhigh cohorts retain their own conditions. One run per arm is descriptive evidence. Missing, stopped, invalid and valid-zero results stay distinct. Source time, evaluation opportunities and cooldown survive checkpoint continuation; donor history is not a new independent repetition.
3. Finishing its own checklist without finishing your goal
+A research goal asks for a better algorithm. The agent decomposes it into implementation, testing and submission. All three Todos finish and the outer loop stops, although the improvement question remains unanswered. Another form of drift promotes an agent’s provisional local proxy threshold into a hard constraint on further research.
+#6133 distinguishes original goals and hard constraints from provisional candidate filters, calls for discriminating executed-artifact evidence, and retains scoped negative results. #6199 carries the original research task through startup, the Goal and recovery: implementation, testing and submission are milestones rather than acceptance. #6649 checks what actually reaches replanning, instead of substituting a generic reminder or truncating useful scoped evidence.
+Persisting the goal makes it retrievable. Delivering it into the next decision gives it a chance to shape subsequent work. The host still enforces deadlines and stops. Goal continuity neither permits indefinite execution nor guarantees a good idea.
4. After failure, take a smaller step—or ask a different question?
+Always shrinking after failure can trap an agent in local repairs. An implementation error and evidence against an entire mechanism require different responses.
+#6298 separated work size, route distance and validation extent. #6321 then replaced mechanical grow / hold / shrink mapping with grow / switch / verify: extend a supported route, switch a refuted mechanism, or perform a discriminating experiment. Each route needs a concrete plan. A work unit must be large enough to complete a meaningful test; shorter per-turn text is not that unit.
+For example, if a solver helps only on highly repetitive inputs, the next useful step might test how benefit depends on repetition before adopting a selector—or retain the old solver. This illustrates the decision distinction, rather than claiming a PR demonstrated general benefit. Explore findings must return to later reviews for assessment of adoption, new information and experiment consequences. A justified continuation need not change direction to raise a replan count.
+These are optional planning mechanisms. Enabling them still requires checking actual decisions and subsequent outcomes; registering a plan does not demonstrate improvement.
5. What must a recovered research run remember?
+Copying candidate code preserves only part of the research state. Forget evaluation opportunities already consumed, reset the cooldown or exclude recovery time, and a supposedly matched continuation quietly receives extra resources.
+#6305 brings conversation, candidates, Explore, Goal, evaluation best, opportunities, cooldown and budget into one checkpoint. Writers pause and the checkpoint is sealed before decisions are released against it. #6622 moves fresh-session switching before replanning: if the old context already chose the route, switching afterward cannot answer how fresh context affects that decision.
+This contract enables a more focused comparison after one research point: what each arm read, chose, executed and retained. It does not erase model, effort or runner differences, nor turn continuations from one donor into independent repetitions. Unknown recovery qualification remains unknown.
6. Hours later: a better start or new progress?
+Later experiments shifted the emphasis to work after many hours. We compare a common observation window, then inspect the initial result, later increments and retained candidate. A final ranking alone hides these differences.
+| Historical cohort | Observed result | Interpretation |
|---|---|---|
| Sol/xhigh, old/new LoopX, Ad Placement · 14h | 49,589,589,573 → 49,615,495,839 | Newer run trailed at 2h and led at 14h; its terminal workspace matched its retained best |
| Astra/xhigh, Official Grid · 6h → 12h | 1862 → 1810, lower is better | A stronger foundation baseline still produced useful late improvements |
Ad Placement provides a concrete instance of later progress rather than a universal plateau. A worse subsequent candidate was rejected and the best version survived. Its raw-score lead is modest—about 0.052%—and only that arm has the cited terminal-workspace verification. The old/new packages changed core and runner together, so this is not an isolated LoopX-feature effect.
+The Astra result expands the foundation-model frontier in our observations. Official separated speed changes from search changes and obtained successive native improvements. That progress belongs to the foundation/Official path; it cannot be credited to LoopX. Stronger models also raise the standard for a useful harness: context and review costs must earn their place against an improving baseline.
+Schema: an initial lead is not sustained improvement
+Schema is the detailed counterexample. In the Sol old/new 14-hour window, the newer run scored 0.804620 versus 0.723684. It already led at the first native result, 0.794620 versus 0.713158, received at different elapsed times. Subsequent increments were only 0.010000 and 0.010526. The larger endpoint advantage mostly reflected the initial result; continuing code changes did not close the six original target requirements.
+A separate Astra/xhigh 12-hour comparison was less favorable: Official reached 0.881813 and LoopX 0.786257, with neither improving its best between 6h and 12h. LoopX recorded 36 completed compactions versus four, and about 5.32 times the uncached input. Compaction can overlap useful work, and versions, recovery, shared load and scorer conditions differ. The trace still identifies the practical challenge: producing more changes and more control activity did not produce more accepted value.
+Conditions and limits of these windows
The Sol old/new study used planned + Explore, Sol/xhigh, TurnEnvelope off, agent-requested native feedback and a one-hour cooldown. The 14-hour window was selected after earlier observations as the largest whole hour below the earliest actual termination; it was not an 18-hour completion. The separate Astra study compares each arm’s own first 12 outer hours, including preparation. The Sol window reconciles 7,522 unique responses and 52 received native results; Astra reconciles 5,277 responses and 45 results. Cumulative counters were not repeatedly added; reasoning is included in output. Historical infrastructure failures and unknown whole-run integrity remain recorded. Different treatments, adaptive restarts and a prior operator exposure to an Official terminal aggregate prevent a clean causal verdict.
7. What does the control plane itself cost?
Another faulty assumption is that a smaller entry packet means a cheaper agent episode. Moving the goal, facts and writer instructions behind a second command shortens the first view, but the model still needs to read them. Losing context adds reconstruction of the same source. Measuring only entry delivery moves cost outside the table.
#7269 routes the original capture through a shared context reader: complete goals, facts and feedback first; writer format and settlement steps afterward. Review and writeback are two views of one immutable decision, rather than a second admission or two permission owners. Source regressions compare the goal, planning horizon, evidence references, complete writeback contract and action signature. A smaller entry must still reach every obligation.
Differencing adds a prerequisite: the receiver must retain the exact baseline. Within the same native session and context epoch, the current Hook path treats normal tool delivery after complete paging as an engineering assumption of continuity. Session changes, observed compaction, missing pages and known delivery failures invalidate it. Recovery then reads the original complete capture; a fresh decision from another guard cannot recover the old one. Missed hooks and unseen downstream truncation remain limits. A read receipt is not independent proof of model retention.
@@ -59,50 +72,7 @@Measure structural input separately
Historical offline replay illustrates why totals matter: structured Host and native presentation bytes fell 57.72% and 60.23%, while native entry plus full recovery rose 6.37%. These are historical byte observations, not current-head model-token results. An earlier offline probe also reported a 2.25% increase in CLI bytes, but its qualification as an actual CLI delivery measurement was withdrawn: it omitted final CLI compaction and reformatted entry output. That figure remains only as an invalid historical measurement and supports no complete-delivery or cost conclusion. A 60% smaller view cannot be reported as 60% lower total cost.
Our current efficiency work connects ordinary and staged delivery to the shared transport, reduces repeated reads and rebinding, and removes avoidable settlement round trips. The default with differencing off matters as much as the opt-in path. Enabled delivery also has to recover correctly and remain easy to activate across the product and benchmark. The reference of 15% for all mechanisms combined remains unqualified; it is neither a separate allowance per mechanism nor a reason to omit failures or reconstruction.
-4. Why check one runtime repeatedly during one read?
-Some overhead belongs to the control plane itself. Reading an Explore context makes several calls to the same managed TS runtime. The Python transport checks its source fingerprint for each call; a request with many quantified findings repeatedly inspects the same source tree. The slow path is a real control-plane read, rather than model inference or the research algorithm.
-#7013 reuses the existing effect_runtime_request_scope around explore_turn_context. One logical request resolves one runtime revision, and its internal calls use that code version. A finally block releases and resets the scope; the next request resolves afresh. The reused value is runtime code identity, not Goal state or research results cached across requests. TS owners still execute shared rules; Python removes repeated transport work.
The original PR measured real isolated CLI calls with 600 synthetic findings. Across three uninstrumented samples after separate warmup, medians changed from 4.005 to 0.495 seconds for File, and 4.268 to 0.603 seconds for SQLite, using Node 24.21, SQLite 3.53 and Python 3.14.8. Complete JSON and source-log bytes stayed equal. This is host latency on a specified historical workload, rather than a current-version remeasurement or eightfold whole-agent acceleration.
-Regressions independently check that the next request sees a new finding, malformed history still fails, the failed request clears its scope, and a subsequent read recovers after source repair. The old version fails the one-fingerprint-per-request counterexample. A permanent cache could also look faster while losing these boundaries.
-The direct value is obtaining the same decision input sooner while preserving freshness on the next request. Whether less waiting yields more validated work still needs a complete trajectory. This case measures neither lower model input nor fees.
-5. Did the repairs produce long-horizon value?
-The counterexamples above establish specific improvements to identity, reading and recovery. Effectiveness still depends on actual subsequent work. Early Lean showed system progress; Ad showed a late lead and retention of its best result. Schema exposed an initial advantage followed by little growth and high control cost. Same-checkpoint #7269 continuation reduced initial review round trips, yet Grid’s complete usage later increased. The original numbers, windows and negative results remain below, without pooling them into one mechanism’s benefit.
-Feedback and continuation: early system comparisons
-How the research changed
-| Stage | Question | What the evidence can establish |
|---|---|---|
| Feedback and continuation | Can we trust results and keep authorized work useful? | Evaluator defects, recovery failures and common-window system progress |
| Later decisions | Does accumulated evidence improve the next experiment? | Decision-to-work traces and changes after a mature research point |
| Context efficiency | Can we deliver the same obligations with less complete cost? | Actual model input, recovery, tool calls and outcome/cost comparisons |
Comparison boundaries
Historical studies include Official, single-call, native Goal, LoopX Resume and LoopX Explore. Explore adds optional evidence capture and planning to continued work. Blind runs retain public tasks, training data and local validators but receive no hidden judge scores or diagnostics; background operator evaluation is not solver feedback. Later native-feedback studies use agent-requested evaluation, a one-hour accepted-submission cooldown and no periodic grading. These are different studies, not one pooled treatment.
Models, effort, prompts, runners and budgets co-evolved. Early studies primarily used Sol/xhigh; later Sol/max and Astra/xhigh cohorts retain their own conditions. One run per arm is descriptive evidence. Missing, stopped, invalid and valid-zero results stay distinct. Source time, evaluation opportunities and cooldown survive checkpoint continuation; donor history is not a new independent repetition.
First make feedback and continuation trustworthy
-The first Portfolio experiments exposed measurement and execution defects before they could tell us much about strategy. A blind wrapper had removed iterative optimization guidance along with the judge entrypoint. A ledger check attributed earlier market returns to holdings bought only at the closing price. Both confounded the intended comparison; repairing them required new attempts while preserving the old results.
-One small oracle made the accounting error clear. Start with 100,000 cash, buy 100 units at a closing price of 200, and pay 10 commission. Immediate equity is 99,990 and NAV is 0.9999; the new holding did not earn the preceding rise from 100. Independent reconciliation then matched all 243 days in each of two frozen samples, with equity residual below 4×10⁻⁹ and no share-count difference. This established ledger consistency, not investment skill. The versioned repair is documented in EdgeBench #14.
-Continuation had a related failure: an outer process could wake repeatedly after a work item ended without recovering a useful next action. The governing question must return to the original goal. Completing a Todo can justify another experiment, waiting, or completion; it cannot by itself settle goal acceptance. Correct recovery and feedback make subsequent research interpretable.
-Early system progress was measurable
-| Blind Lean raw score | Early Resume v14 | Later Resume (#5844) | Early Explore v14 | Later Explore (#5844) |
|---|---|---|---|---|
| 180 minutes | 0.1103 | 0.3478 | 0.1134 | 0.4019 |
| 450 minutes | 0.1882 | 0.5243 | 0.1996 | 0.5605 |
These single-run common windows show roughly 2.8–3.5 times the earlier raw scores. Prompts, task entry, runner reliability and LoopX mechanisms changed together. The observation supports progress in the overall system; it does not identify one mechanism’s causal effect or guarantee terminal performance elsewhere.
-Initial advantage, later improvement and retention
-Look beyond the first good result
-Later experiments shifted the emphasis to work after many hours. We compare a common observation window, then inspect the initial result, later increments and retained candidate. A final ranking alone hides these differences.
-| Historical cohort | Observed result | Interpretation |
|---|---|---|
| Sol/xhigh, old/new LoopX, Ad Placement · 14h | 49,589,589,573 → 49,615,495,839 | Newer run trailed at 2h and led at 14h; its terminal workspace matched its retained best |
| Astra/xhigh, Official Grid · 6h → 12h | 1862 → 1810, lower is better | A stronger foundation baseline still produced useful late improvements |
Ad Placement provides a concrete instance of later progress rather than a universal plateau. A worse subsequent candidate was rejected and the best version survived. Its raw-score lead is modest—about 0.052%—and only that arm has the cited terminal-workspace verification. The old/new packages changed core and runner together, so this is not an isolated LoopX-feature effect.
-The Astra result expands the foundation-model frontier in our observations. Official separated speed changes from search changes and obtained successive native improvements. That progress belongs to the foundation/Official path; it cannot be credited to LoopX. Stronger models also raise the standard for a useful harness: context and review costs must earn their place against an improving baseline.
-Schema: an initial lead is not sustained improvement
-Schema is the detailed counterexample. In the Sol old/new 14-hour window, the newer run scored 0.804620 versus 0.723684. It already led at the first native result, 0.794620 versus 0.713158, received at different elapsed times. Subsequent increments were only 0.010000 and 0.010526. The larger endpoint advantage mostly reflected the initial result; continuing code changes did not close the six original target requirements.
-A separate Astra/xhigh 12-hour comparison was less favorable: Official reached 0.881813 and LoopX 0.786257, with neither improving its best between 6h and 12h. LoopX recorded 36 completed compactions versus four, and about 5.32 times the uncached input. Compaction can overlap useful work, and versions, recovery, shared load and scorer conditions differ. The trace still identifies the practical challenge: producing more changes and more control activity did not produce more accepted value.
-Conditions and limits of these windows
The Sol old/new study used planned + Explore, Sol/xhigh, TurnEnvelope off, agent-requested native feedback and a one-hour cooldown. The 14-hour window was selected after earlier observations as the largest whole hour below the earliest actual termination; it was not an 18-hour completion. The separate Astra study compares each arm’s own first 12 outer hours, including preparation. The Sol window reconciles 7,522 unique responses and 52 received native results; Astra reconciles 5,277 responses and 45 results. Cumulative counters were not repeatedly added; reasoning is included in output. Historical infrastructure failures and unknown whole-run integrity remain recorded. Different treatments, adaptive restarts and a prior operator exposure to an Official terminal aggregate prevent a clean causal verdict.
Same-checkpoint review: actual work and complete input
-Ask whether evidence changed the next work
+Same-checkpoint continuation: outcomes and complete usage
Ask whether evidence changed the next work
A mature checkpoint helps inspect a specific decision boundary. Both receivers inherit the same scientific state and incumbent; we then follow the evidence they read, the experiment they choose, the work they actually perform and the native feedback. A negative local result can be useful if it rules out a branch under stated conditions. Replanning need not force a direction change when continuing is justified.
Recent work on #7269 makes the reader first consume the goal, facts and feedback, then the writeback format. It also releases obsolete task-selection preference and preserves the original Turn settlement after a successor is created. This addresses two observed sources of wasted interaction: reading writer instructions before deciding, and needing another round to resolve which work was settled.
| Same-point Sol/max continuation | Baseline → revised | Boundary | |
|---|---|---|---|
| Schema revised | 622,478 (−26.52%) | 37,570,432 (−7.75%) | 113,162 (−0.45%) |
This observation covers the common 82m27s outer window through October 25, 15:42:31 UTC: initial recovery, review, ordinary work and persisted requests in unfinished Turns. Retained native counters from all four stopped arms were reconciled against their shared donor boundaries, with no counter gaps. Last persisted requests differ by up to 2m22s; unpersisted usage remains unknown. Grid’s revised arm used more of all three components; Schema’s did not increase. In the earlier 68m26s window, Grid’s uncached input fell 7.25%; the longer common window reverses that to a 3.60% increase. Choosing only the earlier window would misrepresent the result. Local review savings have not established net savings for the complete episode.
-6. Context validation starts from zero
-The current context study starts Grid, Schema and Ad Placement from their original tasks with Sol/max and an 18-hour upper limit per case. Historical Official or older LoopX runs provide descriptive references where usable. Their model/effort, source, scorer, opportunity and clock differences remain visible; they are not strict matched controls. A new baseline is warranted where the old material cannot answer the relevant question. Attempts with different source versions, continuity bases or transports are analyzed separately, rather than pooled as one treatment.
+Recent implementation details, in their historical place
A new route exists. What closes the original work?
+A review can conclude that a route lacks evidence and create a successor validation task. That task now exists, but the review itself still needs writeback and settlement. If another admission read immediately selects the successor, the model receives conflicting identities: the completed review belongs to the old Turn, while the new task appears to own the current work. Another model wake does not resolve that conflict.
+#7269 converges the control plane’s continuation semantics. Creating a successor proves a route was recorded; it neither settles the original Turn nor authorizes the successor’s execution. The existing TypeScript replan-transition and quota-settlement owners retain the creation receipt, original obligation and Turn binding. A same-Turn reread returns the original settlement steps. After writeback, only settlement remains; after settlement, this Turn stops. The successor stays open for fresh admission.
+This also requires separating must_attempt from delivery_allowed. The former requires addressing this Turn’s work obligation; the latter describes permission for ordinary delivery. A required replan can have legitimate planning work while ordinary delivery remains closed. Opening ordinary execution merely to make the agent act would be an authority bug. Leases, budgets, stops and admission for the successor retain their existing owners.
Real File / SQLite CLI regressions create a successor and execute the returned writeback and settlement commands unchanged. Premature spending is rejected, repeated settlement produces one debit, and the successor does not replace the original Turn. A later Turn selects the new task. Negative cases change ownership, defer the task or remove its claim; an invalidated creation receipt cannot settle the original result. These checks exercise the state transition and real entrypoint, beyond one field or ACK.
+The repair keeps model attention on the next useful test and removes opportunities for repeated identity negotiation and admission. It does not guarantee insightful subsequent research. We still follow evidence through a decision, actual work and native outcomes. The same-checkpoint observations provide limited positive evidence and contrary results.
+Why check one runtime repeatedly during one read?
+Some overhead belongs to the control plane itself. Reading an Explore context makes several calls to the same managed TS runtime. The Python transport checks its source fingerprint for each call; a request with many quantified findings repeatedly inspects the same source tree. The slow path is a real control-plane read, rather than model inference or the research algorithm.
+#7013 reuses the existing effect_runtime_request_scope around explore_turn_context. One logical request resolves one runtime revision, and its internal calls use that code version. A finally block releases and resets the scope; the next request resolves afresh. The reused value is runtime code identity, not Goal state or research results cached across requests. TS owners still execute shared rules; Python removes repeated transport work.
The original PR measured real isolated CLI calls with 600 synthetic findings. Across three uninstrumented samples after separate warmup, medians changed from 4.005 to 0.495 seconds for File, and 4.268 to 0.603 seconds for SQLite, using Node 24.21, SQLite 3.53 and Python 3.14.8. Complete JSON and source-log bytes stayed equal. This is host latency on a specified historical workload, rather than a current-version remeasurement or eightfold whole-agent acceleration.
+Regressions independently check that the next request sees a new finding, malformed history still fails, the failed request clears its scope, and a subsequent read recovers after source repair. The old version fails the one-fingerprint-per-request counterexample. A permanent cache could also look faster while losing these boundaries.
+The direct value is obtaining the same decision input sooner while preserving freshness on the next request. Whether less waiting yields more validated work still needs a complete trajectory. This case measures neither lower model input nor fees.
+8. Context deltas: qualification gaps recorded on October 28
+The context study recorded on October 28 starts Grid, Schema and Ad Placement from their original tasks with Sol/max and an 18-hour upper limit per case. Historical Official or older LoopX runs provide descriptive references where usable. Their model/effort, source, scorer, opportunity and clock differences remain visible; they are not strict matched controls. A new baseline is warranted where the old material cannot answer the relevant question. Attempts with different source versions, continuity bases or transports are analyzed separately, rather than pooled as one treatment.
First verify that actual delivery changes: the initial full read, a subsequent delta with its continuity basis stated, complete fallback after known baseline loss, and a full review-to-work interaction. Then compare useful progress, retained artifacts and the complete usage vector. Requested flags, receipts and smaller local packets cannot substitute for that evidence. If the feature fails its intended behavior, stop the affected attempt, preserve its costs and history, repair it and use a new attempt identity.
The first Grid and Ad interactions on the new native Hook path have completed full paging, one delta and subsequent task work. Within each same capture, the delta payload was 19.53% and 19.48% smaller than its corresponding full packet. These are single-read payload comparisons: they exclude page envelopes, subsequent model input, hooks, recovery and review costs. They do not establish lower total cost. A complete review-to-native-outcome cycle, sustained benefit and failure recovery remain to be verified.
Our effectiveness target is useful progress after many hours and reliable retention of it. Our efficiency target is comparable accepted value with less complete cost and human attention. The next result must address both. Current runs retain the original deadline, and failed or replaced attempts retain their costs and history.
-