HN user
Founder, Zep. ML, robots, startups.
Graphiti is free and open source. It's MCP server works with any MCP client, from Cursor to Claude, too...
Graphiti MCP has tens of thousands of users. They deploy it to their desktops, servers, you name it. And for many different use cases: B2B, B2C, and personal use.
More here: https://github.com/getzep/graphiti
Source: me, one of the authors of Graphiti :-)
iirc, Go intentionally randomizes map ordering for just this reason.
Thank you! Zep, our commercial memory service, utilized Graphiti as it's internal memory store.
There are definitely potential security issues with memory for coding agents, which apply to not only Cursor but also Windsurf. Looking forward to more research in this area.
I used Claude 3.7 Sonnet for the Cursor Agent when building the demo. Happy to hop on a call to walk through your experience, as I'm surprised the agent performed so poorly. daniel AT getzep.com
We built Graphiti's MCP server for many different use cases. It's a great enhancement to Cursor, but may not offer significant value for your use case. No offense taken.
Correct. You can provide more granular Entity Types: https://github.com/getzep/graphiti/blob/dbe21a1975b0747cd450...
Totally not Cursor-specific. Any MCP Client can be used. You may want to use different entity types that make more sense for your use case: https://github.com/getzep/graphiti/blob/dbe21a1975b0747cd450...
Graphiti MCP can recall more than just preferences and coding styles. Application specifications and evolution of these may be stored. For any non-trivial application, config files would likely be a misfit for this use ase.
You can read more about using Graphiti in your own projects here: https://help.getzep.com/graphiti/graphiti/overview
Thank you!
The MCP server will work with any MCP client.
Graphiti uses OpenAI (or other LLMs) to build the knowledge graph. Setting up the MCP server is fairly straight forward: https://github.com/getzep/graphiti/tree/main/mcp_server
There's also a Docker Compose setup: https://github.com/getzep/graphiti/tree/main/mcp_server#runn...
The Cursor MCP setup is also simple:
```{ "mcpServers": { "Graphiti": { "url": "http://localhost:8000/sse" } } }```
Correct. The Graphiti MCP server, with the help of the agent, stores and retrieves preferences and requirements automatically without requiring rule changes.
I'm not actually sure. Using Cursor Rules, you may be able to instruct the agent to be explicit as to which project a memory is related to. And do the same with retrieval i.e. tell the agent to rerank search results by distance from the project node. The Tools are all there for the agent to use. Compliance likely depends on the Cursor Rules and the model used.
You can override the default OpenAI url using an environment variable (iirc, OPENAI_API_BASE). Any LLM provider / inference server offering an OpenAI-compatible API will work.
You may want to take a look at Graphiti, which accepts plaintext or JSON input and automatically constructs a KG. While it’s primarily designed to enable temporal use cases (where data changes over time), it works just as well with static content.
https://github.com/getzep/graphiti
I’m one of the authors. Happy to answer any questions.
The study makes clear the water findings are inconclusive.
The PlasticList site explores safety levels, including a discussion of aggregate levels across products and chemicals. It’s an interesting but frustrating read.
You could achieve this with a single graph. Graphiti has a "message" EpisodeType that expects transcripts in a "<user>: <content>" format. When using this EpisodeType, Graphiti pays careful attention to "users," creating nodes for them and maintaining "fact" context for each user subgraph.
"Facts" shared across all users will also be updated universally. Alongside Graphiti's search, you'd be able to use cypher to query Neo4j to, for example, find hub nodes (aka highly-connected nodes), identifying common beliefs.
More here: https://help.getzep.com/graphiti/graphiti/adding-episodes
Pleasure! We'd love feedback + suggestions should you try it out.
Hey HN! We're Paul, Preston, and Daniel from Zep. We've just open-sourced Graphiti, a Python library for building temporal Knowledge Graphs using LLMs.
Graphiti helps you create and query graphs that evolve over time. Knowledge Graphs have been explored extensively for information retrieval. What makes Graphiti unique is its ability to build a knowledge graph while handling changing relationships and maintaining historical context.
At Zep, we build a memory layer for LLM applications. Developers use Zep to recall relevant user information from past conversations without including the entire chat history in a prompt. Accurate context is crucial for LLM applications. If an AI agent doesn't remember that you've changed jobs or confuses the chronology of events, its responses can be jarring or irrelevant, or worse, inaccurate.
## Zep’s Suboptimal Fact Pipeline
Before Graphiti, our approach to storing and retrieving user “memory” was, in effect, a specialized RAG pipeline. An LLM extracted “facts” from a user’s chat history. Semantic search, reranking, and other techniques then surfaced facts relevant to the current conversation back to a developer for inclusion in their prompt.
We attempted to reconcile how new information may change our understanding of existing facts:
Fact: “Kendra loves Adidas shoes”
User message: “I’m so angry! My favorite Adidas shoes fell apart! Puma’s are my new favorite shoes!”
Facts:
- “Kendra used to love Adidas shoes but now prefers Puma.”
- “Kendra’s Adidas shoes fell apart.”
Unfortunately, this approach became problematic. Reconciling facts from increasingly complex conversations challenged even frontier LLMs such as gpt-4o. We saw incomplete facts, poor recall, and hallucinations. Our RAG search also failed at times to capture the nuanced relationships between facts, leading to irrelevant or contradictory information being retrieved.
We tried fixing these issues with prompt optimization but saw diminishing returns on effort. We realized that a graph would help model a user’s complex world, potentially addressing these challenges.
We were intrigued by Microsoft’s GraphRAG, which expanded on RAG text chunking with a graph to better model a document corpus. However, it didn't solve our core problem: GraphRAG is designed for static documents and doesn't natively handle temporality.
So, we built Graphiti, which is designed from the ground up to handle constantly changing information, hybrid semantic and graph search, and scale:
- Temporal Awareness: Tracks changes in facts and relationships over time. Graph edges include temporal metadata to record relationship lifecycles.
- Episodic Processing: Ingests data as discrete episodes, maintaining data provenance and enabling incremental processing.
- Hybrid Search: Semantic and BM25 full-text search, with the ability to rerank results by distance from a central node.
- Scalable: Designed for large datasets, parallelizing LLM calls for batch processing while preserving event chronology.
- Varied Sources: Ingests both unstructured text and structured data.
Graphiti has significantly improved our ability to maintain accurate user context. It does a far better job of fact reconciliation over long, complex conversations. Node distance reranking, which places a user at the center of the graph, has also been a valuable tool. Quantitative data evaluation results may be a future ShowHN.
Work is ongoing, including:
1. Improving support for faster and cheaper small language models.
2. Exploring fine-tuning to improve accuracy and reduce latency.
3. Adding new querying capabilities, including search over neighborhood (sub-graph) summaries.
## Getting Started
Graphiti is open source and available on GitHub: https://github.com/getzep/graphiti.
If you try it, we'd love to hear your thoughts, questions, and experiences. Please also consider contributing!
Running neo4j on reasonable hardware (& depending on graph size), approximately 70% of the latency is calling OpenAI's embedding API. We've seen latency up to 750ms, for just the 3rd-party API call. :-/
As a result, we host embedding models on rented GPUs and get a P90 latency of 10ms.
Something worth noting is that the parent comment refers to using Cursor, not ChatGPT/Claude.ai. The latter are general-purpose chat (and, in the case of ChatGPT, agentic) applications.
Cursor is a purpose-built IDE for software development. The Cursor team has put a lot of research and sweat into providing the used LLMs (also from OpenAI/Anthropic) with:
- the right parts of your code
- relevant code/dependency documentation
- and, importantly, the right prompts.
to successfully complete coding tasks. It's an apple and oranges situation.
We extensively use vLLM's support for Outlines Structured Output with small language models (llama3 8B, for example) in Zep[0][1]. OpenAI's Structured Output is a great improvement on JSON mode, but it is rather primitive compared to vLLM and Outlines.
# Very Limited Field Typing
OpenAI offers a very limited set of types[2] (String, Number, Boolean, Object, Array, Enum, anyOf) without the ability to define patterns and max/min lengths. Outlines supports defining arbitrary RegEx patterns, making extracting currencies, phone numbers, zip codes, comma-separated lists, and more a trivial exercise.
# High Schema Setup Cost / Latency
vLLM and Outlines offer near-zero cost schema setup: RegEx finite state machine construction is extremely cheap on the first inference call. While OpenAI's context-free grammar generation has a significant latency penalty of "under ten seconds to a minute". This may not impact "warmed-up" inference but could present issues if schemas are more dynamic in nature.
Right now, this feels like a good first step, focusing on ensuring the right fields are present in schema-ed output. However, it doesn't yet offer the functionality to ensure the format of field contents beyond a primitive set of types. It will be interesting to watch where OpenAI takes this.
[0] https://help.getzep.com/structured-data-extraction
[1] https://help.getzep.com/dialog-classification
[2] https://platform.openai.com/docs/guides/structured-outputs/s...
PCA performs horribly on non-linear data.
Zep AI (YC W24) | Developer Advocate | https://www.getzep.com | Full-time | SF Bay / Remote US-only
Apply at: https://jobs.gem.com/zep
Zep is building the long-term memory layer for the LLM application stack. With a fast growing open source community and recently launched cloud service, we're seeking a developer relations engineer to accelerate adoption among developers and help shape our roadmap.
In this highly visible role, you'll engage with the developer community across multiple channels - writing technical content, delivering presentations, creating sample apps/demos, and fielding inquiries. Working directly with our founder + engineering team, you'll help steer our product strategy.
Zep is funded by Y Combinator, Engineering Capital, and angels such as Guillermo Rauch (Vercel).
We use Ellipsis across most of our repos. PR titling and summaries are great and definitely reduce the cognitive load for both code contributors and reviewers. Reviews are also a good first line of defense for code quality, catching issues human reviewers haven't caught. Though on occasion it's also a little overly pedantic or confused. I guess not unlike us humans at times ;-)
While not as pretty (and mobile-friendly) as the original link, the calculators below support modeling LoRA-based training, alongside full finetuning.
A fun browser-based game for practicing your VI keyboard skillz. Come for the game, enjoy the 80's neon fashion and pixel art font.