Top Sources Coding Agents Fetch From (Ranked by Real Session Data)

TL;DR

Across 500 observed coding-agent runs, documentation took 55% of page fetches, source code 18%, package registries 11%, and third-party content 5%.

• Documentation ranked first at 55%. Agents use it to find setup steps and working instructions.

• Source code ranked second at 18%. Agents inspect code when documentation lacks an exact answer.

• Package registries ranked third at 11%. Agents verify install commands, versions, and dependencies.

• Third-party content ranked fourth at 5%. Blogs and listicles provide context but rarely help agents complete the build.

Within documentation, setup guides, README files, and quickstarts produced roughly 60% of fetches.

Fetch data reveals the live-research layer of Agent Preference Optimization. Gauge shows what agents fetched and whether the integration succeeded.

Why fetch share is the part of agent preference you can actually see

Fetch share measures the live-research stage of Agent Preference Optimization. Before researching, a coding agent may choose a tool based on its model knowledge or repository context. Those decisions can happen without a page request. Live research exposes which sources the agent retrieves when it needs more information.

Gauge measured that behavior across 500 instrumented coding-agent runs. Each run captured the agent’s searches, page fetches, product choice, and implementation actions. The ranking comes from observed sessions rather than surveys or stated model preferences.

Fetch share therefore describes where agents research, not every factor behind their choices. A product can win without a fetch because the agent already knows it. Another product can earn several fetches and still lose after the agent checks compatibility or attempts the integration.

What counts as a fetch, and what to look for in each source

A fetch happens when a coding agent retrieves a page through WebFetch, curl, or a similar tool. A search result does not count. Claude Code’s WebSearch finds URLs, while WebFetch opens a chosen page and extracts information from it. A page can appear in search without the agent ever fetching it.

Fetch share. The percentage shows how often agents retrieved each source type across observed sessions.

Why agents go there. The agent fetches a source to answer a task-specific question, such as finding an install command or checking an API method.

What winning does for APO. A fetch puts your product’s information into the agent’s live research. Model knowledge and session context may still determine which product the agent picks.

Documentation — 55% of all page fetches

Coding agents fetch documentation because they need concrete instructions to complete the task. Across observed sessions, documentation accounted for 55% of all page fetches, far more than any other source type.

Setup guides led with 26% of documentation fetches. README files followed at 18%, and quickstarts accounted for 15%. Together, those pages made up 59% of documentation activity because they usually contain the install command, required configuration, and shortest path to working code.

Agents extract page text and fit it beside the prompt, repository, and other sources in a limited context window. Clear documentation gives the agent exact commands and current API details without making it interpret navigation or product copy. A Markdown version of each page can reduce extra text and make implementation details easier to retrieve.

The difference between build and selection tasks shows when documentation becomes useful. In sessions where Claude Code or Codex had to build with a named vendor, 36.3% opened an llms.txt file. Only 0.5% opened one while choosing a vendor. Build tasks force agents to find exact setup instructions, authentication details, and API behavior. An llms.txt file helps by directing the agent to the authoritative pages.

For APO, winning a documentation fetch puts your product into consideration. The agent still decides what to install after reading.

Source code — 18% of all page fetches

Source code accounts for 18% of page fetches because agents often need details that documentation leaves out. Repository files can reveal the exact function signature, default behavior, or supported type. Tests can also show how maintainers expect an API to work in practice.

Claude Code may receive an extracted summary instead of the full page when it uses WebFetch. Anthropic describes that extraction as lossy by design, so the extraction prompt determines which details reach the main model. When a missing detail blocks implementation, the agent can inspect the source and check the relevant branch or release directly.

Some source fetches are hard to identify in server logs. Codex often retrieves known URLs through shell commands, so a request may appear as generic curl traffic instead of named agent traffic. Observed coding sessions show why instrumented sessions provide a clearer view than user-agent data alone.

For Agent Preference Optimization, winning a source-code fetch keeps your product under consideration by resolving a technical question. The fetch does not guarantee selection or a successful integration.

Package registries — 11% of all page fetches

Package registries receive 11% of all page fetches because they provide current release data in a compact form. Agents use registry pages to confirm the latest package version, copy the exact install command, and check whether dependencies remain actively maintained.

Current registry data helps agents avoid relying on older versions remembered during model training. Endor Labs found that 49% of dependency versions imported by AI coding agents had known vulnerabilities, often because agents selected outdated versions. A registry fetch gives the agent a chance to verify the release before changing the project.

You can improve that fetch by keeping package names, install commands, version numbers, and dependency metadata accurate. Remove stale instructions when releases change, and mark deprecated packages clearly so the agent does not treat them as the default.

For Agent Preference Optimization, winning the registry fetch confirms that your package looks current and usable. The agent still decides whether to install it.

Third-party content — 5% of all page fetches

Third-party content accounted for just 5% of page fetches across 500 observed coding-agent runs. The blogs and listicles you have been buying are rounding errors here because agents usually need material they can turn into working code. A comparison article may name options, but it rarely gives an agent the exact install command, current API details, or error behavior needed to finish a task.

Coding agents read with an execution goal. They fetch a page, extract relevant details, and use those details to choose a package or write code. Persuasive claims offer little help when documentation, source code, and registry data provide more direct evidence.

For Agent Preference Optimization, winning a third-party fetch can put your product in the candidate set. The agent still needs stronger implementation evidence before selecting it.

A fetch is not a win

A fetched page can help an agent recommend a product, but the product still has to survive installation. The agent may encounter stale commands, incompatible dependencies, or documentation that does not match the API.

Agent Experience begins at that handoff. A product can have “won the recommendation, lost the integration” when the agent selects it but cannot complete the task. Fetch share measures influence during research. The session outcome shows whether the integration succeeded.

Inside documentation: what agents actually fetch first

The top three entry pages account for 59% of documentation fetches across setup guides, README files, and quickstarts. Observed coding-agent sessions show that agents concentrate on pages that help them start writing working code.

• Setup guides receive 26% of documentation fetches. Agents need installation steps, authentication details, required configuration, and a clear path to the first successful request.

• README files receive 18%. A good README gives the agent a compact view of the package, its install command, and its basic usage without requiring several more fetches.

• Quickstarts receive 15%. Agents use quickstarts to produce a minimal working integration. Complete code samples work better than long conceptual explanations because the agent can adapt them directly.

• API references receive 13%. Agents open reference pages when they need exact methods, parameters, response shapes, or error behavior that an introductory guide leaves out.

• Package registry pages receive 11%. Within the documentation breakdown, registry pages help agents confirm package names, current versions, and installation commands before changing the project.

• Dependency documentation receives 1%. Agents fetch these pages when an integration depends on another library whose setup or behavior needs clarification.

An llms.txt file can help an agent locate these pages, but the file usually acts as an index rather than the final source. Agents still move into setup guides, references, and other authoritative pages to complete the work.

You should invest first in the documentation that controls the first ten minutes of product use. Clear setup guides, current README files, and runnable quickstarts give agents the shortest path from selection to working code.

How to read this data as a source-targeting checklist

• Prioritize the first-use docs. Keep setup guides, README files, and quickstarts current. Include exact install commands, required configuration, working examples, and common errors.

• Make source code easy to inspect. Use clear names, predictable types, useful comments, and examples that match the current API. Agents check source when documentation leaves a specific implementation question unanswered.

• Maintain package registry details. Publish the correct install command, current version, supported environments, dependency requirements, and release notes. Remove stale metadata that could send an agent toward an outdated package.

• Use third-party content for awareness. Blogs, comparisons, and listicles can introduce your product to the candidate set, but they rarely provide enough detail for selection or implementation. Point those pages toward concrete documentation instead.

Gauge: seeing which sources actually get fetched

Gauge shows which sources coding agents fetch for your product, the order they open them, and how each session ends. You can see whether Claude Code, Codex, or another agent opened your setup guide, inspected source code, checked a package registry, or relied on third-party content.

Gauge runs real coding agents against real prompts and repositories in isolated sandboxes. Each run captures searches, fetched pages, package installs, file changes, and the final integration result. You can tell whether an agent installed your product successfully, abandoned it during setup, or replaced it after a failed attempt.

GA4 can show referral traffic, and server logs can show page requests. Neither source alone connects a fetch to the agent’s decision, implementation steps, and final repository state. Gauge built that measurement layer for Agent Led Growth, a new category focused on what coding agents recommend and whether they can implement the product correctly.

Use Gauge to find where your product loses agent sessions, fix the source or integration problem, and rerun the same tasks to check whether agent behavior changed.

FAQs

Does the data apply equally to Claude Code and Codex?

No. The ranking combines 500 observed sessions, but each agent carries different model knowledge and uses different research tools. You should benchmark the agents, languages, and repositories your developers use.

Why do blogs and listicles matter so little?

Third-party content received only 5% of page fetches because coding agents research to complete tasks. Documentation and source code provide install steps, working examples, and exact implementation details. Blogs can introduce a product, but they rarely provide enough information to finish an integration.

How often should you rerun the benchmark?

You should run a stable set of prompts on a schedule and after major model releases. Rerun it when you change documentation, package metadata, or onboarding so you can measure whether agent behavior changed. Gauge can keep those sessions consistent and compare results over time.