lux

A visual output surface for AI agents.

Lux gives agents and apps a shared visual surface. The intended architecture is a hub/display split: clients send UI descriptions to luxd, the Hub owns authoritative element state and behavior, and the Display renders a replica of the current scene while forwarding user interactions back to the Hub.

The design draws on X11's client/server split and Smalltalk-style live introspection. MCP is one gateway into Lux, not the whole architecture. If you want the short version of the rewrite target, start with docs/architecture/target/target.md. If you need help navigating the docs, use docs/README.md. For the product direction, positioning, and risk assessment — the Working Backwards PR/FAQ — see prfaq.pdf.

Platforms: macOS, Linux

Stage: alpha --- protocol is stable, published on PyPI as punt-lux

A Claude Code plugin displaying a project issue board --- the agent fetches live data from DoltDB via bd list --json, builds a filterable table with detail panel, and renders it in a single tool call. Filters and row selection run at 60fps with zero MCP round-trips.

The same list/detail pattern generalizes to any tabular data. Search, combo filters, pagination, and a detail panel --- all driven by a single show_table() call.

Dashboards compose metric cards, charts, and tables. show_dashboard() builds the layout from structured data --- no manual element positioning needed.

Quick Start

curl -fsSL https://raw.githubusercontent.com/punt-labs/lux/6a95361/install.sh | sh

Restart Claude Code twice. The Lux display window opens automatically when agents send visual output.

uv tool install 'punt-lux[display]'

claude plugin marketplace add punt-labs/claude-plugins
claude plugin install lux@punt-labs

uv add punt-lux

curl -fsSL https://raw.githubusercontent.com/punt-labs/lux/6a95361/install.sh -o install.sh
shasum -a 256 install.sh
cat install.sh
sh install.sh

lux display &
uv run python demos/dashboard.py

Features

• 25 element kinds --- text, buttons (arrow, small), images, sliders, checkboxes, combos, inputs (text, number), radios, color pickers (alpha, full picker), selectables, trees, tables, plots, progress bars, spinners, markdown, draw canvases, modals, dialogs, groups, tab bars, collapsing headers, windows, separators
• Frames --- scenes target named frames (inner windows) via frame_id. Frames persist after disconnect, can be adopted by new clients, and support initial sizing (frame_size) and ImGui window flags (frame_flags)
• Layout nesting --- windows contain tab bars contain groups contain any element, arbitrarily deep
• Incremental updates --- update patches individual elements by ID without replacing the scene
• Session menus --- the menu bar shows one submenu per live session. A session registers a menu entry via register_callback from the connection it holds open to the Hub, and a click on that entry is pushed straight down that connection for the session to service from its own shell. The "Beads" entry each lux-enabled session's lux-beads applet registers is how the beads board reopens from the menu
• Interaction handling --- button clicks, slider changes, and menu clicks fire their handlers on the Hub (D21 remote dispatch); the raw event log is readable via list_recent_events. Hub handlers can publish app events that the agent reads via recv
• Announce on arrival, repaint in place --- a genuinely new scene raises and focuses its frame; updating an existing scene repaints it where it is. A minimized frame stays minimized, the focused frame keeps focus, and the selected tab stays selected --- the user controls what is front-most, not updates
• Persistent tabs --- each show() call opens a dismissable tab; same scene_id replaces content in-place. Users can close individual tabs
• Themes --- 11 themes via set_theme: imgui_colors_dark, imgui_colors_light, imgui_colors_classic, darcula, darcula_darker, material_flat, photoshop_style, grey_flat, cherry, light_rounded, microsoft_style
• Auto-spawn --- the Hub (luxd) starts the display renderer on first use if it isn't already running
• Unix socket IPC --- length-prefixed JSON frames, no HTTP overhead, no threads

MCP Tools

Agents interact with Lux through the MCP tools luxd serves over its streamable-HTTP /mcp endpoint (the authoritative roster is pinned by a test; this table mirrors it):

What It Looks Like

Show text and a button

{"tool": "show", "input": {
  "scene_id": "hello",
  "elements": [
    {"kind": "text", "id": "t1", "content": "Hello from the agent"},
    {"kind": "button", "id": "b1", "label": "Click me"}
  ]
}}

Returns "shown:hello" immediately — the Hub has accepted the scene and its background replicator paints it; no tool call ever waits on the display. A button click fires its handler on the Hub (the agent does not poll for it). To observe interactions, read the introspection log:

{"tool": "list_recent_events", "input": {"count": 5}}

A Hub-side handler can publish an app event that the agent then reads with recv (see the Pub/Sub tools above). An element that declares "publish": ["my.topic"] publishes what the user did — the event's kind, the scene and element it landed on, and its own fields, such as a table selection's row_ids and anchor. The full shape is in the library guide.

Multi-window dashboard

{"tool": "show", "input": {
  "scene_id": "dash",
  "elements": [
    {"kind": "window", "id": "w1", "title": "Controls", "x": 10, "y": 10,
     "children": [
       {"kind": "slider", "id": "vol", "label": "Volume", "value": 50}
     ]},
    {"kind": "window", "id": "w2", "title": "Chart", "x": 320, "y": 10,
     "children": [
       {"kind": "plot", "id": "p1", "title": "Trend",
        "series": [{"label": "y", "type": "line",
          "x": [1,2,3,4], "y": [10,20,15,25]}]}
     ]}
  ]
}}

Update a single element

{"tool": "update", "input": {
  "scene_id": "dash",
  "patches": [
    {"id": "vol", "set": {"value": 75}}
  ]
}}

Element Kinds

All elements with an id support an optional tooltip field (string shown on hover).

CLI Commands

Library (Python)

Python applications drive the Hub through LuxRestClient, the typed client of luxd — the same validation, typing, and identity handling the CLI gets, with no [display] extra required. Long-lived apps add LuxHubClient to receive menu clicks and pub-sub events over a persistent connection; vox's music player is the reference app built this way. The full guide, with working examples, is docs/library.md.

Architecture

Agent or app
  │ MCP or direct Hub API
  ▼
luxd (Hub)
  │ authoritative state + introspection
  │ scene replicas + remote invocations
  ▼
lux display (ImGui + OpenGL)
  │ renders at 60fps
  ▼
Window on screen

The Hub is the single source of truth for element state, ownership, and handler dispatch. The Display is a rendering replica: it paints the current scene and forwards interactions back to the Hub, which runs the real handler and re-pushes updated state. MCP is one entry point, not the only one.

How a session connects, and how its menu entries work

The bundled plugin connects Claude Code straight to luxd, with no per-session process in the path:

{
  "mcpServers": {
    "lux": { "type": "http", "url": "http://127.0.0.1:8430/mcp" }
  }
}

Menu entries are a separate connection, and they belong to the session's applets. An applet is a small program — not a daemon, not part of luxd — that the plugin's session-start hook launches and that runs for the life of that session, in that session's repository and shell. lux-beads is the first.

An applet exists because a menu entry must launch in the time a user reads as instant, so the click has to be answered by something already running and already reachable: not a poll, and never a turn of the model. The applet registers its entry on its own connection, receives clicks pushed down it, and does the work itself — running bd from the repository's own shell and pushing the board to the Hub, which luxd cannot do from launchd with no PATH, no credentials, and no working directory.

It does not make you wait for data it could already have. Reading the issues is a query to a hosted database and it is the whole wait, so the applet loads a board as soon as its entry is registered and holds the board from every click after that. A click puts that board up immediately and reloads behind it; the fresh one replaces it in place, without taking focus. A reload that fails leaves the board standing and says why in the applet's log, because a board a few minutes old is worth more than a red message where the board was. Only a session that has not managed to load one yet sees "Loading issues…".

It leaves when its session does. Handed the session's process id at spawn, it checks every few seconds whether that process still exists and exits when it does not, so an applet cannot outlive its session even when the session is killed rather than closed. The Hub's lease sweeps the menu entry underneath that regardless.

luxd enforces the arrangement rather than trusting it: register_callback is refused unless the calling connection holds a listen leg, because a connection that could never be told its item was clicked must not own one. That is why the tool surface a session talks to owns no entries.

Setup and verification for a hand-configured direct connection are in docs/library.md.

Documentation

Docs Guide | Python Library Guide | Target Architecture | Current Architecture | Design Log | Changelog

Development

uv sync --extra display        # Install dependencies (dev group installs by default)
make check                     # Full gate: lint, format, mypy, pyright, tests, OO ratchet
make test-integration          # Integration tier
make restart                   # Rebuild, reinstall, restart luxd AND the display

make check is the commit gate — it runs ruff, mypy, pyright (via npx), pytest, and the OO ratchet exactly as CI does.

Acknowledgements

Lux is a thin orchestration layer. The rendering is done by Dear ImGui, Omar Cornut's immediate-mode GUI library. ImGui handles all the hard problems --- text layout, widget state, input handling, GPU rendering --- and does so in a single-pass retained-mode-free architecture that maps naturally to Lux's "send JSON, render this frame" model. The 60fps render loop, the composable widget tree, and the ability to drive a full UI from a socket with no threading are all consequences of ImGui's design.

Python bindings come from imgui-bundle by Pascal Thomet, which packages ImGui, ImPlot, and several other ImGui extensions into a single pip-installable wheel with complete type stubs. imgui-bundle is what makes "install one Python package, get a GPU-accelerated UI" possible.

FastMCP provides the MCP server layer.

License

MIT