Development

Build from Source

Build the Origin daemon, CLI, MCP server, shared types, core crate, and plugin from the public repository.

Qi-Xuan LuUpdated Jun 1, 20265 min read

At a glance

The main repo is a Rust workspace with origin-core, origin-server, origin-cli, origin-mcp, and origin-types.

Use the source build path for development; most users should install through the plugin or npx setup.

When to build

Build from source when you are developing Origin, testing a branch, debugging the daemon, or preparing a contribution.

If you only want to use Origin, install through the Claude Code plugin or npx setup instead. The release path installs prebuilt binaries into ~/.origin/bin.

Workspace build

The repository is a Cargo workspace. First builds can take several minutes, especially on macOS where llama.cpp compiles with Metal support.

Run the daemon directly during development. For product-path testing, build release binaries and use origin setup, install, status, and doctor.

Source build

git clone https://github.com/7xuanlu/origin.git
cd origin
cargo build --workspace
cargo run -p origin-server

# before a PR
cargo fmt --check --all
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace

Crate boundaries

origin-core owns business logic and must stay free of Axum and Tauri dependencies. origin-server frames HTTP requests. origin-types stays lightweight because downstream clients consume it.

origin-mcp bridges MCP clients to the daemon. origin-cli manages setup, service state, recall, search, store, spaces, models, keys, and doctor checks.

Platform notes

Origin supports macOS arm64/x64, Linux x86_64/aarch64 with glibc, and Windows x86_64. The service manager differs by platform: launchd, systemd user units, or a Task Scheduler logon task.

Linux and Windows builds are CPU-only by default. macOS keeps Metal acceleration for local model paths.

Before opening a PR

Keep changes focused and evidence-backed. Add or update tests for behavior changes, run the relevant checks, and avoid unrelated refactors.

Docs changes should remove ambiguity or stale public language. Eval changes should follow the repository's citation discipline instead of publishing unsupported headline claims.

Read CONTRIBUTING.md

Testing and CI

Understand which Origin checks run locally, which run in GitHub Actions, and which evals stay manual.