opensrc: The Cache That Lets AI Agents Jump Straight Into Dependency Source
A Rust-powered CLI from Vercel Labs that resolves packages across registries, caches their real source locally, and gives coding agents a faster path from imports to implementation.
(Re)introducing opensrc. Now in Rust 🦀 Give your AI agent deeper implementation context, not just types and docs. The actual source code of your dependencies. Agents use `opensrc path` in any bash command. Fetched once, cached globally. npx skills add vercel-labs/opensrc
- opensrc makes dependency source feel local, which is exactly the kind of context AI agents can use without extra ceremony.
- Its real trick is not fetching code, but converting package identity into a stable cached path that behaves like a file already on disk.
- The Rust core, npm wrapper, and atomic cache writes are all in service of one promise: repeat lookups should be fast, reliable, and boring.
- Compared with package managers and remote code search, opensrc lives in the gap between installation and understanding.
When the bug is in the dependency, docs stop helping
Most AI coding tools are strongest when the answer is already near the problem. Your app files are local. Your dependency source usually is not. That is where debugging gets slow, because types, docs, and package metadata do not always explain why a library behaves the way it does.
Fetch source code for npm packages to give AI coding agents deeper context
That is the gap opensrc is aimed at. It does not try to replace package managers or code search. It tries to make dependency source feel as immediate as a local file lookup.
opensrc turns source code into a local primitive
The pitch is simple: run a command, get a path, and treat third-party code like something your machine already knows where to find. Once that happens, an agent can grep, read, and reason over dependencies with the same tools it uses on the repo in front of it.
The resolution pipeline, from package name to source tree
Under the hood, the path command does a small but important piece of translation work. It parses the spec, figures out whether it is a registry package or a direct repo, checks the cache, and when needed resolves the right repository and version before cloning source locally.
opensrc path zod
opensrc path pypi:requests
opensrc path vercel/aiThe interesting part is the version logic. If the package is already installed in the project, opensrc can probe that local reality instead of guessing. That makes the result feel aligned with the codebase you are actually working in, not just whatever the registry last advertised.
Why the Rust core matters more than it first appears
The Rust binary is doing the heavy lifting. The npm wrapper is mostly a distribution layer that detects platform details, picks the right binary, and launches it without asking the user to think about toolchains.
That choice matters because it hides complexity in the right place. A JS developer gets an npm install. The tool gets native performance, cross-platform detection, and a cleaner path to robust file and network operations.
The cache is the product
opensrc keeps a global sources index and updates it carefully. That sounds mundane, but it is the whole point. A cache only becomes useful when it is trustworthy enough that agents can depend on it across repeated lookups.
The implementation details support that promise: shallow clones reduce unnecessary download cost, `.git` is stripped so cached source stays lightweight, and atomic writes protect the index from corruption if a process stops mid-write. Those are boring decisions in the best possible way.
Why this is different from package managers and code search
Package managers can fetch artifacts. Code search tools can find code. Manual browsing can eventually get you to the same place. None of those is quite the same as a local source-access layer whose main job is to make dependency code feel immediately available to an agent.
| Tool | Primary job | Local source access | Multi-registry support | Agent-friendly path output | Offline repeat access | Best use case |
|---|---|---|---|---|---|---|
| npm, pip, cargo | Install or fetch packages | Partial, usually tied to package layout | No, each ecosystem separately | No | Limited | Build and dependency management |
| Sourcegraph, GitHub Code Search | Search code remotely | No | Broad, but search-centric | No | No | Cross-repo discovery and analysis |
| Manual download or browser browsing | Inspect a specific repo by hand | Yes, after extra steps | Yes, but fragmented | No | Maybe | Occasional deep inspection |
| opensrc | Cache dependency source as a reusable local path | Yes | Yes | Yes | Yes | Agent workflows and repeated source inspection |
That distinction is the whole product strategy. It assumes the hard part is not finding a package name. The hard part is turning that name into source an agent can actually work with, repeatedly, without redoing the plumbing every time.
What the skill file says about the direction of the tool
The presence of a skill file is a clue about intent. opensrc is not only for humans at a terminal. It is also packaging know-how for agents, so the tool can be invoked with the right habits and the right context from the start.
That is a subtle shift, but an important one. The project is not just a downloader. It is a capability layer for systems that need to move from package identity to implementation detail with very little friction.
