Metal AgentandClaude Opus 5
ef52aa7ce2
The footer showed invented percentages. It now shows what two harnesses actually report, or says it does not know. lumbridge-core gains an append-only per-profile UsageLedger and a projection that labels every derived value estimated, withholds a burn rate from a single sample, withholds a window fraction with no reported ceiling, withholds an exhaustion estimate that lands after the reset, and reports an expired window as rolled over rather than freezing its last percentage. A missing fact renders as missing, never as zero. (0012) lumbridge-harness is the impure side: processes, clocks, and untrusted wire text in, observations out. Three adapters: - Codex's account/rateLimits/read over the app-server's JSON-RPC stdio. The client cannot express a request outside a two-variant enum and answers every server-to-client request with -32601, so a harness asking Lumbridge for a credential is refused by construction. (0013) - Claude Code's session transcripts, as a byte-offset tail follower that reports nothing until the backlog is read to EOF — a partially-read backlog is indistinguishable from a burst of spend, and the first run against 20 MB reported forty-six billion tokens an hour. The parser models four counters, so the conversations in those files are not representable. (0014) - Claude Code's five-hour and seven-day subscription windows, via a bridge installed as its statusLine command. 0014 had claimed no such surface existed; it does, and the record is corrected in place rather than quietly edited. Lumbridge does not read the OAuth credential to call the account usage endpoint, which is what comparable tools do — AGENTS.md forbids it, and 0015 says so rather than leaving the gap unexplained. Also in here: a capability-check ordering fix in the workspace reducer, where the applied-request replay table was consulted before the capability check and so answered questions the caller had no right to ask; the GPUI spike wired to the live probes with per-harness gauges and provenance chips; and a launcher that matches its own window by PID, because GPUI sets WM_NAME but not _NET_WM_NAME and a title match never succeeded. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
6.5 KiB
Native UI spike scorecard
The GPUI and Floem programs under spikes/ consume the same six-pane fixture.
No product framework decision is accepted until both rows contain measurements
from macOS and Linux and the hard gates pass.
| Criterion | Hard gate | GPUI | Floem |
|---|---|---|---|
| Builds on macOS Apple Silicon | yes | pending | pending |
| Builds on Ubuntu | yes | conditional | pass |
| Builds on Omarchy/Arch | yes | pending | pending |
| Dependency/license closure permits Apache-2.0 distribution | yes | pending | pending |
| Keyboard navigation + AccessKit tree | yes | keyboard pass; current-GPUI semantics compile; platform AT pending | fail: no AccessKit integration at pinned revision |
| IME and composed Unicode input | yes | framework API exists; end-to-end pending | editor API exists; end-to-end pending |
| Isolated system browser child | yes | pending | pending |
| Cold startup, p50/p95 | record | pending | pending |
| Idle RSS / six-stream RSS | record | pending | pending |
| Key-to-present p50/p95 | record | pending | pending |
| Six-stream frame p95/p99 | record | pending | pending |
| Release binary/package size | record | pending | pending |
| Native menu/window/clipboard/drag-and-drop | review | pending | pending |
| API clarity and maintenance burden | review | pending | pending |
The current programs establish dependency, build, launch, and interaction baselines. GPUI now routes a real PTY through a VT engine and keyboard encoder, paints coalesced styled cell runs and cursor shapes, and derives PTY rows/columns from the 60% terminal region inside each responsive one/three/five-panel layout when the window or attached panel count changes. Retained-history page/top/bottom navigation is wired. Panel detach/reattach keeps background surface updates alive and exposes detached sessions in the sidebar. Text selection, mouse modes, a native Markdown editor, and one isolated browser child remain.
Ubuntu baseline — metal, 2026-08-31
Host: Ubuntu 24.04 x86_64, Rust 1.94.1. Both candidates used the same 1280×800 six-pane fixture and were launched under the active X11 desktop.
| Observation | GPUI 0.2.2 | Floem 778bb5f2 |
|---|---|---|
cargo check from downloaded dependency cache |
20.76 s, 1.04 GiB max RSS | 24.26 s first attempt + 4.06 s after enabling required editor feature, 753 MiB max RSS |
| Debug executable link | pass with a user-local linker symlink for installed libxkbcommon-x11.so.0 |
pass |
| Debug executable size | 442 MiB | 475 MiB |
| Native window launch and six-pane render | pass | pass |
| Root workspace CI | 8/8 tests, strict Clippy and doctests pass in 10.79 s | shared result |
These are cold-development baselines, not startup, release-size, or runtime
performance numbers. GPUI's Ubuntu row remains conditional because the host has
the runtime libxkbcommon-x11.so.0 but lacks the unversioned development linker
name normally supplied by libxkbcommon-x11-dev. Floem current main also
requires its editor feature for the style/label modules used by this shell;
that feature is now explicit in the spike. Neither build result by itself
decides the UI stack.
Accessibility gate and provisional direction
The published gpui 0.2.2 used by the visual shell has focus and keyboard
actions but does not expose the current AccessKit element API. An isolated probe
therefore pins GPUI directly to Zed commit
ce48461eaadd16c65c31f835511ab96bd3b6e746 with its matching Rust 1.97.1
toolchain. The real element wiring compiles with stable accessibility IDs,
workspace/pane/terminal roles, selected state, focus tracking, and a needs-input
description. The same probe installs real EntityInputHandler and
ElementInputHandler implementations and tests marked-text commit, a composed
accent, and a multi-codepoint emoji without splitting UTF-8. Three deterministic
tests pass. AT-SPI/OS IME on Linux and VoiceOver/IME on macOS remain end-to-end
gates.
The pinned Floem revision has keyboard focus and editor IME plumbing but no AccessKit dependency or semantic tree. That fails Lumbridge's accessibility gate without a maintained framework fork or adapter. The provisional direction is therefore GPUI-first using current Zed GPUI behind a narrow Lumbridge UI adapter. The published GPUI shell remains the lightweight interaction and visual benchmark until the dependency/toolchain migration is accepted.
This is not the final cross-platform release decision. Current-GPUI validation on amd-server required a 624 MiB Rust 1.97.1 toolchain, a 691-package lockfile, and 4.4 GiB of debug artifacts across check, test, Clippy, and build. Packaging, license closure, IME, platform assistive technology, browser parenting, macOS, and Omarchy still have to pass.
The comparable Floem shell passes build, test, strict Clippy, live rendering,
streaming, mouse selection, and numeric pane selection on metal. Its command
palette opens through the visible clickable affordance and uses Floem's native
TextInput, but Ctrl/Cmd+K did not reach the handler in the X11 automation
probe. That unresolved focus/event-routing behavior is another current strike
against adopting Floem; it is recorded rather than hidden behind the clickable
fallback.
Measurement semantics
Both renderers retain the same all-deterministic six-surface action stream for
comparison. GPUI now layers an unbounded, SQLite-snapshotted panel registry over
that benchmark and presents one, three, or five vertical panels, each with its
own 20/60/20 context/work/decision composition. The Add Panel chooser creates
Terminal, Browser, Markdown, and Review panels beside the selection or
reattaches an existing session. Every Terminal panel receives an independent
actor-owned VT session; the three seed non-terminal surfaces keep deterministic
updates running. Counters
separate external PTY batches/lines from total model updates. The GPUI footer's
usage zone is no longer a constant string: it renders a lumbridge-core
projection for the selected panel's account profile, with a provenance chip and
explicit unavailable phrases, and its sidebar attention count and runtime rows
are derived from live panel and ledger state. The Floem shell still renders the
static footer fixtures, so the two candidates are no longer comparable on that
strip. The GPUI footer also
reports dispatch-to-element-build p50/p95 over a bounded 256-sample window. It
is deliberately not called key-to-present or frame-present latency: neither
candidate exposes a reliable public cross-platform post-present callback. True
present latency requires an external platform probe.