Lumen
ory312 ดาว
Save 30% token costs when using Claude Code, Codex, OpenCode for free - with open source, local semantic search. Works for small and large codebases and monorepos! Enterprise-ready and fully compliant
- ทรานสปอร์ต
- stdio
- สถานะ
- โลคัล
Power your agent
การติดตั้งจากผู้เผยแพร่ ไม่ใช่เอนด์พอยต์ของ PlugMCP
URL แบบรีโมตหรือคำสั่งบนเครื่องของคุณ? การติดตั้งสองแบบต่างกันอย่างไร
รันบน PlugMCP
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
เปิดClaude reads entire files to find what it needs. Lumen gives it a map.
Lumen is a 100% local semantic code search engine for AI coding agents. No API keys, no cloud, no external database, just open-source embedding models (Ollama or LM Studio), SQLite, and your CPU. A single static binary and your own local embedding server.
The payoff is measurable and reproducible: across 9 benchmark runs on 9 languages and real GitHub bug-fix tasks, Lumen cuts cost in every single language — up to 39%. Output tokens drop by up to 66%, sessions complete up to 53% faster, and patch quality is maintained in every task. All verified with a transparent, open-source benchmark framework that you can run yourself.
Claude Code asking about the
Prometheus codebase. Lumen's
semantic_search finds the relevant code without reading entire files.
Prerequisites:
Platform support: Linux, macOS, and Windows. File locking for background indexing coordination uses
flock(2)on Unix andLockFileExon Windows (via gofrs/flock).
ollama pull ordis/jina-embeddings-v2-base-code
Note: Installation differs by platform. Claude Code and Codex install from plugin marketplaces. OpenCode installs from npm. Cursor packaging is shipped in this repository and is ready for Cursor's plugin distribution workflow.
Install:
Claude Code
/plugin marketplace add ory/claude-plugins
/plugin install lumen@ory
Verify by starting a new Claude session and running /lumen:doctor.
Cursor
Lumen ships a native Cursor plugin bundle in this repository:
.cursor-plugin/plugin.json - plugin manifestmcp.json - local lumen MCP server wiringhooks/hooks-cursor.json - SessionStart hookskills/ - shared doctor and reindex skillsUse Cursor's plugin installation or distribution workflow with this bundle. Detailed packaging notes: .cursor-plugin/INSTALL.md
Verify by opening a new Cursor agent session and asking it to use the doctor
skill or the Lumen semantic_search tool.
Codex
Codex CLI 0.147.0 or newer installs Lumen as a native plugin:
codex plugin marketplace add ory/claude-plugins
codex plugin add lumen@ory
If the marketplace already exists, run codex plugin marketplace upgrade ory
before installing. Legacy manual-clone and broken-plugin repair instructions:
.codex/INSTALL.md.
Verify with:
codex mcp get lumen --json
OpenCode
Add @ory/lumen-opencode to the plugin array in your opencode.json:
{
"plugin": ["@ory/lumen-opencode"]
}
Detailed docs: .opencode/INSTALL.md
Verify with:
opencode mcp list
Updating
ory marketplace, reinstall lumen@ory, and restartopencode.json (e.g.
@ory/[email protected]) and restart OpenCodeOn first Claude Code or Cursor session start, Lumen:
semantic_search MCP tool that the host can use automaticallyIn Codex and OpenCode, the same binary download and index seeding happen on the
first semantic_search call. Codex stores the downloaded binary in the
plugin's writable data directory rather than the read-only package cache.
Two shared skills are also available: doctor (health check) and reindex
(forced re-indexing). Claude exposes them as /lumen:doctor and
/lumen:reindex; the other hosts discover the same shared skill content
through their native skill systems.
The same semantic_search, health_check, and index_status MCP tools plus
the shared doctor and reindex skills are exposed through the Codex,
Cursor, and OpenCode surfaces as well. The first semantic_search call seeds
or refreshes the index automatically.
Lumen sits between your codebase and Claude as an MCP server. When a session starts, it walks your project and builds a Merkle tree over file hashes: only changed files get re-chunked and re-embedded. Each file is split into semantic chunks (functions, types, methods) using Go's native AST or tree-sitter grammars for other languages. Chunks are embedded and stored in SQLite + sqlite-vec using cosine-distance KNN for retrieval.
Files → semantic chunks → vector embeddings → SQLite/sqlite-vec → KNN search
When Claude needs to understand code, it calls semantic_search instead of
reading entire files. The index is stored outside your repo
(~/.local/share/lumen/<hash>/index.db). Git worktrees from the same repository
use one collection for a compatible model, vector-storage, and chunking profile;
non-Git projects use private collections. Different profiles never collide.
Lumen is evaluated using bench-swe: a SWE-bench-style harness that runs Claude on real GitHub bug-fix tasks and measures cost, time, output tokens, and patch quality — with and without Lumen. All results are reproducible: raw JSONL streams, patch diffs, and judge ratings are committed to this repository.
Key results — 9 runs across 9 languages, hard difficulty, real GitHub
issues (ordis/jina-embeddings-v2-base-code, Ollama):
Cost was reduced in every language tested. Quality was maintained in every task — zero regressions. JavaScript and TypeScript show the most dramatic efficiency gains: same quality fixes in half the time with two-thirds fewer tokens. Even on tasks too hard for either approach (Rust, Svelte), Lumen cuts the cost of failure by 26–39%.
See docs/BENCHMARKS.md for all 9 per-language deep dives, judge rationales, and reproduce instructions.
Supports 12 language families with semantic chunking (10 benchmarked):
Go uses the native Go AST parser for the most precise chunks. All other languages use tree-sitter grammars. See docs/BENCHMARKS.md for all 10 per-language benchmark deep dives.
All configuration is via environment variables:
¹ ordis/jina-embeddings-v2-base-code (Ollama),
nomic-ai/nomic-embed-code-GGUF (LM Studio)
Dimensions and context length are configured automatically per model:
Switching models creates a separate index automatically. The model name is part of the database path hash, so different models never collide.
Caveat: the DB path hash includes the model name but not the backend. If the same model name is configured on two backends (e.g. an Ollama and an LM Studio entry both named
foo), they share the same index — use distinct model names per backend to avoid collisions.
lumen index and lumen search accept --model/-m and --backend/-b
to pick from a multi-server config.yaml. The selection filters the
configured servers to those matching both fields; failover still works
within the filtered subset.
# Index with the Ollama server matching this model name.
lumen index --model ordis/jina-embeddings-v2-base-code .
# Same model name hosted on LM Studio (present in YAML, not in the
# static registry) — accepted because the name is configured.
lumen index --model text-embedding-jina-embeddings-v2-base-code .
# Disambiguate when the same model is configured on two backends.
lumen index --model my-embed --backend lmstudio .
# Pick the first configured Ollama server regardless of model.
lumen search --backend ollama "…"
If --model is not configured in YAML but is a known registry model (and
--backend is unset), Lumen falls back to mutating the default server's
model — preserving lumen index --model all-minilm . for users with no YAML.
If your model is not in the registry above, set LUMEN_EMBED_DIMS to bypass the
registry check. LUMEN_EMBED_CTX is optional and defaults to 8192.
Both variables can also override values for known models — useful when running a model variant with a longer context window or different output dimensions.
LUMEN_BACKEND=lmstudio
LM_STUDIO_HOST=http://localhost:8801
LUMEN_EMBED_MODEL=mlx-community/Qwen3-Embedding-8B-4bit-DWQ
LUMEN_EMBED_DIMS=4096
LUMEN_EMBED_CTX=40960 # optional, defaults to 8192
Lumen filters files through six layers: built-in directory and lock file skips →
.gitignore → .lumenignore → .gitattributes (linguist-generated) →
supported file extension. Only files that pass all layers are indexed.
.lumenignore uses .gitignore syntax. Place it in your project root (or
any subdirectory) to exclude files that aren't in .gitignore but are noise for
code search — generated protobuf files, test snapshots, vendored data, etc.
Directories: .git, node_modules, vendor, dist, .cache, .venv,
venv, __pycache__, target, .gradle, _build, deps, .idea,
.vscode, .next, .nuxt, .build, .output, bower_components, .bundle,
.tox, .eggs, testdata, .hg, .svn
Lock files: package-lock.json, yarn.lock, pnpm-lock.yaml, bun.lock,
bun.lockb, go.sum, composer.lock, poetry.lock, Pipfile.lock,
Gemfile.lock, Cargo.lock, pubspec.lock, mix.lock, flake.lock,
packages.lock.json
Index databases are stored outside your project:
~/.local/share/lumen/<hash>/index.db
Where <hash> identifies the Git common directory (or the absolute path for a
non-Git project), indexed scope, embedding model and dimensions, vector
precision, chunking profile, and index version. Worktrees in one repository
share content-addressed file revisions and vectors while retaining independent
project memberships. Vectors use int8 storage by default; set
LUMEN_VECTOR_STORAGE=float32 to opt out. No files are added to your repo.
You can safely delete the entire lumen directory to clear all indexes, or let
Lumen reclaim the space for you:
lumen clean # remove indexes unused for 30 days or whose project is gone
lumen clean --days 7 # tighten the cutoff to a week
lumen clean --days 0 # remove every eligible index except actively locked indexes
An index counts as used every time Lumen opens it (search, indexing, status, or session start), so indexes for projects you still work on are never removed. Indexes with an indexer currently running are always kept.
Git worktrees are detected automatically. A new worktree attaches unchanged path-and-content revisions directly from the repository collection and embeds only missing chunk inputs. Removing an old worktree drops its memberships; shared revisions and vectors remain until their final reference disappears. Legacy per-worktree indexes migrate lazily, reusing unchanged float32 vectors without contacting the embedding backend.
For the complete storage key, sharing rules, status metrics, migration process, and cleanup lifecycle, see Index storage and lifecycle.
Download the binary from the GitHub releases page or let the plugin install it automatically.
lumen help
Ollama not running / "connection refused"
Start Ollama and verify the model is pulled:
ollama serve
ollama pull ordis/jina-embeddings-v2-base-code
Run /lumen:doctor inside Claude Code to confirm connectivity.
In Cursor, Codex, or OpenCode, use the shared doctor skill or call
health_check and index_status directly.
Stale index after large refactor
Run /lumen:reindex inside Claude Code to force a full re-index, or:
lumen index --force .
In Codex, use the bundled reindex skill to refresh the index through the MCP
server, or run the same CLI commands for a clean rebuild. The same shared
reindex skill is available in Cursor and OpenCode as well.
LM Studio: embedding model appears under LLMs instead of Embeddings
LM Studio classifies embedding models by matching the GGUF arch field against
a hardcoded allowlist (bert, nomic-bert). Models built on other
architectures — including Qwen2-based models like nomic-embed-code — are
misclassified as LLMs. This affects lms ls output and the /v1/embeddings
REST endpoint.
Fix (GGUF, v0.3.16+): Open LM Studio → My Models, click the gear icon next to the model, set Override Domain Type → Text Embedding.
macOS / Apple Silicon: MLX format models are significantly faster on Apple Silicon. However, LM Studio removed the domain type override for MLX in v0.3.30+, so MLX embedding models cannot be reclassified. Use the GGUF variant to retain the override option, or switch to Ollama (
ordis/jina-embeddings-v2-base-codeorqwen3-embedding:8b).
Switching embedding models
Set LUMEN_EMBED_MODEL to a model from the supported table above. Each model
gets its own database; the old index is not deleted automatically.
Changing LUMEN_VECTOR_STORAGE, LUMEN_EMBED_DIMS, or LUMEN_MAX_CHUNK_TOKENS
also selects a separate collection. Run lumen clean after the old profile is
no longer in use if you want to reclaim its disk space.
Understanding index size and deduplication
Call index_status for the project. It reports project-local file and chunk
counts alongside collection-wide unique vectors, shared references,
deduplication ratio, vector precision, database size, and currently reclaimable
SQLite pages. See
Index storage and lifecycle for
definitions and examples.
Slow first indexing
The first run embeds every file. Subsequent runs only process changed files (typically a few seconds). For large projects (100k+ lines), first indexing can take several minutes — this is a one-time cost.
git clone https://github.com/ory/lumen.git
cd lumen
# Build locally (CGO required for sqlite-vec)
make build-local
# Run tests
make test
# Run linter
make lint
# Load as a Claude Code plugin from source
make plugin-dev
See CLAUDE.md for architecture details, design decisions, and contribution guidelines, and AGENTS.md for repo-specific agent instructions.
Save 30% token costs when using Claude Code, Codex, OpenCode for free - with open source, local semantic search. Works for small and large codebases and monorepos! Enterprise-ready and fully compliant
ภาพรวม
Save 30% token costs when using Claude Code, Codex, OpenCode for free - with open source, local semantic search. Works for small and large codebases and monorepos! Enterprise-ready and fully compliant via Ollama and SQLite-vec.
เครื่องมือ
ยังไม่มีรายการเครื่องมือ เซิร์ฟเวอร์แบบรีโมตจะได้รายการหลังการตรวจสอบสถานะครั้งแรก
FAQ
คัดลอกคอนฟิก stdio สำหรับ Cursor, Claude Desktop, Claude Code หรือ VS Code ได้ในหน้านี้ คอนฟิกนี้ใช้การติดตั้งของผู้เผยแพร่ ไม่ใช่พร็อกซีของ PlugMCP
ระเบียนนี้ไม่ได้ระบุตัวแปรสภาพแวดล้อมที่จำเป็น
Lumen ทำงานแบบโลคัลผ่าน stdio
ตรวจสอบล่าสุดเมื่อ 2026-10-26 Save 30% token costs when using Claude Code, Codex, OpenCode for free - with open source, local semantic search. Works for small and large codebases and monorepos! Enterprise-ready and fully compliant via Ollama and SQLite-vec.