Connect your software factory or coding agent to a version-aware index of open-source code, documentation, and package data. Discover, use, debug, and maintain dependencies through one interface.
The infrastructure layer connecting agents to the open-source ecosystem.
Connect your agents through MCP, the CLI, or the API.
resolve_targetFind the right package or repository target.
githits resolve fastapi --prefer-kind repositoryranked targets to choose from
Resolve a package or repository name to ranked canonical targets before searching its code.
searchFind code by keywords or API names.
githits search "OAuth2PasswordBearer" --in pypi:fastapi --source coderanked hits with file, line range, enclosing symbol, and a matched snippet
Find code and symbols in a package or repository by keywords, API names, or quoted phrases. Narrow with inline filters such as kind:function or path:lib/.
grepMatch exact text or regex in code.
githits grep -F "sendFile" npm:expressfile:line matches, plus a cursor for the next page
Find exact text or regex matches across a repo or package. Results are deterministic and paginated, and can be scoped by path, glob, or file extension.
listBrowse source files.
githits list pypi:fastapi fastapi/securitya plain list of file paths
List the indexed files and paths in a repo or package, so agents can find the right file before reading it.
readRead versioned code by file, lines, or symbol selector.
githits read pypi:fastapi@0.141.1 fastapi/security/oauth2.py --selector OAuth2PasswordBearerthe source for the selected symbol
Read a source file, a focused line range, or a code symbol using a selector, at the exact version or git ref. It follows straight on from search and grep results.
diffCompare code changes between versions or refs.
githits code diff npm:express 4.21.2..5.2.1 --statrepository-wide changed files with line statistics
Compare source changes between package versions or repository refs.
resolve_targetFind the right documentation site target.
githits resolve express --prefer-kind siteranked targets to choose from
Resolve a documentation-site name to ranked canonical targets before searching its pages.
searchFind documentation sections by keywords.
githits search "useEffect cleanup" --source docs --in site:react.devmatching doc sections with a preview and a target to read next
Search a package's documentation, or a standalone docs site, by keywords. Hits point to the exact page and section.
grepMatch exact text or regex in documentation.
githits grep -F "next()" site:expressjs.commatching lines with page locations and read actions
Find exact text or regex matches in documentation, with matching lines and pages.
listBrowse documentation pages.
githits list site:expressjs.compage titles, each with a ready-made read command
List all available documentation pages for a package or docs site, ready for the read command. This is the same tool that lists source files.
readRead a page or section using a heading selector.
githits read 'https://expressjs.com/en/5x/api/express/' --selector expressjsonthe selected section as clean markdown
Read a documentation page or select a section by its heading ID using a selector. This is the same tool that reads source files.
pkg_infoCheck package health, adoption, and license.
githits pkg info npm:expressa one-screen summary (license, stars, monthly downloads, last publish, advisory counts)
Check a package's health and adoption at a glance: license, downloads, repository activity, publish age, and open advisories.
pkg_vulnsCheck known vulnerabilities and affected versions.
githits pkg vulns npm:lodash@4.17.20 --severity highadvisories with severity, the versions affected, and the version that fixes each one
Check current security advisories for a pinned version or the package's full history.
pkg_depsInspect direct and transitive dependencies.
githits pkg deps npm:express@5.2.1 --depth 2dependency counts and the resolved package list
Inspect what a package depends on: direct runtime dependencies with resolved versions, and optionally the transitive footprint.
pkg_changelogRead release notes and changelog history.
githits pkg changelog npm:next --from 15.0.0one entry per release with date, link, and notes
Get release notes and changelog history for a package or repository, either the latest entries or everything between two versions.
pkg_upgrade_reviewCheck security and dependency changes before upgrading.
githits pkg upgrade-review npm:next@14.2.0 --to 15.0.0advisories fixed, added, and still present, plus changelog and dependency changes
Compare two versions of a package before upgrading: vulnerabilities, release notes, deprecations, and peer and dependency changes. It reports facts only and leaves the decision to you.
Delegate research and example generation to GitHits. Our managed subagents handle the inference for you and are optimized for token efficiency and answer quality.
exampleGet a generated code example grounded in how other open-source projects do something. Prior art.
Cross-project sources produce a generated example
githits example "stream a large file upload to S3 with progress" --lang typescripta generated code example with links to its sources and their licenses
Adapt the example to your project and check the APIs against the package versions you use.
researchExperimental · Coming soon
Ask how a package or repository works. Get an answer with cited sources.
Search, grep, read produce an explanation with sources
githits research npm:express "How does Express handle errors passed to next()?"an explanation with cited sources, read commands, and a thread ID for follow-up questions
GitHits searches and reads the relevant code and documentation, then explains what it found. Ask follow-up questions in the same thread.
Open source powers modern software. GitHits brings source code, documentation, package releases, dependency graphs, and security advisories together so agents can inspect the versions they use, compare alternatives, and plan changes.
Browse the indexGitHits indexes 25,118,954,619 lines of open-source code across public repositories.
Including repositories that aren’t published to a package registry.
If a repository isn't indexed yet, GitHits indexes it on demand, in tens of seconds for small repositories and minutes for larger ones.
| Target | Stage | Progress |
|---|---|---|
| Checking what is indexing right now… | ||
| Target | TookTime from indexing start to fully searchable. |
|---|---|
| Loading recent completions… | |
Connect your coding agent or software factory through the CLI and MCP.
npx githits@latest initEquip your agents for greenfield development, brownfield maintenance, and modernization with code, documentation, and package data for the dependency versions they use or plan to adopt. Use the REST API to tailor retrieval and context to each workflow.
GitHits index
Connect your software factory or coding agent to a version-aware index of open-source code, documentation, and package data. Discover, use, debug, and maintain dependencies through one interface.
The Problem
Coding agents can inspect your repository. When the answer lives in dependency source, documentation, or version history, they may have to search or guess.
Your agent can inspect the files in your repository.
But much of the application’s behavior comes from public frameworks, SDKs, libraries, and transitive dependencies. When the answer lives inside one of those packages, searching the local repository often stops at the import or API call.
The agent can see how your application uses the package. It cannot necessarily see what the package does.
Search results and documentation often describe the latest release. Your project may use an older one.
Between versions, method names change. Configuration options move. Defaults, callback arguments, and lifecycle behavior can change too.
Without the source and documentation for the version in use, an agent may combine information from several releases into an answer that was never correct for any one of them.
A generated change may look natural while relying on an incorrect assumption about a dependency.
It might use an option that no longer exists, miss a required initialization step, misunderstand when a hook runs, or depend on behavior that changed between releases.
The mistake may be obvious immediately. It may also appear later, when a particular request, state transition, or edge case reaches that code.
When the agent cannot verify how a dependency works, it has to find another route.
It may search the web, inspect an installed package, clone another repository, try several changes, or ask the developer for help. Any of these can work, but the same investigation must be repeated for each package and version.
Guess > run > error > retry > burn
The Solution
Let your agents discover packages, understand code and documentation, learn from real-world usage, and evaluate dependencies and upgrades through one interface.
GitHits connects coding agents to the open-source supply chain. It gives the agents building and maintaining your applications one interface to public code, documentation, packages, and dependency information through MCP, the CLI, or the API.
A GitHits query identifies a package, repository, version, or ref. For a fixed version, GitHits maps it to a source commit and retrieves the code and documentation attached to that version.
When an agent reaches an unfamiliar API or dependency behavior, it can query GitHits from the coding tool it already uses. It can search for a symbol, read an exact file, inspect release changes, or find prior art in other public projects.
The results include the package version, repository, and source location. The agent can check what the dependency does instead of relying on a remembered API or documentation for another release.
GitHits complements the agent’s access to your local repository. It provides public open-source context without requiring access to your private source.
Your agent needs a way to add file uploads, background jobs, or another capability. Its training may miss a useful library or a recent release. GitHits finds examples grounded in other open-source projects, giving the agent approaches and libraries to investigate.
Once it has a candidate, the agent can inspect package metadata, licenses, known vulnerabilities, and dependencies before choosing what to use.
An example that works with one release can fail with another. GitHits lets your agent read the source at the version your application uses and consult the relevant documentation. It can check a function’s parameters, return value, and implementation before writing the integration.
Examples from other projects provide useful starting points. The agent can check their APIs against your dependency version before adapting them.
When a library throws an unfamiliar error or handles a request unexpectedly, the explanation may be inside the dependency. Your agent can find the error text, locate the responsible function, and read its implementation at the relevant version.
The agent can then trace the behavior back to your integration and decide what to change.
A new release can change an API, introduce a dependency, or fix a vulnerability. GitHits gives your agent release notes and an upgrade review covering security, deprecations, and dependency changes.
The agent can then inspect the relevant source versions to understand how the change affects your application and plan the migration.
The interface between agents and the open-source supply chain
Search, grep, list files, and read source at a package version or repository ref.
Search, grep, list, and read documentation pages or selected sections.
Inspect metadata, licenses, vulnerabilities, dependencies, releases, and upgrade changes.
Generate a code example from how other open-source projects solve a problem, with links to sources and licenses.
Experimental · Coming soonDelegate a question about how a package or repository works and get an explanation with sources.
Files, symbols, AST, imports, exports
Version history and changes
Markdown, MDX, HTML
Dependencies, imports, call relationships
Vulnerabilities, CVEs, advisories
Changelogs, release notes, diffs
Query GitHits > check the code and APIs > make the change
Why GitHits
GitHits gives coding agents tools to inspect dependency source, documentation, package data, security, changes, dependency graphs, and prior art.
Coding agents can inspect the code in your repository. But application behavior also comes from open-source frameworks, SDKs, libraries, and packages outside that repository.
GitHits gives software factories and individual coding agents one toolkit to discover packages, understand their code and documentation, learn from real-world usage, and evaluate dependencies and upgrades.
The tools answer different questions. When the agent needs to understand an API, it can search for a symbol or read the source. When it is evaluating a package, it can inspect its dependencies, license, and known vulnerabilities. When it is planning an upgrade, it can review what changed between releases. When it needs an implementation pattern, it can look at how open-source projects solved similar problems.
GitHits also keeps the version straight. When the agent specifies a package version or repository ref, GitHits searches the code and documentation for that target.
The agent keeps working in the same coding tool and keeps its view of your local repository. GitHits adds visibility into the open-source dependencies behind it. Together, they let the agent inspect the code it is changing and the code that change relies on.
Without GitHits
The agent can inspect your application code. Dependency source, documentation, package data, vulnerabilities, and release history remain outside its view, so it has to search elsewhere or guess.
30%local repository visible
With GitHits
GitHits adds tools for dependency source, documentation, package data, vulnerabilities, changes, dependency graphs, upgrades, and prior art.
100%local repository + open-source dependencies visible
The Builders
How a GitHub search for an undocumented Azure SDK API became a toolkit that helps software factories and coding agents work with open source.
GitHits started with a question in Slack.
When documentation didn’t explain something clearly, I had a simple fallback: search GitHub.
If a problem has been solved before, there is usually code somewhere showing how it works. Finding the right example still requires digging through files, issues, and discussions.
One day, Softlandia co-founder Mikko asked in Slack:
Who can find the definition for TranscribeDefinition?
He was building a transcription pipeline using Azure’s Speech SDK and couldn’t figure out how to initialize the object.
The official documentation didn’t show it yet, but the definition was already present in Microsoft’s GitHub repository inside documentation files prepared for a future release.
After finding it, I wrote in Slack:
GitHub search solves a surprising number of problems if the project is open source.
Then I added:
You could probably build a coding assistant that answers questions by searching GitHub with some heuristics.
That message started a discussion inside Softlandia Venture Studio. We decided to explore the idea, and Jaakko bought githits.com for $9.
Much of the practical knowledge about how libraries are used already exists in open-source repositories.
Developers have already recorded how libraries work in source code, documentation, issues, releases, and package metadata. The difficult part is finding the material for the package version or repository ref the agent is using.
Documentation can be incomplete, and raw search is noisy. Without the relevant source and package data, an agent may produce a plausible answer based on the wrong API or release.
Developers resolve these questions by inspecting source, reading documentation, checking package data, reviewing changes, and looking at how other projects solved similar problems. Doing that by hand works. Repeating it across dependencies, versions, and tasks is the problem GitHits was built to solve.
GitHits is the infrastructure layer connecting agents to the open-source ecosystem. Its index supports tools for code navigation, documentation, package inspection, vulnerability checks, changelog and upgrade review, and prior art.
Agents query these tools from the coding environments they already use, so they can inspect library code, documentation, and package details without cloning repositories or browsing from scratch.
Agents working together to produce software can use the same tools to discover packages, inspect implementations, learn from prior art, and evaluate dependencies and upgrades.
Engineers using tools such as Claude Code, Cursor, or Copilot when an unfamiliar dependency or undocumented API blocks the task.
Helping Claude Code find undocumented C++ APIs directly from the code.
— Onni Hakala, GitHits user
Engineers using packages whose documentation, examples, or APIs change faster than a model’s built-in knowledge.
I swapped my ritual of 20 browser tabs and stale Stack Overflow answers for a tool that actually understands what I’m trying to do.
— Atharv Singh, GitHits user
Co-founder, CTO
I created the opencv-python package. It has over 1B downloads. I wanted to keep contributing to the open source ecosystem. Now I'm building GitHits search agents and the reasoning layer.
Co-founder, Chief Architect
I thought I was done with startups, but I realized the AI coding revolution is just too big an opportunity to miss. I'm responsible for building the code indexing and intelligence engine that understands dependencies.
Co-founder, CPO
I was one of the first people to test Olli-Pekka's first prototype. I tried something hard: writing a CUDA kernel. Every other AI tool produced code that wouldn't compile. GitHits passed my tests on the first try. I wanted to join the team.
Co-founder, CEO
After my first startup, I was on the hunt to find an idea I'd be excited about. When Olli-Pekka pitched “a coding problem solver using GitHub search with smart heuristics”, I was immediately hooked.
Founding Designer
20+ years shipping digital products across retail, fintech, and entertainment, used by millions. Joined GitHits after experiencing the frustration of AI giving answers that look right but don't actually work. Now I'm fixing that through design.
GTM Engineer
Built AI/LLM automation across multiple production systems — OpenAI, Gemini, Vertex. Awarded for rapid technical growth, strong ownership of complex systems, and continuous skills improvement at Mavric. Now building the GitHits GTM engine.
FAQ
How GitHits works, what it covers, how to get started, and how it handles private code, retrieved context, and open-source licenses.
GitHits is the infrastructure layer connecting agents to the open-source ecosystem. It lets the agents in your software factory, or your individual coding agent, discover packages, understand code and documentation, learn from real-world usage, and evaluate dependencies and upgrades. The tools are available through MCP, the CLI, and the API.
GitHits can search and navigate open-source repositories whether or not they are published as packages. Package-specific tools, such as dependency, vulnerability, license, changelog, and upgrade inspection, are available for supported package ecosystems.
To get started, run npx -y githits@latest init. GitHits detects your coding tool, signs you in, and configures the MCP server automatically.
GitHits is useful when a task calls for context from open-source code, documentation, or package data. Common cases include researching an integration, understanding how a library works, investigating version-specific behavior, checking a package, or finding prior art.
During setup, the GitHits CLI wizard can install guidance that tells your agent when and how to use GitHits. You can also ask the agent to use GitHits explicitly.
GitHits indexes open-source repositories, documentation, and package data by package version or repository ref. When an agent asks for a specific target, GitHits resolves it to the corresponding commit and makes that source queryable.
The index records files, symbols, imports, call relationships, and documentation, so the agent can search and read the exact code it needs.
Fixed package versions and commits remain tied to the same underlying source. GitHits may re-index them as its parsing and search improve, but the source itself does not change.
Moving refs, such as branches and HEAD, follow the repository and update as it changes.
GitHits uses GitHub authentication to identify your account. Signing in does not give GitHits access to your private repositories.
No. GitHits does not access, index, search, or store your private repository code.
Your coding agent works with the code in your local repository. GitHits provides context from open-source code, documentation, and package data.
No. GitHits does not use your code, prompts, outputs, or personal data to train AI models. Service data is processed only to provide GitHits and remains governed by our Privacy Policy and Data Processing Agreement.
GitHits retrieves indexed open-source code, documentation, package data, changelogs, vulnerability data, and examples. It does not modify your code.
Its search infrastructure and MCP tools include guardrails intended to reduce prompt injection and other malicious-content risks. No external source should be treated as automatically safe, and developers should review generated code before shipping it.
For code, documentation, and package queries, the agent specifies a package, version, repository, or ref. GitHits resolves that target to indexed source and package data.
For prior art, GitHits ranks open-source examples using relevance and repository signals such as activity, adoption, maintenance, and license status. License filters are applied before examples are selected, and results link back to their sources.
Prior-art searches use strict license filtering by default. This excludes repositories with copyleft licenses and repositories that do not declare a license. You can relax these restrictions or disable license filtering.
Package inspection also reports license information, so agents can check a dependency's license before recommending or using it.
The Blog
Product updates, engineering notes, and case studies from GitHits.
October 5, 2026
Connect GitHits MCP to CodeRabbit so reviews can draw on open-source code and package data.
September 21, 2026
Software factories and agents still need to read code. GitHits provides infrastructure to discover open-source code and verify how it behaves.
August 27, 2026
How coding agents inspect external open-source dependencies across the software development lifecycle (SDLC).
August 24, 2026
Coding agents should inspect source code directly, use deterministic search for retrieval, and reserve model reasoning for understanding and decisions.
