Architecture and Tech Stack
Monorepo layout, packages, dependency direction, and technologies.
One repository produces every surface -- desktop, terminal and server -- from a shared engine and a shared set of types. This page is the map: what the layers are, which way dependencies point, and exactly which technologies sit underneath.
Tech stack
| Layer | Technology |
|---|---|
| Runtime & package manager | Bun 1.3.14 |
| Desktop shell | Electron 44 + electron-vite |
| UI | SolidJS 1.9 + TailwindCSS 4 |
| Language | TypeScript 5.8 |
| Build | Vite 7, electron-builder, Turborepo 2.10 |
| Database | SQLite (drizzle-orm 1.0) in WAL mode |
| LLM runtime | AI SDK (Vercel) 6.0 |
| Async runtime | Effect 4.0 |
| Browser automation | Playwright (Chromium) |
| Voice input | Chrome SpeechRecognition |
| Voice output | Edge Neural TTS |
| Memory | SQLite WAL + ring buffer + brain daemon |
| Subagents | 3-level deep Mission Control |
| Providers | 25+ (OpenAI, Anthropic, Google, Azure, Bedrock, xAI, Mistral...) |
Dependency direction
Dependencies point downward and never back up. The client and session UI depend on Schema and Protocol only -- never on Core or Server -- which is what keeps a change in the engine from rippling into the interface.
text
┌──────────────────────────────┐
│ Desktop / TUI / SDK │ ← what you interact with
└───────────────┬──────────────┘
│
┌───────────────▼──────────────┐
│ Client · Session-UI │ ← state, chat, composer
└───────────────┬──────────────┘
│ depends on Schema + Protocol only
┌───────────────▼──────────────┐
│ SDK · Protocol │ ← wire types, generated client
└───────────────┬──────────────┘
│
┌───────────────▼──────────────┐
│ Core │ ← effects runtime, config,
│ Schema Server Agent │ database, tools, MCP
└──────────────────────────────┘Project structure
text
ZYRAXON-AI/ ├── packages/ │ ├── zyraxon/ # Core AI engine (888 tools, 63 categories) │ │ ├── src/ │ │ │ ├── agent/ # 11 agent modes │ │ │ ├── mcp/ # MCP servers + tools │ │ │ ├── tool/ # Core tools │ │ │ ├── x/ # domain tools + control systems │ │ │ ├── session/ # LLM streaming │ │ │ ├── screen/ # Vision system │ │ │ └── memory/ # Eternal memory │ ├── desktop/ # Electron app │ ├── app/ # SolidJS UI │ ├── ui/ # Shared components │ ├── core/ # Database, utilities │ ├── llm/ # 25+ provider routing │ └── session-ui/ # Session UI
Request lifecycle
- 01The surface (desktop, TUI or SDK) creates a session.
- 02Your prompt is assembled with memory and, where enabled, a screen frame.
- 03The provider layer picks a working model and streams the reply.
- 04The agent selects tools; each call is checked by the permission layers.
- 05Results are persisted to memory and streamed back as events.
ℹ
Why one repo
Sharing types across every surface means a protocol change is caught at build time everywhere at once, rather than discovered in production in one client.