// local memory for AI coding agents

Give Claude, Codex, Cursor, and OpenCode memory across repos

Agents forget decisions, architecture, and project history between sessions. Orqenix keeps that context in repo-owned local memory, scopes access per project, and recalls only the useful parts when your agent needs them.

~/projects · orqenix

$ npm install -g @orqenix/cli
$ orqenix init

Local-firstMCP-compatibleNo telemetryApache 2.0 core

Install CLI View GitHub

// problem

AI agents are powerful, but their memory is fragile

Production teams do not lose time because agents cannot write code. They lose time because agents repeatedly lose context.

Sessions reset

Decisions, debugging history, and architecture notes vanish when the chat or terminal context is gone.

Repos stay isolated

Your frontend agent cannot easily reuse backend decisions, shared package patterns, or infra lessons.

Cloud memory is risky

Hosted memory often means opaque storage, broad access, vendor lock-in, and unclear provenance.

// where it fits

Sits between your agent and your repos

Keep your existing agents and editors. Orqenix sits underneath them as a shared memory layer that survives context resets and project switches.

Your AI coding agentClaude Code · Codex · Cursor · OpenCode · any MCP client

↓ MCP

ORQENIXknowledge fabric + local mesh memoryYOU ARE HERE

↓ git + .orqenix/

Your reposgit + .orqenix/ folder

↓

Your machinemacOS · Linux · Windows

// real workflows

Built for developers who move between contexts

Orqenix is most useful when work spans more than one session, repo, or agent.

Recall why code changed

Before: re-read commits and chats. After: ask for the JWT refresh rationale and get the signed decision trail.

Share backend context with frontend

Before: explain API constraints again. After: link scopes and let the UI agent recall allowed backend decisions.

Onboard agents to old repos

Before: paste architecture docs manually. After: Orqenix injects relevant docs, symbols, and prior lessons.

Switch agents without starting over

Before: context is trapped in one tool. After: any MCP-compatible client can recall the same local memory.

// how it works

Capture context. Sign memory. Recall only what matters.

A small runtime captures useful context, distills it into signed memories, and injects only the relevant slices back into the agent prompt.

Capture

Watch docs, code, decisions, and session notes as work happens.

Distill

Compress noisy history into versioned, provenance-tagged memories.

Scope

Sign memory with scope identity and directional capability links.

Recall

Retrieve the relevant slices across linked repos and knowledge bases.

Inject

Fit the useful context into the prompt without flooding the window.

Architecture details

L6Agent runtimesClaude Code · Codex · Cursor · OpenCode · MCP

L5Orchestration + Memory MCPrecall · distill · compress · rewrite · hooks

L4Mesh + IdentityEd25519 identity · capability links · routing

L3Memory tiersworking · episodic · semantic · global

L2Knowledge basesDocsKB · CodeKB · DecisionKB · ChatKB

L1StorageSQLite · diff-only BLAKE3 + zstd · polyglot opt-in

MCPagent-compatible interface

SQLitelocal-first storage foundation

BLAKE3diff-aware provenance chain

Capture→Distill→Compress→Index→Recall→Inject

DocsKB

CodeKB

DecisionKB

ChatKB

Working

Active docscurrent task

Hot symbolsopen files

Open choicesin-flight

Live threadthis session

Episodic

Recent readsper session

Edit historydiff chains

Decisionswith context

Past chatshash-chained

Semantic

Conceptsembeddings

Code graphrelations

Rationaledistilled

Q&Avector search

Global

Cross-repoknowledge

Patternsmesh-wide

Lessonsportable

Historyfabric-wide

System Recalled KBs Live Headroom

scope/api

→

scope/shared

→

scope/infra

→

scope/web

// interactive proof

See how memory moves through the fabric

Scroll the visual model to inspect three ideas: scopes link into a mesh, memories live in tiered matrices, and only relevant context is assembled for the agent.

FabricMemory matrixContext pipeline

Preparing interactive fabric...

// differentiation

Not a vector DB. Not a cloud lock-in.

Most agent memory is a single bucket in someone else's cloud. Orqenix is a governed, local-first fabric with signed provenance and portable storage.

Capability	Orqenix	Vector DB	Cloud agent memory
Local-first and offline	Yes	Partial	No
Cross-project mesh	Yes	No	Partial
Capability security, Ed25519	Yes	No	Partial
Provenance on every memory	Yes	No	No
Diff-only versioned storage	Yes	No	No
Agent-agnostic, MCP plugin	Yes	Partial	No
Open source core	Apache 2.0	Varies	No
No vendor lock-in	Yes	Partial	No

Orqenix

Local-first, offline-capable, MCP-compatible memory with signed scopes, provenance, diff-only storage, and Apache 2.0 core.

Generic vector DB

Good retrieval primitive, but usually not a governed agent-memory system with cross-repo permissions and provenance.

Hosted agent memory

Convenient, but commonly tied to one vendor, one account, and opaque storage or access rules.

OSSApache 2.0 core

Localrepo-owned storage

MCPworks with existing agents

Notelemetry by default

// provenance & security

Every memory is signed, scoped, traceable

Orqenix does not blindly share memory between projects. Every cross-scope recall must be allowed, signed, and traceable to its source.

Signed memoriesScoped permissionsLocal storageProvenance tags

Ed25519 scope identity

Each scope owns a cryptographic identity, not a spoofable config label.

Capability tokens

Links are directional and narrowable. Delegation can reduce access, never widen it.

Provenance on every memory

Every recall includes where the memory came from and which scope allowed it.

Before any cross-scope memory reaches your agent, Orqenix checks the signature and capability chain. Invalid or out-of-scope requests are rejected, not silently trusted.

// quick start

Install the CLI and give your agent repo-owned memory

Start with one repo. Link another scope only when you want memory to cross project boundaries.

~/projects · orqenix

$ npm install -g @orqenix/cli
$ orqenix init
$ orqenix link ../web ../shared
$ orqenix recall "JWT refresh"

1Install the CLI

No account or hosted setup required.

2Initialize a scope

Creates local `.orqenix/` memory metadata in the repo.

3Recall context

Ask your MCP-compatible agent for relevant project memory.

// memory sharing

Install Orqenix and keep agent context across every repo

Start local, then promote memory deliberately. Session, repo, project, and team scopes stay separate until you link them.

Install once. Keep context everywhere.

Open source, local-first, and ready to drop into your agent workflow. Apache 2.0 core, no telemetry, no account, no hosted dependency.

Install CLI View releases