Live Demo: https://cognee-hackathon-psi.vercel.app
Built for: WeMakeDevs × Cognee Hackathon 2026
Track: Open Source Build Track + Cognee Cloud Track
I was working on a project last year i was working as an full stack developer intern at Prodigy Infotech. There was a function that rejected any order over $500. No comment. No ticket. Just a hardcoded number sitting there.
I asked three people why it existed. Nobody knew. The person who wrote it had left the company two years ago. I spent half a day searching through old Slack messages and eventually found a single sentence in a six-month-old email thread. The finance team had asked for it to reduce fraud. That was it.
Half a day. For one number.
This happens every single day in companies around the world. Big companies with years of code that nobody fully understands anymore. Junior developers are scared to change anything because they don't know what will break. Senior developers waste hours answering the same questions over and over. And when someone finally leaves, they take years of context with them.
Tools like Copilot and Cursor are great. But they only look at the files you have open right now. They have no memory. They don't know why something was written. They can't tell you what breaks if you change it.
That gap is what Codekeeper tries to close.
Codekeeper gives a legacy codebase a persistent memory. You point it at a GitHub repository or a local folder. It reads every source file, every git commit message, and every piece of documentation. Then it builds a knowledge graph a web of connected information about your code.
After that, you just ask any questions in plain English.
And it answers. Not by guessing. By actually finding the information in the code, the commits, and the docs — and connecting the dots.
When you load a repository, three things get remembered:
Source code — Every Python file gets read and stored. The function names, the logic, the comments, all of it goes into memory.
Git history — Every commit message from the last 20 commits gets stored too. This is the part that most tools completely ignore. Commit messages are where developers explain why they made a change. That context is gold.
Documentation — Every README and markdown file gets read. This captures the intended design and high-level decisions.
All of this goes through Cognee's memory system. Cognee doesn't just dump it into a flat list — it builds a knowledge graph. That means it understands relationships. It knows that this function is called by that module. It knows that this commit changed that file. It can trace connections across the whole codebase.
When you ask a question, Cognee searches this graph using something called GRAPH_COMPLETION. This is different from a simple keyword search. It actually follows the connections in the graph to find the most relevant answer, even if the exact words you used aren't in the code.
Codekeeper uses both Cognee Cloud and Cognee's core functions together:
- Cloud — All memory data (the knowledge graph, code, commits, and docs) lives in Cognee Cloud, so the data is stored safely and can be accessed anytime without managing a separate database.
- Functions — On top of that cloud storage, the app calls Cognee's core functions to actually read and write memory:
remember()to save data,search()withGRAPH_COMPLETIONto recall answers,improve()to get smarter from feedback, andforget()to wipe a dataset clean.
In short: the cloud is where the memory lives, and the functions are how the app reads from and writes to that memory.
This project uses all four of Cognee's core memory operations:
Remember — When you load a codebase, every file, commit, and doc is passed to cognee.remember(). This stores everything in the knowledge graph.
Recall / Search — When you ask a question, cognee.search() with GRAPH_COMPLETION searches the graph and returns an answer. The same session ID is passed throughout your chat session, so Cognee remembers what was discussed earlier in the conversation. Follow-up questions actually work.
Improve — Every answer has thumbs up and thumbs down buttons. When you click them, your feedback gets written back into memory and cognee.improve() is called. The system gets smarter the more you use it on a specific codebase.
Forget — When you're done with a codebase, or when code gets deleted, you click "Forget this codebase." This calls cognee.forget() and wipes that dataset from memory completely. No stale information hanging around.
Chat Interface — Ask anything about the codebase. The chat keeps context across your whole session so you can ask follow-up questions naturally.
Impact Analysis — Type a function name and see what else in the codebase depends on it. Before you change something, know what you're touching.
Knowledge Graph View — See a visual map of the concepts Cognee extracted from your code. Nodes are color-coded by type green for source code, blue for git history, purple for documentation.
GitHub URL Support — Paste any public GitHub repo URL. No need to clone it yourself. Codekeeper clones it temporarily, ingests it, then cleans up.
Feedback Loop — Thumbs up or thumbs down on any answer. This directly feeds into Cognee's memory so answers get better over time for your specific codebase.
Forget Button — One click to remove everything from memory. Clean slate, no leftover data.
Backend
- Python + FastAPI
- Cognee 1.2.2 with the full memory lifecycle API
- Cognee Cloud for hosted memory and graph storage
- GitPython for reading commit history
- fastembed for local vector embeddings (no extra API key needed)
- httpx for Cognee Cloud API calls
Frontend
- Next.js 16 with TypeScript
- Tailwind CSS + shadcn/ui for the interface
- React Flow for the knowledge graph visualization
Infrastructure
- Backend deployed on Render
- Frontend deployed on Vercel
- Cognee Cloud for memory storage ($2.50 per million tokens — our $37 in credits covers thousands of ingestion runs)
Prerequisites: Python 3.11+, Node.js 20+, a Gemini or OpenAI API key
# Clone the repo
git clone https://github.com/SahilArate/cognee_hackathon-.git
cd cognee_hackathon-
# Backend setup
cd backend
python -m venv venv
.\venv\Scripts\activate # Windows
source venv/bin/activate # Mac/Linux
pip install -e .
# Copy the env template and fill in your values
cp .env.template .env
# Edit .env and add your API key
# Start the backend
uvicorn app.main:app --reload# Frontend setup (new terminal)
cd frontend
npm install
cp .env.local.example .env.local
# Edit .env.local and set NEXT_PUBLIC_API_URL=http://localhost:8000
npm run devOpen http://localhost:3000, paste a GitHub repo URL or local path, and start asking questions.
# LLM Provider (Gemini recommended for free tier)
LLM_PROVIDER=gemini
LLM_MODEL=gemini/gemini-2.5-flash
LLM_API_KEY=your_key_here
LLM_ENDPOINT=https://generativelanguage.googleapis.com/v1beta
# Embeddings (local, no key needed)
EMBEDDING_PROVIDER=fastembed
EMBEDDING_MODEL=BAAI/bge-small-en-v1.5
EMBEDDING_DIMENSIONS=384
# Cognee Cloud (optional, enables cloud mode)
COGNEE_API_KEY=your_cognee_cloud_key
COGNEE_CLOUD_BASE_URL=https://tenant-xxx.aws.cognee.ai
COGNEE_CLOUD_MODE=true
# Storage paths
COGNEE_SYSTEM_ROOT=/tmp/.cognee_system
COGNEE_DATA_ROOT=/tmp/.cognee_data
# Server
ENABLE_BACKEND_ACCESS_CONTROL=false
COGNEE_SKIP_CONNECTION_TEST=true
FRONTEND_ORIGIN=http://localhost:3000
The best way to see this in action is to load a real codebase and ask a question that no keyword search could answer.
Try this: load any Python project that has some git history. Then ask "why does [some function] work this way?" If the answer is in a commit message or a comment from two years ago, Codekeeper will find it.
That moment — when you get an answer that you would have spent hours searching for — is what this project is about.
Building this taught me a lot about how Cognee actually works under the hood. The difference between a flat vector search and a graph-based search is real and significant. When you ask about a function, Cognee doesn't just find similar-looking text — it traverses actual connections in the graph to find related entities.
The session memory feature was also more interesting than I expected. Passing a session_id to Cognee's search means the conversation actually has context. You can ask "tell me more about that" and it works, because Cognee remembers what "that" refers to.
The improve() function is the one I'm most excited about for the future. Right now it re-processes the dataset when feedback is given. Over time, on a codebase that a team uses every day, this could genuinely make the answers much better.
As required by the hackathon rules — I used AI assistants for some parts of this project and I'm declaring it here.
Specifically, I used AI help for: looking up Cognee's API signatures, debugging some FastAPI and TypeScript errors, and getting suggestions on how to structure certain parts of the code.
The problem idea, the architecture decisions, what features to build, how to use Cognee's memory lifecycle, the overall project direction, and all the final calls — those were all mine. I also reviewed and understood every single line of code before it went in. Nothing was blindly copied.
I'm Sahil Arate, a developer who got frustrated searching for why old code exists and decided to build something about it.
If this project interests you, feel free to reach out or open an issue.