Firecrawl Ships a Search Index Built Just for Coding Agents

Coding agents spend an enormous share of their tool calls just looking things up: which repo implements an idea, which doc page answers a question, which issue already has the fix for the bug staring back at them. Most of that context lives on GitHub, on docs sites, and in threads, and until this week the tools for finding it were built for humans typing keywords into a browser, not for agents that need a ranked, structured answer they can act on immediately.

On August 20, Firecrawl launched the Developer Index, a search API purpose built for that exact problem, and it’s a good look at where developer tooling is heading as more of the audience for search results is itself software.

What it actually is#

The Developer Index is a semantic search layer over more than 70 million artifacts: READMEs, GitHub issues, pull requests, OpenAPI specs, external documentation, and agent skill files. Most sources refresh daily. Two things make it different from pointing an agent at a general search API:

1. It returns artifacts, not web pages. A query like “how do I configure retries” comes back with a stable ID (doc:, issue:, pull_request:, or readme:), a URL, and the matched passages in markdown, code blocks and tables intact, so an agent can act on the result without a second scrape.
2. It’s filterable the way a developer thinks. The API accepts filters for types, repos, sources, language, topic, license, and min_stars. You can also restrict a search to indexed agent-skill files with skills: "only".
3. It’s keyless to start. No API key is required to make a request; adding one just raises your rate limit. A developer search costs 2 credits per 10 results.

You can reach it two ways: a dedicated /search/developer endpoint for developer-only results, or the standard /search endpoint with categories: ["developer"] if you want it folded into your normal search flow.

Why the benchmark matters more than the launch#

Firecrawl didn’t just ship the index, they shipped DevDex alongside it: an open benchmark of 1,179 developer-search queries across three tracks (repository discovery, documentation lookup, and issue/PR resolution), scored on Recall@10 and MRR@10 against fixed gold answers, with a memorization check to throw out anything the model could already answer from pretraining. Every provider ran under the same driver model and harness.

The headline number: the Developer Index scores 0.63 Recall@10 overall, ahead of Firecrawl’s own general search (0.58), Parallel (0.57), Mintlify and Exa (0.54 each), native web search (0.45), and Context7 (0.17, though Context7 is docs-only and is statistically tied with the Developer Index on that single track). That’s the actual value of an artifact-shaped index over a page-shaped one: nearly 20 points of recall on the same queries.

That’s the part worth internalizing if you’re building anything agentic: general web search is a weak substrate for “find the fix for this bug,” and it’s going to keep losing ground to indexes that model the artifact instead of the page.

Try it yourself#

This runs a real, keyless request against api.firecrawl.dev from your browser. Type a question the way you would ask a coding agent, and see what comes back.

Where this is heading#

The interesting signal isn’t the index itself, it’s that Firecrawl felt the need to build and open-source a benchmark to prove it. As more search traffic comes from agents instead of people, “top result on Google” stops being the metric that matters, and “does my agent find the right artifact in one call” becomes the one that does. Expect more of this: specialized, artifact-shaped indexes for narrower jobs (changelogs, Stack Overflow-style Q&A, package registries) each competing on a benchmark instead of general relevance.

If you’re wiring up an agent that debugs its own code or answers “how do I” questions against a mix of internal and external docs, the Developer Index is worth a spike this week. The DevDex repo is public if you want to see whether your own retrieval setup would have scored better or worse on the same 1,179 queries.