What Is llms.txt? How AIOZ Stream Uses It for AI Assistants

Most API docs are written for a person reading a browser tab, not for an AI assistant trying to generate correct code against an endpoint it's never seen. AIOZ Stream publishes a second, parallel set of docs specifically for the second case: a llms.txt-standard file that Claude, Cursor, ChatGPT, and Copilot can read directly. This is what's actually in it, not just that it exists.

TL;DR:

• AIOZ Stream publishes an index file (llms.txt), a fully concatenated file (llms-full.txt), and 12 per-section files, all in plain Markdown.
• The index file opens with ten numbered instructions for AI assistants: credential handling, the SDK auth pattern, the base URL, pagination defaults, upload sequencing, and more.
• Setup is different per tool: attach the file in Claude or ChatGPT, @-mention it in Cursor, #-reference it in Copilot Chat.
• AIOZ Stream's own docs include the caveat that generated code should still be checked against live API behavior, not treated as guaranteed correct.

What llms.txt actually is

llms.txt is an open convention (llmstxt.org), not an AIOZ-specific idea: a plain-text or Markdown file at a predictable location that gives an AI assistant a map of a site's documentation instead of forcing it to scrape rendered HTML. AIOZ Stream implements it as two files with different tradeoffs. The index file, fetched with curl -o aioz-stream-llms.txt https://aiozstream.network/docs/llms.txt, links out to section files and is meant for tools with limited context. The full file, curl -o aioz-stream-llms-full.txt https://aiozstream.network/docs/llms-full.txt, embeds everything in one download for tools that can afford to load it all at once.

What's actually inside the index file

The index file opens with ten numbered instructions aimed directly at an AI assistant, not a human reader. In order: use environment variables for credentials, never hardcode them; the exact SDK auth pattern (new StreamClient({ publicKey: ..., secretKey: ... })); fall back to fetch with the stream-public-key/stream-secret-key headers for endpoints the SDK doesn't cover yet, like payments and live streaming; the base URL, https://api.aiozstream.network/api; offset/limit pagination defaults (25, max 100); the rule that a media object gets created before a file is uploaded, not the other way around; polling video.getDetail(id) for a "done" status before returning a playback URL; the requirement that a live stream key exist before a session can be created; the five webhook event names; and the two API key types. That's not a marketing summary of the API, it's the actual operational sequencing a correct integration needs to follow, written for something that's going to act on it directly. The create-before-upload rule is a good example of why this matters more for an AI assistant than it would for a person skimming docs: a human reading a REST reference alphabetically or by resource name might reasonably try uploading first and creating the object second, since nothing about a typical API reference's structure signals which order matters. Spelling the sequence out explicitly, as an instruction rather than something to infer from endpoint descriptions, is exactly the kind of detail that prevents an assistant from generating plausible-looking code that calls the API in the wrong order.

The 12 section files

Beyond the index and full file, AIOZ Stream breaks the same content into 12 focused files: api-keys, media-video, media-audio, media-chapters, media-transcripts, players, playlists, webhooks, analytics, payments, live-streaming, and users. The point of splitting it this way is the same reason the index file exists at all, context budget. A tool working on a webhook handler doesn't need the payments file loaded at the same time, and a smaller, focused file is both cheaper to load and less likely to get diluted by irrelevant detail.

Why plain Markdown instead of an OpenAPI spec

AIOZ Stream could have published an OpenAPI/Swagger schema instead, and many APIs do. The tradeoff is token budget: an AI assistant reading a full JSON or YAML schema spends context on structural syntax that doesn't carry information, brackets, indentation, repeated type declarations, before it gets to the part that actually matters. Plain Markdown strips that overhead. It's also why the file favors realistic, concrete examples (the exact StreamClient constructor call, the exact base URL) over abstract parameter descriptions; an assistant generating code benefits more from seeing a working call than from reading that a field is "type: string." There's a real cost to this choice too, worth naming rather than glossing over: an OpenAPI spec is machine-validated by definition, tooling can check that the spec matches the actual API automatically. A hand-written Markdown file has no equivalent automatic check, which is exactly the mechanism behind the webhook-naming and split-subdomain inconsistencies found elsewhere in AIOZ Stream's docs. Token efficiency and drift-resistance pull in different directions here, and AIOZ Stream's llms.txt implementation has picked the former.

Setting it up per tool

The mechanics differ slightly by tool. In Claude's web interface or CLI, attach the file directly (the paperclip icon in the web UI) and describe the task, for example uploading videos and retrieving playback URLs. In Cursor, place the relevant section files in the project directory and @-mention them in chat so only the ones you need are in context. In ChatGPT, attach the file the same way as Claude and describe what you're building. In GitHub Copilot Chat inside VS Code, open the relevant files in the editor and reference them with #. None of these require an account or a special integration beyond the file itself; it's a document, not a service, which is also why nothing here is at risk of breaking if a specific tool changes its own product features later, the files sit on AIOZ Stream's own docs site independent of any AI assistant's roadmap.

This isn't just an AIOZ thing

The two-file pattern AIOZ Stream uses, a lean index plus a fully concatenated version, is the same shape Anthropic uses for its own developer docs. Fetching Anthropic's own llms.txt directly shows the same structure: a curated index with one-line descriptions per linked doc, meant to be read before deciding what to fetch in full. Estimates put llms.txt adoption at somewhere between 5 and 15% of websites as of 2026, with Anthropic, Stripe, Cloudflare, and Vercel among the companies that have shipped one. Still early, in other words, which is part of why AIOZ Stream having a working implementation is worth calling out rather than assuming as table stakes, especially in a decentralized-infrastructure category where AI-assistant-readable docs aren't yet a common expectation the way they've become for mainstream developer-tool companies.

The honest caveat

AIOZ Stream's own documentation includes a direct warning alongside all of this: "always verify final implementation details against the canonical AIOZ Stream documentation and live API behavior." That's worth taking at face value. A machine-readable file reduces how much an AI assistant has to guess, it doesn't guarantee the code it produces is correct on the first try, especially for anything that's changed since the file was last regenerated.

Frequently Asked Questions

Is llms.txt an AIOZ Stream invention?
No. It's an open convention (llmstxt.org) that AIOZ Stream has implemented; the format is shared across many companies' docs, not proprietary to this one.

Should I use the index file or the full file?
Use the index file with a context-limited tool, since it links out to only what's needed. Use the full file when the tool can load everything at once and you'd rather not manage multiple fetches.

Does the llms.txt file replace the human-readable docs?
No, it runs alongside them. The regular docs at aiozstream.network/docs are still the canonical reference; the llms.txt files are a second, AI-assistant-formatted view of the same information.

What base URL does the file tell an AI assistant to use?
https://api.aiozstream.network/api, per the index file's own stated instructions.

Is code generated from these files guaranteed to work?
No. AIOZ Stream's own documentation explicitly says to verify generated code against the canonical docs and live API behavior before trusting it.

Is AIOZ Stream unusual for having an llms.txt file?
It's still ahead of the curve rather than standard practice. Estimates put overall adoption around 5-15% of websites as of 2026, though Anthropic, Stripe, Cloudflare, and Vercel are among the larger companies that have already shipped one.

Related Reading

• AIOZ Stream Developer Guide: the full API and SDK surface these files document
• AIOZ Stream API Keys: the credential handling the index file's first instruction is about
• Getting Started with the AIOZ Stream Node.js SDK: the exact SDK auth pattern the index file references
• Building a Video Upload Endpoint with Cursor or Claude Code: this llms.txt file in actual use
• What Actually Makes an API Agent-Friendly?: auditing AIOZ Stream's own llms.txt against industry best practices
• Does AIOZ Stream Have an MCP Server?: how llms.txt compares to the MCP approach other platforms use

References

• AIOZ Stream AI documentation: the official source for every setup instruction and file described above
• llms.txt: the /llms.txt file: the general open standard AIOZ Stream's implementation follows