Skip to content

Config

Environment Variables

Know which Origin environment variables are normal configuration, which are development-only, and which belong to eval or Windows repair paths.

Qi-Xuan LuUpdated 5 min read

At a glance

01

Most users should configure Origin with /init, origin setup, origin mcp add, origin model, origin key, and origin space.

02

Environment variables are for scoped overrides: spaces, daemon networking, dev isolation, Windows runtime repair, and eval runs.

01

Use commands first

Origin's normal configuration path is command-driven. Use /init or npx setup for installation, origin mcp add for clients, origin space for spaces, and origin key or origin model for optional language features.

Reach for environment variables when you need a temporary override, a scripted run, or a development/eval setup that should not become the default for every session.

02

Normal runtime overrides

ORIGIN_SPACE selects the active memory bucket for the current shell or process. ORIGIN_HOST points the CLI at a daemon URL when you are not using the default local address.

ORIGIN_BIND_ADDR changes where the daemon listens and should stay loopback unless you intentionally expose the daemon in Docker or a VM.

ANTHROPIC_API_KEY is only needed when you opt into daemon-side Anthropic work. The core local memory loop does not require it.

Runtime variables

ORIGIN_SPACE=client-a
ORIGIN_HOST=http://127.0.0.1:7878
ORIGIN_BIND_ADDR=127.0.0.1:7878
ORIGIN_BIND_ADDR=0.0.0.0:7878  # Docker or VM only
ANTHROPIC_API_KEY=sk-ant-...

03

Development isolation

Developers sometimes need a separate port and data directory so a test daemon does not share the same database as the installed product runtime.

Use those overrides deliberately and together. A different port without a different data directory can still point development work at production-like local memory data.

Isolated daemon

ORIGIN_PORT=7879
ORIGIN_DATA_DIR=/tmp/origin-test
cargo run -p origin-server

04

Windows runtime repair

If Windows cannot load the bundled ONNX Runtime library, point ORT_DYLIB_PATH at the onnxruntime.dll inside the Origin install directory before starting the daemon.

This is a repair path, not a normal setup step. Start with origin doctor when the daemon fails to start.

Windows

ORT_DYLIB_PATH=C:\path\to\origin\onnxruntime.dll

05

Eval variables

Eval variables belong to benchmark and maintainer workflows. They control cache location, fixture truncation, and API-backed judge access.

Do not use eval variables to make product claims casually. Public numbers should follow the eval methodology and state run count, fixture, model, and limits.

Eval examples

EVAL_BASELINES_DIR=$HOME/.cache/origin-eval
EVAL_LOCOMO_LIMIT=25
EVAL_LME_LIMIT=25
ANTHROPIC_API_KEY=sk-ant-...
Read evaluation

06

Experimental flags

Main-branch experimental flags are separate from normal runtime configuration. They are for source checkouts, evaluation, and maintainer testing, not routine installed use.

If you set one, record the flag name, git commit, data directory, and whether the feature is released or still on main.

Read experimental flags

07

Security boundary

Environment variables can change where Origin listens, where it stores data, and which provider keys it can use. Treat those values like operational configuration, not copy-paste snippets.

Never publish a shell transcript that includes API keys, private data paths, or a non-loopback daemon address you did not mean to expose.

Read data and privacy

Next

Connect MCP Clients

Use one local Origin memory layer from Claude Code, Codex, Cursor, Claude Desktop, Gemini CLI, and other MCP clients.

Read next