🎥 This Open Source Repo Just Solved Claude Code's #1 Problem

Graphify just solved Claude Code's memory problem. It's able to turn any repository and turn it into a wild knowledge graph just like the one you see here. And in the process, it allows Claude Code to give you more accurate answers at a fraction of the token costs. It's able to do this by traversing your entire code base, mapping all the connections, and discerning the why behind the connections. And the best part is, it's also open source and completely free. And so today, I'm going to show you how you can get this working yourself and what's actually going on under the hood so you can start leveraging it right away. So Graphify came out a couple months ago. It's at nearly 60,000 stars, and what it does is it allows your AI coding assistant doesn't have to be Claude Code, but that's what we're using today to map your entire project, code, docs, PDF, images, and videos into a knowledge graph that you can query instead of grepping through the files. So we are able to take Graphify and point it at any sort of repo we want, and it creates this sort of knowledge graph. The reason we care about this is when we create a knowledge graph, it allows Claude Code to more easily answer questions about that repository because everything's already mapped out. It's very clear how A connects to B, how B connects to C, and why those connections matter. This is in contrast through grepping through files, which is how AI coding assistants like Claude Code normally work. Kind of a simplistic analogy, but it's as if it's just doing control F and trying to search for it versus having a clearly mapped out path of how everything's going, right? This gives Claude Code a map, while grepping through files doesn't at all. So because of that, it costs less tokens to get more accurate answers with something like Graphify. Now, how significant are those token savings? Well, some people are claiming up to 70x, which I found to be a little on the high side, and as you'll see when we demo it today, it's a bit lower than 70x, but still significant. So that's the why you should care. Now, let's talk about how it actually works. How do we go from a code base to some sort of knowledge graph like this, which looks very, very similar to something like a graph rag knowledge base. Are they the same? How's this related to RAG? We'll talk about that. Well, the way it works is through three different passes. On the first pass, we are looking at the code structure, and this is completely free. Everything you see right here, this is just through pass one. This is deterministic. This isn't AI doing a guessing game. It is literally going through the code itself and saying, "This piece of code relates to the second piece of code." And that's literally how the code base is written out. These are established connections. As it says here, a tree-sitter parses your code files and extracts classes, functions, imports, call graphs, and inline comments. This runs locally with no LLM involved. On pass number two, it's looking at video and audio if those files exist at all, and if they do exist, they're going to be transcribed with faster-whisper. And so, once they're actually broken down into text, they will also be injected into the knowledge graph. Lastly, it does a third pass on docs, papers, and images. So, if your code base includes things that isn't true code, whether that's just like PDF files, documentations, images, whatever, this gets hit on pass number three. And this is where the large language model actually comes in and does some sort of like semantic analysis. AKA, what does this document actually mean, and where should it fit in this larger knowledge graph? This third pass is kind of similar without true embedding to what a RAG system does. Once it does all that, it then begins to create the actual knowledge graph itself. It goes into a little bit more technical detail in here, but all of you need to understand is it's going to create nodes, which are these little circles, right? Each one of these circles is a node. We then have edges, which are the line between two nodes, two things that are connected, and then communities. Communities are simply large groupings of nodes that are similar in nature. What you see here are 486 communities. So, that's kind of the overview of how the data is actually extracted and turned into a graph. And remember, we care about turning into a graph because for all intents and purposes, it's a map to Claude code, so it can more quickly answer questions. Now, you probably have a few questions at this point. One, what if there is no code structure? What if I'm pointing at a repository full of markdown files? It's just like a bunch of documents that I want to create a knowledge graph of, and I don't want to go full rag. Can I do that? Yes, in fact, you can actually turn it into an Obsidian vault through Graphy. We'll talk about that a little bit at the end. The second question you probably have is yeah, this actually does look super similar to something like Graph rag. What's actually the difference, and when should I use one or the other? Well, the biggest difference between Graphy and a graph rag system like light rag or rag anything or Microsoft graph rag is really going to be the embeddings, right? Graphy isn't using any embedding system whatsoever. The second biggest difference is the use cases. So, Graphy is best and we get the most out of it when we're talking about code bases. If we see some sort of huge repo, whether it's a new one or one we've been working on, and we want to figure out how it's wired, Graphy is perfect for that. Graph rag on the other hand is great for something that's more un structured. Let's say you have tens of thousands of documents that are all PDF files or markdown files, and you just want to ask about them. You know, imagine they're all policy documents, and you're asking like, "What does the policy say about X?" Right? It could be anywhere amongst any of these documents that aren't necessarily connected. It's very unstructured. That's where Graph rag or really any rag system shines. That being said, the division between those two here is kind of murky because, like I mentioned on that third pass, we can kind of do that with Graphy. It's almost like a rag light system in that sense. So, that's what Graphy is, how it works, and why you should care. Now, let's talk about actually installing this thing and using it for real. But before we jump into that demo, a quick word from today's sponsor, me. So, not too long ago, I released the Claude code masterclass, and it is the number one way to go from zero to AI dev, no matter your technical background. This course gets updated weekly, and it also includes additional masterclasses like the Codex masterclass and the Claude OS masterclass. So, if you're someone who wants to take this a little more seriously, definitely check it out. You can find it inside of Chase AI Plus. There is a link in the pinned comment. So, installing Graphy is relatively simple. We have a few prerequisites as well as instructions for how to install it. If you're using Claude Code, I suggest you make it very easy on yourself. Just go to the Graphy GitHub link. I'll put that down below. Copy it, paste it into Claude Code, and just tell it, "Hey, install Graphy for me." But, if you want to do it manually, you can just follow the steps as they are laid out. And again, Graphy is platform agnostic and it works with any coding agent out there. And once you have Graphy installed, the next question becomes, "Okay, how do I use this? What are the commands?" Well, there are quite a few commands. And there's so many commands, in fact, you are not going to remember any of these. Luckily, when you install Graphy, it's going to come with a Graphy skill. The skill is going to teach Claude Code how to use Graphy and when it should use which commands depending on the natural language you use. So, that being said, I suggest you take a look at the GitHub repo, somewhat familiarize yourself with what is possible because there is a lot, but understand you don't have to have this memorized. Claude Code understands what to do. But, there are a few we should be aware of. If I do {forward-slash} Graphy, that's going to run the whole thing on whatever directory I'm currently on. There are also Graphy commands for querying the knowledge graph. So, if I do Graphy query or Graphy explain, it's going to explicitly tell Claude Code or whatever coding agent you're using to, "Hey, take a look at the knowledge graph when you answer this question. Don't be lazy and just try to answer it on your own." Furthermore, we have commands to make sure it's always on. So, if I do Graphy Claude install, that means it's always going to use Graphy to answer the questions. I don't have to be explicit. It literally becomes a hook. And there are some other interesting flags like the Obsidian flag, which will with one command create an entire Obsidian vault for you and fill it with whatever Graphy comes up with. But again, remember the skill is installed. So, if you ever get confused about what makes sense, just ask Claude Code. It will understand. So, now let's actually run this. For the demo, we are going to be pointing Claude Code at Open Design, which is a relatively large code base. If you've never used Open Design, it's essentially Claude Design, but open sourced. So, I've cloned it on my machine, and I'm going to open Claude Code inside that directory. So, we're inside the directory, and all I'm going to do is /graphify and then {dot} and it's now going to run graphify on this entire folder. So, after running for 6 minutes, this is what we got. It took a look at 203 files. It got 1,907 nodes, 3,447 edges, and 109 communities, and output tokens was just under 120K. So, it lists the god nodes. The god nodes are pretty much like the most prominent nodes, the most prominent connections inside whatever it traversed. We have surprising connections I didn't expect, and suggested questions. So, if we want to take a look at the graph, I can say, "Go ahead and bring up the graph for me." So, here's a look at the knowledge graph it built, and you can kind of see the communities. There it created 109 communities, and that's really just all of these clusters. As we scroll in on them, we can see the nodes, which are the actual dots, and then the edges are the connections between them. When I click on the node, you can see over here on the top right, it's type, so it's a code node, its community, its source, as well as its neighbors. But remember, as cool as this visualization is, and it does look neat, the real value here isn't the knowledge graph. Like this is cool looking, but the actual value is the fact that now we have handed Claude Code a map to the Open Design repository. And I And I can now ask questions about it and get accurate responses. So, what we'll test now is we'll ask it a a about something to do with the repo, and we're going to have it use graphify, so have it actually use the knowledge graph, and then we'll ask pretty much the same question not using graphify. So, just have it like grep the answer, and we'll take a look at what the token difference looks like. So, to take a look at the token difference with and without graphify, we're going to ask the same question to Claude Code about the repo. The first one is, "Trace how a design request flows from the web app to a coding agent and back." So, we're trying to understand how this application actually works. And in the first tab, we're going to say, "Use graphify." And in the second tab, with the same question, we're saying, "Do not use graphify." So, we can see the graphify skill being loaded right away, and then we can see commands like graphify query asking the question we just gave Claude Code. Over here on the non-graphify side, we see that Claude Code has spawned two explore agents to take a look at the codebase, and right off the rip, we've already used 100,000 tokens between them. Now, in terms of the actual answers we got, they were the same. They both identified how this app actually works, but with the non-graphify version, we needed to run those explore agents, so we were looking at about 150,000 tokens, give or take, with the explore agents, plus an additional 50,000 tokens on the main session. So, you know, about 200,000 tokens total versus over here on the non-graphify version, we only used about 80,000. So, about 40% of the total cost of the non-graphify, which is significant savings. Now, since this non-graphify version has now sort of crawled through the repo itself, if I ask additional questions, the token cost won't be as off. However, since we have the knowledge graph built, whenever we want to ask questions about it via graphify, well, we're not going to have to deal with that token cost of going through it again and again, and that kind of leans into the whole memory piece. Like, we've built it out already, we can always query it for cheap. Now, the question then becomes, if this is a living, breathing repo, what happens when we make updates to the repo? Will this knowledge graph also be updated? Well, the answer is yes. We see this spelled out in the workflow in the readme. If we run graph if I hook install, it's going to auto rebuild after each commit. And that is the AST only. There's no API cost associated with that. It's literally just looking at what actually changed, what is it now connected to, and it rebuilds that tree, but it's at no cost to you. Like this is all done in a determinate deterministic way. Furthermore, this also works in a team setup. So if you had two devs working on the same repo in parallel, it also deals with that situation. So in the end, you get this persistent yet living map of whatever repo you want that you can give the cloud code so you can get more efficient answers. And lastly, we hinted at it a little bit here with the Obsidian flag, we can do all of this with a repo that is not code-based. It's a little bit different, and we are actually going to do that in another video where we drill down on Graph AI and Obsidian, and sort of what that connection looks like. But just understand, we aren't pigeonholed into code only. This is a pretty flexible tool. But that is where I'm going to leave you guys for today. I think this is a really cool tool, and when you look at the spectrum of sort of these like memory adjacent applications and plugins that we can use alongside things like cloud code and codex, I think Graph AI sort of falls somewhere in between Obsidian and a true rag system. And I think that's great. The more options we have, the more tools we have at our disposal, the better we can choose the right one for the job. We don't have to only use Obsidian, you know, we might not just be doing something in markdown. And we don't have to go crazy and generate some huge rag infrastructure. This is again, it's a cool little middle ground that I think is worth exploring. So as always, let me know what you thought. Make sure to check out Chase AI Plus if you want to get your hands on the cloud code masterclass. Speaking of Obsidian, I'm actually going to be running a free live webinar next week about Obsidian and cloud code. I'll put a link to that down there as well. And besides that, I'll see you around.