Packages and Monorepo Layout

What each package in the monorepo holds, and why the boundaries matter.

ZYRAXON is a monorepo. Dependencies point one way and only one way: client runtime code may depend on Schema and Protocol but never on Core or Server -- which is what keeps a provider change from rippling into the UI.

Core packages

PackageHolds
packages/schemaThe data shapes everything agrees on
packages/coreEffects runtime, configuration, database, utilities
packages/protocolThe wire types
packages/serverHTTP API and server routes
packages/zyraxonThe agent: tools, session, MCP, prompts
packages/sdkGenerated client
packages/sdk-nextNext-generation Effect-TS SDK
packages/clientUI state and data layer
packages/appThe application shell
packages/uiDesign system
packages/session-uiChat, timeline and composer
packages/desktopElectron shell, TTS, task daemon, packaging
packages/llmProvider definitions and model routing
packages/pluginPlugin system for custom tools
packages/cliTerminal client and Node sidecar
packages/tuiTerminal user interface

The agent package, in detail

FolderContains
src/agentAgent registry, prompts and mode definitions
src/toolCore tools -- bash, read, write, edit, grep, glob and the rest
src/xDomain tools and the control-system classes
src/mcpMCP client, catalog and bundled servers
src/sessionLLM streaming and session lifecycle
src/screenVision system
src/memoryEternal memory
src/providerProvider routing and model status
src/permissionThe layered permission evaluation
src/skillSkill discovery

Why the Effect runtime

The agent is written against the Effect runtime rather than ad-hoc async control flow. Cancellation, timeouts, retries and resource lifetimes are part of the type of a function instead of something to remember at each call site -- which is why a dropped MCP connection or a timed-out fetch cannot leave a resource dangling.

ℹ
Published to npm
The public packages are published under the @zyraxon-ai npm scope. See the SDK page for install commands.