Summary: Firecrawl released the Developer Index on August 20, 2026 as a semantic retrieval layer for coding-agent artifacts such as READMEs, documentation, issues, pull requests, and OpenAPI specs; it does not store code. The company says it holds more than 70 million artifacts and reports a 0.63 DevDex Recall@10 versus 0.58 for Firecrawl Search. The benchmark and results remain Firecrawl-authored pending independent validation.
The Change: A Retrieval Layer Purpose-Built for Coding Agents
Three questions eat a large slice of any coding agent’s tool calls: which repository already implements an idea, which doc page holds the answer to a question, and which issue or pull request repaired a bug. The material answering them is spread over GitHub, docs sites, and threads — and today’s retrieval choices are lexical, partial, or both at once.
Firecrawl shipped the Developer Index on August 20, 2026: a specialized index aimed at coding agents. What goes in are the artifacts an agent needs in order to write code that runs and is up to date — READMEs, external documentation, issues, pull requests, and OpenAPI specs — searched semantically and filtered by metadata, refreshed every day. The index holds 70M+ artifacts: top-repository issues and pull requests, READMEs drawn from a wide range of public repositories, external docs sources such as Stripe, OpenAPI specs, and widely used skill repos. Metadata travels with every artifact: stars, licenses, artifact type.
One point worth stating plainly: code is not stored here, and this isn’t built to serve general web search. It is a retrieval layer built around a single purpose — the artifacts coding agents create and consume.
Released together with the index was DevDex, an open benchmark of 1,179 developer-search queries, graded with Recall@10 and MRR@10, so that any team can measure how far a retrieval system goes in supporting real coding-agent workflows.
Why a Dedicated Index? The Gap It Fills
Watching customers search and scrape for developer content, Firecrawl kept running into the same three patterns:
- Agentic products (like Lovable, Replit, Bolt) that debug backends on end users’ behalf.
- Knowledge-base builders fusing internal and external repos into one retrieval layer.
- Frontier labs that want open developer documentation, code, issues, and PRs for training and evaluation.
Behind all three sat one shared gap. The providers already on the market were not built for a world of agents: their search is lexical rather than semantic, and assembling a complete artifact (a README, its issues, its recent PRs) required chaining 50+ API calls or standing up the entire pipeline yourself. Firecrawl’s own general search and scrape fared no better on this query shape, for a simple reason — a coding agent isn’t after a web page, it’s after an artifact.
That artifact layer is what the Developer Index supplies.
How the Index Works: API, CLI, MCP, and SDKs
Pose a question in natural language to the Firecrawl Developer Index and what returns is a ranked set of developer results plus the passages that matched — enough for an agent to act on directly, with no follow-up scrape. You reach it through either of two surfaces:
- Firecrawl
/search/developerhands back developer sources alone, filterable by result type, repository, and documentation source. This is the surface to pick when ranked developer results with matched passages are what you need. - Firecrawl
/searchwithcategories: ["developer"]surfaces Developer Index results through the standard/searchresponse, shaped the way ordinary web results are.
Every result also carries a stable id (of the form issue:owner/repo#123) — the prefix says which kind of artifact it is (doc:, issue:, pull_request:, or readme:) — alongside a url and the matched passages in markdown, which keeps tables and code blocks intact. The API also accepts filters — types, repos, sources, language, topic, license, min_stars, and others — to narrow a query, plus skills: "only", which restricts a search to indexed agent-skill files. Those filters live on the API alone. Because agents do best with nothing filtered, the CLI and MCP deliberately leave them out.
Starting costs nothing, not even a Firecrawl API key; adding one lifts the rate limits. Pricing for a developer search works out to 2 credits per 10 results, rounded up.
# No API key needed to get started; add -H "Authorization: Bearer $FIRECRAWL_API_KEY" for higher rate limits:
curl -s "https://api.firecrawl.dev/v2/search/developer?query=how%20do%20I%20configure%20retries&k=10"Handing your agent access is simplest through Firecrawl’s dedicated developer skill, which hooks into the Firecrawl CLI or the MCP server:
npx -y firecrawl-cli@latest setup developer-indexThe Developer Index docs carry the full parameter reference and the response schema.
DevDex Results: Where It Stands
DevDex is an open benchmark aimed at retrieval over developer content: it grades how well a system surfaces the right docs, GitHub pages, and Stack Overflow answers when real coding agents ask. The reason it exists: benchmarks built for standard search say nothing about what an agent looks up mid-code.
1,179 developer-search queries make up the benchmark, split across three tracks, each mirroring a real coding-agent retrieval path:
- Repository discovery. Locating the repo that matches a described capability when its name isn’t known. Example: “a library for incremental PDF parsing.”
- Documentation lookup. Tracking down the precise page that answers a how-to. Example: “How do I add Pydantic to my project using uv instead of pip?”
- Issue and PR resolution. Pinning down where a given bug was discussed and fixed. Example: “scikit-learn LogisticRegression random_state not working.”
Scoring on each track is deterministic, on Recall@10 and MRR@10 against fixed gold references, and a memorization check removes any query the driver model can already answer from pretraining. Providers all run under identical conditions: one driver model (Claude Opus 4.8), a single search tool active per run, one harness.
Recall@10 asks whether the correct artifact turns up anywhere in the top ten results — the higher, the better. Overall scores are the mean of the three tracks. The Firecrawl Developer Index lands at 0.63, out in front of Firecrawl Search’s 0.58 (no category), Parallel’s 0.57, and the 0.54 shared by Mintlify and Exa. Native web search comes in at 0.45, Context7 at 0.17.
Track by track, the Firecrawl Developer Index owns issue and PR resolution at 0.66, and draws with Context7 on documentation lookup in statistical terms (0.47 apiece, a 0.006 gap comfortably within the 95% CI). Context7 concentrates on docs and comes out near zero on the remaining two tracks (0.01 for repository discovery, 0.03 for issues and PRs). Repository discovery is where the Developer Index puts up 0.76, trailing Parallel at 0.82 and Firecrawl Search at 0.78.
How far the “no tools” control sits below every other row is the measure of the retrieval problem: pretraining alone won’t carry a coding agent through these queries. How far native web search sits below the specialized indexes is what a purpose-built artifact layer returns.
Half the dataset, along with the evaluation harness, is being open-sourced by Firecrawl, letting any team reproduce results on its own systems. To submit a provider, open a PR on the repo carrying your results for the public half, and send valid API keys to rafael@sideguide.dev so the reruns can happen on the held-out half.
What Product Builders Can Do With It
- Ship an agentic product that can debug its own code. Let the Firecrawl Developer Index sit in your agent’s tool loop, so when an error shows up it goes looking through issues and PRs rather than guessing.
- Build a developer knowledge base. Lean on the Firecrawl Developer Index to bring external documentation and repo artifacts in beside your internal sources, and skip maintaining a GitHub scraper.
- Train coding models, or evaluate them. Treat the Firecrawl Developer Index as the retrieval layer for RAG-style training data pipelines, and score whatever retriever you build with DevDex.
Where It Falls Short
Leading on overall recall doesn’t make the Developer Index the winner on every track. Repository discovery is one it loses, to Parallel and Firecrawl Search both. Documentation lookup ends in a tie with Context7 — a docs-only system that scores near zero elsewhere. And with no code stored in the index, anyone needing code-level retrieval will have to look elsewhere. Neither do the API filters appear on the CLI and MCP, a constraint for users who want to narrow searches from those interfaces. Finally, the benchmark is new: open though it is, it remains Firecrawl’s, and independent validation has yet to accumulate.
Bottom Line: A Public Standard for Developer Search
The Firecrawl Developer Index is available today across the API, CLI, MCP, and SDKs, and it slots into whatever harness you already run — Codex, Claude Code, and Grok Build among them. Pair a specialized artifact index with an open benchmark such as DevDex, and product builders can gauge and sharpen how retrieval for coding agents performs. If the agent you’re building leans on developer documentation, this index deserves a try — above all once general search stops delivering artifact-level results.