Anthropic, Stripe, and Cloudflare each structure their llms.txt files differently — their design decisions reveal what the spec actually enables when you move past a minimal viable file.

Most llms.txt discussions fixate on whether the standard works. That misses something more useful: the companies pushing hardest for AI-readable content are already publishing production-grade implementations. Anthropic ships a dual-file powerhouse with both a curated index and a complete reference. Stripe organizes by product categories with optional guardrails. Cloudflare goes modular, publishing separate file pairs for each product line. Studying their files teaches you more about structuring your own than any generic template. Here’s exactly how they built theirs, what they prioritized, and which trade-offs they accepted.

Anthropic: The Dual-File Powerhouse

Anthropic’s implementation is the most comprehensive among major adopters. They ship both llms.txt and llms-full.txt, and the size difference tells you everything about how they think about AI context.

Their llms.txt file clocks in at 8,364 tokens. It’s a curated index: a blockquote summary of Claude’s documentation, followed by H2 sections for ‘Core Docs’ and ‘Guides & Tutorials.’ Each link carries a one-line description telling an LLM exactly what it will find before it fetches anything. No fluff. No generic labels.

The companion llms-full.txt runs 481,349 tokens. That’s equivalent to roughly 1,500 pages of content in a single file. An AI coding assistant can ingest the entire Claude API specification, every endpoint reference, every authentication guide, and every migration doc in one request. No pagination. No crawling 300 URLs.

Anthropic’s structure reveals their bet: when context windows are large enough, a single comprehensive file beats a navigation index. But they keep both because not every LLM interaction has a 500K token budget. The llms.txt file serves quick lookups. The llms-full.txt serves deep reasoning. This dual approach is pragmatic, not redundant.

Key takeaway: if your documentation footprint is large, don’t choose between the two files. Ship both and let the AI tool decide what it needs.

Stripe: Product-Category Organization with Optional Guardrails

Stripe takes a different approach. They organize their llms.txt by product categories rather than by document type, and they make aggressive use of the ## Optional section.

Their blockquote summary is tight: two sentences explaining Stripe’s payment infrastructure and where the main developer docs live. Then come the H2 sections, each mapped to a product area—Payments, Billing, Connect, Terminal, and so on. Under each heading, they list the most critical documentation links with clear, action-oriented descriptions.

The design choice that stands out: Stripe heavily uses the ## Optional section for specialized tools and edge-case documentation. This isn’t laziness. It’s a deliberate signal to LLMs. When context window space gets tight, the model can confidently skip everything under Optional without losing the core Stripe picture.

Stripe also ensures every linked page has a .md counterpart at the same URL. If their HTML docs live at /docs/api/charges, the plain Markdown version is available at /docs/api/charges.md. This adherence to the full spec means an LLM never has to parse navigation bars, footer links, or JavaScript to understand Stripe’s content.

Key takeaway: the Optional section isn’t a dumping ground. Use it strategically to separate critical content from helpful-but-skippable material. Be ruthless about what qualifies as ‘core.’

Cloudflare: Modular by Product, Not by File Type

Cloudflare’s implementation is structurally unique. Instead of one centralized llms.txt covering everything, they publish separate file pairs for each product line: Workers, Pages, KV, R2, Durable Objects, and more.

Each product gets its own llms.txt and llms-full.txt pair. The Workers file lists Workers-specific guides, API references, and runtime APIs. The Pages file covers deployment, builds, and configuration. No cross-contamination.

This modular design solves a real problem: Cloudflare’s total documentation surface is enormous. A single llms-full.txt covering everything would be impractically large, potentially exceeding even the most generous context windows. By splitting files by product, Cloudflare lets AI tools request only the documentation relevant to the specific task at hand. An AI helping someone debug a Worker doesn’t need the entire R2 API reference clogging its context.

They also organize files at predictable subpaths—/workers/llms.txt, /pages/llms.txt—making discovery straightforward for any tool that knows the convention.

Cloudflare’s approach also simplifies maintenance. When the Workers team updates documentation, they update one set of AI-ready files without touching or risking the Pages files. Product teams own their own AI context.

Key takeaway: if your site spans multiple distinct product domains, consider the modular path. One giant file creates maintenance bottlenecks and wastes AI context.

The Patterns That Cross All Three

Despite different organizational approaches, three patterns emerge across Anthropic, Stripe, and Cloudflare. These aren’t coincidences. They’re the spec working as designed.

Pattern 1: Blockquote summaries are short and concrete. All three companies limit their blockquote to two or three sentences that answer ‘what is this?’ without marketing language. Anthropic says ‘Claude is a family of large language models.’ Stripe says ‘Stripe is a payment infrastructure platform.’ Cloudflare says what each product does. They all resist the urge to add adjectives, claims, or positioning. The LLM needs facts, not persuasion.

Pattern 2: Link descriptions carry the weight. Every link in these files includes a colon-separated description explaining what the linked page contains. No one uses bare URLs or vague labels like ‘Documentation’ or ‘API.’ Each description gives the LLM enough context to decide whether to fetch the page at all.

Pattern 3: .md versions are non-negotiable. All three publish clean Markdown alternatives to their HTML documentation. They don’t rely on AI tools parsing their styled, interactive doc sites. They give the LLM exactly what it can read efficiently: plain text with basic formatting.

Pattern 4: Curation over comprehensiveness. Nobody lists every page. Anthropic doesn’t link to 500 blog posts. Stripe doesn’t enumerate every API endpoint in their llms.txt. Cloudflare doesn’t include archived v1 documentation. Each file reflects deliberate editorial judgment about what matters.

What You Should Steal from Each Approach

You don’t need to copy any single implementation wholesale. Pick elements that match your situation.

Steal from Anthropic if your documentation is deep and you want to serve both quick lookups and immersive AI research. Ship both files. Make the full version genuinely complete. Think of llms.txt as your site’s elevator pitch and llms-full.txt as the full reference manual.

Steal from Stripe if your product has clear category divisions and some documentation is genuinely optional for most AI interactions. Use the Optional section explicitly. Be disciplined about it. If everything is optional, nothing is.

Steal from Cloudflare if you manage multiple distinct products or services under one domain. Modular files at predictable subpaths let AI tools fetch only what’s relevant. Your maintenance workflow benefits too.

Steal from all three: write link descriptions that tell the LLM what it will find, not what the page is called. ‘Authentication guide with OAuth2 setup steps and token refresh logic’ beats ‘Auth’ every time. Keep your blockquote under three sentences. And always, always provide .md versions of your pages.

The spec gives you flexibility. These three companies demonstrate that the flexibility isn’t a weakness. It’s what makes llms.txt adaptable to fundamentally different documentation architectures.

FAQ

Do I need to structure my llms.txt exactly like Anthropic, Stripe, or Cloudflare?

No. The spec requires the H1 title and blockquote. Everything else is flexible. These three companies showcase different valid interpretations. Pick the organizational pattern that fits your content structure.

Should I always create an llms-full.txt file?

Only if your total documentation fits within a reasonable context window for current LLMs (roughly 500K tokens or less). If your docs are larger, consider Cloudflare’s modular approach with product-specific full files. A single 2-million-token file defeats the purpose.

How do I decide what belongs in the Optional section?

Ask yourself: if an LLM had limited context and needed to answer a question about your product, could it do so without these pages? Changelogs, migration guides for old versions, and specialized edge-case docs are classic Optional candidates. Getting-started guides, core API references, and authentication docs are not.

Do Anthropic, Stripe, or Cloudflare confirm that LLMs actively use their files?

Anthropic has requested llms.txt implementation from their docs platform (Mintlify), suggesting internal interest. But none of the three has publicly stated that ChatGPT, Claude, or other LLMs reference their files during inference. The implementations exist as infrastructure, not as confirmed pipelines.

Can I look at their actual files for reference?

Yes. All three publish their files publicly. Visit docs.anthropic.com/llms.txt, docs.stripe.com/llms.txt, or developers.cloudflare.com/workers/llms.txt to study them directly.

Sources