RepoBuddy
An open-source AI tool for understanding code repositories. It builds a code knowledge graph and combines it with large models to answer developers' questions about unfamiliar codebases, with answers accompanied by actual file paths.
Timeline (last 90 days)
RepoBuddy's workflow has three steps: shallow-clone the repository, build a knowledge graph with Graphify, and after graph retrieval hand the question to Gemma 4 to answer.
RepoBuddy uses `git clone --depth 1` to fetch only the latest commit, avoiding the time and disk overhead of the full history.
For each question, RepoBuddy first runs `graphify query` to return the relevant subgraph, then sends it along with the report to Gemma 4, and the prompt hard-requires answering only from the graph and giving file paths.
When `graphify query` returns exit code 4 (the question is too broad and no node matches), RepoBuddy falls back to answering from the report alone rather than erroring out.
To avoid concurrent graph-building races for the same repository, RepoBuddy maintains one `asyncio.Task` per repository protected with `asyncio.shield`, letting all callers share the same build result (request coalescing pattern).
Gemma 4 runs on Ollama Cloud by default (`gemma4:31b`); when the user selects the Gemini API but the call fails, the system automatically falls back to Ollama, and when both fail the error message lists both causes.
RepoBuddy's frontend is a static Next.js site hosted on Cloudflare Pages, and its API is FastAPI deployed on Render, because cloning repositories and running graphify require git and real processes that cannot be done in a pure edge environment.
In RepoBuddy's Beta cloud mode, Cloudflare Pages Functions query the Graphify Cloud-hosted MCP service directly, running the whole chain on Cloudflare, but only for repositories already indexed in the administrator's Graphify workspace.
The disk of a free Render instance is wiped on restart, so a repository whose graph was already built may disappear between two questions; the current handling is for the client to rebuild the graph and retry.
All Facts (9)
RepoBuddy's workflow has three steps: shallow-clone the repository, build a knowledge graph with Graphify, and after graph retrieval hand the question to Gemma 4 to answer.
50%UnverifiedRepoBuddy uses `git clone --depth 1` to fetch only the latest commit, avoiding the time and disk overhead of the full history.
50%UnverifiedFor each question, RepoBuddy first runs `graphify query` to return the relevant subgraph, then sends it along with the report to Gemma 4, and the prompt hard-requires answering only from the graph and giving file paths.
50%UnverifiedWhen `graphify query` returns exit code 4 (the question is too broad and no node matches), RepoBuddy falls back to answering from the report alone rather than erroring out.
50%UnverifiedTo avoid concurrent graph-building races for the same repository, RepoBuddy maintains one `asyncio.Task` per repository protected with `asyncio.shield`, letting all callers share the same build result (request coalescing pattern).
50%UnverifiedGemma 4 runs on Ollama Cloud by default (`gemma4:31b`); when the user selects the Gemini API but the call fails, the system automatically falls back to Ollama, and when both fail the error message lists both causes.
50%UnverifiedRepoBuddy's frontend is a static Next.js site hosted on Cloudflare Pages, and its API is FastAPI deployed on Render, because cloning repositories and running graphify require git and real processes that cannot be done in a pure edge environment.
50%UnverifiedIn RepoBuddy's Beta cloud mode, Cloudflare Pages Functions query the Graphify Cloud-hosted MCP service directly, running the whole chain on Cloudflare, but only for repositories already indexed in the administrator's Graphify workspace.
50%UnverifiedThe disk of a free Render instance is wiped on restart, so a repository whose graph was already built may disappear between two questions; the current handling is for the client to rebuild the graph and retry.
50%