Your API docs are now read by AI agents: what stale docs cost you in 2026

For most of the history of API documentation, the reader was a developer with a browser. They skimmed, cross-checked the page against what they saw in their terminal, and filed a support ticket when the two disagreed.

That reader is now often a coding agent. It reads the page, believes it, and writes the integration. The developer may never open your docs at all.

The reader changed

The numbers depend a lot on who’s measuring and how, so here they are separately:

Mintlify counted agent requests across the docs sites it hosts. In July 2026, agents made 66% of measured traffic, up from 15.2% at the start of the year. In an earlier 30-day sample, Claude Code alone made more requests than Chrome on Windows.
GitBook measured one week in spring 2026 and found AI agents made 51.8% of intentional page reads, with crawlers excluded. Most of that was ChatGPT rather than coding agents.

Different platforms, different methods, different mix of agents. But both point the same way: on a typical docs site in 2026, a large share of your readers aren’t people.

How agents read your docs

Agents don’t read docs the way a browser renders them. They want plain text, as little of it as possible, and they want it fast.

Markdown versions of every page. Most docs platforms now serve a Markdown copy of each page. On Mintlify, GitBook, Fern and Stripe’s docs you can add .md to a URL. Claude Code’s web fetch tool asks for Markdown first. Cloudflare, which converts pages to Markdown at its edge when an agent asks, measured one page dropping from 16,180 tokens to 3,150.

llms.txt. Proposed by Jeremy Howard in September 2024, it’s a Markdown index of a site’s most useful pages, served at /llms.txt. Mintlify, GitBook, ReadMe, Fern and Redocly generate one automatically, and Docusaurus and MkDocs have community plugins. Its value is debated: Google Search says it ignores the file, and an Ahrefs study found 97% of published llms.txt files got no requests at all in a month. Where it does get read, coding agents are among the readers.

MCP servers. Docs platforms now expose your docs to agents as tools. Mintlify, GitBook, ReadMe and Fern generate an MCP server for your published docs, so an agent in Cursor or Claude Code can search them directly. OpenAI and Stripe run their own.

Third-party indexes. Context7, from Upstash, indexes docs for thousands of libraries and serves them to agents over MCP, with version matching. GitHub’s own Copilot CLI docs use it as their example MCP server.

Why stale docs cost more now

A developer reading an out-of-date page has a chance to notice. The response doesn’t match. The parameter doesn’t exist. They get suspicious, check the changelog, and work around it.

An agent usually takes the page at its word, and research on code models shows why that matters: they already lean on outdated knowledge. A study at ICSE 2025 found models used deprecated APIs in 25–38% of completions, and 70–90% of the time when the surrounding code was itself outdated.

The good news is that documentation is the fix. A 2026 study of 270 real API updates found that without full docs, only 42.55% of the generated code ran; with structured docs and larger models, 66.36% did. Another found that telling a model which version to use didn’t help, but giving it the relevant docs did. Vercel tested agents on Next.js 16 APIs that weren’t in the models’ training data: 53% passed with no docs, 100% with a docs index in the project’s AGENTS.md.

Put those together and the cost of a stale page is clear. Agents are steered by your docs more than ever. When the docs are right, they correct the model’s outdated habits. When the docs are wrong, they hand the agent an authoritative-looking mistake, and the code it writes looks reasonable, compiles, and can still fail in production. Nobody reads the page, so nobody notices the page was the problem.

Here’s what that looks like. In our post on docs drift, a small pull request cut the maximum page size of a refund list from 100 to 50. The docs page didn’t mention a page size at all. A developer would find out the first time they counted results. An agent asked to “fetch all refunds, 100 at a time” has nothing on the page to tell it otherwise, so it writes the loop with 100 and moves on. The docs PR DocFit opened for that change added the limit parameter with its new maximum, so the next agent to read the page gets it right.

One wrong page, many wrong copies

There’s a second effect. Your docs no longer exist in one place. Each page now has a Markdown twin, an entry in llms.txt, perhaps a line in llms-full.txt, a slot in your docs MCP server, and copies in third-party indexes.

Your docs platform regenerates its own copies from your pages, which is good: fix the page and they follow on the next deploy. Third-party copies are slower. Context7, for example, refreshes a library only when it’s requested and its copy is older than a threshold, from one day for the most popular libraries to 45 days for the rest, and serves the existing copy while it refreshes. Library owners can trigger a refresh themselves.

So the page is the source for every copy an agent will read. The sooner it’s right, the sooner all of them are. That’s why DocFit edits the source: the pages in your docs repository, in your framework’s own format. It doesn’t publish a copy of your docs for agents to read, so there’s no extra copy to fall out of date.

What to do about it

Serve Markdown and an llms.txt. Your docs platform probably already does; on Docusaurus or MkDocs, add a plugin. It’s cheap, and it’s what coding agents ask for.
Write pages an agent can use without guessing. Mintlify’s guidance is a good start: one topic per page, one name per concept, complete runnable examples. Runnable is the part that slips: an example that worked when it was written can break with the next release, and an agent will copy it anyway. On the Team plan, DocFit runs curl, JavaScript, Python and PHP samples against a mock built from your OpenAPI spec before it opens a docs PR. Cloudflare keeps core instructions out of tabs and collapsed sections, where tools can miss them.
Take deprecated pages out of agents’ path. Exclude them from llms.txt, mark them noindex, and say clearly at the top what replaces them.
Point agents to the source of truth for versions. Stripe’s llms.txt tells agents to check the package registry for the latest version instead of trusting what they remember.
Test your docs with an agent. Keep a fixed set of questions (“create a refund”, “page through results”) and ask an agent to build each one from your docs alone. When the answer is wrong, find out which page misled it.
Update the docs when the code changes, not later. Everything above makes your docs easier for agents to read. None of it helps if the page describes last month’s API.

Keeping the source right with DocFit

That last step is the one DocFit takes off your plate. It’s a GitHub App, and it runs on every merged pull request:

It reads the whole change. The diff, the PR description, commits, review comments and the linked Jira, Linear or GitHub issue. The ticket says why something changed, which is often the sentence an agent needs.
It finds the pages an agent will hit. Changed operations in your OpenAPI spec, and names from the diff (routes, enums, environment variables, CLI flags) matched against every page, not only the obvious one. Those quieter pages are exactly the ones an agent searching your docs will land on.
It edits them the way your team writes them. Mintlify, Docusaurus, Redocly, MkDocs, Nextra, VitePress or plain Markdown, in the same repository or a separate one. The platforms and plugins that generate your Markdown copies, llms.txt and MCP server keep working from the same files.
It checks the result before anyone reviews it. Your docs build, markdownlint and Vale with your config, links, and Redocly or Spectral on the spec. Low confidence or a failed check opens a draft instead of a ready PR.
Your team stays in charge. Every update is an ordinary pull request with a reason for each page it touched. DocFit never merges anything.

Merge the docs PR, and on your next docs deploy every copy your platform generates for agents is up to date: the Markdown pages, llms.txt and your docs MCP server.

See how DocFit works, or start free below and see what it would have changed in your docs for your last few merged pull requests.