Raxol

Recursively, axol. Forever FOSS.

Write one app. Render it to a terminal, a browser, or an agent.

Your application is a single TEA module (init, update, view) running as an OTP GenServer. Raxol renders that module to four surfaces from one codebase:

                          +---> termbox2 NIF (terminal)
                          |
  TEA module (GenServer) -+---> Phoenix LiveView (browser)
                          |
                          +---> SSH daemon (remote terminal)
                          |
                          +---> MCP tools (agents)

The interesting part is the runtime, not the terminal. Your app gets crash isolation per component, hot code reload without restart, distributed clustering with CRDTs, and an agent surface where LLMs interact with structured widget trees instead of scraping pixels. Bubble Tea, Ratatui, and Textual are excellent renderers. A2UI and AG-UI define agent-UI wire formats. Raxol is the runtime that renders all four surfaces from one source module.

Built with Raxol: Xochi

Xochi is a private cross-chain DEX: intent-based swaps across 5 chains, sub-3s settlement, stealth addresses by default, ZKSAR compliance proofs. Its entire trading surface is raxol:

• Trader terminal serves over SSH, zero install, dark-pool aesthetic
• Web trading UI renders the same TEA module via LiveView
• Solver agent surface lets Riddler's sub-2ms solver consume auto-derived MCP tools to bid on intents
• Ops cockpit runs a BEAM dashboard with sensor fusion on solver health, validator peers, settlement latency

One TEA module. Four surfaces. The solver agent and the human trader interact with the same widget tree through different projections. That's the pitch nothing else in this space can match.

Install

# mix.exs
def deps do
  [{:raxol, "~> 2.4"}]
end

Or generate a new project:

mix raxol.new my_app

Hello World

defmodule Counter do
  use Raxol.Core.Runtime.Application

  def init(_ctx), do: %{count: 0}

  def update(:inc, model), do: {%{model | count: model.count + 1}, []}
  def update(:dec, model), do: {%{model | count: model.count - 1}, []}
  def update(_, model), do: {model, []}

  def view(model) do
    column style: %{padding: 1, gap: 1} do
      [
        text("Count: #{model.count}", style: [:bold]),
        row style: %{gap: 1} do
          [button("+", on_click: :inc), button("-", on_click: :dec)]
        end
      ]
    end
  end

  def subscribe(_model), do: []
end

That module runs three ways without changes:

# Terminal
mix run examples/getting_started/counter.exs

# LiveView (mount in your Phoenix app)
# live "/counter", Raxol.LiveView.TEALive, app: Counter

# MCP (an agent clicks the "+" button)
# session |> click("+") |> assert_widget("Count: 1")

The GUI-vs-TUI debate is a rendering argument. Whether your app can be consumed by agents at the same time is a runtime problem, and that's what raxol solves.

Agents that can pay

raxol_payments gives agents wallets, spending controls, and three payment protocols. An agent hits a 402'd resource. The Req plugin handles the rest.

# Agent auto-pays for a resource via Xochi cross-chain settlement
client = Req.new(base_url: "https://api.example.com")
  |> Raxol.Payments.Req.AutoPay.attach(
    wallet: {:op, "Agent Wallet"},
    protocol: :xochi,
    spending_policy: %{per_request: 50_000, session: 500_000}  # in wei
  )

{:ok, response} = Req.get(client, url: "/premium-data")
# If 402 -> wallet signs EIP-712 -> Xochi settles cross-chain -> response arrives

Three protocols behind one interface: x402 (Coinbase HTTP 402, same-chain), MPP (Stripe/Tempo machine payments), and Xochi (cross-chain intent settlement, 0.10-0.30% fees, stealth-capable). Per-request, per-session, and lifetime spending limits enforced by a ledger GenServer. See Agentic Commerce docs.

Agent surface (MCP)

Every interactive widget automatically exposes MCP tools. Button gives you click, TextInput gives you type_into/clear/get_value. A focus lens tracks what's relevant and filters to ~15 tools per interaction, so agents work with a contextual slice of the widget tree rather than a flat dump of every possible action.

Where A2UI and AG-UI define how agents talk to UIs at the wire level, raxol generates both the UI and the agent surface from a single widget tree. Same source of truth, two projections.

import Raxol.MCP.Test
import Raxol.MCP.Test.Assertions

session = start_session(MyApp)

session
|> type_into("search", "elixir")
|> click("submit")
|> assert_widget("results", fn w -> w[:content] != nil end)
|> stop_session()

mix mcp.server starts the MCP server on stdio for Claude Code integration.

Why OTP matters here

Raxol's interface runtime is built on the BEAM, a VM originally designed for telephone switches. Systems that couldn't go down, couldn't lose state, and had to hot-swap code on live calls. Those constraints turn out to be exactly right for multi-surface apps.

For the TUI-framework audience, here's the comparison you'd expect:

¹ Textual has devtools with CSS inspection, but not state-level time-travel.

Try it

git clone https://github.com/DROOdotFOO/raxol.git
cd raxol && mix deps.get
mix raxol.playground          # 30 live demos, browse/search/filter
mix raxol.playground --ssh    # same thing, served over SSH (port 2222)

The flagship demo is a live BEAM dashboard with scheduler utilization, memory sparklines, and a process table, all updating in real time:

mix run examples/demo.exs

More examples:

mix run examples/getting_started/counter.exs    # Minimal counter
mix run examples/apps/file_browser.exs           # File browser with tree nav
mix run examples/apps/todo_app.ex                # Todo list
mix run examples/agents/code_review_agent.exs    # AI agent analyzing files
mix run examples/agents/agent_team.exs           # Coordinator + worker agents
mix run examples/agents/ai_cockpit.exs           # Multi-agent AI cockpit (mock)
FREE_AI=true mix run examples/agents/ai_cockpit.exs  # Real AI via LLM7.io (free)
mix run examples/swarm/cluster_demo.exs          # CRDT state sync demo

Other tools:

mix raxol.repl                                    # Sandboxed REPL (--sandbox strict)
mix phx.server                                    # Web playground at /playground

See examples/README.md for the full learning path.

Features

Process isolation. Wrap any widget in process_component/2 and it runs in its own process. Crashes restart cleanly; the rest of the UI stays up.

Hot code reload. Change your view/1, save, the running app picks it up. No restart.

Widgets and layout. Button, TextInput, Table, Tree, Modal, SelectList, Checkbox, Sparkline, Charts. Keyboard-navigable with focus management. Flexbox and CSS Grid, nested freely. Virtual DOM diffing with damage tracking.

Theming. Named colors, RGB, 256-color, and hex, downsampled to the terminal's capability. Inline images via Kitty, Sixel, and iTerm2.

SSH serving. Raxol.SSH.serve(MyApp, port: 2222). Each connection gets its own supervised process.

LiveView bridge. Same TEA app renders in Phoenix LiveView with a shared state model.

Distributed swarm. CRDTs (LWW registers, OR-sets), node monitoring, seniority-based election. Discovery via libcluster with gossip, epmd, DNS, or Tailscale.

Sensor fusion. Poll sensors, fuse readings with weighted averaging, render gauges and sparklines. Self-adapting layout tracks usage and recommends changes.

Time-travel debugging. Snapshots every update/2 cycle: step back, forward, jump, restore. Zero cost when disabled.

Session recording. Captures to asciinema v2 .cast files with pause, seek, speed control, and auto-save on crash.

Sandboxed REPL. mix raxol.repl with three safety levels. AST-based scanning blocks dangerous operations; safe for SSH exposure in strict mode.

Performance

Full frame in 2.1ms on Apple M1 Pro (Elixir 1.19 / OTP 27), which is 13% of the 60fps budget. In a system like Xochi where the solver loop targets sub-2ms, raxol sits within that frame budget without adding overhead to the hot path.

Unix/macOS backend uses a termbox2 NIF; Windows uses a pure Elixir driver (usable, not yet tuned). See the benchmark suite.

Accessibility

The structured widget tree already carries type, label, and state metadata on every widget. That's semantically richer than a pixel buffer, so screen reader support is a serialization step on top of existing structure rather than a redesign. On the roadmap, tracked, contributions welcome.

Documentation

Start here

• Quickstart
• Core Concepts
• Widget Gallery

Cookbook

• Building Apps
• SSH Deployment
• Theming
• LiveView
• Performance

Reference

• Architecture
• Buffer API
• Benchmarks
• API Docs

Advanced

• Agent Framework
• Agentic Commerce
• Sensor Fusion
• Distributed Swarm
• Recording & Replay
• Why OTP

Standalone packages (grab just the subsystem you need):

Development

git clone https://github.com/DROOdotFOO/raxol.git
cd raxol
mix deps.get
MIX_ENV=test mix test --exclude slow --exclude integration --exclude docker
mix raxol.check              # format, compile, credo, dialyzer, security, test
mix raxol.check --quick      # skip dialyzer
mix raxol.demo               # run built-in demos

Origin

Raxol started as two converging ideas: a terminal for AGI, where AI agents interact with a real terminal emulator the same way humans do; and an interface for the cockpit of a Gundam Wing Suit, where fault isolation, real-time responsiveness, and sensor fusion are survival-critical. The Gundam thing sounds like a joke. Then you look at the constraint set and it's exactly what OTP was built for: systems that can't go down, can't lose state, and have to hot-swap components while running.

License

MIT. See LICENSE.md.