How long can instructions be
You are looking at a box with a character counter and you want to know what fits. This page collects every published limit for the surfaces a brand voice file goes into, quoted from the vendor's own documentation. Where a limit is not documented, it says so rather than guessing, and it names the two widely repeated figures that turn out not to exist.
The short version: the caps are rarely the constraint that bites. Adherence falls off well before the character counter does, and the more useful question is not what fits but what survives. If you want the file rather than the reading, answer eleven questions and get one built to these limits.
This page sits under brand voice for AI, which covers why the same rules have to be written six different ways in the first place.
What is the documented cap on each surface?
These are the limits each vendor publishes. The units differ, deliberately: some vendors count characters, some count lines, and one counts bytes. Where a column says none documented, that is the finding rather than an omission.
| Surface | Documented limit | Unit |
|---|---|---|
| ChatGPT custom instructions, free and Go | 1,500 | characters per account |
| ChatGPT custom instructions, Plus, Pro, Enterprise, Business and Edu | 5,000 | characters per account |
| ChatGPT project instructions | None documented | n/a |
| Custom GPT instructions | None published by OpenAI | n/a |
| OpenAI Assistants API instructions | 256,000 | characters |
| Codex AGENTS.md | 32 KiB combined | bytes |
| CLAUDE.md, every tier | Under 200 | lines, stated as a target |
| Claude path-scoped rules | 4 MiB per rule | bytes |
| Agent Skills SKILL.md body | Under 500 | lines |
| Agent Skills description, specification | 1,024 | characters |
| Agent Skills description, claude.ai uploads | 200 | characters |
| Cursor project rules | Under 500 | lines |
| Copilot repository instructions | None documented | n/a |
One correction worth making because it is repeated everywhere. The ChatGPT custom instructions limit is not 1,500 characters per field. It is a per-account total, and it rises to 5,000 on a paid tier. If you have been budgeting two fields of 1,500 you have been working to a number that does not exist.
Which caps are documented, and which are folklore?
Two figures circulate widely enough that they appear in most guides on this subject. Repeated passes over GitHub's personal, organisation, Enterprise Cloud, concept and reference documentation found neither of them.
- A 3,000-character limit on Copilot personal instructions. Not in the documentation. The only character count on those pages sits inside GitHub's own example of a bad instruction.
- A 5,000-character limit on Copilot organisation instructions. Also absent. GitHub's single piece of quantitative size guidance is a line inside its recommended onboarding prompt: instructions must be no longer than two pages.
- An 8,000-character limit on Custom GPT instructions. This one is community-reported and may well be accurate in practice, but OpenAI publishes no figure, so it is not stated here as documented.
The distinction matters more than it looks. A documented cap is a contract you can build against. An observed cap is a measurement of today's deployment, and it moves without notice.
What happens to a file that is under the cap but over the attention budget?
This is the question the character counter cannot answer, and the one vendor statement on it is unusually blunt. Anthropic's memory documentation targets under 200 lines per CLAUDE.md and gives the reason directly: longer files consume more context and reduce adherence. It also notes that the files are loaded in full regardless of length, so nothing truncates. The file gets read and the rules get lost.
Anthropic's engineering guidance is sharper still. It suggests asking of every line whether removing it would cause a mistake, and cutting it if not, and it states that if the model keeps ignoring a rule you have written, the file is probably too long and the rule is getting lost in it.
Cursor arrives at the same place from a different direction. Its documented advice is to keep a rule under 500 lines and split larger guidance into composable rules, and its anti-pattern list names copying entire style guides, with the recommendation to use a linter instead. That warning is about code style, but the shape of it generalises exactly: a four-thousand-word brand bible pasted into a rules file is the failure mode two vendors independently warn about.
So the operative limit is not the cap. It is the point at which adding a rule makes the existing rules less likely to be followed, and every vendor who has commented places that point far below their own documented ceiling.
The same voice compiled to five lengths
The download from this site renders the same voice at five sizes: 500, 1,500, 3,000, 5,000 and 8,000 characters. They map onto the caps above, and none of them is a longer version cut short. Each is rendered from the same source to fit its budget, which is why the 500-character version is a usable instruction rather than a truncated sentence.
Seeing them side by side is the fastest way to understand what a budget costs you, and the full manifest lists every rendered length with the destination each one is for.
What gets cut first, and in what order
The order is fixed, and it is the reverse of what most people cut by hand. Worked examples are kept longest and adjectives go first.
- Adjectives and personality description go first. They are the largest share of most voice documents and the least actionable: warm means something different to everybody, and a model cannot act on it.
- Rationale goes next. The reason a rule exists is useful to a person and costs a model context it will spend on the rule itself.
- Secondary rules go third, in the order the questionnaire ranked them, which is why the ranking question exists.
- Mechanical rules stay: person, contractions, spelling variant, punctuation prohibitions. They are a few characters each and they change every sentence.
- Worked examples stay longest of all, because a short pair of before-and-after sentences does more work per character than any description of a voice.
Does a longer file get you more adherence?
No, and this is the one place where the vendors, the research and this project's own design all agree. Compliance with a set of constraints degrades as the constraints stack: the effect is large enough that the file this tool produces caps at fifteen binding rules by design, with thirty as an absolute ceiling enforced by the renderer rather than left to the person filling it in.
That cap is the single most counter-intuitive decision in the product, and it is the one most often argued with. The limits page sets out what a file cannot fix, including where adherence degrades and which instruction shapes are ignored regardless of length.
Which surface should get the long version
Give the long version to the surface with the highest authority, not the one with the biggest box. A file sitting in a knowledge base with no authority is inert however many characters it is allowed, and a 500-character instruction in a system-level slot will beat it.
Why an assistant ignores your instructions covers the precedence chain that decides this, and what happens when two instruction files disagree covers the case where you have filled in more than one box.
If you would rather not work it out surface by surface, the eleven questions produce every length and every format at once, with each file named for where it goes.
Where these come from
Every claim above is quoted from one of these, and each was read on the date beside it. If one of them has changed since, the page is wrong and we would like to know.
- OpenAI: custom instructions checked 2026-08-16
- OpenAI: Model Spec checked 2026-08-16
- Anthropic: memory and CLAUDE.md checked 2026-08-16
- Cursor: rules checked 2026-08-16
- GitHub: add repository instructions checked 2026-08-16
Every one of these lengths is rendered from the same source rather than cut down: build a voice file at all five sizes at once.