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>
Native UI spikes
These disposable applications render the same fixture through GPUI and Floem. They are a decision instrument, not product code. The root workspace excludes this nested workspace so normal Lumbridge CI does not download or compile both UI frameworks.
The GPUI spike uses published gpui 0.2.2. The Floem spike pins upstream commit
778bb5f2aa08429e579ee2e6ac97e84fbf18b618; the crates.io floem 0.2.0 package
lags the current API substantially enough that comparing it to current GPUI
would not be representative.
Both spikes must preserve the same information architecture:
- workspace/sidebar and remote host state;
- two rows of three busy surfaces;
- local and remote terminal/agent panes;
- native Markdown editor/preview and browser placeholders;
- connection, harness, usage, and burn context in the footer.
GPUI also has an integration mode with one real local PTY owned by
lumbridge-runtime; the other five surfaces remain deterministic. Floem and the
shared model retain the all-deterministic mode for like-for-like framework
comparison. GPUI feeds raw output through lumbridge-terminal and sends encoded
keyboard input and terminal protocol replies through the bounded runtime actor.
Its visual adapter coalesces VT cells into native styled runs, paints cursor
shapes, and resizes the engine and PTY from the middle 60% of a responsive
one/three/five-panel workspace. Every panel owns separate context and decision
regions. Retained-history navigation is wired; text selection and
mouse input remain intentionally unfinished.
Build independently:
cargo build --release --manifest-path spikes/gpui-shell/Cargo.toml
cargo build --release --manifest-path spikes/floem-shell/Cargo.toml
Each candidate is an independent Cargo workspace. GPUI pins taffy 0.9.0
while current Floem requires taffy 0.9.2; putting them in one comparison
workspace creates an artificial resolver conflict and would let one candidate's
dependency decisions distort the other candidate's build.
The comparison records release build time, binary size, startup, idle RSS, six-pane streaming frame time, key-to-present latency, accessibility/IME, window behavior, browser-child integration, packaging, dependency count, and license closure on macOS, Ubuntu, and Omarchy. A build is not adoption: GPUI's complete dependency-license closure remains a hard gate.