CORE / terminal-first autonomy · v0.13.11 beta · open source

Forged to run.Hardened to last.Built to evolve.

A terminal-first agent that plans, runs real tools, asks when it matters, and scales to a swarm - for any kind of work, not just code.

>npx @ferroxlabs/wayland-coreCopy
Activity
type / for commands
Esc interrupt   ⏎ queue a message for the next turn
claude-sonnet-4-6 Default ctx 0% $0.00 00:11
Provider-neutral
MCP client + server
OS-native sandbox
Worktree swarms
Failover + retries
JSON-stream embedding
Self-evolving
Egress firewall
Engine & app

Wayland Core is the engine.
Wayland Desktop is the app.

Core is the open Rust runtime that does the work - the agent loop, tools, providers, sandbox, and memory. Desktop is the GUI product that embeds Core over a JSON-stream protocol. Same engine: run it raw in your terminal, or get the full command center on top.

CORE · you are hereApache-2.0

Wayland Core

The embeddable engine. One Rust binary - terminal-first agent, headless JSON-stream, MCP, OS-native sandbox, ~20 providers, ~70 tools.

  • Run in your terminal or headless
  • Embed it behind your own app
  • Expose it as an MCP server
$ npx @ferroxlabs/wayland-core
DESKTOP · the appGUI product

Wayland Desktop

The polished command center built on Core: assistants, workflows, teams, a sub-agent monitor, approvals, and a UI - for everyone, not just the terminal.

  • Visual workspace & approvals
  • Assistants, workflows, teams
  • Local or cloud, your call
Get the desktop app →
Not a mockup

This is the actual terminal.

Run it with no arguments and Core finds your provider keys and drops you into a full-screen TUI - onboarding, a live sub-agent swarm, and the finished run, all in your shell.

Wayland Core onboarding - connect a provider
ConnectDetects your keys, picks a model
Wayland Core - a sub-agent swarm running
SwarmParallel sub-agents, isolated workers
Wayland Core - the finished run
ShipMerged result, every step gated
What it does

Three things almost no other agent does together.

Most agent CLIs lock you to one vendor, run tools wide-open, and never get better. Core is built the other way.

Provider-neutral by design

~20 providers - Anthropic, OpenAI, Bedrock, Vertex, Gemini, plus ~15 OpenAI-compatible vendors and local Ollama - behind one trait, where every quirk is config data, not a code branch. Per-request retries, key rotation, a cross-provider fallback chain, and a circuit breaker on every provider. Switching vendors is a one-line change.

~20 providersFailover + retriesHundreds of models via routers

Hardened to run untrusted work

Every shell command runs in an OS-native sandbox - bubblewrap on Linux, sandbox-exec on macOS - and fails closed when none is available. On Windows the default is a kill-on-close Job Object, which bounds the process but does not confine the filesystem; AppContainer is opt-in via WAYLAND_SANDBOX=appcontainer. Every outbound request passes a default-on egress gate, enforced structurally by a Clippy lint. Approval modes gate the risky calls; budget caps actually block. Real security, not a checkbox.

OS-native sandboxEgress firewallApproval gatesBudget caps

It learns as it works

An offline evolutionary optimizer (GEPA) mutates and scores skill prompts across generations, and an in-session drafter auto-writes a reusable skill after three successful runs on the same task. That drafting loop is on by default: the draft is recorded into GEPA's PromptStore with full lineage and the skill router reads from it, so the library your install uses grows out of work that actually succeeded. Winners are persisted with full lineage, and promotion into the live catalog is a deliberate manual gate rather than an automatic one. Online evolution - the loop running against your own sessions - is configurable and off by default, because it spends a model call at session end. Offline plus drafting, reviewed before promotion; not a live production self-rewrite.

GEPA optimizerAuto-drafted skillsCognitive memory
How it compares

We ran the audit. Here's the landscape.

A file-level audit of the open-source agent CLIs and a docs-level orientation against the closed ones. Where we lose, we say so.

Landscape comparison - Wayland Core vs opencode, aider, Claude Code, Codex CLI
Providers and model routing, compared
Orchestration and swarms, compared
Security and sandboxing, compared
Built-in tools, compared
Extensibility, compared

Closed-source tools (Claude Code, Codex CLI) are a docs-based orientation, not a code audit. Where we lose, we say so - git auto-commit/undo belongs to opencode and aider.

The full runtime

And everything else, built in.

One binary. Point it at a model and it does the work - calling real tools, orchestrating sub-agents, and staying inside your budget.

Crucible council

A Mixture-of-Providers council: N proposers, each pinned to a different provider, work in parallel, and a fenced read-only aggregator fuses one answer. Run wayland-core crucible "<task>" with --auto, --advisor, or --terminal, inside budget and daily-cap guards.

One binary, three modes

An interactive ratatui TUI, a one-shot wayland-core "prompt", or a headless --json-stream engine - from a single entry point.

~70 built-in tools

Files, shell, search, web, media, scheduling - availability-gated, with a no-stubs contract: env-gated tools hide when credentials are absent.

MCP client + server

Connect any MCP server over stdio, SSE, or streamable-HTTP - or run wayland-core mcp-serve to expose your tools to other hosts.

Sub-agents & swarms

Fan work to parallel sub-agents with Spawn and Delegate, or run worktree-isolated swarms - up to a 100-agent Fleet, each on its own git branch.

ForgeFlows

Declarative, validated workflows - Agent, Pipeline, and Parallel stages - run as a DAG, callable as a tool or straight from the CLI.

Cognitive memory

A real 5-partition × 3-tier memory, SQLite-backed and searchable by meaning. On by default, with background decay. What you teach it survives.

Scheduled tasks

Cron expressions that fire a slash command, a channel message, or a skill - from the CLI, or scheduled by the agent itself.

10 messaging channels

Drive the agent from Slack, Discord, Telegram, Signal, WhatsApp, SMS, Email, Matrix, Teams, or iMessage - one config file.

Plan mode

A read-only mode that studies the code and writes a structured plan before it touches a file. Approve, keep, or discard it.

Plus context compaction, named profiles with inheritance, project-context injection, computer-use on four OSes, a browser tool, an eval harness, and signed self-update.

Built to endure

Most demos prove it can finish.
We're proving it can last.

Can an agent run unattended for hours on its own codebase - surviving crashes and injected faults without drifting or corrupting its state? We're running exactly that, as an open endurance trial.

12 hrs
One continuous unattended run
322
Maintenance iterations - 229 gate-passing commits (~71%)
80 / 80
Fault-injection kills recovered, zero duplicate commits
< $10
Total provider cost, from raw usage records
Resilience under fire - WAL, retry, and checkpoint recovering through deliberate kills

What we don't claim: this isn't recursive self-improvement - the build is pinned and nothing rewrites itself. One clean run isn't proof of a week. A continuous week, then a month, are roadmap goals, labeled as goals. Read the method →

For builders

Embed the whole agent loop behind your app.

One flag - --json-stream - turns Core into a headless engine you drive over a typed, versioned JSON-Lines protocol. Stream tokens, render tool calls, gate approvals, resume sessions. It's exactly how Wayland Desktop is built.

  • Typed events - text deltas, tool requests & results, sub-agent events, approvals.
  • Honest errors - a retryable flag on every failure, no guessing.
  • Host-driven approvals - pause on a tool; approve once, always, or deny.
  • Apache-2.0 - build and ship commercial software on it.
Read the embedding docs →
$ wayland-core --json-stream "fix the failing test"
{"type":"ready","session":"a1b2c3"}
{"type":"text_delta","text":"I'll find the test…"}
{"type":"tool_request","name":"Bash","input":{"cmd":"cargo test"}}
{"type":"tool_result","name":"Bash","ok":true}
{"type":"text_delta","text":"Fixed an off-by-one."}
{"type":"stream_end","usage":{"in":4200,"out":890}}
Architecture

One engine. Many surfaces.

A workspace of focused crates. Dependencies flow strictly downward; the engine only ever sees provider-neutral types, and format conversion lives inside each provider.

One engine, many surfaces - CLI, TUI, JSON stream, and an embedded host all driving the same core
LayerCratesResponsibility
Foundationwcore-types · wcore-compactProvider-neutral data types; context compression
Core serviceswcore-config · wcore-providers · wcore-tools · wcore-mcpConfig + ProviderCompat, LLM providers, built-in tools, MCP
Capabilitieswcore-skills · wcore-memory · wcore-sandbox · wcore-swarm · wcore-browserSkills, memory, sandbox, swarm, browser + computer use
Enginewcore-agentAgent loop, sessions, orchestration, workflows
Surfacewcore-cliCLI / TUI / JSON-stream binary
Fleet spawn fan-out - one orchestrator, isolated workers, merged result

Worktree swarm - each worker on its own git branch, process-isolated.

Security: fail-closed - sandbox plus one CI-enforced egress gate

Fail-closed security - OS sandbox plus one CI-enforced egress gate.

Get Core

One command. Apache-2.0.
macOS · Linux · Windows.

$npm i -g @ferroxlabs/wayland-coreCopy

Grabs the prebuilt binary for your platform - no Rust or Node project required. Or run it once: npx @ferroxlabs/wayland-core "summarize the TODOs in this repo".