Overview

What quickable is

quickable is a NATS-native webservice for LLM-driven visuals. An LLM (or any program) uses it over REST and MCP interchangeably to host and hot-modify sandboxed HTML/TSX apps; humans open them in a browser and interact; both sides share cheap, realtime, two-way state — no polling, no page reloads.

Every application operation is one typed NATS address (a subject plus zod request/reply schemas) in a single registry. REST routes and MCP tools are mechanical projections of that registry — there is exactly one API, described completely in the generated API reference.

LLM / script ── REST /v1 ─┐
LLM (agent)  ── MCP /mcp ─┤                        ┌─ core (flows, KV state)
                          ├─ gateway ── NATS ──────┼─ transform (build worker)
browser shell ── ws /nats ┘   (broker-enforced     └─ JetStream (KV / objstore)
   └─ sandboxed iframe          per-namespace
      (user TSX bundle)         accounts)

Why it is fast and token-efficient

• Block-addressed patches, not file rewrites. material.get returns your file annotated with content-hash block anchors; material.patch edits by anchor with CAS on the read revision. A two-block edit costs a few hundred tokens instead of retransmitting the file, and a conflict reply carries only the stale blocks — repair, never re-read.
• One small API. 18 addresses cover identity, apps, material, sessions and realtime. MCP tool schemas are generated from the same zod shapes the server validates with, so a model's first call is usually its last.
• Hot modify. A material write triggers the transform worker (Vite 8, oxc line); the built bundle lands on the app manifest and every open browser swaps the sandbox in place, preserving realtime state. No deploy step exists.
• Realtime push. Committed state changes fan out on NATS events; browsers render from the pushed delta. A client that missed events reconciles with one rt resume call.

The two shapes

Visual companion. An LLM creates an app, pushes a TSX visual, and hands the user a link. The user looks, clicks, comments — every interaction is a realtime intent the LLM can read and react to, updating the visual in place. See the visual companion guide.

Couch multiplayer. Realtime intents are server-authoritative (optimistic CAS on one KV key, idempotent within a dedup window), so two or more parties can play a shared game with durable resume. See the multiplayer guide.

Where to go

• Architecture — the containers, the sole-channel rule, and the 16 frozen invariants.
• Auth & namespaces — bring-your-own-key signup, the three credential classes, bearers for REST/MCP.
• API reference — every address, generated from the contract on every build.
• Run it — the whole stack from one docker compose file.
• Operations — observability, durable state, ramp-to-zero, honest residuals.