[akiiwa-games]

What

In Mode A, a tool-loop step or a short follow-up ("继续") can be routed from scratch instead of keeping the session's model and effort. It happens whenever the request lands on a different pooled runtime from the one that served the session.

Root cause

The session's route lives in a store inside the middleware's runtime, and nothing outside that runtime can hold it:

• Magpie hands each request a moejs runtime from a sync.Pool and gives middleware no storage across requests (internal/middleware/middleware.go, mw.pool).
• ctx carries no headers (internal/middleware/run.go, acquire).
• serveAgent runs onRequest before serve (internal/gateway/middleware.go). Magpie's own affinity (internal/gateway/affinity.go, affine) therefore runs after the model is rewritten and only orders accounts within it.

Change

• turnChain reads from the resent history which turn a request continues.
• When the runtime has no record of that turn, or has a record of another turn, replayedState cuts that turn's request out of the history (bodyUpTo) and decides it again, up to 4 turns back. The history is the one input every runtime gets, so they all reach the same answer. Nothing is recorded during a replay.
• A held model keeps the candidate's name (upstream/claude-opus-5-5). Before, it became the canonical bare id, which can resolve to another provider (heldTarget).
• onRequest's claimed-model branch moves into routeClaimed so that a replay runs the same code. The code moved as it was, including agentcompass 0.1.3: :minimal and :ultra are efforts; ultra reads as the model's Max, minimal sits below its Low #750's fallback retry, so a replayed fallback matches the original one.

hooks.js and Mode B are untouched.

README

#765's README already describes the history replay, but the code wasn't on main until this PR. I added what it was missing, in both languages: why Magpie's affinity can't do this, and which clients are covered. Responses clients that send only previous_response_id are covered, because Magpie fills in the conversation first. A client that sends only its last message, with no history, can't be held.

Tests

• 7.7 (new): runtimes with separate stores agree on turn 1, the tool loop and the follow-up, including a runtime whose record is from an earlier turn. It fails with main's src.
• 9.9: runs with affinity off and also times the replay path.

Each break below turned a test red:

break	red
main's middleware.js and continuity.js	7.7
no replayedState call	7.7
held model as the canonical name, without heldTarget	7.7, 9.9

At 3a7ba70 (Windows, Bun 1.4.0, Node 24.12, temp HOME): bun test 45 pass, node --test test/router.test.mjs 45 pass, bun scripts/check.mjs agentcompass exit 0.

E2E

This was measured in the plugin's own repo at akiiwa-games/magpie-agentcompass-router@d05f598, not at this head. It ran the real Magpie 0.1.2891 in a sandbox on default GOMAXPROCS, with Scenario 8 over 20 sessions:

	follow-up re-routes	tool-loop re-routes
before	13/20	not separately recorded in the commit
after	0/20	0/20

The replay code is the same here. The one difference is the fallback retry from #750, which I checked only at the unit level: a lone gpt-6-astra:minimal on a coding task routes to itself on turn 1 and on a follow-up on a fresh runtime. The sandbox run hasn't been repeated at this head.

🤖 Generated with Claude Code

[yetone]

Review at 3a7ba70 (agentcompass 0.1.5)

Thanks. The diagnosis is right (pooled moejs runtimes, no storage across requests), and the warm case works: a tool loop or a "继续" within the cache TTL now gets the same route on a fresh runtime as on the one that routed the turn. heldTarget also fixes a real bug on main, where a hold recorded the bare canonical name (claude-opus-5-5:xhigh instead of upstream/claude-opus-5-5:xhigh). One thing has to change before this can merge.

Blocker: a replayed state is always warm, so a fresh runtime holds a cold session

replayedState sets updatedAt: env.now. evaluateProviderContinuation then sees age 0, and the TTL-gated holds (followup and cache) always pass on a runtime that replays. The runtime that has the real record sees the real age, goes cold, and routes again. So after a pause the runtimes disagree again, and the fresh ones (most of the pool) keep the expensive frontier model and effort. On main both runtimes agree in these cases. Probe on chat, with candidates upstream/{claude-opus-5-5, claude-sonnet-5-5, claude-haiku-5-5, gpt-6-astra, gpt-6-luna, gemini-3.8-flash-high, deepseek-v4.1-flash-free}. Turn 1 is a ~3,000-word deadlock audit, routed to upstream/claude-opus-5-5:xhigh:

request	PR, same runtime	PR, fresh runtime	main, both
"继续" 1 min later	opus:xhigh	opus:xhigh	same runtime claude-opus-5-5:xhigh (bare name, the bug heldTarget fixes); fresh runtime sonnet:high
"继续" 30 min later	sonnet:high	opus:xhigh	sonnet:high
"继续" 3 h later	sonnet:high	opus:xhigh	sonnet:high
new turn, "mechanical batch rename foo_bar → fooBar" 30 min later	gemini-3.8-flash:high	opus:xhigh (cache)	gemini-3.8-flash:high

So the README's "every runtime produces the same route" holds only inside the TTL. The history carries no time, so a replay can't know the age. The rule needs to give the same answer without one. For example: a replayed state holds only where time doesn't matter (within, the tool-loop lock), and treats followup/cache as cold. Or take the age from something every runtime sees. Whichever you pick, please extend 7.7 with a request past the TTL on both a fresh runtime and the one with the record, and check they agree.

Smaller

• recordRequest's new comment says "model is kept canonical", but both model and target are set from decision.model, which is now the routed name. Either drop the comment or record the canonical name in model.

What was run at 3a7ba70 (merged onto origin/main 654d3be, no conflicts)

All runs were on mote (macOS) through mote-run, with HOME=$(mktemp -d) and Bun 1.4.2.

• bun test packages/agentcompass: 45 pass. node --test packages/agentcompass/test/router.test.mjs: 45 pass. bun scripts/check.mjs agentcompass: exit 0.
• Broken by hand: with no replayedState call, 7.7 goes red. With const target = cont.model (no heldTarget), 7.7 and 9.9 go red. With main's middleware.js and continuity.js, 7.7 goes red. Your table is confirmed.
• Timing: a 2,000-turn chat body ending in six "继续" turns, on a fresh store (full replay depth), took 8–21 ms. The same body with affinity off took 1.5–2.9 ms. That is well under the 250 ms hook limit.
• Version: 0.1.5 is free. The package isn't on npm, and dist's index.json has 0.1.0–0.1.4.
• Every line of middleware.js, continuity.js, the test and the README diff was read. hooks.js and Mode B are untouched. The routeClaimed move matches main's branch line for line, apart from the anchor/replayed fields and heldTarget.

Not tried

• magpie's own moejs engine, and a real Magpie gateway with pooled runtimes.
• Responses previous_response_id and Gemini contents bodies through the replay.
• Windows and Linux.

---

中文总结

在缓存有效期内，多个池化运行时的结果已经一致，heldTarget 也修好了 main 上 hold 后模型名变成裸名的问题。但重放出来的会话状态把 updatedAt 设成了当前时间，被当成缓存始终是热的。所以停顿超过 TTL 之后，记录了真实时间的运行时会重新路由（比如改到 sonnet 或 gemini-flash），新运行时却继续用 opus:xhigh，两边又不一致，而 main 上两边是一致的。请让重放状态在不知道时间的情况下给出一致的结论（比如只在工具循环里保持，followup/cache 按冷处理），并在 7.7 里补一个超过 TTL 的用例。测试 45/45 通过，check.mjs 通过，三种手动破坏都能让测试变红，版本 0.1.5 未被占用。

[akiiwa-games]

Update at c89db01 (agentcompass 0.1.5, on top of 3a7ba70)

Thanks for the review. I took the rule you suggested.

Blocker: a replayed state no longer counts as warm

• replayedState no longer sets updatedAt: env.now. It sets ageKnown: false, because the history carries no time.
• In evaluateProviderContinuation, withinCacheTtl requires ageKnown !== false. On a replayed state, followup and cache therefore count as cold. The within tool-loop lock still holds, since time doesn't matter there. keepsEffort treats a replayed state as not warm for the same reason. The cold result reports ageMs: null when the age is unknown.
• The trade-off: without a time source, a fresh runtime can't hold a follow-up inside the TTL, so it routes that turn from scratch, as main does today. Inside the TTL, only the runtime holding the record keeps the follow-up. Runtimes agree in the tool loop and once the cache TTL has passed. The README now says exactly this, in place of "every runtime produces the same route".

Smaller

• recordRequest comment: set() already stores model canonical, and the readers expect that (evaluateProviderContinuation canonicalizes model, heldTarget and healthKey prefer target). I corrected the comment: target keeps the name as routed, set stores model canonical. No behaviour change.

7.7

• The within-TTL follow-up row now asserts what happens: "继续" 2 s later is held (followup) on the runtime with the record, and routed from scratch (cold) on a fresh runtime.
• New rows past the TTL: turn 1 is the deadlock audit plus a ~300-line lock dump (over 1,024 tokens, so the cache is worth holding). Each row runs on a fresh store and on a store that routed turn 1, and asserts the two give the same model, held and why. A tool loop 30 min later still holds on a fresh runtime.

Same candidates as your probe, plus the rest of 7.7's pool. Turn 1 routes to upstream/claude-opus-5-5:xhigh.

request	runtime with the record	fresh runtime, c89db01	fresh runtime, 3a7ba70
tool loop 30 min later	opus-5-5:xhigh (turn)	opus-5-5:xhigh (turn)	opus-5-5:xhigh (turn)
"继续" 2 s later	opus-5-5:xhigh (followup)	gpt-6.1-sol:high (cold)	opus-5-5:xhigh (followup)
"继续" 30 min later	gpt-6.1-sol:high (cold)	gpt-6.1-sol:high (cold)	opus-5-5:xhigh (followup)
"继续" 3 h later	gpt-6.1-sol:high (cold)	gpt-6.1-sol:high (cold)	opus-5-5:xhigh (followup)
new turn, "mechanical batch rename foo_bar → fooBar" 30 min later	gemini-3.8-flash-high:high (cold)	gemini-3.8-flash-high:high (cold)	opus-5-5:xhigh (cache)

The runtime-with-record column is the same at both commits.

What was run (Windows, Node; bun isn't installed here, so only node --test was run)

• node --test packages/agentcompass/test/router.test.mjs at c89db01: ℹ tests 45, ℹ pass 45, ℹ fail 0.
• The same 7.7 with 3a7ba70's src/: 7.7 fails.
• Not run: bun test packages/agentcompass and bun scripts/check.mjs agentcompass (no bun; check.mjs uses import.meta.dir).
• The source repo has the same fix on main (akiiwa-games/magpie-agentcompass-router 90a2303): npm test gives 247 pass, 0 fail. The rest of main (classifier-only profiles, account states, routing contract) is not in this PR; it goes in a separate 0.1.6 PR after this one.

---

中文总结

重放状态不再把 updatedAt 设成当前时间，而是标记 ageKnown: false。没有时间信息时，followup/cache 一律按冷处理，只有工具循环（within）继续保持。现在多个运行时在工具循环里和超过缓存 TTL 之后结论一致。代价是 TTL 内的“继续”只有持有记录的运行时会保持，新运行时会重新路由，和 main 现在的行为相同。README 已按此改写。recordRequest 的注释已更正：set() 本来就把 model 存成规范名，target 保留路由名，行为不变。7.7 新增超过 TTL 的三行（30 分钟、3 小时后的“继续”，30 分钟后的机械改名），并改写了 TTL 内 follow-up 那一行。本机没有 bun，只跑了 node --test，45/45 通过；用 3a7ba70 的 src 跑，7.7 失败。

[akiiwa-games]

Follow-up: bun is now installed here, so I ran the two checks my last reply said were skipped, on c89db01 (Windows, bun 1.4.4, HOME set to an empty temp directory):

• bun test packages/agentcompass: 45 pass, 0 fail.
• bun scripts/check.mjs agentcompass: ✓ registry.json, exit 0.

中文总结：已补跑 bun 测试，c89db01 上 bun test 45/45 通过，check.mjs 通过。

[yetone]

Re-review at c89db01 (agentcompass 0.1.5)

Thanks. The behaviour is now right. A replayed state no longer counts as warm, and past the TTL a fresh runtime and the runtime with the record give the same route. The tool-loop lock still holds on a fresh runtime. The README states the trade-off inside the TTL honestly, and the recordRequest comment is fixed. One thing is left, and it is about the tests.

Left: the two ageKnown checks are what the fix is named for, and no test fails without them

At this head, a replayed state has no updatedAt, so ageMs = now - 0, about 56 years. Every TTL check is already false without ageKnown. So what fixes the bug today is that updatedAt: env.now was removed. The two new ageKnown !== false checks change nothing, and no test notices if they go. They only start to matter when a replayed state carries a time again, which is exactly the regression they are there to stop. I broke them by hand on mote (bun 1.4.2, bun test packages/agentcompass):

change by hand at c89db01	result
withinCacheTtl = ageMs <= ttlMs (no ageKnown, in evaluateProviderContinuation)	45 pass
drop sessionState.ageKnown !== false && in keepsEffort	45 pass
both of the above	45 pass
replayedState gets back updatedAt: env.now (keeping ageKnown: false)	45 pass (the checks hold)
updatedAt: env.now and no ageKnown check in evaluateProviderContinuation	7.7 red ("a fresh runtime doesn't hold a follow-up it can't date")
updatedAt: env.now and no ageKnown check in keepsEffort	45 pass
updatedAt: env.now in place of ageKnown: false (3a7ba70's state)	7.7 red

Please add unit tests that call the functions directly with a state that has an age, so each check fails on its own:

• evaluateProviderContinuation with { ...state, ageKnown: false, updatedAt: now } (cache worth holding, short follow-up, and a plain new turn): why: "cold", ageMs: null. The same state without ageKnown gives followup / cache.
• keepsEffort with { effort: "xhigh", ageKnown: false, updatedAt: now, tokens: 5000 } and a wanted "medium": returns "medium". The same state without ageKnown returns "xhigh".

Each should go red when its check is removed. Leaving updatedAt out of replayedState is right too, and 7.7 already covers it.

Read for new bugs

• Other paths that read age: the 24h session_expired check and store.get/prune all need updatedAt to be set, so a replayed state skips them. That is right, since a runtime with a record over 24h old drops it and replays as well. strict and session modes hold a replayed state without looking at age, the same as a record. The replayed state is never written to the store: recordRequest writes only the decision, so ageKnown doesn't leak into a record.
• ageMs: null: nothing outside continuity.js reads ageMs. routeClaimed doesn't copy it into decision.continuation, and index.js and hooks.js (Mode B) don't read it.
• Effort: on the held path, keepsEffort now gets the replayed effort back unchanged (wanted is cont.effort, which is the state's effort), so a tool loop keeps the turn's effort on a fresh runtime. On a re-route after a replay, the effort isn't ratcheted. That matches the runtime with the record past the TTL, and is the trade-off the README states inside it.

What was run at c89db01 (on mote through mote-run, HOME=$(mktemp -d), Bun 1.4.2)

• bun test packages/agentcompass: 45 pass, 0 fail. bun scripts/check.mjs agentcompass: ✓ registry.json, exit 0.
• Repo-root bun test: not finished. It waited ~7 min on mote's suite lock behind about a dozen queued Go and GUI suites (some had waited 14 h), so I stopped it. PR CI's test job is green at this head.
• The hand-broken variants in the table above.
• Every line of the 3a7ba70..c89db01 diff was read, along with keepsEffort, all of evaluateProviderContinuation, replayedState/routeClaimed and the store's get/set/recordRequest. Main has no agentcompass changes since 654d3be. The PR's CI (test, on-npm) is green.

Not tried

• magpie's moejs engine with real pooled runtimes. Windows and Linux.

---

中文总结

行为已经正确：重放状态不再被当成热缓存，超过 TTL 后新运行时和持有记录的运行时结论一致，工具循环在新运行时上依然保持。剩下一点：在这个提交里，重放状态没有 updatedAt，ageMs 约等于 56 年，所以两处 ageKnown 检查实际上不起作用，删掉任何一处（或两处）测试仍然 45/45 通过；keepsEffort 里那处即使把 updatedAt 加回来也没有测试覆盖。请为 evaluateProviderContinuation 和 keepsEffort 各加一个直接调用的单元测试，传入带 updatedAt: now 和 ageKnown: false 的状态，确保删掉对应检查时测试变红。其余部分（24h 过期、strict/session、ageMs 为 null、effort 处理）都查过，没有发现新问题。

[akiiwa-games]

Added the two direct unit tests in packages/agentcompass/test/router.test.mjs at 1c67fcd (no runtime changes, version stays 0.1.5):

• Test 7.8 (evaluateProviderContinuation): calls evaluateProviderContinuation(facts, { ...state, ageKnown: false, updatedAt: now }, { now }) directly across a cache worth holding, a short follow-up, and a plain new turn, asserting shouldHold: false, why: "cold", ageMs: null on each, and verifying the same state without ageKnown holds with followup / cache (plus ageMs: null vs 0 below CACHE_WORTH_TOKENS).
• Test 7.9 (keepsEffort): calls keepsEffort({ model: "claude-opus-5-5", effort: "xhigh", ageKnown: false, updatedAt: now, tokens: 5000 }, "medium", 0, now) directly, asserting "medium", and verifying the same state without ageKnown returns "xhigh".

Hand-broken check results at 1c67fcd

change by hand at 1c67fcd	result
withinCacheTtl = ageMs <= ttlMs (no ageKnown, in evaluateProviderContinuation)	7.8 red (46 pass, 1 fail)
drop sessionState.ageKnown !== false && in keepsEffort	7.9 red (46 pass, 1 fail)
both of the above	7.8, 7.9 red (45 pass, 2 fail)
replayedState gets back updatedAt: env.now (keeping ageKnown: false)	47 pass (the checks hold)
updatedAt: env.now and no ageKnown check in evaluateProviderContinuation	7.7, 7.8 red (45 pass, 2 fail)
updatedAt: env.now and no ageKnown check in keepsEffort	7.9 red (46 pass, 1 fail)
updatedAt: env.now in place of ageKnown: false (3a7ba70's state)	7.7 red (46 pass, 1 fail)

Commands run (HOME set to an empty temporary directory, Bun 1.4.0)

• bun test packages/agentcompass: 47 pass, 0 fail (127ms)
• bun scripts/check.mjs agentcompass: ✓ registry.json (exit 0)

---

中文总结

已在 packages/agentcompass/test/router.test.mjs（提交 1c67fcd）补上两个直接调用函数的单元测试（7.8 测 evaluateProviderContinuation，7.9 测 keepsEffort），未改动运行时代码，版本号保持 0.1.5。手动逐个去掉 evaluateProviderContinuation 中的 ageKnown 检查与 keepsEffort 中的 sessionState.ageKnown !== false && 检查时，7.8 和 7.9 分别独立变红；恢复后在空临时 HOME 下运行 bun test packages/agentcompass（47/47 通过）和 bun scripts/check.mjs agentcompass（✓ registry.json）均通过。