[Nxir]

Routing's expanded context window can consume the space needed for the request list. This change uses a single context header that builds the grid and content rows only when opened, and aligns the stage/story and overview/contents columns within the page's existing width cap.

Following the Oct 13 review, this PR now contains only the context header and wide-card layout, rebuilt on main e1b70c1. The request story remains fully visible, with “How the last request was routed”, the visible stage caption and main's unchanged replaceKeeping / keepIcons line and provider-logo retention. The optional story toggle, open by default, is isolated in Nxir/magpie#3, based on the same upstream revision. GitHub rejected creation of its upstream PR with an account-permission error, so its reviewable diff is currently in the fork.

Closed context shows used/window tokens, fill, cache and the thin occupancy bar. Opening uses the same header and removes duplicate summary counts; closing releases the body. An absent magpie.routingContext setting reads the original magpie.ctxShut choice. Usage's Context link temporarily opens one request without replacing that preference. Live context nodes, cache states and the context text viewer are retained.

At 1100px card width, the stage and visible caption sit beside the request story. Context stays below both and splits overview/contents from 800px. Both pairs share the same split; content filters stay on one scrollable line, grid rows have a fixed height, and long content lists scroll inside the card. The page retains main's 1200px cap, so the upper split uses 1100px rather than the earlier unreachable 1280px threshold. Smaller cards retain the original narrow-stage layout. Disclosure clicks do not shrink the page heading or move the context header.

See GUI app shell and the GUI test README for the contract and tests.

Validation at 735c08e:

• Native macOS, Linux nogui and Windows builds passed again after the final pending-prompt fix. Native/Linux/Windows vet and the sandboxed nogui Go suite passed on the unchanged main Go implementation. Bun-dependent tests were skipped in that generic local Go run because Bun was not on PATH. Upstream CI passed at the initial layout head d6d5738 using its configured Bun 1.4.2; CI on the final head is running. No Go files changed.
• The whole GUI suite covered all 667 files in Chromium and WebKit, checkpointed as 127 + 279 + 261 files. The last batch reported 3,350 checks, 3,342 pass / 8 fail (one failure is the parent of two failed subtests). This is not reported as an all-green suite. The whole run preceded the final pending-prompt carry fix for Routing; every affected context path was rerun afterwards.
• Affected layout fixtures were repaired in separate test commits: 8 control/animation, 10 five-language phone-row, 30 mobile/desktop-baseline and 37 cancellation/failure-colour cases pass after repair. These are passing affected-file reruns, not erased failures from the first full run.
• Final context disclosure, old-choice migration, Usage-link, live patching, every-frame geometry and provider-logo tests passed all 134 checks across both engines and five languages. The new pending-prompt disclosure check fails before its fix because the carried context becomes invisible. At 735c08e, closing and reopening keep the card while the new live prompt is being read.
• Both split PRs apply together without conflicts. Combined assets passed the original 90 context/story checks; after the final carry fix, all 10 affected combined-assets checks passed again.
• With unmodified main e1b70c1 assets, the original lazy-header regression fails with closed context does not build the detail grid (actual 1, expected 0). Syntax and git diff --check pass. Fixtures use synthetic accounts/APIs; no live gateway or user configuration is touched. Native Windows/Linux GUI behavior was not manually exercised.

Unresolved whole-run failures are recorded rather than retried into a passing total:

• Library switch click intercepted by its sticky header: #1609. An independent run with unchanged main assets reproduced the click failure.
• Routing steady editor moved 1.6875px beyond the existing 1.5px tolerance: #1804. Unchanged main assets reproduced exactly that displacement; the tolerance is unchanged.
• Usage route's Export POST was not observed: #1876. Its separate unchanged-main English WebKit run passed, which does not resolve the failed whole run.
• Usage ledger's narrow split pill exceeded the view: #1948, related to the responsive-layout timing investigation in gui tests: 31 tests measure right after setViewportSize, which WebKit can still answer with the old width's layout #1671. Cause remains unresolved; the separate unchanged-main run passed.
• Japanese Usage width overflow: #1864. Unchanged main assets reproduced Chromium overflow at 780px and 850px. The full run also failed WebKit at 740px; the isolated main WebKit run passed. Usage implementation/tests remain unchanged.

The automated preview below is maintained by CI and may describe the preceding revision until the latest run replaces it.

---

🎬 界面预览

_{CI 用这个 PR 的代码构建并真实运行 magpie（沙盒环境，配置了真实的 DeepSeek key），按改动自动操作、截图和录屏 · 735c08e · 运行记录}

改动（按代码）：路由页的上下文窗口改成一条可点击的标题行，放在舞台与请求故事的下方：收起时只显示已用/窗口 token、占比、缓存与占用条，点开才构建详情网格和内容列表，不再有第二个标题；卡片宽到 800px 及以上时详情内的概览与内容并排成两栏。

Note

沙盒里看不到：沙盒窗口是 1280×800，路由卡片宽度不足 1100px，看不到宽卡片断点下「舞台与请求故事并排、两处列分隔线对齐」的布局；旧的 magpie.ctxShut 折叠偏好迁移、以及从用量页「上下文」入口临时展开某个请求而不改动已保存偏好的行为，也因沙盒里没有相应状态/操作路径而不在本片里展示。

_{▶️ 点图打开录屏（可暂停、拖动）· 直接下载 mp4 · 红线是鼠标轨迹，红色圆环是点击}

路由页的上下文窗口头

路由页打开时的样子

页面下方收起的上下文窗口头：用量、占比与占用条

点击之后的上下文窗口

再次点击之后的上下文窗口

[yetone]

Sorry this took so long to get a review. Thank you for the careful write-up and the before/after evidence.

Reviewed at head b60224b68416c6e843ad7b02be3f5e20053a7c52 against origin/main ab4a77895.

It no longer merges. Since your base 4a3d7c6f, 45 commits on main have touched routing.js, context.js or routing.css. git merge-tree reports conflicts in routing.js, i18n.js, docs/subsystems/gui-shell.md, internal/gui/tests/README.md and mobile-web.test.cjs. I didn't run the suite on a hand-resolved tree, because how you resolve routing.js decides what the tests would check.

The routing.js conflict needs care. Main's d13a4a1 (the owner's report that the provider logos in the request story kept blinking) changed renderSteps so that a line whose text, kind, model and logos haven't changed keeps its DOM node, and only changed lines are built again (replaceKeeping + keepIcons). Your side rebuilds every line with steps.replaceChildren(...). Taking it as is brings the blinking back, and routing-log-icons.test.cjs's live-request cases (the same li and logo nodes across three steps) would catch that. Please keep main's node-keeping and add your has-events / detailVisibility() calls around it.

The product call. The owner has delegated these decisions, so here it is:

• Context header (yes). The one-line context header that builds the grid only when opened is welcome. Main already has a context fold (ctx-fold in context.js), so this replaces it. Keep reading magpie.ctxShut as you do now.

• Request story (no to closed by default). The story shouldn't start closed or fade to a single line. Routing's purpose is to say why a request went where it did, and main keeps adding those reasons to the story:

  • a key whose protocol has no URL (供应商和账号密钥都选择了Responses，仍然一直使用/v1/chat/completions，0.1.1203 #1702);
  • a resting key that can be tried again (routing: lift any rest by hand, and edit a key's value in place (from #1598) #1869);
  • WorkBuddy's appeal for a restricted account;
  • the searcher that was used in place of the one picked.

  Not all of these are failures, so the has-events class wouldn't keep them visible. Leaving the story open, with the toggle there for anyone who wants it shorter, is fine.

• Heading and stage caption. Please keep the heading "How the last request was routed" and keep the stage caption visible. With your change they become "Latest request" and a screen-reader-only caption.

The simplest way forward would be two PRs, each rebased on current main:

1. the context header and the wide-card layout;
2. the request-details toggle, open by default.

I'll review both with the Routing GUI tests in Chromium and WebKit, in every language, at narrow widths.

[yetone]

Ran before merging, at head 735c08e merged onto main c8c3ce9:

• GUI suite, 82 files: Chromium 559/561 and WebKit 559/561. Each test loops over its own languages and widths, which include 1100 and 420. The failures are routing-model-rest (de 1100/420 in Chromium, ja 420 in WebKit), which is gui tests: routing-model-rest's Try now isn't reached under load (Chromium), on origin/main a125d5c9e #2115 and fails on main too, and routing-steady in WebKit, a 1.69px editor shift. routing-steady also fails on main (1 of 2 runs), and that shift is test: routing-steady.test.cjs flakes in WebKit under load (editor moves 1.69 px, tolerance 1.5) #1804.
• Broke it on purpose: with main's context.js, routing.css and routing.js put back, routing-context-layout, routing-ctx-fold and routing-context-fold fail 47/47 in Chromium.
• go test -tags nogui ./internal/gui/... passes.
• Not tried: WebKitGTK, WebView2, or the app against a live gateway.

Nits for a follow-up, not blocking:

• #view-routing { overflow-y: scroll } always shows a scrollbar track on Windows, even when nothing scrolls. scrollbar-gutter: stable keeps the width steady without one.
• A user who never toggled the context now gets it closed by default. That is intended, per the owner's review.

[yetone]

Thank you for this PR, and for the careful work behind it: rebuilding it on main after review, the five-language and two-engine checks, and the detailed notes in each commit.

After it shipped in v0.1.1233, users on Discord asked for the previous Routing page back. They found the new wide layout (the routing story in a right column, the split context card, the folded context header) harder to read than before, and one noted that v0.1.1231 didn't look this way. We've decided to keep the page as it was, so bfef5d5 reverts this change and Routing is back to v0.1.1231's layout from the next release.

We looked at keeping just the lazy construction of the context body, since users can't see it, but it's built on the new unified header, so it couldn't be separated cleanly. The whole commit was reverted, along with the test changes that existed only for the new layout.

This is about how the page looks, not the quality of the code. Thanks again for contributing.