rea/experiments/atomic-codemode/savepoint-control-study.md

# Real-agent savepoint control investigation

The [question and oracle](savepoint-control-oracle.md) were committed at
`e2205313a` before either model launch. Both lanes have the same atomic facts,
target, engine, question and common envelope/stopping guidance. They start with
the function name and two messages, without supplied code addresses. This tests
the newly available full recovered graph, not provider parity or superiority
over a traditional RE interface.

## Initial pair: natural discovery

Both complete answers pass the frozen source/answer review:

- Incoming string references select `0xea6d0` from two same-name entries before
  one retained VM capture. Neither lane fetches the complete C report or graph.
- Both format pointers merge through `0xf238b:ceb7` and reach CALL
  `0xf238b:7130`, with the correct predecessor/edge bindings and RSI storage.
- Each answer supplies both successor edges for each nearest local conditional
  predecessor. The open guard is signed four-byte `0 < loaded32`; release is
  four-byte equality to one. Both trace one-byte Booleans to the right LOADs,
  preserve operand indexes/widths and stop before guessing loaded contents.
- Focused instruction windows check loads, the spill, signed JG/equality JZ,
  format setups and shared machine CALL. Independent GNU/ELF verification checks
  eleven instruction sites against the same target bytes. PHI/edge identities
  remain separate from machine instructions and transfers.
- Real source IDs and the target digest are present. Each answer limits itself
  to recovered graph/local guards and states machine-flow, alias,
  nontermination, earlier-path and runtime-feasibility limits. Neither uses
  derived controllers or claims a SQL trigger. Both close the lease.

Each answer cites ten observed source IDs. Both have one successful VM capture,
whose recovered graph equals the complete producer golden; facts come from the
preserved `677b9795...` engine. Full answers, events, tool context, traces and
resource receipts are retained locally under
`.cache/atomic-codemode/sqlite-savepoint-control-{direct,codemode}-v1*`.

| Whole-task measure                | Direct atomic | Code Mode |
| --------------------------------- | ------------: | --------: |
| Cumulative input tokens           |       515,024 |   610,715 |
| Included cached input             |       466,304 |   563,328 |
| Uncached input                    |        48,720 |    47,387 |
| Output tokens                     |         5,537 |     6,345 |
| Included reasoning output         |         1,344 |     1,502 |
| Observed model responses          |            17 |        18 |
| MCP attempts, including rejection |            24 |        15 |
| Successful atomic fact reads      |            20 |        21 |
| Model wall seconds                |       206.269 |   223.636 |
| Family wall seconds               |       207.427 |   224.133 |
| Family CPU seconds                |        53.794 |    52.777 |
| Kernel process-family peak MiB    |         874.9 |     883.2 |

Code Mode's fifteen attempts include a rejected `timeout_ms:200000` request;
the actual schema maximum is 120,000. It retries within that bound. The client
also initially tries to JSON-parse the validation error's text and gets a
SyntaxError. Both costs remain in the ledger. There are no recorded inner-API
failures or resource aborts. Direct has no failed MCP attempt. MCP attempts,
successful host reads, client execution calls and model responses are distinct
counts; the trace has no handler entry for the schema rejection.

In this one sample, Code Mode reduces uncached input by about 2.7% but increases
cumulative input by 18.6%, output by 14.6% and model wall time by 8.4%. Fewer MCP
requests do not establish a whole-task advantage. The lanes also choose slightly
different fact selections and output detail. This is an observational pair,
not a controlled estimate of a single dispatch mechanism's causal effect.

The first client discovery call in both lanes applies a broad `rea.*...` regular
expression to all tool names/descriptions. It matches unrelated tools, including
creation tools, and prints large, truncated metadata. This is a real observed
agent cost, not an analysis-provider failure; it also adds noise to comparing
the two interfaces. A repeat should give both lanes the same exact-name discovery
policy while retaining every advertised tool and charging that guidance to the
whole task. No analysis steps, addresses or answers should be added.

Both runs request `gpt-6.1-sol/high` through Codex 0.161.0; the resolved service
build is unknown. Per-response usage sums match the runner ledger. Cached input
is already included in input, and reasoning is included in output. One CPU,
4 GiB hard / 3 GiB early-stop limits apply. Kernel peak includes charged file
cache; it is not RSS. Both runs have OOM 0, verified payload/profile cleanup,
unchanged runtime fingerprints, engine and target digests. Each lease is fresh;
OS/provider-service caches and remote compute costs are uncontrolled/unmeasured.

## Discovery-controlled repeat

Executed at `7a7c4a6d7`, Code Mode first, then direct. The repeat keeps the same
question, oracle, native engine and all atomic methods, and uses the runner's existing
`--enabled-tools` / `--guide-enabled-tools` options with server name `rea`.
Each manifest lists that lane's complete catalog: seventeen direct tools or four
Code Mode tools. No analysis method is removed. Captured first client calls
select these exact function names; neither repeats the broad metadata spill.
This changes discovery guidance and namespace together for both lanes; it is a
separate stratum from the natural-discovery pair, not a retroactive replacement.

Both complete answers again pass the same oracle: correct format ownership,
PHI/call and native edges, signed-positive versus equality guards, Boolean/load
widths and operand indexes, independent selected machine bytes, real provenance
and explicit static/alias/runtime limits. Both use one retained VM capture and
close the lease. Direct cites ten observed source IDs; Code Mode cites nine,
combining some instruction windows. All recovered graph and ordinary function
fields equal the earlier full golden in both lanes. Neither fetches a whole C
report or graph. Neither uses derived controllers; both keep local guards
separate from all earlier conditions and runtime feasibility.

| Whole-task measure             | Direct atomic | Code Mode |
| ------------------------------ | ------------: | --------: |
| Cumulative input tokens        |       538,013 |   608,622 |
| Included cached input          |       457,088 |   530,688 |
| Uncached input                 |        80,925 |    77,934 |
| Output tokens                  |         5,150 |     5,989 |
| Included reasoning output      |           697 |     1,462 |
| Observed model responses       |            19 |        25 |
| MCP attempts                   |            24 |        13 |
| Successful atomic fact reads   |            20 |        18 |
| Model wall seconds             |       187.544 |   266.141 |
| Family wall seconds            |       188.086 |   266.650 |
| Family CPU seconds             |        52.113 |   102.739 |
| Kernel process-family peak MiB |         859.1 |     883.1 |
| VM source-capture wall seconds |        37.026 |   107.804 |

There are no failed MCP attempts, recorded inner-API failures or resource aborts.
Per-response usage sums agree; OOM is zero, cleanup is verified, and target,
engine and runtime fingerprints remain unchanged. Full records use suffix `-v2`
under the same local artifact directory. Request/model settings and resource
bounds are unchanged from the first pair.

Code Mode again has slightly lower uncached input (3.7%) and fewer MCP requests,
but more cumulative input, output, model responses, wall time and family CPU in
this sample. It has twelve client waits versus three for direct. Discovery
guidance alone has not established an overall improvement across strata.

The VM capture is a substantial confound: its 107.804 seconds differs from
37.026 in direct and 38.013/38.871 in the first pair. Source elapsed time includes
command supervision and retention; it is not an isolated native drive interval.
No per-command CPU or phase diagnostic was captured during these model trials.
The additional instruction-window API call overlapped the pending Code Mode
snapshot; its own wall time also includes waiting beyond the retained native
source times. Whether concurrency, host contention or another lower boundary
caused the variation is unresolved. CPU affinity/quota do not give an exclusive
core. Do not subtract these intervals from whole-task time to manufacture a
Code Mode speedup or attribute the difference to dispatch alone.

Both lanes actually use the client's `exec`/`wait` JavaScript surface, despite
the recorded client Code Mode feature flags being false. Direct atomic already
composes MCP calls through that client executor. These results compare a server
Code Mode boundary against directly called atomic MCP tools in that environment;
they do not compare JavaScript composition against its absence. Tool counts and
configured feature flags cannot establish the client's actual available surface.

## Remaining questions

Four real runs establish this scoped control/data-flow task on the full recovered
graph, without a stable overall efficiency win. There is no traditional-provider
cell for this graph-identity question and no general complex-software superiority
claim. Whole-task cumulative input across all four runs is 2,272,374 tokens,
including 2,017,408 cached and 254,966 uncached; output is 23,021 including 5,005
reasoning tokens. Total model wall is 883.590 seconds. These totals retain the
initial failed request and discovery costs, not a pooled treatment estimate.

The retained graph also exposes the next coverage question: `0xea801:fe` is one
`CPUI_BRANCHIND` in block 8 with 149 recovered successors. Current edges expose
identities/destinations but no case values. The native jump-table owner should
be examined before exporting case-to-edge/target relations; a successor ordinal
is not a case value. This is a fact-export limitation, not evidence that Kuna
itself cannot recover the labels. The source-capture/concurrent-read cost
variation also needs a bounded, matched diagnostic before further speed claims.
The [subsequent four-case public MCP diagnostic](overlap-study.md) confirms
provider admission is serialized and does not reproduce the long capture;
the original cause remains unknown rather than being declared fixed.
The [native switch extension](switch-study.md) now exports the case labels and
checks all 182 original targets independently; its new model question is separate.