
Raxol: Same OTP app rendering as a terminal UI, LiveView, MCP server, Telegram bot, and Watch push
Update on Raxol, an OTP-native runtime I've been building.
Raxol lets you build a TEA module (Model, Update, View, i.e. the Elm Architecture) that renders to all of these:
- A terminal UI via the Raxol VT100 emulator
- A Phoenix LiveView in the browser
- Auto-derived MCP tools for AI agents
- Telegram inline keyboards
- Apple Watch and Android push cards
- A JSON API
Raxol's update/2 doesn't care where the message came from.
A keystroke, an LLM token, a x402 response, a sensor reading: all messages. When the Telegram bridge drops, the LiveView keeps rendering. When a job in raxol_symphony crashes, the orchestrator stays up.
Agents and human-facing apps want the same shape.
The human reacts to keystrokes.
The agent reacts to LLM tokens. update/2 can't tell them apart.
e.g. Raxol.Agent is Raxol.Core.Runtime.Application with a different message source. ReAct, chain of thought, an FSM with guards: different bodies, same shape.
Per-process wallets work on the BEAM in a way they don't elsewhere. raxol_acp gives you one supervised process per ACP job, a NonceServer GenServer per wallet so concurrent jobs don't race on the nonce, and DETS-backed memo persistence so restarts resume mid-flight. Every other ACP seller is a Python script with a threading. Lock and a polling loop.
... Anyways, if you're down to clown we're open to contributions!
Otherwise lmk your ideas-- happy to collaborate.
Github: Raxol 11 of 13 packages on Hex. raxol_acp and raxol_symphony still pre-alpha.