Skip to content

Platforms

Platform Support

Understand how Origin runs on macOS, Linux, and Windows: service managers, local data paths, model backends, and Docker/VM caveats.

Qi-Xuan LuUpdated 5 min read

At a glance

01

Origin's released runtime supports macOS arm64/x64, Linux x86_64/aarch64 with glibc, and Windows x86_64.

02

The daemon contract is the same across platforms, but service registration, data paths, and model acceleration differ.

01

Supported platforms

Origin v0.7.0 broadened the local runtime from macOS-first to cross-platform support across macOS, Linux, and Windows.

The same daemon, CLI, and MCP connector shape applies on each platform. The operating-system integration is what changes.

Runtime matrix

macOS    arm64, x64              launchd user agent
Linux    x86_64, aarch64 glibc  systemd user unit
Windows  x86_64                 Task Scheduler ONLOGON task

02

Service registration

Origin installs as a per-user service so the local daemon can be available to MCP clients without a manual terminal session.

macOS uses launchd. Linux uses a systemd user unit. Windows uses a per-user Task Scheduler ONLOGON task.

03

Data paths

The daemon keeps its database and application data in the OS application data location. Origin also exposes human-readable artifacts under ~/.origin so pages, sessions, status records, and local git history are easy to inspect.

Treat both locations as private application data. They can contain project decisions, preferences, client context, and old versions.

Data locations

macOS:   ~/Library/Application Support/origin/
Linux:   ~/.local/share/origin/ or $XDG_DATA_HOME/origin/
Windows: %LOCALAPPDATA%\origin\

Readable artifacts: ~/.origin/

04

Model backends

The core memory loop does not require a local model or API key. Store, embed, search, recall, MCP context, and the agent-side workflow still work without configuring daemon-side language models.

For optional local model paths, macOS keeps Metal acceleration. Linux and Windows release builds are CPU-only by default in the current public shape.

05

Docker and VMs

Normal laptop use should keep the daemon bound to 127.0.0.1:7878. That keeps the HTTP API local to the machine.

Use ORIGIN_BIND_ADDR only when you intentionally need non-loopback access, such as a Docker or VM setup. Exposing the daemon changes the security boundary, so pair it with the security reporting and configuration guidance.

Bind address

ORIGIN_BIND_ADDR=127.0.0.1:7878
ORIGIN_BIND_ADDR=0.0.0.0:7878  # Docker or VM only

06

After setup

Whatever platform you use, verify setup the same way: run origin status and origin doctor, then do one capture/recall round trip from the client you care about.

If the daemon works but an MCP client does not, restart the client and rerun origin mcp add for that client before assuming the runtime is broken.

Next

HTTP API

Know the local daemon surfaces that the CLI, MCP connector, plugin, and local tools call under the hood.

Read next