Persistent Agent Memory That Never Bloats Your Context

If I use Antigravity, Claude Code, and Codex simultaneously, do they share memories? Are they tagged?

Yes, with automatic client source tagging and 2-Tier Namespace Routing.

All your coding tools connect to the exact same local Titan Mem daemon and SQLite database (~/.titan/mem/memory_graph.db). Every memory stored is automatically tagged with metadata.client (e.g. antigravity, claude-code, codex) and authenticated with an isolated per-client token:

• Tier 1 (Shared Ground Truth): Architecture decisions, verified bug fixes, learned patterns, and API quirks are globally shared across all tools. If Claude Code solves a tricky compiler error in the terminal, Antigravity, Codex, and Cursor in your IDE instantly inherit the verified fix.
• Tier 2 (Private Episodic): Ephemeral code edits, session deltas, and scratchpad traces remain strictly isolated to the originating client. Scratchpad diffs and temporary experiments in one tool never bleed into or pollute the context window of another.

What is the "Zero Data Hostage" Guarantee?

Across every tier (Community, Pro, and Max), your memories are stored in an open, unencrypted SQLite database directly on your own disk at ~/.titan/mem/memory_graph.db. We believe your engineering knowledge belongs exclusively to you. If you ever cancel a subscription or uninstall Titan Mem, your database stays on your machine. You can query, inspect, backup, or export your data anytime using standard tools (sqlite3, Python, DBeaver) with zero vendor lock-in.

Can I use Titan Mem on both my laptop and desktop? How does licensing work?

Yes. We use cryptographic hardware node-locking so you don't have to keep re-activating:

• Community ($0): 1 machine (Free forever, 100% offline).
• Pro ($35/mo): Up to 2 personal machines (Workstation + Laptop under 1 named user).
• Max ($49/mo): Up to 3 personal machines (Workstation, Laptop, Cloud Devbox) plus autonomous compiler compression (titan-mem run / capture).

How does Titan Mem detect devices or enforce hardware node-locking?

When you run titan-mem-mcp activate <key>, the native binary computes a non-reversible cryptographic SHA-256 hash derived from the machine's immutable hardware components (CPU vendor model, primary MAC address, and DMI motherboard/chassis serial). When activating a Pro or Max key, our Keygen cluster registers the hardware hash. If an additional device attempts to activate an exceeded key, activation is denied until you deactivate an old machine.

How does the pricing pay for itself in token savings alone?

The math is simple: preventing a single stuck debugging loop or compressing noisy test dumps pays for the entire subscription.

Frontier models (Claude Sonnet 5.5, Opus 5.5, Claude Fable 5.1) cost between $3.00 and $15.00 per million input tokens, and up to $75.00 per million output tokens:

• Static Schema Pruning (All Tiers): Pruning 250 tool schemas from 48,000 tokens to ~140 tokens saves ~47,800 tokens on every single conversational turn. Over a 50-turn day, that avoids 2.39 million prompt tokens—saving ~$7.17 to ~$35.80 in API costs every single day.
• JIT Rule Injection (Pro): Injecting verified regression anchors prevents 30-minute wandering loops where the agent repeatedly reads the wrong files, saving 50,000+ unnecessary reasoning tokens per stuck session.
• Terminal Output Compression (Max): Running titan-mem run <cmd> compresses noisy 500-line compiler and test failures from 32,000 bytes down to <90 tokens, avoiding hundreds of thousands of context tokens on test-heavy days.

Conclusion: Across every tier—from individual solo developers to high-velocity power engineers—Titan Mem pays for itself within the first few days of active coding solely through eliminated token churn and avoided debugging hours.

Does storing session context make the model generate tokens faster?

No—and anyone claiming local memory accelerates cloud LLM generation speed is being dishonest. Model inference speed is physically constrained by cloud GPU cluster latency and Time-To-First-Token (TTFT). What Titan Mem eliminates is human wall-clock debugging hours and runaway token costs. Instead of pasting 20,000-token historical transcripts or having a new engineer spend 4 hours re-solving an obscure allocator bug, Titan Mem injects a <150 token distilled rule on prompt 1.

How does Titan Mem prevent hallucinations and bug regressions?

Verified outcomes over raw transcripts. Dumping raw chat logs into an agent pollutes the context with terminal noise. The proprietary Titan Mem Engine™ extracts verified debugging patterns and links historical decisions to preceding fixes. When a compiler or test fails, the agent is automatically anchored to your project's verified history rather than exploratory hallucination.

How does Titan Mem handle hundreds of MCP tools without blowing up my context window?

Modern agent setups often connect to dozens of tools across cloud infrastructure, databases, and APIs—preloading these schemas conventionally burns 40,000+ tokens before you even type a prompt. Titan Mem features an autonomous native tool router. Instead of exposing every tool continuously, Titan Mem matches your intent against your local tool catalog in under 30 milliseconds, injecting only the exact 2 or 3 tools needed for the immediate step. You get the power of an extensive toolchain with a verified 99.7% reduction in token overhead.

Does Progressive Disclosure (<150 tokens) break LLM Prompt Caching? What about tool call overhead?

It protects your prompt cache from active schema bloat. LLM providers (Anthropic Claude, OpenAI, Gemini) use prefix caching: identical static prompt prefixes receive a 90% discount. While modern IDEs like Claude Code automatically compact past chat history, they cannot compact away active tool schemas. If an agent connects to dozens of MCP tools, that ~48,000-token schema payload must sit in the prompt on every turn, incurring massive cache-read fees and eating 25% of your context window.

The Honest Math on Tool Calls: In a real-world workflow, an agent should never poll memory on every single turn (doing so would waste output tokens and round-trips). Instead, Titan Mem operates strictly Just-In-Time (JIT):

• Static Schema Elimination: Titan Mem acts as a local meta-router, shrinking the static prompt overhead from ~48,000 tokens down to a single lightweight tool definition (~140 tokens). This alone eliminates 99.7% of permanent schema bloat.
• Minimal JIT Invocations: In a typical session, memory search is called only 3 to 5 times—specifically when an unfamiliar API is requested or an error occurs. 5 queries $\times$ ~140 tokens adds less than 1,000 tokens of total session overhead, while preventing hours of manual re-debugging.
• Cross-Session Persistence: When a session ends, IDE auto-compaction memory is wiped clean. Titan Mem stores verified fixes permanently in local SQLite, ensuring you never re-debug the same bug twice.

Net Result: 99.7% reduction in static schema overhead, zero round-trip waste, and permanent cross-session recall.

Why use Titan Mem instead of a cloud decision model like Jev or external tool routers?

Developers are raving about "System 1" decision models (like TypeSafe's Jev) because nobody wants to waste 45,000 prompt tokens on an LLM just to pick an API to call. But Jev is still a third-party cloud service that adds network hops and privacy exposure. Titan Mem performs local, in-process System 1 routing on your machine before the LLM ever sees the prompt:

Do I have to restart my IDE when memories are saved or background sweeps run?

No. Restarting IDEs and losing active state is completely unacceptable. Titan Mem runs with SQLite Write-Ahead Logging (WAL) concurrency. When memories are saved, indexed, or audited in the background, active Claude Code, Cursor, Antigravity, and terminal sessions detect updated rows on their very next query—with zero IDE restarts and zero prompt latency.

How do I use "Remember this fix"? Do I have to type complex JSON commands or install git hooks?

Never. You don't type JSON and you don't install git hooks. You simply tell your agent in natural English during any chat: "Remember this fix: [description]". The agent automatically resolves the active Git commit hash (via git rev-parse --short HEAD) and touched file paths, storing the rule in SQLite via MCP. To make it completely autonomous, add a 2-line directive to your repository's CLAUDE.md or .cursorrules, and your agent will capture lessons after successful debugging turns automatically.

How does Titan Mem prevent prompt bloat?

Conventional agents dump entire files, long rule lists, and chat history into every turn, causing prompt bloat and massive API bills. Titan Mem keeps your system prompt lean (~400 tokens) and hydrates matching rules just-in-time via sub-3ms MCP search only when relevant.

What happens to my data if I uninstall?

Nothing happens to your data. The uninstaller removes only the binary and client configurations. Your SQLite database at ~/.titan/mem/memory_graph.db is preserved untouched. You can inspect it anytime with standard SQLite tools.

Do you send my code or memories to an external server?

No. Titan Mem runs completely locally on your machine. In the free Community tier, network egress is literally non-existent. In the Pro tier, cloud sync is End-to-End Encrypted (E2EE) with zero-knowledge keys—we cannot read your memories even if subpoenaed.

Is there an MCP tool call on every turn? What happens if Titan Mem doesn't find a solution?

There is ZERO MCP call overhead on normal turns. It is a pure, zero-cost pass-through.

Many memory tools make the fatal mistake of having the LLM call a search tool on every single turn, burning 50–100 expensive output tokens and adding 2 seconds of latency to every chat. Titan Mem uses a Pre-Prompt Native Hook that runs locally in ~35ms before any prompt reaches the cloud:

The Asymmetric Math: When there is no match, you pay 0 tokens. When there is a match, spending 22 tokens on Turn 1 saves 5 turns of trial-and-error, 25,000 tokens of failing test runs, and hours of Jira ticket spelunking.

Is Titan Mem doing the work of Jira, Confluence, or project documentation?

No. Jira and Confluence are written for humans; Titan Mem is an active constraint cache for the AI compiler.

Human documentation is filled with sprint story points, retrospective notes, and long narrative tickets that LLMs choke on. Titan Mem ignores conversational fluff and stores only executable operational invariants (50–100 chars):

• Jira / Confluence: "Ticket PROD-1042: We had an outage because K8s OOM killed the pod due to jemalloc cgroups v2 issues. Marcus spent 3 days debugging. Retrospective scheduled for Tuesday." (Pure token noise).
• Titan Mem: Rule: In deploy/helm, MALLOC_CONF=background_thread:true (Fixes K8s cgroups v2 OOM kill). (Compact, actionable, zero filler).

How does the agent know when to retrieve a memory? Does it have to guess?

Zero guesswork. Retrieval happens deterministically across 3 automated triggers:

• 1. Terminal Error Interception: When cargo build, npm test, or pytest fails, the hook queries error_fix_index in SQLite in <2ms, injecting the exact proven solution before the agent hallucinates.
• 2. File & Symbol Anchors: When you mention a file (e.g. connection.rs), Titan Mem matches memory_symbol_edges and hydrates only the specific invariant tied to that component.
• 3. Topic Trigram Filter: Mentions of architectural keywords trigger a fast SQLite FTS5 search (score > 0.65), injecting <100 tokens of verified context into the prompt.

If storing rules is tricky, isn't having a monolithic CLAUDE.md / AGENTS.md an anti-pattern?

Yes—stuffing ALL repo rules statically into every prompt IS the anti-pattern.

As repositories grow, developers cram 50+ guidelines into AGENTS.md (Docker, Rust, Python, database migrations, styling). This creates three severe problems:

• Attention Degradation: When an LLM receives 50 rules at once, it suffers from "lost in the middle" and forgets Rule #37.
• Prefix Cache Busting: Frequently modifying rules in the system prompt resets the LLM prefix cache, destroying your 90% prompt caching discount.
• Token Bloat: Burning 4,000 tokens on every turn—even when asking a trivial question.

The Titan Mem Solution: Titan Mem shards monolithic rules into granular SQLite nodes. When you edit CSS, it injects 0 database rules. When you edit connection.rs, it JIT-hydrates only the relevant database invariant as a tail result (<80 tokens), keeping your prompt cache 100% stable.

What exactly does Titan Mem store (and what does it reject)?

Titan Mem operates on the Institutional Immune System principle. It stores:

• ✅ Anti-Regression Invariants: Silent landmines that broke production in the past.
• ✅ Architecture Decision Records (ADRs): Superseded decisions so agents don't re-introduce discarded designs.
• ✅ Compiler / Build Post-Mortems: Exact error text mapped to the verified fix.
• ✅ API & Environment Quirks: Undocumented sandbox rate limits, WSL2 quirks, and auth edge cases.

Titan Mem actively rejects:

• ❌ Raw Code Dumps: (Git and disk already own this).
• ❌ Ephemeral Chat Pleasantries: Zero conversational clutter.
• ❌ Static Line Numbers: Anchors to AST symbols instead, because line numbers drift immediately.

Do these specific items really happen often enough for developers to care?

Every single day in real production engineering. The reason developers burn through token budgets and curse their AI agents isn't because the model doesn't know basic syntax—it is because agents repeatedly trigger invisible project-specific traps:

• CI & Test Suite Deadlocks: Naive agents run cargo test or pytest concurrently. Without knowing project-specific database locking or environment quirks, tests hang or deadlock, burning 40,000 tokens across 4 retry turns trying to "debug" working code.
• Dependency Bloat & Performance Ceilings: Agents love pulling in heavy, familiar packages (e.g. adding reqwest or lodash) to solve a 5-line problem, turning a 5MB binary into a 45MB monolith. A 20-token performance invariant stops this cold.
• Undocumented API Quirks: An agent calls a third-party payment or cloud API, gets a generic HTTP 400 Bad Request, and hallucinates parameter changes for 6 turns because the vendor's sandbox requires an undocumented header.

How does Titan Mem know when code changes make an old memory stale?

Deterministic AST structural hashing and body digest comparisons.

Line numbers drift immediately upon editing, and naive text search cannot tell whether a function changed. When you anchor a memory to a function (e.g. titanmem_remember with file_path and symbol), Titan Mem derives an AST hash and comment-stripped body hash in SQLite.

Automated Staleness Auditing: During background decay passes or git commits, Titan Mem re-checks AST hashes. If a symbol was deleted, it flags symbol_removed and demotes retrieval priority by 0.5x. If a file was modified, it tracks file_modified informatively without prematurely degrading your memory score.

Do I have to manually pre-program these rules? What happens when I encounter a new bug tomorrow?

Zero manual pre-programming. Titan Mem learns autonomously from everyday debugging turns.

Nobody wants to sit down and write "memory entries" like documentation. Titan Mem captures knowledge dynamically through the natural course of work:

• Autonomous Post-Tool Ingestion: When your agent encounters a failed build or broken test, spends 2 turns fixing it, and the test suite passes, Titan Mem automatically extracts the delta: Error string → Code fix hunk → Root cause, binding it to the active Git commit SHA.
• Hands-Free 2-Line Directive: With our 2-line directive in CLAUDE.md or .cursorrules, your AI agents record verified solutions autonomously upon resolution.
• Asymmetric Savings for the Future: You spend 10 minutes resolving the bug once. Every future AI session on that repository spends 0 seconds, as the fix is JIT-injected on Turn 1 in 35ms.

What is the engine architecture?

Titan Mem pairs a high-performance native Rust core and MCP server (sub-3ms search, atomic SQLite transactions) with a local FastEmbed daemon in RAM via systemd, delivering synchronous 384-d dense vector embeddings, FTS5 lexical BM25 matching, and zero cloud token leakage.