Self-hosted · agent-agnostic · built for teams

You rent the model. You own the knowledge.

Firekeep is a self-hosted server your coding agents check in with. A new session opens already briefed — unfinished work, open tasks, matching playbooks, recent quality trends — and recall is ranked by how each memory performed in the sessions that used it. One complete product, team-ready out of the box. Your team's memory lives on your own infrastructure.

  • 0.82 evidence recall@10 · LongMemEval‑S
  • Any Docker host — VPS or your own desktop · 13 containers
  • No account · no vendor service
  • Any MCP client · adapters for Claude Code, Codex, Kiro, OpenCode
install — server first, then each workstation
# on the server — one Linux host with Docker (13 containers) $ curl -fsSL https://firekeep.ai/latest/install.sh | sh $ firekeep init # on each workstation $ firekeep connect user@host
session_start · briefingIllustrative
Any MCP client
CLClaude Code CXCodex KIKiro OCOpenCode

Every capability is an MCP tool, so anything that speaks MCP can use it. These four ship a configured adapter; Claude Code, Kiro and OpenCode additionally hook the session lifecycle — briefing at start, presence, and the pre‑edit gate.

The shape of the product

Seven rungs. Five are software you can run today.

Memory is one capability here, not the product. The product is a widening radius of context — one session, your working history, a team, an organisation — on the same server. The last two rungs are where it goes next.

01 · one sessionIt doesn’t start blankShipped

A session opens already briefed.

At session start the client fetches a briefing from your server: resumable sessions with crash detection, open tasks, teammate bulletins, playbooks matching the goal, recent quality trends. If context compaction wipes the window mid-session, the recorded working state is restorable with one tool call.

session_start hook → GET /briefing · resume + crash detection · post-compaction restore — the automatic pre-compaction checkpoint is Claude Code only; the restore call works from any runtime

02 · many sessionsRecall ranked by resultsShipped · default on

What worked rises. What didn’t sinks.

Recall is re-ranked by whether the sessions that used a memory went on to succeed — deterministic bookkeeping over recorded outcomes, no model in the loop — and by agent feedback on knowledge that was actually acted on. A newer memory that closely matches an older one supersedes it — the superseded memory is kept and still recallable, at half weight; confirmation raises a memory’s standing; stale knowledge is ranked down on age and then recoverably archived, with hard deletion a deliberate, off-by-default operation. When two unconfirmed memories genuinely conflict, neither is silently dropped: the pair is marked contested, stays visible in recall, and waits in a review inbox for a human verdict.

outcome-weighted recall (default on) · feedback-weighted recall · near-duplicate supersedes at 0.5× with chain kept · confirmation multiplier · contested pairs wait for a human verdict · archive-first aging

03 · a teamShared knowledgeShipped

Knowledge that outlives its author.

Every memory carries its project and contributor. Handoff briefs pass work between people, playbooks go through a draft-then-approve review queue, and a bulletin board, tasks and messages keep agents coordinated. What one person’s sessions learn, the whole team can recall — attributed to its source.

per-memory project + contributor attribution · handoff briefs · skills review queue

04 · an organisationGovernance & auditShipped

An audit trail of what your agents knew and did.

Memory reads and writes are traced with session and agent attribution. Risky edits pass a policy gate whose block and rethink decisions land in an audit log. Parallel agents take fenced leases instead of overwriting each other. Completed sessions are scored on ten measurable quality metrics, with trends over time.

replay traces · policy audit log · fenced leases (monotonic tokens) · per-session auto-evals + quality trends

05 · the system itselfLiving InstructionsRound 1 shipped

The instruction layer measures itself.

Every capability lives or dies by whether agents are actually told to use it — so Firekeep scores its own instructions against what sessions actually did. The Autopilot tab's compliance table shows, per instruction, how many sessions recalled before answering, recorded as they went, declared consequential actions — computed deterministically from the replay record, and honest about what it can claim: this measures behavior, not whether the behavior helped. The first live read, on the maintainer's own deployment (32 sessions, window split in halves by time): recall-before-answering went 44% → 69%, record-as-you-go 31% → 63%, recalled-knowledge-visibly-used 13% → 44%. Behavior moving, measured — with the quality question deliberately left to the A/B rounds ahead: instruction rewrites drafted by your own agents, approved by you, validated across real sessions. And because a rate is only as honest as its denominator, sessions now carry receipts of which instruction text actually reached them — content-hashed per runtime, with everything unverifiable reported as unknown rather than counted against anyone.

per-instruction compliance from replay (shipped) · trend over time (shipped) · exposure receipts + per-runtime slicing (shipped) · fleet-drafted rewrites under human verdict · A/B validation — roadmap

06 · many teamsLinked instancesRoadmap

Servers that talk to each other.

Multiple Firekeep servers sharing knowledge across an organisation, so what one team learns is recallable by another.

07 · many kinds of workDomain profilesRoadmap

Separate experiences. One shared brain.

The same client kit, profiled per kind of work: coding today; document and research profiles ahead. Each profile exposes the tools, retrieval policies and guardrails its work needs — and they all read and write the same memory, so a runbook can be checked against how the code actually behaves, research findings can inform an implementation, and an implementation can keep its own documentation current. Not separate products, and never separate memory stores.

Documents in · knowledge out

Build a knowledge base your agents can actually use.

Put runbooks, public documentation, architecture notes and incident knowledge into Firekeep once. Relevant fragments then surface alongside recorded decisions and proven fixes whenever any of your connected agents needs them. If you already keep an AGENTS.md or CLAUDE.md, this is the layer it cannot hold.

  • Sources stay searchableCorpus retains the source and exposes the relevant chunks through ordinary recall.
  • Procedures become reusableWith generation configured, detected procedures enter a human review queue before becoming active Skills.
  • Work feeds the systemExplicitly recorded decisions, fixes and completed sessions give later agents better evidence.
shared knowledge lifecycleIllustrative flow

Corpus sources are searchable immediately after ingestion. Procedure drafting requires a configured generation model and human review; Firekeep does not silently turn every document into an executable instruction.

The capability stack

Memory is one of five capabilities.

All five sit behind one local gateway the coding agents you already use know how to talk to — and all five ship in every install.

Session continuity

Sessions open briefed, resume after crashes and survive context compaction. Recorded working state — plan, decisions, progress, file notes — is restorable when the window is lost.

briefing · resume · restore

Memory with a lifecycle

Not a pile of embeddings. Recall is re-ranked by how each memory performed in the sessions that used it; a close restatement supersedes what it restates, confirmations promote, stale knowledge is ranked down, then recoverably archived — and genuine conflicts surface in a review inbox instead of being resolved by a guess.

outcome-ranked recall · supersede · confirm · contested → human verdict · archive-first

Code intelligence

A client-side symbol index of your working tree — functions, callers, dependencies, change impact — so agents pull the code that matters instead of whole files. Installed automatically with the client kit; indexing runs and stays on the workstation, and can be switched off.

client-side · 12 languages · tree-sitter

Team coordination

Tasks, bulletins, direct messages, presence and fenced file leases keep parallel agents out of each other’s way — whether that is three terminals of yours or a teammate’s agent.

tasks · messages · leases · presence

Governance & audit

Replay traces memory reads and writes with session and agent attribution; a policy gate keeps its block decisions in an audit log; every session is scored on ten quality metrics. The trail is a side effect of normal use.

replay · policy audit log · evals
Symdex · built-in local code intelligence

Give agents the code they need—not the whole file.

Symdex indexes your working tree into symbols and relationships, then serves focused code context when that is enough and broader context when an edit needs it. Firekeep installs it automatically with the client kit.

  • Find functions, classes, callers, dependencies, related tests and change impact across every supported language.
  • Join the code as it exists now with the decisions and fixes Firekeep remembers from earlier sessions.
  • Keep indexing on the workstation as a local stdio MCP server; only requested tool output returns to your configured AI client.
Built-in language coverage
  • Python
  • JavaScript
  • TypeScript
  • Go
  • Rust
  • Java
  • PHP
  • C
  • C#
  • Ruby
  • Kotlin
  • Swift
How Symdex works and how we measured it →
Three flows worth seeing up close

Carry the work forward—not just the chat transcript.

First, watch a proven procedure cross from one agent client to another. Then see the two mechanics that make continuity checkable: resuming recorded working state, and following what actually happened. These flows explain the systems; they are not recordings of a specific client UI.

Cross-runtime continuity

End a Codex session. Start Claude Code. Keep the lesson.

Firekeep sits behind both clients. The first session captures a reusable recovery procedure with its source and project; the next session gets that procedure in its briefing because the new task matches.

cross-runtime handoff · api-platformIllustrative flow
Codex · session 41connected
YouCapture the silent-agent fix so nobody has to rediscover it.
skill_create(...)saved ✓
release-recoveryReproduce the subprocess startup with env -i and a throwaway HOME before debugging the agent UI.
Firekeepteam memory
Firekeep ember mark
Active skill · infrastructure release-recovery

Silent assistant after a symlinked release deploy.

project · api-platformsource · Codex
Claude Code · fresh sessionbriefed
YouFind why the assistant went silent after today’s release.
session_start1 match
Matching playbook · release-recoveryCheck the resolved release path and reproduce the subprocess in an isolated environment first.
  • different clients
  • new session
  • same project
  • your server
The interface is illustrative. The tools, project attribution, active-skill lifecycle, and session briefing are product behavior.
Bridge · durable sessions

Resume the work, not the reconstruction.

Restore the recorded goal, plan, decisions, file notes and next step after an interruption.

Replay · inspectable trace

Follow what happened, event by event.

Inspect recorded session events and open the exact or nearest saved decision context instead of relying on the final error alone.

And the controls around the work.

These supporting surfaces are part of the same installation, not separate add-ons.

Encrypted Vault

Keep secrets encrypted and separate from ordinary memory recall; listings expose metadata, not values.

Decision Board

When a task needs several choices, the agent opens one local browser board with its questions and the memory evidence behind them; your answers return together. Drafted suggestions need a fast generation backend and are skipped on a CPU-only host — the evidence is deterministic and still arrives.

Local Dashboard

Inspect memories, sessions, knowledge sources, agent coordination, events, traces and operations in one web UI.

Personal mode

Make Firekeep dormant for work you do not want recorded, then restore the tool surface when you return.

Governance & audit

See what your agents knew — and did.

Agent autonomy is a hard sell past the first demo without a trail behind it. Firekeep records the trail as a side effect of normal use, on your own infrastructure.

  • Replay traces on memory reads and writes, attributed to a session and an agent — inspectable event by event, with the saved decision context near any point in the timeline.
  • A policy engine evaluates risky edits before they land; its block and rethink decisions are kept in an audit log you can query.
  • Fenced leases with monotonic tokens keep parallel agents from silently overwriting each other’s files.
  • Ten measurable quality metrics per session — tool success rate, failure rate, claim contention and more — with trends across sessions.
pre-edit enforcement by runtimeClient capability matrix
RuntimePre-edit gateWhat that means
Claude CodeHard blockA blocked edit is stopped with the policy reason.
OpenCodeHard blockValidated live: the write aborts, the file is untouched.
Kiro 2.12.1AdvisoryThe hook fires and the check runs; the client does not enforce the block.
CodexNoneNo hook surface; the same checks are callable as tools.

Tracing and per-session evals do not depend on hooks — they ride the server calls themselves. This table covers one thing: whether the client can stop an edit at the moment it happens.

Measured recall · LongMemEval‑S

Recall quality, measured the way you’d audit it.

LongMemEval‑S hides evidence inside ~115k tokens of chat history per question and asks 500 questions about it. We ingested every haystack through the same /memory/learn endpoint agents use, asked Cortex to recall, and scored whether the right conversation’s evidence surfaced in the top results.

  • Reader-independent: scored against the benchmark’s evidence-session labels, not an LLM judge’s opinion — no grading model can inflate it.
  • Product-path: stock write path with near-duplicate supersession on, stock recall endpoint, and both the default install config and the benchmark config reported side by side.
  • Reproducible: pinned dataset revision, local GPU embedding, and every per-question row in the published run record — the raw JSON and its method notes, exactly as generated.
Method & caveats

Each question’s haystack is written as turn-pair memories under its own namespace (123,845 write calls, none rejected), then recalled with the question as the query. Evidence Recall@k asks whether any memory from a labeled evidence session ranks in the top k; Coverage@k, MRR and NDCG@k score how much and how high. These are retrieval-layer metrics — not the leaderboard’s GPT-4o QA accuracy, and not comparable to it. An end-to-end pipeline check with a local qwen3:14b reader answering from the recalled context scored 47.6%. Memory identity is derived from content, so identical turn pairs recurring across a synthetic haystack collapse into a single memory — about 23% of labeled evidence sessions have no memory of their own to retrieve, and questions resting on one are scored as misses. Production memories are agent-distilled rather than raw turn pairs.

results/20260803-201503-full-v1.jsonReal run · 2026‑08‑03
0.82

Evidence recall@10. The right conversation’s evidence surfaced in the top 10 recalled memories for 385 of 470 scored questions.

ConfigurationkRecall@kCov@kMRRNDCG@k
Stock recall settingsdefaults30.7790.5610.7680.571
Benchmark configraw · top‑k 10100.8190.7180.7770.630
500 questions470 scored · 30 abstention held out0 calls rejectedmxbai-embed-largecortex 9f94dd4
Your infrastructure

Keep the control plane where the work lives.

Your Firekeep services, datastores and default model run on infrastructure you control. Downloads and update checks use the public release channel; optional providers connect only when you configure them.

  • Authentication enabled and application ports bound to loopback by default.
  • Checksum-verified client and server release artifacts.
  • No licence keys and no phone-home; the BUSL licence is a legal document, not a technical gate.
  • Encrypted vault entries stay separate from memory recall.
  • One local MCP gateway, with independent capability backends.
The install shape

One server host. A client per workstation.

There is no hosted service and no account. You run the server; your workstations connect to it.

Provision the server

Any machine with Docker runs the whole stack — a VPS, an office server, or your own desktop. 13 containers, datastores and the bundled local-inference model included. 16 GB RAM is recommended for the default local-inference configuration; the recommendation follows the bundled model, not a hard floor.

Server installation →

Install the client

One command installs the client kit on a workstation and renders adapters for Claude Code, Codex, Kiro and OpenCode. macOS, Linux and Windows.

Client installation →

Connect and verify

firekeep connect user@host issues a join code and a verified connection over SSH; firekeep doctor reports the state of the connection and the server.

Connecting workstations →
Licensing

One product. One build. Team-capable.

There are no editions and no feature gates — every install is the complete, team-capable product: multi-member workspaces, shared memory, coordination, governance. Self-hosted, no account, no licence keys. Individual use is free; team use runs on a commercial subscription.

Firekeep is source-available under BUSL-1.1, and the terms carry a published expiry: each release’s licence converts to Apache-2.0 four years after it ships — a floor with a dated end, not a lock.

Frequently asked

Before you install.

What is Firekeep?

A self-hosted server your coding agents check in with. It carries session continuity (briefings, resumable sessions, durable working state), memory with a lifecycle (outcome-ranked recall, supersession, archive-first aging), client-side code intelligence, coordination for parallel agents, and governance — replay traces, a policy audit log and per-session quality metrics — behind the coding tools you already use. It grew out of an internal system that development and operations teams used daily for five months — read the case study.

What do I need to run it?

Any machine with Docker for the server — a Linux VPS, an office server, or your own desktop (Docker Desktop on macOS, or with the WSL2 backend on Windows). 13 containers, including the datastores and the bundled local-inference model. 16 GB RAM is recommended for the default local-inference configuration; the recommendation is tied to the bundled model, not a hard floor. Each workstation then runs the client kit, which renders adapters for Claude Code, Codex, Kiro and OpenCode.

How is memory recall quality measured?

Against LongMemEval‑S: 500 questions, each with ~115k tokens of chat history to search. We ingest every haystack through the ordinary learn endpoint and score whether evidence from the labeled source conversation surfaces in the top recalled results — Evidence Recall@10 was 0.819, with MRR 0.777 (the first relevant memory typically ranks first). These are retrieval-layer metrics scored against the benchmark’s own evidence labels, with no LLM judge involved, and they are deliberately not comparable to GPT-4o-reader QA accuracy figures other vendors quote. The full run record — every per-question row, configs, model tags and caveats — is published with each run: the raw JSON and its method notes.

Does Firekeep send my memories to a hosted service?

No hosted Firekeep service is required. The server, datastores and default inference path run on your infrastructure. Public downloads and update checks use the release channel, and optional connectors or model providers make external requests only when you configure them.

Does the code index upload my repository?

The index runs on your workstation, not on the Firekeep server. As with any local MCP tool, the code context an agent requests becomes part of that agent's working context and may be sent to the model provider you configured.

Which AI coding clients work with it?

The installer includes adapters for Claude Code, Codex, Kiro and OpenCode. Other MCP-capable clients can be configured manually, but lifecycle automation differs because each client exposes different hook capabilities.

Keep what you learn

Start the next session already briefed.

Install Firekeep on your own host. Everything it learns stays on infrastructure you control.

Questions? support@firekeep.ai · Security reports: security@firekeep.ai