Zep's Byte-Based Billing: How 15,000 Episodes Jump from $125 to $375

Zep's pricing doesn't care how many Episodes you write—it cares how big each Episode is. One credit covers the first 350 bytes, then every additional 350 bytes (or partial 350 bytes) adds another credit. The formula is simply credits = ceil(bytes / 350).

Someone ran this formula with a fixed 15,000 Episodes per month, changing only the average Episode size. The bill climbed from $125 all the way to $375—without a single change in write count.

Same Write Volume, Triple the Bill

Take 15,000 Episodes per month, calculated against the plans and quotas on Zep's pricing page:

Average Episode Size	Credits per Episode	Monthly Credits	Plan Tier
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

From 300 bytes to 3,500 bytes, credit consumption increases tenfold and the bill triples. For product teams, this means a seemingly unrelated integration change can quietly push costs up a tier.

Here, a credit is Zep's billing unit, tied to plan quotas. The Flex plan includes a certain number of credits per month; exceeding that requires a top-up or an upgrade to a higher tier. The "Plan Tier" column shows which plan tier the monthly credits from 15,000 Episodes fall into, determining the bill amount. Notably, credit consumption is decoupled from write count—it's determined solely by the byte size of each Episode. So even a small change in average size can trigger a tier jump.

What the Formula Doesn't Charge—Look Carefully

This isn't a pure hit piece on Zep. Zep charges nothing for retrieval, storage, threads, users, or graph storage. If your product is read-heavy and write-light with small write volumes, running on Zep is actually cheaper. And the billing formula is published openly, not buried in contract fine print—more transparent than some competitors.

The real problem: Episode size is the most uncontrollable variable in this product. A customer service integration initially sent only message bodies, then added ticket metadata, historical status, and system notes. Write frequency didn't change, but the plan tier slid from the first row of the table to the last—and nobody ever requested that.

Self-Hosting Zep: No Longer an Escape Route Since April 2025

Self-deployment used to be an option. Not anymore. In April 2025, Zep announced a shift in its open-source strategy, deprecating the Community Edition. What remains open source is the underlying temporal graph engine Graphiti—not the Zep service itself. The "free tier" on the pricing page refers to the hosted plan with 10,000 credits per month, which at 700-byte Episodes works out to roughly 5,000 writes.

So "running it yourself" means switching to a different project. The key question becomes: which part of Zep do you actually want to keep?

Graphiti is Zep's open-source temporal graph engine. It supports time-validity intervals for entities and relationships, enabling queries like "what was true at a given point in time." It requires a graph database (such as Neo4j, FalkorDB, or Neptune) and offers Server and MCP adapters for self-hosting. But Graphiti only provides engine capabilities—it doesn't include Zep's service-layer features like identity authentication, queues, monitoring, backups, and other productized functions. Migrating from Zep to Graphiti means building that infrastructure yourself.

Six Alternatives: The Big Picture First

Alternative	What It Replaces	Storage	Hosting Options	Where Costs Shift
Graphiti	Zep's temporal graph engine	Neo4j, FalkorDB, Neptune	Zep itself	Self-managed graph database
Statewave	Subject memory on a graph stack	Postgres + pgvector	None	Postgres plus compile-time LLM calls
Hindsight	Recall plus learned observations	Postgres or pg0	Yes	Inference costs, and more of them
Cognee	Document and code knowledge graphs	Relational, graph, vector	Yes	Configuration time
Mem0	Familiar per-user memory API	Configurable vector store	Yes	Vector store and extraction calls
Letta	Stateful agent runtime	Memory blocks and MemFS	Yes	Orchestration rewrite

There's no unified scoring of graph capabilities here. Many readers leaving Zep do so precisely because they no longer want a graph database on the critical path. A unified score would reward Graphiti—exactly the requirement they want to delete.

Breaking Down the Six Options

1. Graphiti: Keep Zep's Model, Drop the Service

The closest option to "keeping Zep's model," because it is Zep's model: entities and relationships each carry validity intervals, allowing queries on what was true at a given date. Both Server and MCP adapters can be self-hosted.

But it's delivered as an engine, not a product. Identity authentication, queues, monitoring, backups, schema, and application APIs all need to be built and maintained by you. Costs shift to the graph database you operate and the extraction calls that build the graph.

2. Statewave: Subject Memory on Postgres with a Policy Layer

Raw Episodes are append-only and immutable, stored separately from the typed memories compiled from them. Each memory carries a confidence score, validity period, and source Episode ID. Memories are organized by subject (user, account, ticket, Agent, or repository) rather than one graph per user. Retrieval runs under a token budget, YAML policies enforce deny and redact on sensitive tags, and signed receipts of the assembled package are output.

Costs shift to a Python service plus Postgres, and to LLM calls at compile time.

A subject in Statewave is the entity that memories belong to—it can be a user, account, ticket, Agent, or repository. Unlike per-user graphs, Statewave organizes memories by subject, with each subject having its own memory collection for isolation and retrieval across sessions and scenarios. The policy layer uses YAML to define deny and redact rules for sensitive tags, and outputs signed receipts of the assembled package during retrieval to prove the policy was enforced.

3. Hindsight: Let Agents Consolidate Rather Than Recall

It retains world facts and experiences, then consolidates them into observations and mental models, reflects on both, and runs four recall paths in parallel. Suited for Agents that want to "form evidence-backed beliefs" rather than "recall rows." Retain is asynchronous, and bank and tenant design decisions should be made early. Costs shift to model calls—and because reflect is inference, call volume will be higher.

Reflect is the core operation in Hindsight. It refers to an Agent reasoning over and consolidating world facts and experiences to form observations and mental models. Unlike traditional retrieval, reflect doesn't simply return matching rows—it generates beliefs based on evidence. Four recall paths work in parallel, each handling different types of information. Because reflect involves inference, it consumes more model calls, shifting costs primarily to the inference side.

4. Cognee: Heterogeneous Corpora and Code

It builds graph and vector knowledge layers from documents, code, and conversation history, distributed across relational, graph, and vector backends, with embedded defaults for local development. The best fit on this list for mixed corpora and document/code GraphRAG. Costs shift mainly to configuration time—its interface surface is broad, and default configurations won't hold up in production.

5. Mem0: Smallest Migration Effort

A familiar per-user memory API with configurable vector stores—you can integrate in an afternoon. But since the v3 open-source SDK, graph memory is only available in the Platform edition. If you're leaving Zep to stop paying for graph features, verify which edition contains the features you need before migrating. Costs shift to your vector store and extraction calls.

6. Letta: If You Were Going to Change Runtimes Anyway

Editable memory blocks plus a transcript, plus a Git-backed memory filesystem, all within a stateful Agent runtime. The most "opinionated" memory design of the six—the versioned filesystem is genuinely useful for auditing "what did this block say last Tuesday." The trade-off is scope: it replaces the Agent runtime, not just the memory layer. Costs shift to an orchestration rewrite.

The Author's Own Admission of Weaknesses

Statewave's author also lists failure scenarios for their own solution:

• No entity-relationship graph, no traversal. If your product's core question is "what was true on March 3, and how does it derive from another fact," Graphiti is the honest answer.
• No managed cloud, no cross-region clusters.
• Tenant isolation is enforced at the application layer, not via Postgres row-level security.
• Server-side CI testing has only been done on Linux.

Four Tests to Run Before Switching

Pick a candidate, replay a month of real Episodes against both backends, and check these four things:

1. Changing facts: A value updates midway through history. Does the new backend return the current value? Can it still show the old value?
2. Cross-session recall: Something said in session 2 surfaces in session 9 without being named.
3. Denied sensitive context: Memories that policy should withhold don't appear in the assembled context, and afterward you can distinguish "withheld" from "nonexistent."
4. Subject deletion: Delete a subject, then search for its traces. Half-deletion is a common failure mode—and it happens silently.

Then model the bill. With byte sizes in hand, a script can compute Zep's side in a minute. If you don't have them, measure first—the entire decision rests on that number.