Zep charges per 350 bytes, so the same 15,000 episodes can land on a $125 or a $375 plan

Zep's pricing is metered on episode size, not episode count. One credit covers the first 350 bytes, and every additional 350 bytes or part of it adds another. So credits = ceil(bytes / 350).

I ran that against a fixed workload of 15,000 episodes a month, changing only the average episode size. Plan prices and allowances come from Zep's pricing page, checked 14 October 2026. The arithmetic is mine, and the script is below so you can run it against your own distribution.

Avg episode	Credits each	Monthly credits	Lands on
300 B	1	15,000	Flex, $125
700 B	2	30,000	Flex, $125
1,200 B	4	60,000	Flex plus one top-up, $150
3,500 B	10	150,000	Flex Plus, $375

Same number of writes. Ten times the credits across that range, and a tripled bill between the first row and the last.

import math

PLANS = [("Flex", 50_000, 125, 10_000, 25),
         ("Flex Plus", 200_000, 375, 40_000, 75)]

def credits(sizes):
    return sum(math.ceil(b / 350) for b in sizes)

def monthly_cost(total):
    for name, included, price, topup_size, topup_price in PLANS:
        if total <= included:
            return name, price
        packs = math.ceil((total - included) / topup_size)
        if packs <= 3:
            return f"{name} + {packs} top-up", price + packs * topup_price
    return "Enterprise", None

for size in (300, 700, 1200, 3500):
    print(size, monthly_cost(credits([size] * 15_000)))

What the formula does not charge you for

Two things stop this being a hit piece. Zep charges nothing for retrieval, storage, threads, users or graph storage, so a read-heavy product with small writes is cheap to run there. And the formula is published rather than buried, which is more than several competitors manage.

Why episode size drifts without anyone deciding to change it

Episode size is the variable your product controls least. A support integration that starts by sending a message body, and later sends the body plus ticket metadata, prior status and a system note, has not changed how often it writes. It has changed which row of that table it sits in, and nobody filed a ticket for it.

We build Statewave, one of the six alternatives below, so weigh that entry accordingly.

Self-hosting Zep stopped being the fallback in April 2025

It used to be. Zep announced a new direction for its open-source strategy in April 2025 and the Community Edition was deprecated. What remains open is Graphiti, the temporal graph engine underneath Zep, rather than the service around it. Free tier on the pricing page means a hosted plan at 10,000 credits a month, which at 700-byte episodes is about 5,000 writes.

So "run it ourselves" means picking a different project, and the useful question is which part of Zep you are trying to keep.

How the six compare, before the detail

#	Alternative	Replaces	Storage	Managed option	Where the cost moves
1	Graphiti	Zep's temporal graph engine	Neo4j, FalkorDB, Neptune	Zep itself	A graph database you operate
2	Statewave	Subject memory off a graph stack	Postgres + pgvector	No	Postgres, plus compile-time LLM calls
3	Hindsight	Recall plus learned observations	Postgres or pg0	Yes	Inference, and more of it
4	Cognee	Document and code knowledge graphs	Relational, graph, vector	Yes	Configuration time
5	Mem0	Familiar per-user memory API	Configurable vector store	Yes	Vector store and extraction calls
6	Letta	Stateful agent runtime	Memory blocks and MemFS	Yes	A rewrite of your orchestration

I did not score graph capability uniformly across that table. For a good number of readers the reason to leave is that they no longer want a graph database on the critical path, and a uniform score would reward Graphiti for the exact requirement they are trying to delete.

The six alternatives in detail

1. Graphiti, for keeping Zep's model and dropping the service

github.com/getzep/graphiti · Apache-2.0 · Neo4j, FalkorDB or Amazon Neptune

The closest thing to keeping Zep's model, because it is Zep's model: entities and relations, each carrying a validity interval, so you can ask what was true on a given date. Server and MCP adapter are both self-hostable.

It ships as an engine rather than a product. Identity, auth, queueing, monitoring, backups, schema and your application API are yours to build and keep running.

Cost moves to: a graph database you now operate, plus the extraction calls that build the graph.

2. Statewave, for subject memory on Postgres with a policy layer

github.com/smaramwbc/statewave · Apache-2.0 · Postgres 14+ with pgvector, Python 3.11+

Raw episodes stay append-only and separate from the typed memories compiled out of them, and each memory carries confidence, validity and the source episode IDs behind it. Memory is scoped to a subject, meaning a user, account, case, agent or repository, rather than to a graph per user. Retrieval runs under a token budget with a YAML policy of deny and redact rules over sensitivity labels, and emits a signed receipt of the assembled bundle.

Cost moves to: one Python service plus Postgres, and LLM calls at compile time.

3. Hindsight, for agents that consolidate rather than retrieve

github.com/vectorize-io/hindsight · MIT server · Postgres or embedded pg0, hosted option available

Keeps world facts and experiences, then consolidates them into observations and mental models, with a reflect pass over both and four recall paths running in parallel. Pick it when you want an agent that forms evidence-backed beliefs rather than one that recalls rows. Retain is asynchronous, so bank and tenant design needs deciding early.

Cost moves to: model calls, and more of them, because reflection is inference.

4. Cognee, for heterogeneous corpora and code

github.com/topoteretes/cognee · hosted option available · check the repo for current licence terms

Builds a graph and vector knowledge layer out of documents and code plus session history, spread over relational, graph and vector backends, with embedded defaults for local work. Best fit on this list for mixed corpora and document or code GraphRAG.

Cost moves to: configuration time, mostly. Its surface is wide and the defaults will not survive contact with production.

5. Mem0, for the smallest migration on the list

github.com/mem0ai/mem0 · Apache-2.0 core, managed platform alongside

The familiar per-user memory API, configurable vector store, small enough to adopt in an afternoon. Graph memory has been Platform-only since the v3 open-source SDK, so if you are leaving Zep specifically to stop paying for graph features, verify which edition holds the one you need before you plan the migration.

Cost moves to: your vector store and extraction calls.

6. Letta, when you are replacing the runtime anyway

docs.letta.com · hosted option available

Editable memory blocks and a transcript, plus a Git-backed memory filesystem, all inside a stateful agent runtime. Memory design here is the most opinionated of the six, and the versioned filesystem is genuinely useful for auditing what a block said last Tuesday. Scope is the catch, because it replaces the agent runtime rather than only the memory layer.

Cost moves to: a rewrite of your orchestration, if you already have one.

Where our own entry loses

• No entity-relationship graph and no traversal. If "what was true on 3 March, and how did that follow from the other thing" is your product, Graphiti is the honest answer and this is not.
• No managed cloud and no cross-region clustering.
• Tenant scoping is enforced in the application, not by Postgres row-level security.
• The server is CI-tested on Linux only. ## Four tests to run before you cut over

Pick a candidate, replay a month of real episodes through both backends, and check these.

1. Changed facts. A value updates mid-history. Does the new backend return the current one, and can you still see the old one?
2. Cross-session recall. Something stated in session 2 surfaces in session 9, without you naming it.
3. Denied sensitive context. A memory that policy should withhold stays out of the assembled context, and you can tell afterwards that it was withheld rather than missing.
4. Subject deletion. Delete a subject, then search for traces of it. Half-deletes are the common failure and they are quiet. Then model the bill. That script gives you the Zep side in about a minute if you have the byte sizes. If you do not, measure them before anything else, because it is the number the whole decision turns on. Post what your distribution looks like in the comments, I am curious how wide the spread is across different products.

Code for the implementation I work on sits at github.com/smaramwbc/statewave if you want to read the compile and receipt code rather than trust a table.

Pricing and repository details above were checked on 14 October 2026.