Launching today
GitHits beta 0.9
Give your AI coding agent access to open-source code
137 followers
Give your AI coding agent access to open-source code
137 followers
GitHits gives coding agents access to the open-source code your app depends on. Get real implementation examples, dependency source navigation, package inspection and documentation. Agents can grep and read your codebase. They can't grep and read the open-source code your app depends on. That's where they start guessing, retrying, and looping. GitHits builds a version-aware index on demand. Agents can search, navigate, and inspect the code behind their dependencies. CLI: npx githits@latest init
Interactive
Free
Launch Team / Built With
GitHits beta 0.9
Hi Product Hunt! 👋
I’m Olli-Pekka, one of the co-founders of GitHits.
I've been a member of the open-source community for 15 years. I created opencv-python, which got 100M+ downloads while I maintained it as a side hustle. Fun fact: I’m from 🇫🇮, just like Linus Torvalds. 🙂
I noticed I kept giving the same advice to colleagues and friends when the docs were missing something. My go-to hack was simple: use GitHub search to find code that already solves the problem. It’s powerful, even though it only returns raw results rather than the answer in context.
I started building GitHits to bring that workflow to coding agents.
GitHits complements tools like Claude Code, Codex, Cursor, and other AI coding agents.
Those agents are great at navigating your local codebase. They can grep, search, and read files to understand how your application works.
The problem is that modern software doesn't stop at the repository boundary.
A large part of the system lives in frameworks, libraries, SDKs, and other open-source dependencies. Agents can usually see where your code calls into those dependencies, but they often can't navigate and inspect them in the same way. And even when an agent reads the docs, they only tell it what to call, not how it actually behaves. For that, you need the source.
GitHits gives agents access to:
Code examples based on real implementations from repositories, issues, discussions, and pull requests, linked back to the implementation code
Code navigation across packages and repositories: search, grep, file listing, and exact line reads without cloning
Package inspection for dependencies, vulnerabilities, changelogs, and upgrade changes
Documentation access across hosted docs and repository-backed docs
GitHits does this by building a version-aware index of open-source code on demand, usually in 10-20 seconds for an average repository.
GitHits is useful when an agent reaches the limits of the local repository.
That might happen during planning and research, when it needs to understand how a dependency works, what changed between versions, or how something has been implemented elsewhere. It also happens during implementation, when the agent starts retrying variations and exploring dead ends because the answer isn't in the local repository.
As developers, that's usually the point where we leave our own repository and start reading somebody else's.
What users say about GitHits:
Onni: Helping Claude Code to find undocumented APIs from the code
Rob: had a problem in my openusage v2 app - boom, perfect fix without guesses
Forever free tier available.
No trial period. Just create your account and connect your agent to GitHits.
Launch day special.
Everyone who signs up today gets 3x credits for 6 months. No strings, just more GitHits.
Setup is one command:
It installs the CLI and connects GitHits to Claude Code, Codex, Cursor, or any MCP-compatible agent. Or sign up using this link.
If you’re already using GitHits, let me know what you use it for, and how we can make GitHits even better.
We look forward to your brutally honest feedback and sincerely appreciate the support!
Really impressive backend work. Are you guys running the parsing/indexing entirely on your infra and serving it via API, or is there a local caching layer involved when we link it to Claude Code via MCP? Happy to support 🙌
GitHits beta 0.9
@vikramp7470 We are running indexing it fully on our infra. CLI and MCP are just make API calls to our backend. We have Rust-based indexing engine, Elixir based coordination layer and Python based agentic layer.
Building a version-aware index per release rather than scraping GitHub's default branch is the right call. Agents that can't inspect the exact version they depend on just hallucinate API signatures. We've hit this when agent-generated code breaks because docs described the wrong version. How does GitHits handle monorepos with independently versioned packages?
GitHits beta 0.9
@anand_thakkar1 That's indeed a complex problem, but we solved the monorepo issue with our custom crawler and indexer. There might be still raw edges and that's why there is the beta label. So many different ways of versioning software out there.
Congrats on the launch!
The "AI agent + OSS context" gap is real — most agents either hallucinate APIs or refuse to commit when they're unsure. Giving them grounded access flips that.
Question for you: how do you handle licensing exposure when the agent pulls from copyleft repos and the user is on a proprietary codebase? That's the piece I'd worry about if I were shipping this into a regulated team.
GitHits beta 0.9
@somdip_roy1 You can setup license filtering in the settings for the example generation. In strict mode we skip repositories with copyleft, unknown and missing license information.
@jlitola Smart default. The "skip unknown and missing" piece is the part most people would
get wrong — easy to only think about copyleft and forget that "no license file"
is the real legal landmine.
Quick follow-up: is strict mode opt-in or the default? In a regulated team I'd want
my devs on strict by default and have to consciously turn it off to widen the pool,
not the other way around. Curious how you landed on the default.
Following the launch — best of luck for today 🚀
GitHits beta 0.9
@somdip_roy1 We are defaulting to strict mode just so there won't be nasty surprises if you don't visit the settings. I'm also expecting us to put effort to harden things for the corporate settings later this year, and having org wide controls on things like allowed licenses.
@jlitola Strict by default + org-wide license controls is exactly where this needs to land
for regulated teams. The "no nasty surprises" framing is the right one, most
licensing issues are silent until they're loud, and silent-by-design beats
loud-by-design every time.
Have a great launch day 🙌 will be following along.
GitHits beta 0.9
Hi Product Hunt! 👋
I'm Juha, co-founder and chief architect of GitHits. I'm responsible for the indexing engine underneath, so I want to talk about the part you don't see.
The question I get more than any other is some version of this: my coding agent can already clone a repo, grep it, and search GitHub, so what is GitHits actually adding?
It's a fair question, and the honest answer is that scraping GitHub gives your agent raw results, not understanding. It clones whatever is at the top of the default branch and greps one repo at a time, treating code as text with no sense of what is worth trusting. And here's the part that surprises a lot of people: GitHub's own code search only covers a repository's default branch, so the older version you actually depend on usually isn't even searchable. That's fine for a quick lookup, but it falls apart the moment the problem gets specific.
What GitHits does instead is build a real, version-aware index. We fetch the actual source, parse it, turn it into structure, and keep that structure version by version, so your agent reads from something we already built rather than scraping and guessing in the moment.
People are usually surprised how much work that is. One small example: just figuring out which commit a version like 1.2.3 actually points to. There's no standard for how projects tag releases, so the part of our indexer whose only job is that is more than 700 lines, and we've rewritten it six times as we keep hitting new conventions in the wild. And that's before we've parsed a single line of the actual code.
And it isn't only code. We index documentation the same way, version by version, and combine it with the rest so your agent grounds itself in a balanced mix of code, tests, examples, and docs, instead of one slice it has to guess from.
I wrote up the full under-the-hood walkthrough here if you want the long version: https://githits.com/blog/what-it-actually-takes-to-index-open-source/
The best way to judge it is to just test it out. Setup is one command:
It connects GitHits to Claude Code, Codex, Cursor, or any MCP-compatible agent. Or sign up here: https://app.githits.com/signup
I built the indexing engine, so I'd genuinely love to hear where it works or breaks for you. Brutally honest feedback is the most useful kind.
Works great, I've been using Githits to explore implementation details from different libraries to ground my coding agent with real world examples. It's cool to point your coding agent towards an open source reference implementation that you know has already implemented what you want to implement.
GitHits beta 0.9
Thanks,@matti_ryttylainen Appreciate your kind words and all feedback you've provided along the way!
Giving a coding agent access to real open-source code is a smart idea. How does GitHits pick which repos or snippets are most relevant?
GitHits beta 0.9
@doganakbulut For snippets it's actually pretty involved. We run our own code index, so on top of standard ranking like BM25 we can use a bunch of code-specific signals for scoring. We also keep a separate document index for docs from canonical documentation sites. That lets us pull a balanced mix of function definitions, real usage examples, tests and related documentation, so the agent gets proper grounding, with each snippet linking back to the source it came from.
For picking which repos to pull from, right now we lean on a wide range of GitHub searches plus our own reranking. We're also building out a dedicated index for that part.