Repository navigation
koto 1.7.3
koto 1.7.3
A TUI-only release: typing is fast again, in both the input prompt and the shared terminal. No daemon or guest changes, and no dependency version changes.
TUI: keystroke latency fast paths (#79)
- A keystroke used to rebuild the whole screen: the transcript, the agents tree, the status bar and the shell pane were all redrawn for every key, even though only the focused pane changed. Under a busy fleet that made typing feel slow.
- The input prompt and the shared terminal pane now have a keystroke fast path. Off-focus regions are kept in a frame cache and redrawn only when their own inputs change (stream deltas, ticks, tree scroll offset, resizes). Background stream deltas and clean flushes no longer throw the cached frame away.
- A new load benchmark (
BenchmarkFocusInput,BenchmarkFocusShell: many groups and sessions, streaming events, spinner ticks, pty output; idle and burst) measures keystroke to frame cost. Before (8c09f31) and after (ed8fae5) were run back to back on the same VM (about 20.8% CPU steal on average). Medians of 5 runs:- input prompt, typical keystroke: 1.6ms -> 0.075ms (about 21x). p99 idle: 15.6ms -> 0.76ms. p99 during a stream burst: 16.1ms -> 1.6ms.
- shared terminal, typical keystroke: 8.0ms -> 0.31ms (about 26x). p99 idle: 26ms -> 3.5ms. p99 during a stream burst: 25ms -> 2.9ms.
- allocations per keystroke: input 702 -> 64, shell 2531 -> 120.
- The goal was p99 at or under 2ms in both panes. The input prompt meets it. The shared terminal does not: its p99 is still about 3ms (see Known issues). Typical keystrokes there are well under 1ms.
- Rendered output is unchanged. New equality tests compare fast-path frames with full redraws, including a scrolled agents tree.
Upgrade
- From 1.7.2:
koto update. - From 1.7.1 or earlier: run the installer once,
curl -fsSL https://kotovm.com/install.sh | sh. Installers before 1.7.2 cannot read the signed# koto-version:line at the top of SHA256SUMS, sokoto updatefrom those versions fails. After this one-time step,koto updateworks again.
Assets
- koto: rebuilt (version bump only, no daemon code change). Same pinned go1.26.10 build image as 1.7.0 to 1.7.2.
- koto-tui: rebuilt (#79). Same pinned go1.26.10 build image.
- rootfs.img (fedora44), vmlinux 6.1.188, firecracker 1.17.0: the 1.7.2 assets, reused byte-for-byte. They were downloaded from release 1.7.2 and checked against its signed SHA256SUMS. Nothing outside
tui/changed since 1.7.2, so the guest is identical. - No dependency version changes since 1.7.2. go.sum, go.work and package*.json are identical to tag 1.7.2. The only go.mod change is in tui/go.mod:
github.com/charmbracelet/ultraviolet(same version, already in the build) is now imported directly, so its// indirectmarker was dropped.
Tests
- On release/1.7.3 @d104d23 (d9276ef = develop with #79, plus the DIST_VERSION bump) with the go1.26.10 image: gofmt is clean on every .go file changed since 1.7.2, and build and vet pass for all 4 modules. go test for tui, protocol, fcguest and daemon passes on the first full run (daemon 126.6s, tui 11.0s, fcguest 2.4s). The only later commit is d2e1884, the artifacts.sha256 manifest update, which changes no code.
- Reused assets: rootfs, vmlinux and firecracker are byte-identical to the 1.7.2 release assets. They were verified against the signed 1.7.2 SHA256SUMS before reuse, and their SHA256SUMS lines match 1.7.2 exactly (rootfs 620f1c56…, vmlinux de3cd729…, firecracker 6083c11a…). Only koto (415a837a…) and koto-tui (1225e524…) were rebuilt.
- End-to-end smoke run on the 1.7.3 candidate (koto 84d63120, koto-tui d04d8ecc, installed rootfs unchanged): claude-wan, claude-none and minimax all pass on the first try, koto-tui starts, and
koto ctl listreturns ok after the daemon restart. 1.7.3 is installed and running.
Known issues
- Shared terminal keystroke p99 is about 3ms under the load benchmark, above the 2ms goal (#79). The typical keystroke is about 0.3ms.
- The goal-finished notification banner is not session-scoped. The handoff turn goes to the origin session, but the operator banner is raised against the group as a whole (
goalNotifypasses no session, daemon/goals.go:1665). TestStopDisarmsTheReportWindowfails rarely, with no message, under full-suite ordering. It passes in isolation. Suspected cause: a race between tests over a TempDir or global path.TestFcGrowWorkspaceImgOnlyTruncatesdepends on the host disk being under 90% full, because the disk-admission guard is not stubbed in that test.TestOtelUnreachableReceiverNeverBlocksis slow (about 2 minutes of the daemon test run). It measures wall-clock p99 latency, so it can flake on a heavily loaded host.- Guest boot has a fixed 30s limit. On a heavily loaded host a guest can miss it and the send fails with a boot timeout. Retrying once the load drops works.
🤖 Generated with Claude Code