Persistent Agent Memory That Never Bloats Your Context

What is the "Zero Data Hostage" Guarantee?

Across every tier (Community, Pro, Max, and Enterprise), 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).
• Enterprise ($99/seat/mo): Strict per-seat / per-machine commercial licensing. Commercial organizations are legally prohibited from sharing individual Pro/Max keys across multiple colleagues.

How does Titan Mem detect multiple users 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 a 4th device attempts to activate a 3-device Max key, activation is denied until you deactivate an old machine. Furthermore, Enterprise clusters monitor simultaneous active session leases to prevent credential sharing across developers.

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 enterprise 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.
• Cross-Seat Regression Avoidance (Enterprise): When Developer B doesn't spend 3 hours re-solving an obscure Docker allocator bug that Developer A already solved, that saves $300+ of engineering payroll in a single morning.
• Zero Prompt Exfiltration (Enterprise): Eliminates duplicate cloud context spend across hundreds of engineers while enforcing zero prompt exfiltration through dedicated VPC relays.

Conclusion: Across every tier—from individual developers to high-velocity commercial teams and enterprise organizations—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 enterprise MCP tools without blowing up my context window?

Enterprise agents often connect to hundreds of tools across cloud infrastructure, databases, and payment 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 organization's 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 entire enterprise 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 200+ enterprise 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 and your team 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 or my team have to restart our IDE when new memories sync?

No. Restarting IDEs and losing open tabs is completely unacceptable. Titan Mem runs with SQLite Write-Ahead Logging (WAL) concurrency. When team rules or multi-device deltas sync in the background, active Claude Code, Cursor, and terminal sessions detect new 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, teams 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 the team's database locking quirks, the tests hang or deadlock, burning 40,000 tokens across 4 retry turns trying to "debug" working tests.
• 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.

Isn't Git already there to prevent conflicting refactors between teammates?

Git detects merge conflicts at the end (too late); Titan Mem prevents wasted work at the beginning (JIT).

Git is a passive version ledger. It only complains after an engineer has already spent 4 hours writing code, opened a Pull Request, and tried to merge. By then, the developer time and AI token budget are already wasted.

The Titan Mem Difference: When an agent opens an active subsystem (e.g., src/auth/jwt.rs), Titan Mem injects a 1-line Intent Anchor: "Marcus is migrating JWT signing to ed25519 in PR #104. Coordinate before refactoring." The agent stops immediately—preventing a 4-hour duplicate implementation before a single conflicting line is committed.

Do we have to manually pre-program these rules? What happens when my team encounters 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: The first developer spends 10 minutes resolving the bug. The remaining 9 developers on the team—and every future AI session on that repo—spend 0 seconds, as the fix is JIT-injected on Turn 1 in 35ms.

Why native Rust instead of Python?

Python engines require heavy virtual environments, 150MB+ runtimes, and introduce 200ms–800ms cold start delays. Titan Mem is compiled into a single static native binary that launches in 2.9ms, consumes under 15MB of RAM, and runs with zero external dependencies.