Self-Hosted Memory Layer vs Managed: The Hidden Costs

A self-hosted memory layer looks free until you add up hosts, model calls, storage growth, upgrades, and on-call time. Here is an honest look at both operational models — and the managed tiers, from $0, with the numbers attached.

What a self-hosted memory layer actually involves

A self-hosted memory layer is not one binary. It is a small stack you operate: a vector store for embeddings, an extraction step that turns message batches into durable facts, a retrieval path that searches those facts at session start, an API with project-scoped keys, plus backups and upgrades.

You provision the hosts or containers, attach persistent volumes, and wire the service into your agents. Each coding agent — Claude Code, Codex, OpenCode, Cursor or Windsurf through MCP — needs the same endpoint and credentials. If you run separate projects, you also need the isolation model: which keys read which namespaces, how deletes propagate, and who can list what.

Upgrades are part of the job from day one. Embedding libraries, vector store versions, and your own extraction prompts all change. You test the new build, migrate stored vectors when formats shift, and roll back when recall regresses.

The question of what belongs in that store is separate from where it runs. RAG vs memory layer explains the split: documents stay in retrieval, durable facts about your project stay in memory.

The running costs people leave out

Compute is the line item everyone remembers and underestimates. A memory service is always on because agents read at session start and write during sessions. Even a small deployment needs a host for the API, memory and disk for the vector index, and headroom for reindex jobs. Idle time still bills.

Storage grows with extraction, not with API calls. Every durable fact keeps text plus a vector, and graph relations add edges on top. A team that stores conventions, decisions, and incident lessons adds thousands of records a month. Backups and snapshots multiply that footprint. Plan for growth in records, not just in requests.

Model costs sit outside the host bill. Extraction and search both call models: one to pull facts from a message batch, another to embed queries and rank results. Those calls scale with how much context you feed the extractor. A session that digests a migration plan extracts far more than a session that records one naming decision. If you batch more text to save API calls, you still pay in extracted facts and model input.

People time is the largest hidden line. Someone owns upgrades, key rotation, restore drills, and the 2 a.m. page when search returns nothing. Debugging recall is slower than debugging a crash: you compare what was stored against what was injected, check scoping, and re-run the query. Multiply a few hours a month by your loaded rate and the "free" stack has a monthly price.

Isolation mistakes are the last category. A self-hosted memory layer puts access control in your hands, which means a mis-scoped key or a shared namespace can leak one project's conventions into another. Audaxic's managed model isolates data per organization with namespace-scoped vector search. Reproducing that boundary yourself takes design and review, and the failure mode is silent contamination rather than an error page.

When self-hosting is the right call

Self-hosting fits teams that already run stateful services and want control over every layer. If you have a platform engineer who owns Postgres, vectors, and backups today, adding one more stateful service is routine work rather than a new discipline.

Custom retrieval is the second reason. Some teams rank memories with project-specific rules, filter by branch or ticket, or join memory results with internal metadata before injection. Owning the code path makes those experiments faster. You change the query, redeploy, and measure recall on your own data.

Data placement can force the decision. Audaxic stores data on servers in the US and EU and never trains on customer data. If your policy needs a different region or a specific VPC layout, a stack you control is the direct answer. Audaxic offers on-premise deployment available on request on Enterprise for teams that need a managed option inside that constraint, but a fully self-operated build remains the choice when policy names your own network.

The honest test is staffing. If you can name the owner for upgrades, backups, and recall regressions for the next twelve months, self-hosting is a defensible call. If that owner is "whoever has time," the stack will drift.

Budget the maintenance in writing before you commit. List who rotates project keys, who tests restores, and who reviews extraction quality each month. A self-hosted build without those three names becomes stale data on a running host: the service stays up while the memories inside it lose value.

When a managed layer wins for small teams

A managed layer wins when you want memory without a second job. Audaxic is fully managed with zero infrastructure to run: you create a project, take a project key, and point your agents at the API. One memory per project means switching agents never resets context — Claude Code, Codex, OpenCode, and any MCP client read the same store.

Indie developers feel this first. You work across two or three repos in different tools and cannot afford an evening of vector store maintenance. The managed path is plugin installs plus one MCP URL: https://memory-mcp.audaxic.com/mcp with a Bearer ak_... key.

Small teams feel it in onboarding. A new teammate installs the Claude Code plugin with npx @audaxic/memory-claude install, the Codex plugin with npx @audaxic/memory-codex install, or the OpenCode package with npm install -g @audaxic/memory-opencode, pastes the project key, and starts with the same conventions. Cursor connects through MCP only — there is no Cursor plugin — so the same server URL covers it. Past work carries over too: npm install -g @audaxic/memory-import brings in prior Claude Code, Codex, and OpenCode conversations with correct timestamps.

The managed side uses flat monthly pricing with no per-token fees and no overages: a heavy import month costs the same as a quiet month on the same tier. For the side-by-side numbers, read Mem0 Alternative: Cheaper Memory Layer for Coding Agents.

The managed side in numbers: flat tiers from $0

Managed pricing is five published tiers, all with unlimited projects and graph memory included from Hobby through Enterprise:

Hobby requires no credit card. Counting is explicit: an add request is counted per memory extracted from a message batch, so one /add call that extracts five memories counts as five add requests. Retrieve requests use tiered counting — the first 10 memories retrieved count as 1 request and each additional 10 counts as 1 more, so 25 memories count as 3 requests.

The API shape is mem0-like across five endpoints: POST /add, POST /search, GET /list paginated with limit and offset, PUT /update, and DELETE /delete/{memory_id} plus DELETE /delete. Project keys look like ak_... for the data plane at https://api.memory.audaxic.com. Workspace automation uses at_... auth tokens with scopes for projects and keys on the management plane. Requests carry a date-based X-Api-Version header, currently 2026-09-25.

Two policy facts matter for the comparison. Data is isolated per organization with namespace-scoped vector search, and Audaxic never trains on customer data. Current numbers live on the pricing page, which is the source to quote in a budget.

Maintenance hygiene works the same on either side. When a convention changes, correct it with PUT /update rather than adding a duplicate; when a decision expires, remove it with DELETE /delete/{memory_id} so future sessions stop recalling it. A memory that stores every superseded fact turns retrieval noisy. The teams that get lasting value review stored facts monthly and delete what no longer describes the repo.

Decision checklist before you commit

Run this checklist with your team before you pick a side. It takes one meeting and prevents a replatform six months later.

If you choose managed, verify it in ten minutes. Create a project, install one plugin, store a fact only this repo would know, then search it from a different agent on the same project key:

# store two facts from this repo
curl -s https://api.memory.audaxic.com/add \
  -H "Authorization: Bearer ak_YOUR_PROJECT_KEY" \
  -H "X-Api-Version: 2026-09-25" \
  -H "Content-Type: application/json" \
  -d '{"messages": [{"role": "user", "content": "We use pnpm and prefix API errors with ERR_"}]}'

# recall from the second agent's session
curl -s https://api.memory.audaxic.com/search \
  -H "Authorization: Bearer ak_YOUR_PROJECT_KEY" \
  -H "X-Api-Version: 2026-09-25" \
  -H "Content-Type: application/json" \
  -d '{"query": "package manager and API error convention"}'

# page through what the project remembers
curl -s "https://api.memory.audaxic.com/list?limit=20&offset=0" \
  -H "Authorization: Bearer ak_YOUR_PROJECT_KEY" \
  -H "X-Api-Version: 2026-09-25"

A second agent that returns the pnpm and ERR_ conventions without being told proves the shared layer works. The quickstart shows the same flow with client libraries and the MCP setup.

FAQ

Written by Efe — Oct 09, 2026 · More articles · X @AudaxicTech