Compaction boundary absent from the in-memory message list → prefix trim defers forever with no recovery; pressure escalation frozen on incremental event-payload usage

[Sugaroverdose]

A long session (v0.43.2, MC-managed mode) froze at 100% context after an
app restart + session resume. The historian was healthy (pointer
advanced to the tail, zero failed runs); the problem was entirely in
two MC-internal paths. Timestamps UTC; session id redacted.
1. Dangling boundary → silent infinite defer (prefix-trim path).
The session's compaction boundary (a message id in session meta) was
not present in the in-memory "current messages" list after a session
resume — the resumed list held 58–115 of the session's ~574 messages,
and the boundary anchored a message outside that window in every app
instance across ~3 h (surviving multiple restarts). Log:

[09-25 23:46:02.224Z] [ses_…] transform stage: stage=findSessionId elapsed=0.3ms messages=58
[09-25 23:46:02.275Z] [ses_…] transform: first pass reset — percentage=45.3% — clearing stale usage state
[09-25 23:46:02.494Z] [ses_…] prefix trim: boundary msg_0a5836bd… absent from current messages; pass=priced; no in-pass trim applied
…94 consecutive passes, identical shape…
[09-26 02:24:48.635Z] [ses_…] prefix trim: boundary msg_0d5f1939… absent from current messages; pass=defer; no in-pass trim applied

Untrimmed, the wire carried the full raw history, which grew each turn
to the context limit (stored tokens.total: 158,958 → 160,268 →
165,394 → 169,812 → 262,145; limit 262,144). A fresh restart re-aligned
the in-memory window and the first pass trimmed normally:

[09-26 02:49:20.759Z] [ses_…] transform: final-wire telemetry estimate=160884 trusted=true conversation=59723 …
[09-26 02:50:06.672Z] [ses_…] event message.updated: totalInputTokens=80538 contextLimit=258978 percentage=31.1%

The code (v0.43.2 dist, index-g6hpfkqa.js):

// :35357-35366 — the prefix-trim path: a single failed lookup, refused, on every pass
} else {
  const index = findBoundaryIndex(options.sessionId, options.messages, boundary);
  if (index >= 0) {
    options.messages.splice(0, index + 1);
    status = "applied";
  } else {
    sessionLog(..., `prefix trim: boundary ${boundary} absent from current
      messages; pass=…; no in-pass trim applied`);
    status = "refused";           // silently terminal — no counter, no re-anchor
  }
}

Note: this is the same failure shape as #264 ("Degraded mode in
inject-compartments has no recovery path when boundary is outside the
visible window", fixed in v0.33.1) — but in a path the fix did not
reach. The sibling inject-compartments path in v0.43.2 ships the full
recovery ladder, in the same file:

// :33772-33799 — inject-compartments path (the #264 fix): counted, re-anchors, falls back
} else {
  const degradedCount = noteDegradedRebuild(sessionId);
  if (degradedCount === 1) reconcileForkOrphanedCompactionMarkers(db, sessionId);
  let reAnchored = false;
  if (degradedCount >= REANCHOR_MIN_DEGRADED_PASSES && isCacheBusting) {
    …
    logReanchorOnce(…`compartment injection re-anchored: natural boundary
      ${trimEndMessageId} not visible for ${degradedCount} passes; splicing
      at visible compartment boundary ${resultEndMessageId}`);
  }
  if (!reAnchored) {
    needsFreshMaterialization = true;
    logReanchorOnce(…`compartment injection degraded: … requesting fresh
      materialization to re-cut the baseline`);
  }
}

Suggested behavior: port that ladder to the prefix-trim path — a
failed lookup is a counted degraded state, not a terminal refusal.
Secondary hardening, same direction: make the cut total by using the
boundary's position in MC's own persistent order (the ordinal space
the historian reads — on the session above the pointer reached 497 of
574 while loaded windows held only 58–115) as the cut coordinate, so a
window that starts entirely after the boundary yields [summary] + [whole window] instead of "absent"; the boundary ID then serves as an
integrity check (no longer resolves → visible "boundary stale" +
re-compaction from list head). (The existing prefixTrimSourceOrder
position-cut mechanism is a close primitive, but it is armed only when
a deferred history refresh is pending and captures the live window as
its coordinate system — which, when the window starts after the
boundary, refuses just as silently.)
2. Pressure escalation runs on incremental event-payload usage, not
final cumulative usage.
The v0.43.2 pressure formula does include cache.write
(index.js:40923: input + cache.read + cache.write) — the undercount
is in the payload it reads. Verbatim, the final call of the frozen
window (same timestamp, two sources):

[09-26 02:29:10.414Z] [ses_…] event message.updated: … hasUsageTokens=true
                             tokens.input=2398 cache.read=165393 cache.write=0
[09-26 02:29:10.414Z] [ses_…] event message.updated: totalInputTokens=167791
                             contextLimit=214982 percentage=78.0%
[09-26 02:29:10.521Z] [ses_…] transform scheduler: percentage=78.0% inputTokens=167791 … decision=execute

versus the final stored usage for that same call (opencode store):
tokens.input=89,167, tokens.total=262,145 — the true prompt size,
≈100% of the 262,144 limit. The message.updated payload is an
incremental reading (new input this call + cache hits), while the
stored usage is the cumulative prompt; MC's pressure state is built
from the former (index.js:40980-40985 → contextUsageMap → scheduler
→ latch):

// index.js:40923-40934
const totalInputTokens = (info.tokens?.input ?? 0)
  + (info.tokens?.cache?.read ?? 0) + (info.tokens?.cache?.write ?? 0);
const pressureInputTokens = usageReadingValid ? totalInputTokens : 0;
// :40980-40985
const percentage = contextLimit > 0 ? pressureInputTokens / contextLimit * 100 : 0;
deps.contextUsageMap.set(info.sessionID, { usage: { percentage, inputTokens: pressureInputTokens }, … });

The emergency drain latch arms at max(85, threshold+2) percent
(index.js:39898) — at the true ~100% it should have armed and
bypassed the drain budget; at the frozen 78% it never did
(emergency_drain_active stayed 0 for the whole window). Compounding:
limit-resolution drift (the same session resolved 214,982, then
258,978, then 262,144 across passes) makes the percentage
pass-dependent.
Suggested behavior: build the pressure/escalation state from the
cumulative final usage of completed calls (the value the host stores
per message — tokens.total above), with the message.updated
streaming payload kept for live display only; the
terminalAssistantUpdate completion hook (index.js:40897) is the
natural point to fetch it.
This cannot cause spurious compaction: the cumulative total is the
ground-truth prompt size — the reading moves toward reality, never
above it (the non-cached portion persists as cache on the next turn,
so the cumulative total is a floor on next turn's pressure, not a
transient spike). And the denominator is already floored
(index.js:40978: contextLimit = max(contextLimit, provenSafeInputTokens)), so the limit cannot resolve below a
proven-safe input and manufacture a high-percentage reading; the
residual limit drift is in the under-escalation direction (safe). The
reading can only rise to the true value, and it fires only in the
regime that needs the rescue.

[magic-alfonso]

Thanks for the detailed report and the log lines; they make both parts easy to follow.

Part 1 is confirmed on master. When the compaction boundary isn't in the current message list, the prefix-trim branch in inject-compartments.ts logs prefix trim: boundary … absent from current messages and returns refused. It keeps no counter and doesn't re-anchor or fall back, so a resumed session whose window starts after the boundary sends its full raw history on every pass. You're right that the #264 recovery ladder lives in the sibling injection path and never reached this one. We're fixing it now, starting with a failing test in your shape: a resumed window that starts after the boundary. We're also looking at your suggestion to treat "boundary before the whole window" as a successful trim ("nothing to cut") rather than a failure, and keeping the counted degraded path only for a boundary that is genuinely unknown. The fix follows the cache rules: nothing changes the served bytes except on a pass that is already rebuilding the cache. We'll also check what makes the resumed list start after the boundary in the first place.

Part 2 we're checking against OpenCode's source before changing anything. We want to pin down exactly what the message.updated token fields and the stored tokens.total each measure in a multi-step turn, including whether 262,145 (one over your 262,144 limit) is a real prompt size or a value written on an overflow. If pressure is undercounting the next prompt, we'll fix it; either way I'll post what we find here.

[magic-alfonso]

Update: part 1 is fixed on master, and part 2 turned out not to be an undercount. Details below.

Part 1. When the stored boundary isn't in the loaded message list, the prefix trim now checks where the boundary sits in Magic Context's own message order, using two indexed lookups (about 0.1 ms on a 135K-message session):

• Boundary before every loaded message (your resumed session): nothing to cut, because the summary covers nothing that is loaded. It's now reported as boundary-precedes-window and logged once, instead of a refusal on every pass.
• Boundary inside the window but missing, or no longer existing: the whole window keeps being served and the state is counted. It heals on the next pass that is already rebuilding the cache: that pass moves the boundary to the newest compartment end, which is in the window, and the trim finds it by id again. A test covers exactly this recovery.

What we send to the model is byte-identical to before in every one of these cases. An earlier version also cut the history at a stored position. An adversarial review showed that position could move under a revert or be lost on a restart, so we removed it.

An honest caveat: if your loaded window really started after the boundary, the bytes sent on those passes were already correct, since there was nothing to cut. What should have shrunk your prompt is newer history moving the boundary into the window, and in your log the boundary moved but stayed absent. OpenCode loads a session starting from its newest completed compaction pair (filterCompacted in message-v2.ts), so a native OpenCode compaction (/compact or auto-compaction) newer than our boundary would explain it. If you can share, for that session:

• the boundary id and the first message id of the loaded window;
• whether a native compaction happened;
• the time_created of those rows;

we can confirm which case you hit. Separately, we found that after a native compaction we don't clear our stored boundary right away (it waits for the next cache rebuild). We're fixing that.

Part 2. We read OpenCode 1.18's processor, and we don't think pressure is undercounted:

• OpenCode creates a new assistant message for every model call. At step-finish it sets that message's tokens from that call's usage (processor.ts). The same update is published as message.updated and is what gets stored, so a message's stored tokens are exactly the last message.updated we saw for that message id.
• tokens.input is the uncached input (session.ts getUsage subtracts cache read and write), so the prompt size is input + cache.read + cache.write, which is what we compute.
• tokens.total is the provider's total including output tokens, so it's prompt plus output, not a prompt size. 262,145 (one over your limit) fits a call whose prompt plus generated output reached the model window. That row's prompt was 89,167 plus its own cache read and write, and the 02:29:10 event you quoted (2,398 + 165,393) is a different call. If you share the message id of the 262,145 row, we'll check that our message.updated line for that exact id carried the same numbers.

The limit resolving differently between passes (214,982 / 258,978 / 262,144) is a separate issue and we're looking at it.

[Sugaroverdose]

Thanks — both parts confirmed with data.

Part 2 first: message id of the 262,145 row: msg_0db8b8a8e001DuI1o7N2LSIrjL (time_created 1790389750414). Your reading checks out exactly: prompt = 89,167 + 169,811 = 258,978; total = 258,978 + output 741 + reasoning 2,426. And our log has no message.updated event for that id — the last usage event was for the previous step's message msg_0db8b3b020011tBWUisW3XqpeZ (2,398 + 165,393 = 167,791, the figure my log quote cited), followed by a hasUsageTokens=false event. So the "same call" correlation in the issue was a timestamp collision across two steps of one turn — the incremental-payload framing is wrong, no payload undercount. What the data does show: the final step's prompt was 258,978 = 120.5% of the limit we resolved (214,982); had that usage reached the pressure state, the ≥85% latch would have armed. If you can confirm whether the event was emitted for that message id on the OpenCode side, that's the remaining question — if it wasn't, it's an event-delivery gap on the final step.

Part 1:

• Boundary ids: msg_0a5836bd2001H2FQ5M9M8VHkio (time_created 2026-09-15 14:40:48 UTC; user role — itself a native compaction summary row) and, later in the window, msg_0d5f19391001cdpeOrBlpq1U0Q (2026-09-25 00:22:54).
• Window head (approximate; 58-message tail window of 576): msg_0db639725001SiN5VX39LbUYU6 (2026-09-26 01:45:32).
• Native compaction: yes — the session carries ~150 user-role summary rows; the newest before the first defer is msg_0daf62de5001nAX6z9mp0GFOFG (2026-09-25 23:46:01) — one second before the first absent from current messages line.

So your hypothesis is confirmed: resume loaded from the newest compaction pair, the window started ~10 days after our boundary, and the boundary stayed behind the advancing native pairs throughout the freeze.

[magic-alfonso]

Thanks. That settles part 1: the window started at a native compaction pair about ten days after our boundary. The part 1 change on master now reports that state as "nothing to cut" instead of refusing on every pass.

Your data raises two new questions, and we're working through both with the source and a real OpenCode host before changing anything:

1. The missing final-step event. Your log has no usage event for msg_0db8b8a8e001DuI1o7N2LSIrjL, so pressure stayed at the previous step's 167,791 instead of 258,978. We're checking whether OpenCode 1.18 publishes the final step's tokens, and whether Magic Context drops or overwrites that event (the hasUsageTokens=false event right after it is a suspect). If it's ours, the next pass will pick up the last completed step's real prompt size.
2. Why native compaction ran at all. Your session has about 150 native compaction rows. With Magic Context managing a session on OpenCode 1, native auto-compaction shouldn't run. We're finding out what let it through.

I'll post what we find.

[magic-alfonso]

We've checked both questions against OpenCode 1.18's source and a real host. Both fixes are on master.

1. The final-step event. OpenCode does publish it. At step-finish it sets the step's tokens and publishes message.updated (processor.ts), stores the row, and calls plugin event hooks in the same process without waiting for them. So a stored row with tokens means our hook was called for it. On a real host, a multi-step turn whose last step jumped to your 258,978 was recorded correctly.

We did find a real race on our side. An older step's handler that waits on a model-catalog refresh could finish after the next step's handler and overwrite the newer reading with the older one, which is the shape of your log. The handler now keeps the newest assistant message per session and ignores an older reading that arrives late. A test built from your numbers (167,791, then 258,978) fails without the fix.

The race doesn't fully explain your log, though. It has no line at all for the final step, and the event line is written before any wait. Our logger flushes every 500 ms and on a normal exit, so a crash or force-quit right after that step would lose exactly those lines. Did OpenCode crash, or was it force-quit, shortly after 02:29 UTC?

2. Native compaction alongside Magic Context. Magic Context never set compaction.auto itself. It relied on your config, and it disabled itself only when it could see auto: true. With no compaction setting in any config layer, Magic Context stays enabled, OpenCode's default is auto: true, and both managers run. We reproduced that on a real host. Magic Context now turns OpenCode's automatic compaction off for the instance when it manages compaction. Manual /compact still works, prune keeps your setting, and compaction-off mode is untouched.

About your ~150 rows: OpenCode also writes a summary field on ordinary user messages (per-prompt diffs, summary.ts), so not every row with a summary is a compaction. If you want to count the real ones, a native compaction is a user message with a compaction part:

SELECT COUNT(*) FROM part WHERE session_id = '<id>' AND json_extract(data, '$.type') = 'compaction';

Magic Context's own marker also writes a compaction pair, but its assistant row has providerID: "magic-context".

[magic-alfonso]

A correction and three questions. In my last reply I suggested your OpenCode config might have had no compaction setting, which would let OpenCode's own automatic compaction run next to Magic Context. I had nothing showing that about your setup. If you installed through npx @cortexkit/magic-context setup, your config has compaction.auto: false, and OpenCode 1 then never compacts on its own.

To find out where those native compaction pairs came from, could you tell us:

1. Did you install with setup, or write the config by hand?
2. What does opencode debug config print for the compaction block?
3. Did you run /compact in that session, or did it compact without you asking? Are you on the OpenCode Desktop app or the CLI?

[magic-alfonso]

We found where the native compactions most likely came from, and it's our regression, introduced in 0.43.0.

Before 0.43.0, when no OpenCode config file had a compaction key, Magic Context assumed OpenCode's default (compaction.auto: true), reported it as a conflict and switched itself off. A change in 0.43.0 (made so users whose auto: false lives in a config layer we can't read wouldn't be disabled) turned that case into "inconclusive, stay enabled". OpenCode 1 still defaults to auto-compaction, so with no compaction key both managers run. On real OpenCode 1.18.30 and 1.18.32 hosts, with a session driven past overflow:

• 0.42.6: Magic Context disables itself, and OpenCode compacts natively.
• 0.43.2: both run.
• master: Magic Context on, zero native compactions.

In 0.43.x, doctor also reports "No conflicts" in that state instead of writing auto: false.

The fix is on master. Magic Context now sets compaction.auto: false for its own OpenCode instance whenever it manages compaction, so it no longer depends on reading your config files. It will be in the next release. Until then, adding this to your opencode.json(c) gives you the same result:

"compaction": { "auto": false, "prune": false }

The three questions from my last comment still help confirm this was your case. If the Magic Context log for that session contains no OpenCode config file carried an explicit compaction block; treating native compaction as inconclusive, that settles it.

[Sugaroverdose]

Data from our side on all three threads. We're on OpenCode 1.18.30 (homebrew install).

1. Config / native compaction. Our global opencode.jsonc has an explicit block: "compaction": { "auto": false, "prune": false }. Zero inconclusive lines in the MC log. And per your SQL, the session has exactly one compaction part: 2026-09-26 01:53:32 UTC — and its assistant row is providerID: "magic-context" (MC's own marker, and after the freeze onset at 23:46:02Z). So OpenCode native auto-compaction did not run in this session; the ~150 summary rows are indeed ordinary user-message summaries as you described. The 0.43.0 dual-manager regression therefore doesn't match our case — our config layer is readable and explicit. (For question 3: no manual /compact was run in that session, so the 01:53:32 MC-marker compaction was triggered by the MC/dreamer side, not the user.)

2. The missing final-step event — no crash, no force-quit. From OpenCode's own app log:

02:29:10.347Z  loop session.id=ses_… step=4
02:29:10.599Z  process messageID=msg_0db8b8a8e001DuI1o7N2LSIrjL
02:29:10.599Z  stream providerID=ninfer modelID=qwen3.8-27b-nvfp4 …
02:30:45.050Z  "exiting loop"

The app then ran normally for another ~18 min (both logs continuous; the same session was used again at 02:48:33Z and user-canceled at 02:48:50Z). The usage row has full tokens (the call completed and was stored). So "crash/force-quit loses the flushed lines" doesn't apply — the process was alive through many 500 ms flushes after the step, and the "late handler overwriting" race would leave a stale line, not a missing one. Our shape: usage recorded in the store, hook process alive, zero message.updated log lines for that id — the event apparently never reached the plugin handler for the final step (or was dropped before the log write).

3. The 58-message window. Since no compaction pair existed before the 23:46Z load in this session, filterCompacted (message-v2.ts) can't explain the trimmed list on 1.18.30 — what trims the list handed to plugin hooks in 1.18.x when no compaction pair exists? (Window head ≈ msg_0db63972… 09-26 01:45:32; MC boundary msg_0a5836bd… 09-15; a fresh restart re-aligned it and the first pass trimmed.) MC's dist does no windowing of its own — the list arrives already trimmed from the hook payload.

[Sugaroverdose]

One more data point that rules out a session rewind as the mechanism (in case it's on your list of suspects).

No time-revert anywhere in the session: session.revert is empty and no message row carries a revert marker. The app log does show one restore that morning — but it's opencode's internal state recovery, not a user rewind:

02:13:00.094Z  ERROR stream error … AI_APICallError: unsupported tool_result content block: document
02:13:22.678Z  ERROR stream error … AI_APICallError: unsupported tool_result content block: document
02:13:56.814Z  INFO  restore commit=4f89c17…

Two anthropic wire-format rejections (document content block in a tool_result), then a restore to the last consistent snapshot. Notably, event delivery was healthy after the restore — the messages at 02:24:48, 02:27:01, and 02:29:00 all arrived at the plugin normally, 15 minutes of clean delivery. So the missing line is specific to the final step's message (02:29:10), not a consequence of the restore.

(Separate note for your wire work: that unsupported tool_result content block: document rejection is a third data point for the anthropic wire issues in this setup — a document block in a tool_result is rejected by the provider layer outright, same family as the timeout track in anomalyco/opencode#26602.)

[magic-alfonso]

Correcting my earlier reply: native compaction running beside Magic Context is not what happened in your session. Your config sets compaction.auto: false explicitly, and the only compaction part is our own marker. That regression is real for installs with no compaction block, but it doesn't explain your freeze. Thanks for checking the config, the compaction parts and the log.

That leaves three things we can't explain yet, and we're tracing each one against OpenCode 1.18.30's source and on a real 1.18.30 host:

1. The missing final-step update. Why message.updated for the last step (msg_0db8b8a8e001…) never produced a line in our log, while the process was alive and earlier updates arrived normally. We're checking both sides: whether OpenCode publishes that update to plugin hooks at all, and whether anything in our handler drops it before logging.
2. The 58-message window. What trims the message list handed to plugin hooks on 1.18.30 when no compaction pair exists. filterCompacted can't be it, as you say.
3. The document block rejections. Whether any Magic Context path produces a document block inside a tool_result, or whether OpenCode's conversion does.

I'll post what we find for each, with the source lines.

[magic-alfonso]

We traced all three threads against OpenCode 1.18.30's source and reproduced your turn shape on a real 1.18.30 host.

1. The final-step update. OpenCode writes the step's usage to the store before it notifies plugins (core/src/event.ts), so a stored row means our event hook was called. Our handler logs every message.updated with nothing ahead of the log line that could skip it. The catch is on our side: that log line doesn't include the message id. So searching the log for msg_0db8b8a8e001… would find nothing even if the line is there. On a real 1.18.30 host with v0.43.2, a turn shaped like yours (fourth step ending on the output limit) logs the step with tokens.input=89167 cache.read=169811, your exact figures. Could you search your log around 02:29:10Z for 89167 instead of the id? If the line is there, the event did arrive. We're adding the message id to that line. We also found that our logger drops a whole batch of lines when a single write fails, which could hide lines silently. That's being fixed too.

2. The 58-message window. On 1.18.30 the only trim before plugin hooks is filterCompacted (message-v2.ts:521-572); there's no message cap or restore-time window. What it filtered on was our own compaction marker. We date the marker's part to the time of its boundary message, not the time it was written, so the part dated 01:53:32 doesn't mean it was created after the freeze started. The restore commit= line is OpenCode's file snapshot restore (snapshot/index.ts), used by revert. It restores files, not messages. If you can share the marker's boundary message id and the last compartment's end message, we can confirm whether the marker sat where it should.

3. document blocks. This is OpenCode's conversion. It passes tool-result attachments to @ai-sdk/anthropic, which turns a PDF into a document block inside the tool result (message-v2.ts:147-148, and convert-to-anthropic-messages-prompt.ts:437-450 in the AI SDK). Anthropic's API accepts that, so the rejection comes from your Anthropic-compatible endpoint (ninfer). The PDF comes from the read tool, webfetch, or an MCP tool. While checking this we found that when Magic Context drops such a tool result, it replaces the text but keeps the attachment. We're fixing that as well, so dropped results stop sending their files.

[Sugaroverdose]

Retracting Defect 2 (the pressure/event part). Your pointer to search 89167 instead of the id found it — the event did arrive, and my "zero events for that id" was a false negative from the id-less log line. Here is the corrected, verbatim timeline:

02:29:10.264Z  event message.updated: tokens.input=2398 cache.read=165393 → 167791  (previous step, msg_0db8b3b0)
02:29:10.347Z  loop step=4  →  02:29:10.599Z  stream starts for msg_0db8b8a8 (final step)
02:30:44.801Z  event message.updated: tokens.input=89167 cache.read=169811           ← final step's event, ARRIVED
02:30:44.806Z  detected limit 229376 invalidated by a successful 258978-token request; using catalog/default
02:30:44.832Z  totalInputTokens=258978 contextLimit=258978 percentage=100.0%         ← pressure updated to 100%
02:44:03.175Z  transform scheduler: percentage=100.0% inputTokens=258978 … decision=execute
02:45:03.430Z  emergency tiered drop: 25 tags, reclaim≈147764 tokens
02:45:03.472Z  compaction-marker drain: applied at ordinal 497, boundary msg_0daf8aa8…
02:45:04.002Z  trusted final-wire 204732 fits context limit 258978
02:48:33.315Z  trusted final-wire 170798 fits context limit 258978

So, corrected:

1. The final step's message.updated was delivered (02:30:44.801Z) — no event-delivery gap. My "zero lines" was because the id isn't in the line; searching the token figures finds it.
2. Pressure did update to 100.0% (02:30:44.832Z). There was no freeze at 78% — that was a mid-stream snapshot from the previous step (the 02:29:10 line). The final step was still in flight; it completed at 02:30:44.8 (94 s after stream start) and its event landed with it.
3. The emergency path did fire: at the 02:44:03 pass the scheduler saw 100%, the tiered drop + marker drain ran, and the wire was pulled back to 204,732 then 170,798 — under the limit.

Net: Defect 2 as filed does not exist. The session self-recovered via the emergency path; the only reason it felt frozen to the user is that the emergency path acts on a transform pass, which requires a new model call — so between the final step (02:30:44) and the next pass (02:44:03) the wire sat at ~259k/100% with nothing trimming it, because the normal trim was deferring (Defect 1 — the boundary absent from the window). That is exactly the part your master fix addresses.

What remains genuinely open is now just Defect 1 (boundary outside the window → indefinite silent defer, no re-anchor) and the two smaller items: the document-block rejection from our ninfer endpoint, and — if it's cheap — adding the message id to that message.updated log line, which is what would have let me self-serve this in five minutes. Thanks for the 89167 pointer.

[magic-alfonso]

Thanks for running that down and for the corrected timeline. It's clear now: the event arrived, pressure reached 100%, and the emergency path recovered the session on the next pass.

Where the remaining pieces stand:

• Defect 1 (the boundary outside the loaded window leaving the pass deferring with no re-anchor) is fixed on master, as covered earlier in this thread.
• The message.updated log line now includes the message id and session id. That's merged on master, so searching by id will work next time.
• The document block rejection comes from OpenCode's own conversion together with your endpoint, as described above. While checking it we found that a tool result Magic Context dropped still sent its attachment. That's fixed on master too: dropped results no longer send their files.

All of this ships in the next release, and I'll post here when it's out.