How long can instructions be

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.

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.

Do not skip over this distinction. 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 if a file is under the cap but over the attention budget?

The character counter cannot answer this. The one vendor statement on it is 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. It also says 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 limit that matters comes before the cap: adding one more rule starts making the existing rules less likely to be followed. 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 shows what a budget costs you. 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.
• 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. On this 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. The renderer enforces the cap rather than leaving it to the person filling it in, and marks anything past it non-binding.

People argue with that cap more than with any other decision in the product. 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 most authority, even if another has a bigger box. A file in a knowledge base with no authority does nothing, however many characters it is allowed. A 500-character instruction in a system-level slot gets followed instead.

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 questionnaire produces 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-09-24
• OpenAI: Model Spec checked 2026-08-16
• Anthropic: memory and CLAUDE.md checked 2026-09-24
• Cursor: rules checked 2026-08-16
• GitHub: add repository instructions checked 2026-08-16