Firekeep's server holds what your agents have learned. A dex is the other half: a pack that runs on your machine, indexes one domain of your world, and answers questions about it precisely. One ships today — Symdex, for code. The rest of this page is careful about which parts of that sentence are already true.
An agent that can read your files is not the same as an agent that understands them. Reading is linear and expensive: open the file, spend the context, hope the relevant part was in it. Understanding needs structure — what this function is, who calls it, what breaks if it changes.
A dex builds that structure. It parses a domain into an index, keeps the index local, and exposes it to your agents as tools they can call. Nothing about it is a chat wrapper or a file-reading shortcut; it is a real index, and the answers it gives are derived from it.
The parse and the index happen on the workstation. What is indexed does not travel to the Firekeep server.
A dex knows one world well — its own grammar, its own relationships — rather than treating everything as text.
Agents ask for a symbol, a caller list, an impact set. They get that, not the file it happened to live in.
A dex answers questions. It does not send, move or spend anything on your behalf.
The naming rule. A dex names what it indexes, and nothing gets the
-dex suffix unless it is genuinely an index.
This is not a style guide, it is the boundary. The moment a capability acts — sends a message, moves a file, spends money — it is not a dex and does not get the name, however convenient that would be. Keeping the suffix honest is what keeps the category honest: everything in the dex family is something your Keep understands, and understanding is a much smaller thing to trust than action.
Symdex indexes source code. It parses your working tree with tree-sitter — a real parser producing a real syntax tree, not regular expressions over text — and captures functions, classes, methods, types, constants, routes and the relationships between them across twelve languages.
It ships as firekeep-symdex, a stdio MCP server installed automatically with
the Firekeep client kit from a checksum-verified wheel. It runs beside your editor, as
your user, on your machine. There is no Symdex on the Firekeep server: a server has no
working tree to index (the vestigial server-side container was removed).
Find a symbol by name or pattern and pull back that definition — not the 900-line file around it.
Who calls this, what it depends on, how the modules import each other, what inherits from what.
What a change actually touches, what a reviewer needs open beside the diff, and what nothing references any more.
The shape of the codebase as it is, and new code stubbed to match the conventions already in it.
Thirty tools are registered by default, including list_repos for the indexed
inventory. A further eight — evolution timelines, code churn, contributors, change summaries,
pattern detection, complexity metrics, hotspots and repo comparison — are heavier analytics
that only mean anything once repositories are
indexed, so they are hidden unless you turn them on with
SYMDEX_ANALYTICS_ENABLED=true. A tool list is a context cost on every session;
tools that would return nothing useful do not get to charge it.
FIREKEEP_SYMDEX_MAX_FILES)Across a repeatable 360-lookup benchmark over twelve pinned open-source projects, a Symdex symbol response used 54.8% fewer estimated tokens than sending that symbol's whole containing file, and every one of the 360 retrieved sources matched the pinned Git blob byte-for-byte. It is a direct-retrieval measurement against a whole-file baseline — not a claim about whole tasks or whole sessions, and 58 of the 360 lookups actually used more tokens than the file — small sources where the serialized response can exceed the file itself. The full method and the per-language table are in the docs.
Context spent on code an agent did not need is context unavailable for the problem it was asked to solve. That is the whole argument for a dex over a file reader.
The most common question about code intelligence is whether it uploads the repository. It does not, and the reason is structural rather than a promise: the index is built and stored on your workstation by a local process, and the Firekeep server has no code path that receives it. Your repository is never uploaded to Firekeep.
Local indexing is not the same as local inference — and we would rather say so.
As with any local MCP tool, the specific code context an agent requests becomes part of that agent's working context, and that context goes to whatever model provider you configured for that client. Symdex does not change where your model runs. What it changes is how much gets sent: a symbol and its relationships instead of every file the agent might have grepped. The honest framing of a dex is not "your code stays put" — it is "your index stays put, and far less of your code leaves."
Indexing runs on the workstation and can be switched off. Firekeep itself is self-hosted: the memory server runs on a host you control, so the same reasoning applies one layer up.
Code is one domain. It is not a special one — it is simply the domain we had the sharpest problem in, and the one that proves the shape works. The direction is a family of dexes that install and uninstall like any other capability, behind one registry the gateway reads, so adding understanding of a new domain is an install rather than a rewrite.
None of that exists yet. The design is decided and written down; the
registry, the manifest and the firekeep dex command family are not built.
Today there is exactly one dex, it arrives with the client kit, and there is nothing to
add or remove. When the registry lands, an update will never take away a capability an
install already has.
A manifest-driven registry behind the gateway, so dexes become a list you can inspect, add to and run a doctor against — with per-dex scoped identity on the server side and plainly-stated permissions on the client side. Designed; no code.
A folder-scanning dex for the documents a person actually keeps, so the Keep can understand a runbook or a contract the way Symdex understands a call graph. The server-side half — per-document visibility enforced as a hard filter on recall — is shipped. The client-side scanner is a design document, and its first design decision is that folder selection is a human privacy choice, so no agent can call a tool to choose folders. That tool is absent, not guarded.
There is no announced dex list beyond this, and none of it appears in the product before it works. If you are reading a Firekeep page and cannot tell whether something exists, that is a bug in the page — tell us.
Symdex needs no separate install. It comes with the Firekeep client kit, registers itself with every runtime the kit configures — Claude Code, Codex, Kiro and OpenCode — and starts answering when an agent asks. The install is one command on the workstation.