How
A local Unix socket with JSON-line requests: push, patch, key, mouse, click, layers, screen, state, stats, upgrade. A CLI wraps each one. No MCP server yet.
thc-scene
A live terminal UI, as one JSON value an agent drives.
thoughtcontrol.app ↗repo ↗caretline, the editor engine underneath ↗
- license
- MIT · Same as thc. The scene crate is on a prototype branch and not yet published.
- language
- Rust
- backing
- One author (Thought Control), with agents doing much of the building.
the case for it
The best case: an agent can write a terminal UI as one small JSON value, drive it like a person, see exactly what it drew, change one piece at a time, and keep live data flowing at thousands of updates a second without that data ever passing through the model. It has already reproduced a hand-written production screen cell for cell, so a generated UI doesn't have to look generated. Nothing else found pairs that loop with a terminal-native renderer and a pixel layer.
scores
| UI as data | 5 | |
|---|---|---|
| Agent can drive it | 5 | |
| Agent can see it | 5 | |
| Small, targeted edits | 5 | |
| Time travel | 0 → 5 | 0 today. Planned: an agent can read, seek, fork and replay (see the design). |
| Live data rate | 5 | |
| Terminal native | 5 | |
| Pixel graphics | 4 | Rich, but only where the terminal speaks the kitty graphics protocol (Ghostty, kitty, iTerm2, VS Code) |
| Teaching | 3 → 5 | Callouts, spotlights and scripted tours work today; record, take over and rewind are planned. |
| Maturity | 1 | A prototype: one author, no release. |
| Openness | 4 | MIT, but single-author and not yet published. |
scene now scene planned
how agents use it
Wiring it in
Write one JSON UI and point its sources at commands; send ops over the socket. An MCP server is the planned way in for any agent.
Seeing the result
Yes: `screen` (the frame as text) and `state` (everything, as JSON).
Small edits
Yes: `patch` replaces one node by id; streams update one source; keys and clicks move selections.
History
Not yet. State is serializable and every input is a message, so it's designed (history, state_at, screen_at, diff, seek, fork, replay, export/import) but not built.
In short
Built for agents to drive and to see. The parts a standard would give it (MCP, A2UI input) are missing.
architecture
The whole UI is one serializable value: a tree of components, data sources bound to shell commands, JSON-line streams or literals, keys, a theme and callout layers. Elm architecture: a serializable State, a pure update that returns effects, a pure view that returns the frame plus hit regions and pictures. A runtime owns the terminal, a local control socket, child processes and the pixel layer. It sits on caretline (a Helix-model editing engine) and caretline-layers (placement for callouts, arrows and spotlights).
- Push a whole UI, or patch one node by id; view state (selection, focus) survives by id, like React keys
- Read the current frame as text, or the full state, from outside
- Keys, mouse and clicks injected like a person's
- `upgrade`: the running screen saves its state, execs a new binary and carries on
- Templates with theme-token styles, value maps and conditionals; data values can't inject styles
- Kitty graphics: cards beneath text, anti-aliased plots, SVG rendered with resvg, PNGs; cells everywhere else
performance
Measured by its own stress suite on one machine; not independently reproduced.
- About 6,000 whole-UI pushes a second from one client while drawing ~108 fps (release build, 170×52). (crates/scene/README.md)
- 1,000 patches a second applied with every frame under 1 ms; a 50,000-row list replaced 20 times a second draws in 0.18 ms. (crates/scene/README.md)
- With a 15 Hz pixel plot, frames take ~7 ms: rasterising on the main thread. Not yet moved to a worker. (crates/scene/README.md)
adoption and upkeep
Adoption
Unreleased. Used only in demos so far: a thc Today rebuild, a finance dashboard, stress tests and a pixel tour.
Used by: thc itself (its Today screen, rebuilt cell for cell)
Maintainability
A prototype with tests and measured numbers, but one person and no release.
Releases: None yet. · Contributors: 1 · Recent: Built in October 2026 on a branch of thought-control. · Bus factor: low: one author
weaknesses
- A prototype by one author, unreleased, untested by anyone else.
- Its own format: no A2UI, json-render or MCP Apps input yet, against standards with real momentum.
- Data sources run shell commands: the opposite of the field's 'data, not code' safety stance. Needs a command policy before anyone pushes untrusted UIs.
- Fullscreen only: loses the terminal's native scrollback, search and selection, which agent CLIs have been moving back toward.
- Pixel features need kitty-graphics terminals (a minority).
- No MCP server yet, so agents need the socket or the CLI.
sources
- thought-control repository github.com
- caretline caretline.app