GitHits beta 0.9 - Give your AI coding agent access to open-source code

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

Add a comment

Replies

Best

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:

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:

npx githits@latest init

It installs the CLI and connects GitHits to Claude Code, Codex, Cursor, or any MCP-compatible agent. Or sign up using .

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!

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:

The best way to judge it is to just test it out. Setup is one command:

npx githits@latest init

It connects GitHits to Claude Code, Codex, Cursor, or any MCP-compatible agent. Or sign up here:

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.

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 ๐Ÿ™Œ

ย 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.

This app is seriously helpful and turns your coding agent in a top tier senior engineer. When I am introducing a new pattern or library in my code, I always think to find real battle tested implementations first from GitHits. Eventually you realize just letting a coding agent vibe out consequential and high leverage code is just plain dumb and irresponsible.

Thanks,! Let us know how we could make GitHits even better!

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?

ย 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.

We are often asked how GitHits compares to Context7, so here is the comparison:

GitHits and Context7 are both available as MCP servers and CLIs that provide external context to AI coding agents. Both help fill gaps in model knowledge by retrieving information about libraries and dependencies.

Context7 is centered on version-aware library documentation.

GitHits also retrieves version-aware library documentation, while providing access to dependency source code, package metadata, and implementation examples from open-source repositories.

Capability

GitHits

Context7

Version-aware documentation

โœ…

โœ…

Open-source implementation examples

โœ…

โŒ

Version-aware source code search & navigation

โœ…

โŒ

Version-aware package metadata

โœ…

โŒ

MCP server

โœ…

โœ…

CLI

โœ…

โœ…

Documentation

Both tools retrieve documentation for specific library versions, allowing agents to work with current APIs instead of relying solely on model knowledge.

Context7

Context7's workflow consists of resolving a library and retrieving documentation for it. The results contain relevant documentation sections together with code snippets and explanatory text from the indexed documentation.

Tools

ctx7 library react "How to clean up useEffect with async operations"

ctx7 docs /facebook/react "How to clean up useEffect with async operations"

GitHits

GitHits provides version-aware documentation together with source code, package metadata, and implementation examples. Agents can search documentation, browse available pages, and read individual documentation pages for a specific package version.

Tools

npx githits@latest search "middleware" --in npm:express --source docs

npx githits@latest docs list npm:

npx githits@latest docs read <page-id>

The same search command can also search source code or symbols by changing the --source option.

Implementation Examples

Both products return code, but the source of that code is different.

Context7

Context7 returns code snippets from indexed documentation. These snippets accompany the relevant documentation and illustrate how an API is intended to be used.

Tools

ctx7 docs /facebook/react "How to clean up useEffect with async operations"

GitHits

GitHits retrieves implementation examples from open-source repositories. Rather than extracting snippets from documentation, it searches real projects for implementations matching a natural-language query and links back to the original source.

Tools

npx githits@latest example "how to use express middleware"

npx githits@latest example "jwt authentication middleware" --lang typescript

Documentation snippets help explain an API. Implementation examples show how similar problems are solved in real applications.

Source Code

Context7

Context7's interface is centered on documentation retrieval. Agents resolve libraries and retrieve documentation, including code snippets and explanatory text from the indexed documentation.

GitHits

AI coding agents already use search, file listing, file reads, and grep to understand your local codebase. GitHits extends those same capabilities to dependency source code, allowing agents to inspect implementations without cloning repositories or leaving their existing workflow.

Tools

npx githits@latest search "Router" --in npm:express --source code

npx githits@latest search "RequestHandler" --source symbol

npx githits@latest code files npm:express lib/

npx githits@latest code read npm:express lib/express.js --lines 1-80

npx githits@latest code grep npm:express "Router" lib/ --ext js

These tools allow agents to search indexed code and symbols, inspect repository structure, read source files, and perform deterministic grep across dependency source code.

Package Metadata

Context7

Context7 retrieves library documentation. Its public interface is centered on documentation rather than package inspection.

GitHits

GitHits provides package inspection commands for dependency analysis and upgrade planning.

Tools

npx githits@latest pkg info npm:express

npx githits@latest pkg vulns npm:

npx githits@latest pkg deps npm:

npx githits@latest pkg changelog npm:express --from 4.18.2 --to 5.2.1

npx githits@latest pkg upgrade-review npm: --to 4.4.3

These commands allow agents to inspect package metadata, dependency graphs, known vulnerabilities, changelogs, release notes, and factual upgrade information for specific package versions.

Overall

GitHits and Context7 both help coding agents retrieve information that is not reliably available from model knowledge alone.

Context7 is centered on version-aware library documentation. The workflow is straightforward: resolve a library, then retrieve the relevant documentation.

Question
    โ†“
Resolve library
    โ†“
Read documentation

GitHits also retrieves version-aware documentation, but exposes several retrieval primitives instead of a single workflow. This allows agents to adapt their retrieval strategy to the question they are trying to answer.

Question
   โ”œโ”€ Search documentation
   โ”œโ”€ Search source code
   โ”œโ”€ Search symbols
   โ”œโ”€ Find implementation examples
   โ””โ”€ Inspect package metadata

For example, if an agent needs to answer "Why does Express strip this header?", it might search the documentation first, then inspect the Express source code to trace the implementation. If the behavior changed between releases, it can also review the package changelog.

The products overlap in documentation retrieval but differ in the range of information they make available to an agent. Depending on the task, they can also complement each other.

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.

Thanks,ย 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?

ย 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.

Congrats!

Thanks! Appreciate your support! ย 

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.

ย 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.

ย 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 ๐Ÿš€

ย 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.

ย 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.

12
Next