Titen

Try it in 30 seconds

No account, no key, no configuration — but the CLI runs on Bun 1.2 or newer, and refuses to start without it:

curl -fsSL https://bun.sh/install | bash   # skip if you already have Bun
npx titen-memory mcp

With no environment set, that opens or creates ~/.titen/memory.db, writes a real organization, workspace, project and owner into it, and serves MCP over stdio in-process — no HTTP hop, no key to paste, and no outbound network call. Retrieval is FTS5, so nothing needs an embedding provider or a model.

curl -fsSL https://titen.dev/install.sh | bash does the same in one step: it adds Bun when it is missing, then installs the titen command.

Point an agent at it:

claude mcp add --transport stdio --scope user titen -- npx -y titen-memory mcp

Already using @modelcontextprotocol/server-memory? Titen serves the same nine tool names with the same schemas, and answers memory://knowledge-graph too, so a client does not notice the swap. On the first local-mode start it imports your existing graph. Pass the old store's path, because that server writes beside its own install rather than in the directory you launch it from:

claude mcp add --transport stdio --scope user titen \
  --env MEMORY_FILE_PATH=/path/to/memory.jsonl -- npx -y titen-memory mcp

Without it Titen still checks the working directory, its node_modules, and npm's npx cache — and says on stderr when it found nothing, rather than starting empty in silence. Point titen at a served instance later by setting TITEN_MCP_URL and TITEN_API_KEY — full setup below.

Audit what any agent memory store has accumulated, including one Titen does not own:

npx titen-memory audit ./memory.json

What is different about it

• No provider, no key, no account. FTS5 lexical retrieval is the default operating point, not a fallback. Embeddings and model enrichment are opt-in projections that degrade cleanly when they are absent.
• No runtime dependencies. package.json declares none. What it needs is Bun and one SQLite file; everything else is the standard library and Web APIs.
• Drop-in for @modelcontextprotocol/server-memory. Eighteen tools — the nine titen_* plus the nine reference-server names — with search_nodes routed through real retrieval rather than a substring scan, and your existing memory.json imported on first run.
• It audits stores it does not own. titen audit reads a reference-server memory.json, a Mem0 export, or a Titen store, and reports duplicates, recall loops, secret patterns and staleness with per-item evidence you can check by hand.
• The benchmark publishes the losses. Two of the five pre-registered falsifiers fired against Titen, and they are printed on the chart below rather than left out of it.

Already running @modelcontextprotocol/server-memory?

That server had 106,662 downloads in the week of 31 July 2026 — it is the default memory for a large part of the MCP ecosystem, and it is deliberately minimal. Reading its published 2026.7.4 tarball: the store is one newline-delimited JSON file rewritten in full on every mutation, and a search is

graph.entities.filter(e => e.name.toLowerCase().includes(query.toLowerCase()) || ...)

String.includes on a lowercased needle. No tokenizer, no stemming, no ranking — results arrive in insertion order — no scoping or authorization, and no eviction, so the file grows without bound and every call is O(n) in the whole graph. Ask it "which service handles refunds" and it matches nothing unless that exact sentence is stored.

Titen answers the same nine tool names, with the same argument schemas, and the same memory://knowledge-graph resource, so a client does not notice the swap. What changes is underneath: search_nodes runs the real retrieval path — FTS5 with stemming, ranked best-first, and the vector index when one is configured — and every read is scoped to a subject and filtered by authorization before it is retrieved, not after.

	@modelcontextprotocol/server-memory	Titen
Search	String.includes, insertion order	FTS5 + stemming, ranked, optional vectors
Scope	the whole graph, always	org / subject / project / workspace, enforced pre-retrieval
Contradictions	overwritten	kept, linked to evidence, flagged
Growth	full-file rewrite, unbounded	SQLite, retention and eviction policies
Provider	none	none — no key, no LLM, no embedding provider

Import is on first start; the switch is above.

Audit any agent memory store

Every published memory benchmark measures retrieval on a corpus somebody curated. The failure people actually report is on the write side: a store fills with copies of its own output. The one public audit of a production store found 97.8% of 10,134 entries were junk after 32 days. Nothing measures that.

npx titen-memory audit ~/.titen/memory.db        # a Titen store
npx titen-memory audit ./memory.jsonl            # @modelcontextprotocol/server-memory
npx titen-memory audit ./mem0-export.json --json # a Mem0 export

Five counts — exact duplicate, near duplicate, recall loop, secret pattern, stale — each with per-item evidence you can check by hand. No network, no model, no upload: it opens the path read-only and prints a report; sharing it is your decision. A store that lacks the signal a metric needs is reported as not measurable from this export, never as a failure. There is no composite score and there is no leaderboard.

The detection rules are published in audit rules. Titen's own numbers — including 17.9% duplicates and 96.7% stale in its own store, and a compatibility-surface defect the tool found in Titen itself — are in the self-report.

You author the claims

Titen's default memory model is caller-authored claims. consolidate() takes statements you wrote, each explicitly linked to a source observation you already recorded. Titen does not read a transcript and decide on its own what is worth remembering.

That is deliberate. Every claim has an author, a source, and a scope, which is what makes provenance, permission, conflict, and audit answerable at all. It is also a real cost, and it is the honest comparison point: systems that derive memory from raw dialogue do work Titen hands back to you.

Model-assisted derivation and reflection are implemented and ship in the package, but they are activation-gated and no candidate model has passed the gate — the best result on record is 65.56% against a 90% contract threshold. Treat them as unfinished work with a public gate, not as a feature you can simply switch on. The roadmap carries the current evidence.

The questions Titen answers

Question	Titen's answer
Where did this memory come from?	Every claim points back to source observations and keeps its version history.
May this agent see it?	Organization, subject, project, workspace, and visibility checks run before retrieval.
What if two sources disagree?	Contradictions remain visible until an explicit lifecycle action resolves them.
Who is doing the work?	Leases prevent silent double ownership; checkpoints and handoffs make work resumable.
Can we audit or move it?	Canonical records live in SQL, with authenticated audit trails and versioned JSONL export/import.
Do we need an LLM or vector database?	No. The default install is FTS-only with no provider at all; embeddings and model enrichment are opt-in projections. Whether the vector arm helps depends on the store shape — see below.

Agents connect through authenticated REST, Streamable HTTP MCP, the titen mcp stdio bridge, or the TypeScript SDK. Titen never treats retrieved memory as an instruction, and it does not run agent loops.

Measured against the field

On LongMemEval-S (MIT, externally authored, 500 instances, 246,930 turns), our own scorer, failures kept in the denominator, protocol pre-registered before each run. Full table and method at titen.dev/benchmark.

Every figure below names its condition, because the condition moves recall@1 by 63 points on the same corpus. Per-instance (scoped) gives each question its own ~50-session haystack — the single-subject shape a product actually serves. Pooled puts all 19,829 sessions in one unscoped store and asks the same 500 questions. These are two conditions of one corpus, not two measurements of one thing, and a number quoted without its condition is meaningless.

Condition A — per-instance (scoped)

Lane, n=500, titen-memory 0.6.0	recall@1	MRR@10	LLM calls	embedding calls
Titen 0.6.0, FTS + vector	0.900	0.9384	0	4,989
Titen 0.6.0, FTS-only	0.880	0.9147	0	0
verbatim-RAG control (~100 lines of cosine)	0.854	0.9067	0	877
MemPalace 3.6.0	0.804	0.8717	0	—

This condition barely separates anything. recall@10 is 0.982 and saturated, with 2.2 points of spread across the serious lanes. Exactly one of the three paired sign tests reaches significance, and it does not say what it looks like it says:

• FTS+vector vs the dense control: 35/12/453, p = 0.0011 — significant.
• FTS+vector vs FTS-only: 27/17/456, p = 0.174 — the vector arm is not proven to be the cause of that win.
• FTS-only vs that control: 44/31/425, p = 0.165 — not significant.

We do not beat Mem0's LLM-free mode here. Mem0 infer=False scores 0.8667 on the shared n=60 subsample, and Titen FTS+vector against it is 3/4/53, p = 1.0 — indistinguishable. Its default infer=True mode spends 2,981 LLM calls to score lower (0.8333), so Mem0's own extraction bought nothing measurable here. Any cost claim must name the configuration it measured.

Answer accuracy is a flat null. With one reader pinned across every lane, eight pre-registered comparisons produce nothing significant (best p = 0.41). Retrieval significance does not transfer to answers.

Condition B — pooled, all 19,829 sessions in one store

Lane, pooled 19,829, titen-memory 0.7.0	recall@1	MRR@10	tax vs its own per-instance cell
Titen 0.7.0, FTS-only	0.246	0.3259	−63.4
Titen 0.7.0, FTS + vector	0.212	0.3153	−68.8
Mem0 OSS 2.0.15 infer=False	0.182	0.2716	−68.5 ¹
verbatim-RAG control, router embeddings	0.174	0.2459	−68.0
MemPalace 3.6.0, published shape	0.164	0.2152	−64.0
verbatim-RAG control, fastembed	0.124	0.1868	−64.8
MCP reference server	0.000	0.0000	could not serve a store this size at all

¹ against Mem0's n=60 per-instance cell, not n=500.

Titen's zero-provider lane is significantly above every measured competitor at this condition — every pair below is written Titen-first, wins/losses/ties: 86/25/389 (p < 0.0001) against the fastembed control, 76/35/389 (p = 0.0001) against MemPalace, 59/27 (p = 0.0007) against Mem0 infer=False, 65/29 (p = 0.0003) against the router control. Those are the first significant lane-vs-lane retrieval separations this programme has produced on this corpus, at 363.8 s of ingest with zero provider calls against Mem0's 3,953 s and 205,641 embedding calls.

Two of the five pre-registered falsifiers fired against Titen, and they get the same prominence as that win.

• The prediction was wrong by more than 45 points. We pre-registered full-pool recall@1 at 0.70–0.85 and measured 0.246. LongMemEval-S personas share topics by construction, so pooling makes the store denser in cross-persona near-duplicates rather than sparser: all 377 rank-1 misses retrieved a cross-instance session, and zero retrieved a wrong session from the question's own haystack.
• Compile p95 is 864.9 ms against our own pre-registered 250 ms kill line, already crossed at the 10,000-session cell (430.8 ms). Published anyway, as promised.

Nobody's architecture escapes the pooled tax — MemPalace loses 64.0 points and the strongest dense control 68.0, against Titen's 63.4. And the vector arm reverses sign between the conditions: +2.0 points per-instance (unproven, p = 0.174) and −3.4 points pooled (0.212 against 0.246, p = 0.082), at 2.8x the compile latency after a 9,054 s index drain. Three embedding families now land 7.2–16.8 points below FTS-only at pooled density, so the vector arm is documented for scoped stores only. Full report: the pooled-store condition.

Scoping is the largest lever we have measured

Same corpus, same tarball, same 500 questions — one arm scoped to its subject, one not:

Store shape, titen-memory 0.7.0	recall@1	compile p95
Subject-scoped anchor, 424,168 claims	0.880	138.1 ms
Unscoped pooled, 342,129 claims	0.246	864.9 ms

+63.4 points of recall@1 and 6.3x less latency. That is the measured value of authorization-before-retrieval, and the measured answer to "just scope by user_id" — scoping is the authorization layer, and Titen's runs before retrieval by construction.

The FTS-only curve across store shapes is 0.880 scoped, then 0.524 / 0.364 / 0.308 / 0.246 at 1k / 5k / 10k / 19,829 pooled sessions. Do not read the 0.880 without it.

The improvement cycle failed every gate

On 2026-08-08 we pre-registered a cycle to move those numbers — a candidate cap for latency, six ranking variants, and a third embedding family — and every gate in it failed. Nothing shipped. All six ranking variants failed their gate: term coverage −2.4, proximity −14.4, chunk-sum −11.8, combined −3.6, a local cross-encoder −1.2 at +642 ms per compile, RRF fusion +0.2 at p = 1.0. The five that were run against the scoped anchor regressed that too. The candidate cap was worth 4.5% of p95 against a predicted 30–60%, so the latency falsifier stands. The third embedding family scored 0.078. Full report: the pooled-improvement cycle.

That failure bought two things, both evidence rather than features:

• The shipped ranking is now ablation-backed, not incidental. Best-chunk aggregation beats sum-of-chunks by 11.8 points, and shipped BM25 order beats coverage, proximity, their combination, RRF fusion, and a local cross-encoder on both conditions.
• The +26.2-point top-10 ceiling is real, open, and unclaimed. Gold sits in the pooled top-10 at 0.508 against 0.246 at k=1. The cheap lexical class of fixes is spent; reaching it needs a signal that is not question-term overlap.

What survives every configuration argument is the dependency floor: Titen's FTS-only lane made zero LLM calls and zero embedding calls in both conditions. Mem0 without an LLM still needs an embedding provider. dependencies: {}, zero external imports in src/core/, and exactly two outbound calls in the whole codebase, both opt-in.

Other published losses: FTS-only recall@1 falls from 1.00 to 0.49 between 10³ and 10⁵ claims on a synthetic corpus — which understated the real-data degradation above — one process saturates one core at 10k claims, there is no reranking stage, and no external suite scores the governance and collaboration primitives at all.

Memory for a team, not a chatbot

A storage-only memory saves text. A retrieval-only memory embeds it and returns nearby passages. Both leave the caller to decide what is current, permitted, or true, and neither stops two agents from quietly claiming the same work.

Titen's Level 5 kernel turns source observations into evidence-linked, temporal claims and compiles only the context a caller is allowed to see. Level 6 joins that kernel to checkpoints, leases, handoffs, governance, audit, and signed federation.

Memory model	What it can do	Where it stops
Logs and files	Keep past text	The caller must decide what is current, trusted, and relevant
Vector recall	Find semantically similar passages	Similarity does not prove provenance, permission, or truth
Titen Level 5 kernel	Compile bounded context from scoped evidence, claims, time, trust, and conflicts	It remembers well, but does not coordinate parallel work by itself
Titen Level 6 fabric	Add task ownership, resumable state, handoffs, policy, audit, and federation	Titen records coordination; your agents or orchestrator still choose what runs next

Level 6 is Titen's product model, not an external certification. The distinction is observable in the API: memory and collaboration share one authorization, evidence, and audit boundary.

Project status

Titen is pre-1.0. Per SemVer clause 4, the public API is not yet stable. Below 1.0.0 the minor slot is the only breaking-change signal consumers get: 0.5.7 to 0.6.0 may break you, and ^0.5.0 does not match 0.6.0. Pin an exact version and read the changelog before upgrading.

Where the word stable appears around Titen — the npm latest dist-tag, "channel": "stable" in titen.dev/version.json, and titen version --check — it names the release channel: a deliberate release rather than a prerelease on next. It never describes API stability, and it is not a maturity badge. See versioning and channels.

The current release includes the memory kernel, REST API, MCP server, TypeScript SDK, collaboration tools, enterprise governance, signed federation, and the operator dashboard.

You can run Titen on Bun with SQLite or on Cloudflare Workers with D1. Semantic retrieval is optional: use sqlite-vec on Bun, or Vectorize and Workers AI on Cloudflare — verified live only on the maintainer's isolated the maintainer release stack stack, which is test production and not general availability (scope note). Titen runs in your own infrastructure.

Clients. Titen ships a TypeScript/JavaScript SDK, the titen CLI, and a minimal Python client in clients/python/. The Python client is one standard-library-only file covering observe → consolidate → compile → evidence, with a generic request for every other route. It is not published to PyPI: install it from a checkout with pip install ./clients/python, or vendor titen.py. There is no client for any other language — those callers use the authenticated REST API directly, and every route, scope, and error shape is in the API reference.

See the maturity matrix for detailed runtime evidence and remaining gates, or the changelog for release history.

Install and connect an agent

This section is the served deployment: a long-running instance with its own API keys, reachable over HTTP by more than one agent. If you only want memory for the agent on this machine, the 30-second path above is the whole setup and you can skip to optional semantic retrieval.

The local server needs Bun 1.2 or newer. The website installer adds Bun when needed, then installs the titen command for your current user:

curl -fsSL https://titen.dev/install.sh | bash
titen --version

Windows PowerShell:

irm https://titen.dev/install.ps1 | iex
titen --version

You can also run bun add --global titen-memory@latest. npm and pnpm global installs work when Bun is already on PATH.