# getzep/zep: examples and integrations for Zep Cloud agent memory > The getzep/zep repository is not the Zep product. It is a collection of example apps, framework integration packages, a bulk ingestion tool and benchmarks for Zep Cloud, and the README is explicit about that split. **getzep/zep** — Zep | Examples, Integrations, & More. It contains example code, framework integrations, and tools for building agent memory with Zep Cloud, Zep's managed agent memory platform. - Repository: https://github.com/getzep/zep - Website: https://help.getzep.com - Stars: 4,932 · Forks: 654 - Language: Python - License: Apache-2.0 - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/getzep-zep ## What getzep/zep actually is, and what it is not The README opens with a disclaimer that is easy to skip: "This repository is not Zep's product or service." Zep Cloud is a managed agent memory platform hosted at getzep.com, and this repository is the surrounding material: example apps, integration packages, an ingestion pipeline, ontology definitions, benchmarks and an evaluation harness. If you arrived expecting a server you can run, you arrived at the wrong repository. The README points elsewhere for that, and the pointer is worth reading carefully because it explains a lot of the confusion around the project. The audience is narrower than the name suggests. You need a Zep Cloud account and an API key from app.getzep.com before any of this does useful work. The examples in examples/python, examples/typescript and examples/go are written against the hosted service, and the integration packages under integrations/ wrap the official SDKs rather than replacing them. Someone evaluating memory infrastructure for an agent product is the intended reader. Someone looking for a local vector store or a self-hosted memory backend is not. ## Repository layout: examples, integrations, ingestion, benchmarks The top level is a monorepo of independent pieces rather than a single library. examples/ holds snippets in Python, TypeScript and Go. integrations/ is organized framework-first and then by language, so a path looks like integrations///, and the README states each package is built, tested and released independently. That structure matters operationally: nothing forces you to take the whole tree, and the release cadence of one integration does not imply anything about another. The integration list is the most concrete thing in the README. Python covers Google ADK, Microsoft Agent Framework, Microsoft AutoGen, AG2, CrewAI, LangGraph, LiveKit, Pydantic AI and Strands Agents. TypeScript covers Google ADK, Mastra and the Vercel AI SDK. Go covers Google ADK only. That asymmetry is real and worth planning around. If your stack is Go plus anything other than Google ADK, this repository does not have a package for you yet. Two directories deserve separate attention. ingestion/ contains zep-ingest, the bulk data ingestion pipeline, and it is the only component with its own release series in the recent tags. ontology/ holds default ontology definitions, which is where you would look if the extracted entities and relationships do not match your domain. benchmarks/ and zep-eval-harness/ are for measuring ingestion and retrieval behavior, and the README names LoCoMo and LongMemEval as the memory benchmarks involved. ## Installing the SDK and running a first example The README lists the official SDKs directly, and these are the packages the examples and integrations build on. Pick the one matching your language. ```bash pip install zep-cloud ``` For TypeScript or JavaScript the README gives the scoped npm package: ```bash npm install @getzep/zep-cloud ``` For Go the module path carries a major version suffix: ```bash go get github.com/getzep/zep-go/v3 ``` The repository itself is Python-first and pins a modern interpreter. The pyproject.toml at the root declares requires-python = ">=3.12" and an empty dependency list, which tells you the root project is a container for the tree rather than a published library. Do not expect pip install zep to give you anything useful. Credentials come from the environment. The .env.example file at the root is written for the MCP server configuration and documents exactly one required variable plus one optional one. Copy it and fill in the key: ```bash cp .env.example .env ``` ```bash ZEP_API_KEY= LOG_LEVEL=info ``` The file comments state that ZEP_API_KEY is required and that you get it from app.getzep.com, and that LOG_LEVEL accepts debug, info, warn or error with info as the default. Once that is set, open examples/README.md and follow the language directory that matches your stack. The README does not document a rollback or teardown path for ingested data, so plan your test data accordingly. ## zep-ingest and the bulk loading path The ingestion directory is the part of this repository with the clearest release history. The recent tags are zep-ingest-v0.3.0 on 2026-08-28, zep-ingest-v0.2.1 on 2026-08-19 and zep-ingest-v0.2.0 on 2026-08-12, so the tool has moved through three releases in under three weeks. That cadence is a signal about where development attention sits, and it is the opposite of the impression you would get from the root pyproject.toml, which is essentially a stub. The README describes zep-ingest as a bulk data ingestion pipeline covering Slack, documents, email, JSON/CSV and fact triples. That list is the useful part. Fact triples in particular means you can load structured subject-predicate-object knowledge rather than only raw text, which is a different ingestion shape from most memory tools that expect conversation transcripts or documents. If your data already lives in a graph or a relational schema, that path is the reason to look here first. The README does not document throughput numbers, batch size limits, retry behavior or rate limiting for zep-ingest. Anyone planning a large backfill should read the ingestion directory and the zep-eval-harness rather than assume the pipeline handles interruption gracefully. The eval harness exists precisely because ingestion and retrieval quality are things you measure rather than assume. ## The Community Edition is deprecated, and Graphiti is a separate project This is the limitation that decides adoption for a lot of people. The README states plainly that Zep Community Edition is no longer supported and that its code has been moved to the legacy/ folder, with a link to a blog post titled "Announcing a New Direction for Zep's Open Source Strategy." If you found this repository through an older tutorial that walked you through running Zep locally, that tutorial is now describing unsupported code sitting in a folder the README labels deprecated. The README also redirects readers who want the open-source temporal knowledge graph framework that powers Zep to a different repository, getzep/graphiti. That is a genuinely different project with its own repository, not a directory here. Treating getzep/zep as the open-source memory engine and Graphiti as an add-on inverts the relationship the README describes. There is a second, quieter constraint. The README points to two agent plugins, "Build with Zep" for Claude Code, Codex and Cursor, and "Zep Memory" for Claude Desktop, Cowork and ChatGPT Work, and notes both live in separate repositories. So the plugin surface is not in this tree either. What remains here is examples, integrations, ingestion, ontology, benchmarks and the eval harness, all of which assume the hosted service. ## How this differs from mem0 and from running your own store The comparison people search for is Zep versus mem0, and the architectural difference is worth stating precisely. Zep Cloud is a managed service: you send data to an API and the platform handles storage, extraction and retrieval, with this repository supplying the client-side glue. The README's framing of the repository as example code and integrations, distinct from the product, is the clearest evidence of that split. mem0 is commonly deployed as a library or self-hosted service that you run alongside your own vector store, which means you own the operational surface. That difference shows up in what you debug. With a hosted memory platform, the failure modes you can fix locally are in your integration code and your ingestion pipeline, which is exactly what this repository contains. With a self-hosted library, retrieval quality problems may be yours to fix at the index level. Neither is strictly better, but the choice determines whether zep-ingest and the integration packages are useful to you or irrelevant. If your requirement is that memory data never leaves your infrastructure, the README's direction points you at Graphiti, not at this repository. A third option, doing nothing and keeping conversation history in your own database, remains viable for short-context agents. The benchmarks directory exists because that trade-off is empirical, not obvious. ## Maintenance, licensing and upgrade cost The repository is not archived, and the last push was on 2026-08-28, which lines up with the zep-ingest-v0.3.0 tag. The activity that is visible is concentrated in the ingestion tool and the integration packages, and the README states each integration package is built, tested and released independently. That independence is the main upgrade cost: there is no single version number for this repository that tells you what changed. You track the package for your framework and language, and you check integrations/README.md for its release status before upgrading. The licence is Apache-2.0, stated in the repository metadata and present as a LICENSE file at the root. Apache-2.0 is permissive and includes an explicit patent grant, which is generally the reason projects pick it over MIT. It does not change the fact that the code here talks to a commercial hosted service, and the README makes no claim about what the service terms are. Nothing in the README describes pricing, quotas or a free tier, so treat cost as something to confirm at signup rather than something this repository answers. I am not giving legal advice; if the patent grant or the notice requirements matter to your organization, have counsel read the LICENSE file. The upgrade risk to watch is version drift between the SDKs and the integration packages. The README lists zep-cloud for Python, @getzep/zep-cloud for TypeScript and github.com/getzep/zep-go/v3 for Go, and the Go module path already carries a v3 suffix, which tells you the Go SDK has had at least two major transitions. If you pin an integration package, pin the SDK alongside it. ## Conclusion Adopt this repository if you already have a Zep Cloud API key and you want a working starting point for LangGraph, CrewAI, Pydantic AI, Mastra or the other integration packages, or if you need to bulk load Slack, email, documents or fact triples through zep-ingest. Do not adopt it if you want a self-hosted memory server: the Community Edition code now sits in legacy/ and the README states it is unsupported, and the open-source temporal graph work lives in the separate Graphiti repository. Before committing, verify that the integration package for your framework and language is actually present under integrations///, check the release status listed in integrations/README.md, and confirm your Python version satisfies the >=3.12 requirement in pyproject.toml. ## FAQ ### What is Zep AI used for? Zep Cloud is a managed agent memory platform, and this repository provides example code, framework integrations, an ingestion pipeline, ontology definitions and benchmarks for building against it. It is aimed at developers adding memory to agents rather than at people running their own memory server. ### What does "zep" mean? The README does not explain the origin or meaning of the name. It only uses Zep as the product name for Zep Cloud and as the repository name getzep/zep. ### What is the price of Zep memory? The README does not document pricing, quotas or plan tiers. It only states that you sign up at www.getzep.com and read the documentation at help.getzep.com, which is where pricing would have to be confirmed. ### Who created Zep AI? The README does not name the founders or the company behind Zep. The repository organization is getzep on GitHub and the product site is getzep.com. ## Sources - [Official documentation](https://help.getzep.com) - [Official README](https://github.com/getzep/zep#readme) - [Project repository](https://github.com/getzep/zep) - [Release notes](https://github.com/getzep/zep/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/getzep-zep