Fraym

Inspiration

The agent is becoming the interface, not a feature in the corner of a product but the primary way you use it. The good agent UIs today are terminal tools like Codex, genuinely excellent, but built for a developer coding in a terminal. You cannot drop them into an enterprise product, an existing app, or a website. Every product is about to grow an agent and needs a real interface for it. The model underneath is commoditizing fast, and the surface around it is the part everyone still rebuilds. I wanted to build it once, for any agent, and give it away.

What it does

Fraym is the open React cockpit for agent sessions: a web UI you embed in your product, not a terminal. Feed it a typed event stream and it renders everything, streaming messages, reasoning, tool cards with real diffs, approvals, a composer, and live presence. It is platform-agnostic, one responsive surface across web, desktop, and mobile, with a Tauri v2 desktop app today and mobile next.

Everything crosses one data-only boundary: a harness emits a typed AgentEvent stream and Fraym renders it, no function references cross, so the UI never imports a runtime. That makes it portable, with drivers for Codex, the Agent Client Protocol, the Vercel AI SDK, and replay, or one subscribe() for your own. A CLI ships too, so an agent can search the catalog and scaffold from stable JSON instead of reading the whole source. It is on npm, MIT, themeable, dark and light.

How we built it

I built Fraym with Codex CLI driving GPT-5.6, one feature at a time. I held the spec and the taste, wrote the tests and the design contract, handed Codex a slice, and it read the workspace, wrote the code, ran the checks, and commited each slice itself. GPT-5.6 reasoned the hard parts, the typed event contract and the one SessionThread surface every app reuses; Codex was the hands. Quality was its own loop: Codex ran React Scan for wasteful re-renders, React Doctor for a health score, and Fallow for dead code and boundary violations, and a jury of critic agents scored each design pass on hierarchy, contrast, and brand before anything shipped.

Challenges we ran into

Keeping one surface honestly reusable was the hard part, so every app mounts the same SessionThread instead of a fork. Presence nearly cost the demo: the looping thread remounted a few-thousand-node cockpit and ran out of memory, until I made it re-subscribe in place. And the live path found its own bugs, which is the point. A real ACP connection surfaced a working-directory bug a mock never would.

Accomplishments that we're proud of

The one I am proudest of is recursive: I pointed Fraym at a live Codex session and watched it render the exact session that built it. It is all real. The demo runs live over ACP against a real agent, the same surface runs on web, desktop, and mobile, and it is a real family of twelve packages on npm, with a kitchen-sink anyone can clone and poke.

What we learned

The boundary is everything. Once the UI could only speak in data-only events, every decision got simpler, because there was one place the runtime and the interface could meet. And a tight loop with a coding agent works when the spec and the tests are clear, as long as I stayed the one holding the taste.

What's next for Fraym

More harness adapters as the protocols land, an Extension SDK so plugins become first-class surfaces, and realms beyond code. And there is more to open: the full Fraym runs inside our own product and carries much more than what is here, the whole workspace shell, docks, session groups, and plugin surfaces. I will keep opening it, not just the drivers.

Built With

• agent-client-protocol
• bun
• cmdk
• codex
• fallow
• fraym-cli
• gpt-5.6
• npm
• radix-ui
• react-19
• react-doctor
• react-scan
• shiki
• streamdown
• tailwind-css-v4
• tauri-v2
• typescript
• virtua
• vite
• websocket
• zustand