HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
getzep
zep
Python2023–2024
getzep / zep

zep

Zep | Examples, Integrations, & More

2Distinct people
12Mentions
0Explicit recommenders
5KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Zep | Examples, Integrations, & More

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month12 dated mentions

Observed mentions: 2023-05-10 16:40:20 UTC to 2024-09-26 16:40:33 UTC.

01232023-05-01 00:00:00 UTC to 2023-06-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 commentsMay 20232023-06-01 00:00:00 UTC to 2023-07-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-07-01 00:00:00 UTC to 2023-08-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2023-08-01 00:00:00 UTC to 2023-09-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2023-09-01 00:00:00 UTC to 2023-10-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2023-10-01 00:00:00 UTC to 2023-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-11-01 00:00:00 UTC to 2023-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-12-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2024-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsJan 20242024-02-01 00:00:00 UTC to 2024-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-03-01 00:00:00 UTC to 2024-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-04-01 00:00:00 UTC to 2024-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-05-01 00:00:00 UTC to 2024-06-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-06-01 00:00:00 UTC to 2024-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-07-01 00:00:00 UTC to 2024-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-08-01 00:00:00 UTC to 2024-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-09-01 00:00:00 UTC to 2024-10-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 commentsSep 2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
May 20232023-05-01 00:00:00 UTC2023-06-01 00:00:00 UTC110
Jun 20232023-06-01 00:00:00 UTC2023-07-01 00:00:00 UTC101
Jul 20232023-07-01 00:00:00 UTC2023-08-01 00:00:00 UTC312
Aug 20232023-08-01 00:00:00 UTC2023-09-01 00:00:00 UTC211
Sep 20232023-09-01 00:00:00 UTC2023-10-01 00:00:00 UTC312
Oct 20232023-10-01 00:00:00 UTC2023-11-01 00:00:00 UTC000
Nov 20232023-11-01 00:00:00 UTC2023-12-01 00:00:00 UTC000
Dec 20232023-12-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
Jan 20242024-01-01 00:00:00 UTC2024-02-01 00:00:00 UTC000
Feb 20242024-02-01 00:00:00 UTC2024-03-01 00:00:00 UTC000
Mar 20242024-03-01 00:00:00 UTC2024-04-01 00:00:00 UTC000
Apr 20242024-04-01 00:00:00 UTC2024-05-01 00:00:00 UTC000
May 20242024-05-01 00:00:00 UTC2024-06-01 00:00:00 UTC101
Jun 20242024-06-01 00:00:00 UTC2024-07-01 00:00:00 UTC000
Jul 20242024-07-01 00:00:00 UTC2024-08-01 00:00:00 UTC000
Aug 20242024-08-01 00:00:00 UTC2024-09-01 00:00:00 UTC000
Sep 20242024-09-01 00:00:00 UTC2024-10-01 00:00:00 UTC110

What Hacker News says

12 sources
roseway4·Sep 26, 2024Submission

Show HN: Zep – Open-Source Graph Memory for AI Apps

Hi HN, we're Daniel, Paul, Travis, and Preston from Zep. We’ve just open-sourced Zep Community Edition, a memory layer for AI agents that continuously learns facts from user interactions and changing business data. Zep ensures that your Agent has the knowledge needed to accomplish tasks successfully. Github: https://github.com/getzep/zep Zep walkthrough: https://vimeo.com/1013045013 A few weeks ago, we shared Graphiti, our library for building temporal Knowledge Graphs (https://news.ycombinator.com/item?id=41445445). Zep runs Graphiti under the hood, progressively building and updating a temporal graph from chat interactions, tool use, and business data in JSON or unstructured text. Zep allows you to build personalized and more accurate user experiences. With increased LLM context lengths, including the entire chat history, RAG results, a
Read the rest
nd other instructions in a prompt can be tempting. We’ve experienced poor temporal reasoning and recall, hallucinations, and slow and expensive inference when doing so. We believe temporal graphs are the most expressive and dense structure for modeling an agent’s dynamic world (changing user preferences, traits, business data etc). We took inspiration from projects such as MemGPT but found that agent-powered retrieval and complex multi-level architectures are slow, non-deterministic, and difficult to reason with. Zep’s approach, which asynchronously precomputes the graph and related facts, supports very low-latency, deterministic retrieval. Here’s how Zep works, from adding memories to organizing the graph: 1. Zep identifies nodes and relationships in chat messages or business data. You can specify if new entities should be added to a user and/or group of users. 2. The graph is searched for similar existing nodes. Zep deduplicates new nodes and edge types, ensuring orderly ontology growth. 3. Temporal information is extracted from various sources like chat timestamps, JSON date fields, or article publication dates. 4. New nodes and edges are added to the graph with temporal metadata. 5. Temporal data is reasoned with, and existing edges are updated if no longer valid. More below. 6. Natural language facts are generated for each edge and embedded for semantic and full-text search. Zep retrieves facts by examining recent user data and combining semantic, BM25, and graph search methods. One technique we’ve found helpful is reranking semantic and full-text results by distance from a user node. Zep is framework agnostic and can be used with LangChain, LangGraph, LlamaIndex, or without a framework. SDKs for Python, TypeScript, and Go are available. # More about how Zep manages state changes Zep reconciles changes in facts as the agent’s environment changes. We use temporal metadata on graph edges to track fact validity, allowing agents to reason with these state changes: Fact: “Kendra loves Adidas shoes” (valid_at: 2024-08-10) User message: “I’m so angry! My favorite Adidas shoes fell apart! Puma’s are my new favorite shoes!” (2024-09-25) Facts: - “Kendra loves Adidas shoes.” (valid_at: 2024-08-10, invalid_at: 2024-09-25) - “Kendra’s Adidas shoes fell apart.” (valid_at: 2024-09-25) - “Kendra prefers Puma.” (valid_at: 2024-09-25) You can read more about Graphiti’s design here: https://blog.getzep.com/llm-rag-knowledge-graphs-faster-and-... Zep Community Edition is released under the Apache Software License v2. We’ll be launching a commercial version of Zep soon, which like Zep Community Edition, builds a graph of an agent’s world. Zep on GitHub: https://github.com/getzep/zep Quick Start: https://help.getzep.com/ce/quickstart Key Concepts: https://help.getzep.com/concepts SDKs: https://help.getzep.com/ce/sdks Let us know what you think! We’d love your thoughts, feedback, bug reports, and/or contributions!
6 points · Open discussion
I’m struggling to understand what’s novel here. LLM-based summarization of chat history memory is a well-established technique implemented by many LLM frameworks. Summarizing on every message is, as proposed in the paper, a major performance bottleneck and adds significant latency to the chat loop. Many implementations utilize a fixed sized buffer, progressively summarizing batches of older memories when they fall out of the buffer. Ideally, this is also done out of band to the chat loop. I’m an author of Zep[0], an open source long-term memory store, and this is how we implemented summarization. 0: https://github.com/getzep/zep
In Recursively summarizing enables long-term dialogue memory in LLMs
roseway4·Aug 3, 2023Submission

Show HN: Zep – pgvector-based memory store for LLM apps

Hey HN - we launched Zep's document vector DB today. Zep is an open source memory store for LLM apps, and this builds on existing chat history memory persistence, embedding, and enrichment capabilities. Zep uses Postgres and pgvector for database operations and vector search. Vector search can be complicated on Postgres, with careful configuration required at both index creation and query time. We've focused on significantly improving this developer experience. Zep automatically selects index and query parameters for developers based on best practices and known heuristics. Vector database operations are exposed via a simple Python (and LangChain) API for working with document collections, documents, and search results. While we focus on LLM App use cases, you can turn any Postgres instance with pgvector into a vector database with great D
Read the rest
6 points · Open discussion
Kismet this is published today. We've just announced Zep's[0] new Document Vector Store[1] built on pgvector, and the embedding model we ship with is all-MiniLM-L6-v2. Very fast, low-memory, and surprisingly performant. Our focus with Zep is on LLM app use cases, and in particular, searching over chat histories and documents for RAG apps. You can, however, use Zep to turn any Postgres instance into a vector store with great developer experience. pgvector index configuration and query tuning can be challenging. We've tried to do much of this work for developers. Also, I'm super excited about the prospect of HNSW support in pgvector, slated for pgvector 0.5.[2] [0] https://github.com/getzep/zep [1] https://blog.getzep.com/introducing-the-zep-document-vector-... [2] https://github.com/pgvector/pgvector/issues/181#issuecomment...
In Pgvector: Fewer Dimensions Are Better
Bard's multimodal abilities are impressive. It's worth noting that PaLM 2 does not offer multimodal capabilities, and your experience here, as you suggested, likely leans on Google's long history of building search across both text and image data. In a reasoning and creativity shootout, I'm not convinced Palm 2 (and Bard) fairs well against Claude v2 and GPT-3.5. Is anybody aware of Palm 2 being used in production other than with Bard? I see companies building and deploying with Claude* but have yet to come across Palm 2 users. * I've fielded several requests to add Claude 2 API support to Zep, an open source memory store I co-authored. https://github.com/getzep/zep
In Bard’s latest update: more features, languages and countries
We embed Postgres and pgvector in Zep[0], a memory store for LLM apps. It’s rock solid, even with very wide vectors, and with the right indexes ANN is performant up to tens of millions of rows. Haven’t tested beyond this, though. It’s super useful for hybrid search: vector similarity search over unstructured data joined with filtering by structured data. One caveat: It’s important indexes are added after a fair number of vectors have been persisted, which can make some production use cases challenging to implement. [0] https://github.com/getzep/zep
In Supabase Vector, the Open Source Vector Toolkit for Postgres
roseway4·May 10, 2023Submission

Show HN: Zep – Long-Term Memory Store for LLM Apps

Zep is a long-term memory store designed for conversational AI applications built using modern LLMs. It handles the storage, summarization, embedding, indexing, and enrichment of chat histories, and offers developers a simple, low-latency API to this data. Chat history storage is an infrastructure challenge all developers and enterprises face as they look to move from prototypes to deploying conversational AI applications that provide rich and intimate experiences to users. Key features include long-term memory persistence, auto-summarization, vector search, auto-token counting, and Python and JavaScript SDKs. Upcoming features include Langchain Memory and Retrievers, integrations with other conversational AI frameworks, entity extraction, and much more. Github repo: https://github.com/getzep/zep Long-term memory persistence enables a var
Read the rest
iety of use cases, including: - Personalized re-engagement of users based on their chat history. - Prompt evaluation based on historical data. - Training of new models and evaluation of existing models. - Analysis of historical data to understand user behavior and preferences. However: - Most AI chat history or memory implementations run in-memory and are not designed for stateless deployments or long-term persistence. - Standing up and managing low-latency infrastructure to store, manage, and enrich memories is non-trivial. - When storing messages long-term, developers are exposed to privacy and regulatory obligations around PII, retention, and deletion of user data. Zep aims to solve these challenges. Zep and its Python and Javascript client libraries have been open-sourced under the Apache License. Learn more and contribute: - Zep server: https://github.com/getzep/zep - Python SDK: https://github.com/getzep/zep-python - Javascript SDK: https://github.com/getzep/zep-js Daniel & Sharath
7 points · Open discussion

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.