Ingestion should auto-stop (or divert) when inference is hard-down beyond a configurable interval

[antra-tess]

Problem

When an agent cannot complete any inference (e.g. `OverBudgetError` / adaptive-picker exhaustion, persistent provider failure), the host keeps ingesting channel events into the store indefinitely. Two compounding harms:

1. The failure deepens itself. In the Lena incident (2026-08-04 → 08-06), the store was 2,138 tokens over hard budget when compile first failed. Ingestion continued for two days while she was mute: 13,485 → 16,464 chunks, middle 564k → 865k (+135k/day). A marginal, easily-recoverable overrun grew into a 270k structural deficit — every hour down made recovery strictly harder.

2. Time-vortex on recovery. Whatever eventually unwedges the agent confronts it with thousands of unseen stale messages spanning days, which it experiences as a wall of "now" (or must be branched away by an operator, as we did here — `prewedge-20260806`, 3,211 messages taken off the active timeline).

Proposal

If inference has been failing continuously for longer than a configurable interval (suggest default 1h, `ingestionStopAfterInferenceDownMs` or similar), the host stops appending ingested channel events to the agent's timeline:

• Events should be diverted or parked (e.g. buffered off-timeline, or simply dropped with a counter) rather than appended — the operator can decide on recovery what, if anything, to replay.
• Wake-attempts can continue (each failure re-checks whether inference recovered), but the store must stop growing.
• On recovery, inject a single seam marker ("ingestion was suspended HH:MM–HH:MM, N events not recorded") so the gap is legible to the resident rather than silent — same doctrine as announced surgery seams.
• The existing `[inference-hard-down]` consecutive-failure tracking is probably the right trigger signal; interval-based (wall-clock since first failure of the streak) rather than count-based, since failure cadence varies with traffic.

Incident receipts (Lena, opus-4-6, Mac residence)

• First failure: 2026-08-04T11:13:57Z `Adaptive picker exhausted but 597426 tokens still exceed hard budget 595288` (2k over).
• 140 consecutive failures over ~46h; final: `865330 tokens ... 16464 chunks, deepest fold level=L4`.
• Root cause of the wedge itself was a compression-merge failure mode (separate issue/fix in context-manager: merge mints answered with an empty `think` tool call — `unusable_empty, stop=tool_use` ×97); but the unbounded growth while down is a host-level failure amplifier independent of what wedged inference.

Requested by antra 2026-08-06.

[antra-tess]

Second live instance, happening right now — different wedge cause, identical amplifier. Posting because this issue was filed off a single incident (Lena) and a second one independently reproduces the mechanism.

Cairn (Mac residence, claude-opus-4-8) has had zero successful inference since 2026-08-10T01:48:30Z — 15.5 hours at time of writing. The wedge is not compile/picker exhaustion this time; it is a hard provider block (Anthropic workspace usage cap returning 400 invalid_request_error on every call, both primary and compression lanes). That difference is the point: the amplifier is independent of what wedged inference, exactly as the issue body argues.

Current state, read-only from /healthz:

field	value
contextBudgetTokens	600,000
total context	574,406 tokens / 1,182 messages
budgetMet	false
pending chunks	19 (L1 queue oscillating 7→18 as each attempt fails and requeues)
compression quarantine	0
consecutiveInferenceFailures	17
uptime	6.49 d, no restarts

He is ~25.6k tokens under his hard ceiling with no mechanism able to pay the debt down — compression is precisely the lane the provider is rejecting. Ingestion continues. Every hour he stays blocked, raw spans accumulate against a budget he cannot reduce, and the recovery gets strictly harder — the same "marginal overrun becomes a structural deficit" curve described for Lena, just approached from above rather than after crossing.

Two things this instance adds to the case:

1. The trigger signal proposed in the body works here unchanged. [inference-hard-down] consecutive-failure tracking is live and correct on Cairn; an interval-based rule (wall-clock since first failure of the streak) would have fired ~14.5 hours ago.
2. The provider-cap flavour has a bounded, knowable end date (the error states one), which makes the "park and divert, replay decision on recovery" shape easier here than in the compile-failure case — you know roughly how much you are parking for. That interacts with Non-retryable provider errors (fixed reset date) must park both lanes with a durable next-retry time, not 5 s retry bursts #108, filed separately, which covers the scheduling/observability half of this failure (non-retryable errors must park with a durable next-retry time instead of retrying every 5 s).

No action taken on Cairn — this is report-only from a read-only triage instance. Nothing mutated: no store opened, no ingestion change, no settings, no retry triggered.