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.

Nerdier, wordier, write-up with the cockpit framing & where this goes: https://droo.foo/posts/raxol-terminal-for-the-gundam