Zep AI Pricing in 2026: Plans and What You Pay
Oct 29, 202616 min read
Current Zep pricing plans
How Zep credit pricing works per episode
Zep bills in credits, with each ingested episode using one credit per 350 bytes (or part thereof). Your monthly cost is episodes multiplied by credits per episode multiplied by the price per credit, and only the last term appears on the pricing page.
The episode count is easy enough to track if you log it yourself, whether in a spreadsheet or through a workflow tool like Activepieces, but the middle term is the one you'll only learn by watching real usage.
Zep pricing is a usage-based model in which you pay for credits consumed by each episode of conversation or data ingested into its memory service, so your real cost depends on your ingestion volume as much as on the plan you choose.
Zep's a memory service for AI agents: it stores conversations and business data as a knowledge graph your agent can query later.
Count messages, not people: every message or document you send in is an episode, so your bill follows your traffic and not your headcount.
If you've priced a workflow in any automation tool, the same discipline applies: count the runs first, then read the tier.
Plan table, checked against Zep's pricing page
I've no plan figures I could confirm against Zep's pricing page on 2026-10-29, so I won't print prices or limits I can't stand behind. The table below shows which column controls which part of your bill. Read each plan on Zep's page against it.
| Column | What it controls | What it does to your bill |
|---|---|---|
| Monthly price | The fixed fee for the tier | Only the starting point, so it says little about your total |
| Included credits | How many episodes the fee covers | Decides how soon you are billed for more |
| Rate limits | How fast you can ingest and query | A low cap can force you into a higher tier even if your volume fits |
| Retention | How long stored data is kept | Short retention can mean re-ingesting, which spends credits twice |
| Support | Who answers when ingestion breaks | Matters most when a pipeline stalls mid-month |
| Overage rule | What happens past the included credits | Separates a predictable bill from a surprise |
Compare the overage rule before anything else, because it sets the slope of your cost once volume grows.
I can't verify a change history, so I won't describe one. Compare the plan you're on against the live page, and check that your invoice's credit count matches the episodes you actually sent.
If you are running this arithmetic for your own team, see what the same workload costs on Activepieces.
What one Zep credit buys in practice
To reconcile your invoice, count episodes by size, not just messages, because one credit buys one episode of up to 350 bytes.
Zep episode size and credit cost
Because Zep bills per episode, size moves the price. According to DEV Community, a 300-byte episode costs 1 credit, 700 bytes costs 2, 1,200 bytes costs 4 and 3,500 bytes costs 10.
A 3,500-byte episode costs ten credits, while a 300-byte one costs one, so credit cost scales with episode size.
To get your monthly credit count, multiply the number of episodes by the size band each one lands in.
If your messages are short, chat is the cheap case. Ten thousand 300-byte messages cost 10,000 credits.
Ten thousand 1,200-byte records, such as support tickets or CRM notes, cost 40,000 for the same episode count. If your forecast uses "messages per month" for both, the business-data side will be off by a factor of four or more.
Ingestion only: that is all the size figures above describe. I've no confirmed credit cost for retrieval or graph queries, so don't assume they're free.
Check the live pricing page for a query charge, and for how Zep handles unused credits and overages, before you model a month.
Monthly Zep bill for three realistic workloads
Multiply episodes by credits per episode, then match the result against what each plan includes: that is your monthly Zep bill. The plan with the lowest sticker price loses once your episodes are large or frequent enough to push you past its allowance.
I've no confirmed rates here, so the table below shows the arithmetic and leaves the prices for you to read off the live page. The episode counts assume one message becomes one episode and 20 messages per user a month, for both app sizes.
The plan with the lowest sticker price loses once your episodes are large or frequent enough to push you past its allowance.
Because volume is the only input that moves between rows, credits, not the plan name, drive the cost.
| Workload | Episodes a month | Credits | Plan | Upgrade point | Monthly cost |
|---|---|---|---|---|---|
| Prototype | Whatever your tests push in | Episodes × credits per episode | Free tier | The month credits exceed the free allowance | Zero until then |
| Support assistant (1,000 users × 20 messages) | 20,000 | 20,000 × credits per episode | Lowest paid plan whose allowance covers it | When 20,000 episodes, at your episode size, exceed the allowance | Plan fee, plus overage if any |
| 10,000-user app | 200,000 | 200,000 × credits per episode | Whichever plan covers ten times the support volume | Likely immediately, since volume is ten times higher | Plan fee, plus overage if any |
Read the table by row, then check each plan's allowance against the credits column.
While it stays inside the free allowance, a prototype costs nothing, so the real question is how many credits your test data burns. Pasting long documents as single episodes drains the allowance faster than short chat turns do.
With 1,000 users, twenty thousand episodes is a modest count for a support assistant, which makes episode size the deciding variable.
A cheaper plan with a small allowance can cost more than a pricier plan once overage applies, so price both at your real transcript length.
Two hundred thousand episodes for a consumer app with 10,000 users is ten times the support volume, overwhelming your support operation. You'll probably outgrow a plan that fit comfortably at 1,000 users, which means you'll need to migrate to a larger plan while still scaling.
If any tier requires a sales call to price this, treat that as a reason to model your own credits first.
Hidden Zep costs and limits teams hit first
When you read a quote, remember the catches tied to volume and plan limits. They're re-ingested history, oversized documents, throughput ceilings, gated features, and the LLM spend that sits outside Zep entirely. Model each before you trust a quote.
Credit burn from bulk and large episodes
Because Zep charges credits per ingested episode, a backfill costs real money. Loading a year of chat history on day one is a one-time spike, and it lands in a single billing period, which means your first month isn't a preview of your steady state.
If you change your extraction approach or fix a bug and then re-ingest history, you pay for the same conversations twice.
Then come large documents, the second trap. A long document is billed by size, at one credit per 350 bytes (or part), whether sent as one episode or several. A pile of PDFs can cost far more than the same number of short chat messages.
Count episodes after chunking, not files. Ask Zep sales how it meters oversized episodes, because the public pages don't make this easy to model.
Zep rate limits and throughput by plan
Because each plan carries its own request limits and ingestion is asynchronous, a bulk load that hits the ceiling queues rather than finishing. That turns a "one afternoon" migration into days on a lower tier.
Confirm the exact limits for your plan before you schedule a backfill, and ask whether a higher limit is a tier upgrade or a negotiated exception.
Zep features limited to higher plans
Watch the caps. Project counts and data retention are capped by plan. If you run separate projects for staging, production and each customer environment, the project cap can force an upgrade before your credit volume does.
Once memory ages out, your agent no longer has it, so retention limits matter the other way.
Support is gated too, with faster response and direct help reserved for upper tiers. Treat any enterprise-only feature as a sales-confirm item, and price it before you design around it.
Costs that never appear on Zep's invoice
Depending on how you deploy, some of the LLM calls that build the knowledge graph land on your own provider account.
On top of that, your agent's own model calls are a separate line, such as Claude Sonnet 5.5 or GPT-6.1 Sol answering with retrieved memory. Richer context raises your input tokens on every turn.
Add engineering time for tuning what you ingest. The Zep bill is one input to the total, not the total.
Worth checking against a plan that does not meter every step: one credit covers a whole run on Activepieces.
Zep against Mem0, Letta and Supermemory on cost
Set beside Mem0, Letta and Supermemory, Zep's price can't be compared plan to plan, because each vendor meters a different unit, and the unit decides what your volume costs.
Because Zep counts credits per ingested episode, a chatty product pays for every message it feeds in. A rival that meters stored memories or queries can come out cheaper for the same traffic, or dearer, depending on how your users behave.
I've left dollar figures out of the table. Plan prices and free allowances change, and I'd rather send you to the vendor's own page than print a number that has gone stale.
Record the date you check, because a quote read in January isn't evidence in June. The 1,000-user column is something you compute from your own message counts, not something to copy.
| Entry paid price | Free tier | Billing unit | Cost at 1,000 users | Self-hosting and licence | Enterprise gating | |
|---|---|---|---|---|---|---|
| Zep | Read from its pricing page | Check its page | Credits per ingested episode | Your episodes per user × 1,000 | Graphiti, its graph engine, is open source; the hosted platform is not | Custom quote |
| Mem0 | Read from its pricing page | Check its page | Memory operations | Your operations per user × 1,000 | Open-source core available | Confirm on its page |
| Letta | Read from its pricing page | Check its page | Plan tier with usage limits | Your agent activity × 1,000 | Open-source core available | Confirm on its page |
| Supermemory | Read from its pricing page | Check its page | Usage-based | Your usage per user × 1,000 | Open-source core available | Confirm on its page |
Two columns matter most. A self-hostable rival turns a metered bill into a server bill plus engineering hours, which is cheaper only if someone already runs infrastructure. And any "custom quote" cell means you can't budget until you've been on a call.
Ways to cut credit use before upgrading a plan with Activepieces or code
Once you've counted episodes, the cheapest way to lower the bill is to send fewer of them. An Activepieces workflow is a reasonable place to enforce that, because it sits between your source system and Zep's API and decides what crosses over.
Filtering and deduplicating well takes several steps, and it would be perverse if each one added to the price.
The Activepieces pricing page lists 1 credit per flow run, whatever the number of steps, so the seven-step flow below costs the same as a bare two-step one.
Zapier's pricing page bills per task and Make's per module, which means every check added ahead of the Zep call raises the cost there, while here the run is the meter and the steps inside it aren't.
I couldn't confirm whether it has a ready-made Zep connector. Plan on its generic HTTP step calling Zep's API directly, or a code step using Zep's SDK.
Either way, the logic is yours, and you can write the same thing in a plain script if you prefer.
Because every step before the API call is free and every episode after it is billed, the order matters:
- Trigger on a new helpdesk ticket, CRM note or chat message.
- Filter to messages that contain durable facts.
- Deduplicate against what you already sent.
- Summarise what remains.
- Batch the summaries.
- Apply a per-user cap.
- Send to Zep through the HTTP step or SDK.
Filter which messages Zep ingests to save credits
"Thanks, that fixed it" and "can you hold on a moment" are billable episodes if you send them, and they teach the memory nothing. Keep messages that state a preference, a plan, a constraint, a name or a decision.
Drop the chatter with a simple rule on message length and keywords. The saving scales with your conversation volume, which is exactly the variable that drives the bill.
Batch and deduplicate Zep episodes to cut credits
When a CRM field is re-saved or a ticket is edited, each edit can fire the trigger again. Store a hash of what you last sent per user and skip repeats.
Then summarise a ticket's thread into one episode rather than sending twelve replies, and flush on a schedule. Check how Zep counts an episode before you rely on batching, since the saving depends on that definition.
Track credit burn weekly
Add a per-user cap in the workflow so one noisy account can't consume the allowance. Then log how many episodes each run sends and post a weekly total to chat.
Set an alert at a share of your monthly allowance you choose. If burn trends toward the limit, you've a filter to tighten before you've a plan to buy.
Monday checklist for budgeting a Zep plan
Do these six things in order this week, and you'll know your own credit burn before anyone quotes you a price. The numbers you gather at step one decide everything downstream.
- Pull a month of chat turns and any business data you push in, such as documents or CRM updates. Each of those becomes an episode, so this count is your volume, and every later estimate is only as good as it is.
- Multiply that count by Zep's per-episode credit cost, then add headroom for growth. If the result lands near a plan's ceiling, you're already shopping for the next tier.
- Trial one week on real traffic. Synthetic tests understate the damage, because real users send longer messages and more of them. Run live traffic so the sample reflects how people actually use your product.
- Read the usage dashboard and compare actual credits consumed against your step-two estimate. A gap means your per-episode assumption is wrong, and it's better to learn that now than from an invoice.
- Pick a consumption level, written down and owned by a named person, at which you move up a plan. Without it, you'll either overpay early or hit a limit in production.
- Ask Zep sales three questions. Ask what happens at the limit: do requests stop, or do overages bill automatically, and at what rate? Ask how credits are counted for long messages or large documents, and whether a single episode can consume more than one credit. Ask whether unused credits roll over. Get the answers in writing, because a tier you can't price without a call is one you should price before signing.
Frequently asked questions
Five questions remain that volume math alone doesn't settle, and the answers below stick to what the pricing model implies.
Is Zep AI free to use?
Zep has offered a free tier, but treat it as a place to measure, not to run production. Its credit allowance is what you test against.
Push a representative batch of your real conversations through it, count the episodes, and you have the volume figure that every paid-plan comparison depends on.
Does Zep offer a self-hosted version now?
Not as a maintained product, as far as I can confirm. Zep's older community edition was retired, and the open-source graph library behind its memory work, Graphiti, is what remains for self-hosting.
That's a build-it-yourself route: you trade the credit meter for your own infrastructure and engineering hours, and that cost belongs in the comparison.
What happens when I run out of Zep credits?
Check the plan's terms for whether ingestion stops or overage billing begins before you rely on either. The difference decides whether a traffic spike costs you money or costs you memory, meaning new conversations that never get stored.
Either way, track credit consumption weekly rather than waiting for the invoice.
Can I switch Zep plans mid-month?
Plans are generally changeable, but whether the change is prorated, and whether unused credits carry over, is a billing detail worth confirming in writing.
If you can't get a clear answer without a sales call, assume unused credits are lost and time upgrades to the start of a billing cycle.
Does Zep charge for retrieval or only for adding data?
You pay per episode you add, because the credit model is built around ingestion. Reading memory back isn't what the meter is designed to count, which means your bill tracks how much you write, not how often you query.
Confirm that against the current plan terms before assuming reads are free at scale.
Related reading
References
Running the numbers
See what the same workload costs here.
Free forever plan, and every paid plan self-hosts at no extra cost.
See pricing Talk to sales
