Language, format, placement: how to write prompts an LLM understands better

I spend my days wrangling big prompts to language models — and the same question keeps coming up: what actually works better? Is it true that if you write tersely, telegraph-style, with no filler, the model both understands more precisely and costs you less? People say Chinese prompts come out cheaper — does that hold up? And more broadly: does the language you write in matter, do you really need headings and lists, and where do you put the main question so it doesn’t get lost?

These questions keep nagging, and every so often you stumble onto something worth passing along. I dug through the research, checked it against my own experience, and here’s what came out.

TL;DR. The short version — here’s what works:

🌐 Language. It pays to write your instructions in English: in another language the prompt doesn’t shrink, it bloats — a non-English language costs the model roughly twice as much (for Russian, about ×2). And "write in Chinese, you’ll save tokens" is, for the popular models, just a myth.
📍 Placement. A model notices the beginning and the end best, and loses the middle easily. So put the most important things — and the question itself — at the edges, not buried in between.
🧱 Form. Simple markup with headings and lists is the clearest of all; save heavy technical formats for data, not for the request itself.
✂️ Brevity. Cutting filler words really does help — but it saves a real ~15–20%, not the promised "minus 75."
🔣 Glyphs. Emoji and box-drawing characters used to "save space" only get in the way.
🪜 Order. First sort out what goes where and how it’s formatted, then language, and squeezing the length is the very last thing to do.

If you’re just chatting with a bot, the first two — language and placement — are what truly help you; the rest matters more for people tuning a model to their task or wiring it into a product. Now each point in turn, with examples and numbers.

Before you start: two budgets

Whatever you’re writing to the model, it all comes down to two limited resources — and almost every technique below is about spending them wisely.

💰 The token budget — money and space

The model doesn’t see letters: text is cut into tokens (chunks of words), you pay per token, and tokens are also what fills up the context window. You don’t do the cutting — the tokenizer does, and unevenly: the same meaning takes a different number of tokens across languages and formats. An English phrase packs noticeably tighter than a Russian one; clean Markdown packs tighter than the same meaning in JSON. Exactly how much, we’ll count up in the techniques; the gap between languages isn’t a matter of percent — it’s a multiple.

🎯 The attention budget — quality

Even when everything fits in the window, the model reads it unevenly: attention is a finite resource, and it goes mostly to the edges, while the middle sags. The longer the prompt, the stronger the effect. So where you put the important stuff decides whether the model even notices it.

Next we’ll go through five key techniques for working with prompts and optimizing these budgets. But the same technique costs differently in a live chat than in a prompt "baked into" a product: in one place a miss costs pennies, in another it multiplies across millions of calls. So keep four task types in mind — each with its own cost of error and its own budget headroom:

Four task types

Chat — you write to the model directly, in plain words, one-off. A mistake is cheap: didn’t like it, you ask again.
Production prompt (system prompt) — a single prompt baked into a product and called at scale; the answer is often parsed by code. Every extra token and every ambiguity multiplies across the call volume.
Agent harness — the permanent "scaffolding" of an autonomous or coding agent: instructions, a skill set, tool descriptions, memory between steps. The context is huge and long-lived, so the cost — both in tokens and in inattention — is highest here.
Data — whatever you pour inside any of the three: documents, tables, tool outputs, chunks pulled in by search. Broken out separately, because data has its own packing rules.

Technique 1 · 🌐 Language and tokenization

Choice of language is a lever on cost and quality, not on size: you won’t shrink a prompt by switching languages, but you can easily overpay and lose precision. On Western models an English instruction core is usually both cheaper and more accurate — but you can address the model in whatever language is convenient, and that works fine.

Why the same meaning costs different amounts. Two things get conflated here. First, information density: how much meaning fits in a character (it’s high for ideographic scripts). Second, how the tokenizer cuts the text: under the hood is BPE (byte-pair encoding — slicing into frequent chunks), trained mostly on English, so it encodes English economically and fragments the rest. These two forces pull in opposite directions — and the slicing outweighs the density.

Rough guides for Western tokenizers:

English — about 4 characters per token, the most economical language.
Non-English languages — multiples more tokens for the same meaning. Russian, for example, is roughly twice as many: Tokenizer Tax across 25 European languages (2026), the first controlled comparison on parallel texts, puts Slavic languages at the most expensive end, while Petrov et al. (2023) gives a gap of more than 4× for some language pairs — and English carries the smallest markup.
Cyrillic pays extra at the byte level: a study on Ukrainian (Frontiers, 2025) reminds us that a Cyrillic character is encoded as 2 bytes even when it isn’t in the vocabulary.

STRR (2025), on six tokenizers and seven languages, confirms the same picture: English keeps tokens-per-word consistently low, and outside the Latin script it’s high.

💡 What this means in practice. The same prompt in a non-English language is multiples more tokens; for Russian it’s about ×2: twice as expensive, and you hit the window twice as fast. Not by percentages — by multiples.

This is also where the advice "write in Chinese, you’ll save tokens" falls apart. The ideograph is dense, but the tokenizer fragments it into several tokens, and the gain gets eaten. A direct test came from Mythbuster (2026) (preprint): the saving isn’t confirmed, it depends on the model, and quality in Chinese is on average lower. For the popular models, Chinese isn’t cheaper — and often enough it’s more expensive and worse. So language by itself doesn’t shrink the prompt: all of English’s advantage is in the price of tokens and in quality, not in size.

A common case: English instructions — answer in the user’s language

English lives better in instructions — but it’s often more convenient and more effective for the user to write in their own language, and that works. The typical setup: system prompt and instructions in English, while the user writes in their own language and wants the answer in it too. Let’s look at where it’s strong and where it stumbles.

Why an English core pays off. The English-centricity of models is a measured fact. Cross-lingual studies (2025) consistently give English instructions first place on quality — with an important caveat: for small post-trained models (7–9B) the picture flips in places, and the native language works no worse. That is, "English is better" is about large frontier models, not a law of nature. Plus an English core is cheaper in tokens.

How to keep a non-English output from "drifting." There are proven techniques:

Give the output-language command on a separate line and at a pole (at the start or the end), don’t weave it into the middle. Language Confusion (EMNLP 2024) shows it directly: an isolated language instruction confuses the model noticeably less than an integrated one, and a single example pushes correct-language output to about 80% even where the model was floundering.
Align the language of input, reasoning, and output. When Language Shapes Thought (2025): a forced mismatch ("think in one, answer in another") worsens knowledge retrieval. If you need nuance in the user’s language — let it reason in that language too; if factual accuracy matters more — English reasoning plus a translation into the user’s language at the end.

Where it stumbles:

Matching languages doesn’t save you on its own. Tears or Cheers? (2026): English prompts are on average better, while matching the prompt’s language to the data’s language does not improve quality. "At least it’s all in one language" is not an argument.
Translation loses shades. The "English core → user-language render" chain is accurate on facts but poorer on nuance and tone than reasoning in the user’s language. For legal or cultural nuance, that’s a price.
Safety. XSafety (2023): on non-English prompts models more often produce unsafe answers — for production systems with user input that’s a separate risk, which an English instruction core partly removes.

📌 Short recipe. English instructions + an explicit, isolated output-language command + one example. Reasoning in the user’s language — where nuance matters; an English core with a translation at the end — where accuracy and cost matter more. And don’t expect "everything in one language" to improve anything on its own.

On tone: politeness and language

An unexpected but tested nuance. Mind Your Tone (2025), on a small sample, found that a slightly rude prompt gave higher accuracy than a polite one. It’s tempting to conclude "be rude to the model" — but don’t rush: a cross-lingual study (2024) shows that the politeness optimum depends on the language, and the balance point is different for each. Most non-English languages haven’t been measured separately, so the takeaway is modest: excess politeness ("please, would you be so kind, if it’s not too much trouble") is just tokens — cut it; deliberately being rude isn’t worth it.

✅ Pattern	⛔ Antipattern
Instructions in English; language command explicit, at a pole, + one example	Shrinking a prompt by "rewriting it in Chinese"
Aligned language of input / reasoning / output	Forcing the model to think in one language and answer in another with no need
Cut excess politeness (it’s just tokens)	Thinking "at least it’s all in one language" will improve the answer

Technique 2 · ✂️ Caveman / brevity (telegraphic style)

"Caveman," telegraphic style is when you throw out the "glue" (function words, courtesies) and keep only the substance: rules, tool names, values. Example:

Before: "Please, would you mind, if it’s not too hard, looking through the list below and removing the duplicate entries from it."
After: "Scan the list, remove duplicates."

Same meaning, a third of the tokens. This style fully pays off in agents, in a lightened form — in system prompts, and in ordinary chat it isn’t needed: there’s no point squeezing a one-off short request. On instructions it saves about 15–20%, not the viral "−75%."

Where the numbers come from. "−75%" is a best case and only for output tokens ("up to 75%" on a chatty answer), not a saving on the prompt itself. By actual measurements it’s more modest, but still nice:

On instructions — ~15–20% (14–21% across different measurements) while preserving meaning. In one reproducible micro-test by the author, an 85-token distillate beat a 552-token prompt while keeping 100% of the facts — it’s not a big benchmark, but it’s telling.
In multi-turn sessions with caching it adds up to ~39%.
Agentic patterns cut more radically: CaveAgent (2026) — −28% total tokens with a rising success rate by collapsing steps.
The bonus isn’t only about money: Hakim, "Brevity Constraints" (2026), on 31 models and 1485 tasks: a brevity constraint raised large-model accuracy by +26 pp where verbosity was muddling the answer (the model talks itself into the wrong one). This is one study so far, but the effect is striking.

A counterweight from practitioners cools expectations: the saving across a whole session more often comes out at ~4–10%, and part of what’s claimed doesn’t survive to the token bill.

An important caveat about reasoning. Apply telegraph to instructions and output, but not to the internal chain of reasoning: with DeepSeek-R1 or Claude in extended thinking, clamping the reasoning is harmful. And don’t over-engineer the compressor itself — a short directive ("be concise, cut the water, keep all rules and values") beats an elaborate rulebook.

✅ Pattern	⛔ Antipattern
Cut the glue in reusable and agentic prompts	Turning on telegraph for a one-off chat request
Preserve rules, names, values verbatim	Cutting so hard that meaning is lost
Brevity on the final output	Clamping the internal reasoning of a reasoning model

Technique 3 · 🧱 Formats: Markdown, XML, YAML, JSON

Models understand Markdown best: training text is saturated with it, and the tokenizer encodes it economically, whereas JSON with its brackets and quotes gets fragmented. And keep in mind that the markup itself is also tokens: every tag, bracket, and quote is paid for, so heavy markup (XML, JSON) on the same content comes out more expensive than light markup (Markdown).

A model also understands best the formats it has seen a lot of in training, regardless of how elegant they are in theory. The fate of the TOON format is telling: it saves tokens but loses on comprehension, because there are few examples of it. All of this applies first of all to the body of the instruction (the system prompt) and to the form in which you feed in data.

🛠️ From my practice: structure pays off twice. While you’re breaking the instruction into sections and bullets, you’re clarifying it for yourself — half of a prompt’s bugs get fixed simply because you write structurally rather than as a wall of text. And only then the second payoff: the model reads such an instruction more precisely. So structure works for you even before it reaches the model.

🛠️ From practice: write it readably while a human is working with the prompt. When you yourself read and debug the instructions and answers, a human-readable format (Markdown, YAML) is half the battle: your eyes can see where the prompt broke and what the model misread. But if both the prompt and the answer are generated and consumed only by code, readability is no longer the priority — optimize for the machine.

How to apply it:

Instruction body — Markdown (headings, bullets). Mark up the prompt like a short article: ## Role, ## Context, ## Task, ## Output format, with lists inside. That format affects quality is confirmed by He et al. (2024): for GPT-3.5 the spread across templates reached 40% (large models are steadier). There’s no single optimum, but Markdown is a solid default.
Section boundaries — XML tags (<instructions>, <context>, <examples>, <output_format>). Wrap large blocks in tags so the instruction doesn’t "leak" into the data, or an example into the context. XML is verbose, so it’s a container for boundaries, not the language of the body itself.
Nested data — YAML, not JSON. The same data in YAML is shorter and readable by eye — indentation instead of a ladder of brackets and quotes. In improvingagents (2025) measurements YAML beats XML, which inflates tokens by +80% over Markdown (on most models). For tables, Markdown-KV is good (~60.7%, benchmarked on GPT-4.1-nano).
JSON — only at the output boundary, where the result is parsed by code (for example, the answer goes to an API or a script). Rigid structured output chokes reasoning: Tam et al., "Let Me Speak Freely?" (2024) records a noticeable drop. Let the model solve a reasoning task in prose, and package the finished answer into JSON in a separate step.

About trendy "economical" formats — go carefully. Serializations keep surfacing with the promise of "the same data, but a fraction of the tokens." The big one right now is TOON (Token-Oriented Object Notation): a compact repacking of JSON — indentation instead of brackets, tabular rows for homogeneous arrays. The interest is real (a 1.0 release, thousands of stars, SDKs for dozens of languages), and imitators are already multiplying. Before you move a prompt to a trendy format — a couple of sobering facts:

Cheaper ≠ clearer, and the saving is measured against bloated JSON. The claimed "minus 40–55%" is against "indented" JSON: against compact JSON the gain drops to about 25%, against YAML to 38%, and for flat tables plain CSV is shorter than TOON itself. And in a comparison of 11 formats (improvingagents, 2025) the most economical, CSV, gave the worst accuracy (~44%), while the most accurate, Markdown-KV (~61%), cost almost three times more tokens.
But it’s not "always worse" either. On homogeneous tabular data, TOON in its own benchmark beats JSON on both axes at once. So it’s not "economy always kills comprehension," but a trade-off whose direction depends on the shape of the data and on what you’re comparing against — an independent measurement (Matveev, 2026) on short contexts actually handed accuracy to plain JSON.

And don’t confuse format with prompt compression (like LLMLingua, which uses a separate model to throw out low-value tokens) — that’s a different tool.

The takeaway: chasing an economical format for the sake of tokens almost never pays off in the instruction body. For data it’s sometimes justified — but only if you measured it on your own task and data shape, rather than believing the headline.

✅ Pattern	⛔ Antipattern
Markdown body + XML section boundaries	Writing the whole instruction body in JSON
YAML / Markdown-KV for data	Deeply nested JSON as a reasoning format
JSON only on a parsed output	Rigid JSON output on a reasoning task

Technique 4 · 📍 Placement and attention

💡 The important things and the question itself go at the poles of the window, not in the middle: attention barely reaches there. Don’t count on the whole window: the reliable length is less than in the spec, and the longer the prompt, the more a placement miss costs.

Behind this are several converging results. Lost in the Middle (2023): accuracy is U-shaped — higher when the needed thing sits at the edges, and it sags in the middle (on multi-document QA — a gap of around 20 points). Found in the Middle (2024) exposes the mechanism: attention itself is distributed toward the poles, regardless of where the answer lies. Chroma "context rot" (2025): similar but irrelevant content actively throws it off — even one extra chunk drops quality, four make it worse. And the working length of the window is shorter than advertised: "Context Is What You Need" (2025) records effective context many times below the stated figure, and the benchmarks NoLiMa (2025) and RULER (2024) show that already at 32K half the models fall apart. The space the model actually trusts is smaller than the spec says, and its middle is the weakest. Now — where to put what, by task type:

Chat: if a long document is pasted above, put the question itself at the very end.
Production prompt: the format spec and the variable part — at the tail.
Harness: critical rules — at the poles: the context is huge (200k+), and the middle sags the most. The stakes here are far higher than in chat.
Data: relevant chunks — at the poles, ranked by relevance; don’t dump everything "just in case": the extra only throws it off.

This also applies to examples (few-shot): a study on the positional bias of few-shot (2025) shows that the same block of examples, shifted by position, moves accuracy by up to 50 pp. Examples are not only "which" but "where."

And while we’re on examples — it’s better to set the form of the model’s answer by a sample than by a prohibition:

📌 An example beats a prohibition. "Don’t do X" without showing "do it like this" works poorly — the model latches onto the form of the example, not onto the abstract prohibition. For a structured answer this rule is ironclad: give at least one sample.
⛔ Prohibition without a sample:
   "Don't write at length. Don't use markdown. Answer in JSON only."

✅ Structure + one sample:
   <output_format>
   Return JSON strictly per the sample:
   {"verdict": "pass", "score": 0.87, "reason": "one short phrase"}
   </output_format>

You can also direct attention explicitly, but with a caveat: Attention Instruction (2024) shows that a by-index pointer ("block #2," "section X") works reliably, while a vague "pay attention to the middle" is weaker. Inference-time methods like SEAL (2025) also help pull the needed thing out of a long context (it’s a trainable attention-strengthening method, not just a prompt trick). On models — a separate section below.

✅ Pattern	⛔ Antipattern
Key content, the question, and examples — at the poles	Hiding the main instruction or examples in the middle
One answer sample for structured output	A bare "don’t do it like this" prohibition with no "do it like this"
Relevant data — toward the edges, ranked	Dumping everything into the window "just to have it"
A by-index pointer "look at block #X"	Hoping the model finds the needed thing in the middle on its own

Technique 5 · 🔣 Special characters, emoji, separators

The intuition that "compact glyphs save space" breaks against the tokenizer. A simple emoji costs about a token, while composite ones — flags, modifiers — blow up into several byte tokens, sometimes a dozen, whereas the word "the" costs one. Box-drawing and ASCII tables are expensive too: the borders alone eat a pile of tokens. Program symbols (===, operators), on the other hand, are cheap.

Separators, though, are an underrated lever. A separator is what you use to set off one chunk of the prompt from another: ### in a heading, a --- line, <context>…</context> tags, triple quotes around text, a vertical bar in a table. Seems like a trifle — but "A Single Character can Make or Break Your LLM Evals" (2025) shows that the choice of separator alone shifts the result by tens of percent, and — most unpleasant — the fragility grows with model scale: by picking a separator you can even tweak which model "wins" in a comparison.

📌 The takeaway isn’t "find the magic symbol," but "pick sensible separators (Markdown headings, XML tags) and stick with them across the whole prompt."

A simple failure: in one section you set off blocks with hashes ###, in another with asterisks, in a third with just a blank line; it’s harder for the model to tell where the instruction ends and the data begins, and your own measurements turn to noise.

So for saving space, glyphs are useless — emoji and box-drawing are only a minus. But for reliability, the choice of separator matters more than it seems. Build structure with headings and tags, not with glyphs.

(And yes — this post has emoji, but those are for you humans, to grab the key points on the run. Inside a prompt for the model, there’s no point.)

✅ Pattern	⛔ Antipattern
Simple, consistent separators (Markdown/XML)	Changing separators from section to section
Minimum of decorative characters	Wrapping the prompt in emoji "for focus"
Structure through headings/tags	ASCII tables and borders for the sake of "looks"

How different models work

The techniques are general, but frontier models place their accents in their own way.

Everyone agrees on one thing: structure the prompt with XML tags or Markdown with explicit separators. And, as the Gemini documentation puts it directly, the choice of format itself is secondary — what matters more is to pick one and stick with it. And in reasoning modes the advice is common to all: don’t overload the prompt, don’t force examples, give a high-level goal.

ChatGPT (OpenAI). Instructions up front, separators sharp; responsive to a conversational, role-based style. GPT-5 has an anchored system layer.
Claude (Anthropic). XML-native: tags for sections, the request at the end of a long context (Anthropic’s docs record a gain of "up to 30%"). The guide "Effective context engineering" calls for "the smallest set of high-signal tokens" and the "right altitude" for instructions; "Building Effective Agents" adds, separately, that tool descriptions deserve as much attention as the prompt itself.
Gemini (Google). Likes compact prompts; XML or Markdown — your choice, but consistently; terse by default. Grounding via search is a toggleable tool, not a phrase in the prompt.
DeepSeek. V3/V4 like structure: Markdown headings, bullets, and XML improve adherence. The cache works top to bottom: static content up top, the dynamic request at the end, don’t mix them. R1 (reasoning) — no few-shot, high-level goals; JSON is weaker on R1 than on V3. (There’s an idea that XML markers help MoE routing — the model picks which of its many expert sub-networks to switch on — but that’s the guess of a single blog, not a documented mechanism; don’t bank on it.)

Finale: assembling per task

General decisions — for any task type

First, the cross-cutting questions: the answer to them doesn’t depend on whether you’ve got a chat, a production prompt, or an agent.

Need to save? First put placement and format in order, then think about language, and leave compression (caveman) for last: it gives the least and breaks meaning the most easily.
Is the task a reasoning one? Let the model think in prose — don’t clamp the reasoning with rigid JSON and don’t turn on telegraph for the reasoning chain; you’ll impose structure on the finished answer in a separate step.
Is the prompt long? The important things and the question itself — at the poles, not the middle, and don’t count on the whole window.
Does a program read the answer? JSON only at the very output boundary and as a separate step — not in the same place where the model reasons.
Writing in a non-English language? An English instruction core + an explicit output-language command at a pole + one example.

Stack per type

Chat — don’t overcomplicate:

prose, a convenient language; the output-language command — explicit and at a pole;
the question at the end, if there’s a long text above;
don’t optimize tokens, don’t turn on caveman. The cost of a mistake is pennies.

Production prompt:

body — Markdown, section boundaries — XML;
caveman-lite: cut the "glue," but preserve rules and names;
a couple of canonical examples (few-shot);
the format spec and the variable part — at the tail;
JSON — only on the output that a program parses.

Agent harness:

caveman full-bore; work tool descriptions like a separate prompt;
critical rules — at the poles; memory between windows (a progress file);
don’t clamp the reasoning; remember that the effective window is smaller than stated.

Data:

YAML or Markdown-KV instead of JSON/CSV; don’t overcomplicate the format;
cut into chunks and pull out what’s needed, rather than dumping everything;
the relevant stuff — at the poles.

And a quick run-through before sending a big prompt: key content and the question at the poles? body — Markdown, section boundaries — XML? JSON/YAML — only for data, not for the instruction body? "glue" cut (if the prompt is reusable or agentic)? reasoning not clamped? language command — with an example? separators chosen and uniform across the whole prompt?

And one last thing — so this mountain of numbers doesn’t throw you off. Trust the large, repeatedly reproduced effects (important things at the poles, an English core is cheaper, rigid JSON chokes reasoning) and take the one-off sensational percentages more calmly: some of them live only in the way they were measured (Flaw or Artifact?, 2025). Have your own task — measure on it, not on someone else’s benchmark.

Sources

Tokenization and languages. Petrov et al., 2023; Mythbuster: Chinese is not more efficient, 2026 (preprint); STRR / Beyond Fertility, 2025; Tokenizer Tax, 25 European languages, 2026; Ukrainian tokenization, Frontiers, 2025.

Caveman / brevity. Hakim, Brevity Constraints, 2026; CaveAgent, 2026; caveman-micro (Guzik); Better Stack (≈39% with caching); critique of compression, Hecatus, 2026.

Placement and attention. Lost in the Middle, 2023; Found in the Middle, 2024; Attention Instruction, 2024; Chroma context rot, 2025; Context Is What You Need (MECW), 2025; NoLiMa, 2025; RULER, 2024; SEAL, 2025; few-shot position, 2025.

Formats. He et al., effect of format, 2024; Tam et al., "Let Me Speak Freely?", 2024; improvingagents: nested data and tables; TOON (format + benchmark); Matveev, independent TOON measurement, 2026; Flaw or Artifact?, 2025.

Language, tone, safety. When Language Shapes Thought, 2025; Language Confusion, 2024; Tears or Cheers?, 2026; cross-lingual retrieval, 2025; Mind Your Tone, 2025; politeness cross-lingually, 2024; XSafety, 2023; the separator decides, 2025.

Context engineering and models. Anthropic, context engineering; Anthropic, building effective agents; Gemini prompting docs; DeepSeek guide.

Язык, форма и место: как писать запросы, чтобы нейросеть понимала лучше

Каждый день вожусь с большими запросами к нейросетям — и постоянно всплывает вопрос: а как лучше? Правда ли, что если писать сухо и телеграфно, без лишних слов, модель и поймёт точнее, и обойдётся дешевле? Говорят, по-китайски запросы выходят экономнее — это так? И вообще: важно ли, на каком языке писать, нужно ли городить заголовки и списки, куда деть главный вопрос, чтобы его не потеряли?

Такие вопросы возникают сами собой; иногда попадается находка, которой хочется поделиться. Я перерыл исследования, сверил со своим опытом — вот что вышло. Делюсь.

TL;DR. Если совсем коротко — работает вот что:

🌐 Язык. Писать инструкции выгоднее по-английски: на другом языке запрос не сжимается, а, наоборот, раздувается — русский обходится нейросети примерно вдвое дороже. А «пиши по-китайски, сэкономишь» для популярных моделей — просто миф.
📍 Место. Нейросеть лучше всего замечает начало и конец, а середину легко теряет. Поэтому самое важное — и сам вопрос — ставьте по краям, не прячьте в середину.
🧱 Форма. Простая разметка заголовками и списками понятнее всего; сложные технические форматы лучше оставить для данных, а не для самой просьбы.
✂️ Краткость. Убирать лишние слова и правда помогает — но экономит реальные ~15–20%, а не обещанные «минус 75».
🔣 Значки. Эмодзи и рамочки ради экономии места только мешают.
🪜 Порядок. Сначала разберитесь, что где стоит и как оформлено, потом — язык, а ужимать длину стоит в самую последнюю очередь.

Если вы просто переписываетесь с чат-ботом, вам по-настоящему пригодятся первые два — язык и место; остальное больше для тех, кто настраивает нейросеть под свою задачу или встраивает её в продукт. Дальше — про каждый пункт по порядку, с примерами и цифрами.

Прежде чем начать: два бюджета

Что бы вы ни писали модели, всё упирается в два ограниченных ресурса — и почти все приёмы ниже сводятся к тому, чтобы тратить их с умом.

💰 Бюджет токенов — это деньги и место

Модель не видит буквы: текст режется на токены (куски слов), за токены вы платите, и в них же упирается окно контекста. Режете не вы, а токенизатор — и неравномерно: один и тот же смысл на разных языках и в разных форматах занимает разное число токенов. Английская фраза укладывается заметно плотнее русской, аккуратный Markdown — плотнее того же смысла в JSON. Насколько именно — посчитаем в приёмах; разница между языками не процентная, а кратная.

🎯 Бюджет внимания — это качество

Даже когда всё уместилось в окно, модель читает его неровно: внимание — конечный ресурс, и достаётся он в основном краям, а середина проваливается. Чем длиннее промпт, тем сильнее эффект. Поэтому место, где лежит важное, прямо решает, заметит ли его модель.

Дальше мы рассмотрим пять ключевых приёмов работы с промптами и оптимизации этих бюджетов. Но один и тот же приём в живом чате и во «вшитом» в продукт промпте стоит по-разному: где-то промах — копейки, а где-то множится на миллионы вызовов. Поэтому держим в уме четыре типа задач — у каждого своя цена ошибки и свой запас по бюджетам:

Четыре типа задач

Чат — вы пишете модели напрямую, обычными словами, разово. Ошибка дёшева: не понравилось — переспросили.
Прод-промпт (системный промпт) — один промпт, зашитый в продукт и вызываемый массово; ответ часто разбирает программа. Каждый лишний токен и каждая двусмысленность множатся на объём вызовов.
Агентный harness — постоянная «обвязка» автономного или кодинг-агента: инструкции, набор навыков, описания инструментов, память между шагами. Контекст огромный и живёт долго, поэтому цена и за токены, и за невнимание здесь максимальная.
Данные — то, что вы вливаете внутрь любого из трёх: документы, таблицы, выводы инструментов, найденные поиском куски. Вынес отдельно, потому что у данных свои правила упаковки.

Приём 1 · 🌐 Язык и токенизация

Выбор языка — это рычаг цены и качества, а не объёма: сжать промпт сменой языка не выйдет, зато легко переплатить и потерять в точности. На западных моделях английское ядро инструкций обычно и дешевле, и точнее — но обращаться к модели можно на любом удобном языке, и это нормально работает.

Почему за один и тот же смысл платят по-разному. Тут смешивают две вещи. Первая — информационная плотность: сколько смысла влезает в символ (у иероглифов она высокая). Вторая — как токенизатор режет текст: под капотом BPE (byte-pair encoding — нарезка на частые куски), обученный в основном на английском, поэтому английский он кодирует экономно, а остальное дробит. Эти две силы тянут в разные стороны — и нарезка перевешивает плотность.

Ориентиры для западных токенизаторов:

Английский — около 4 символов на токен, самый экономный язык.
Неанглийские языки — за тот же смысл кратно больше токенов. Русский, например, — примерно вдвое больше: Tokenizer Tax по 25 европейским языкам (2026), первое контролируемое сравнение на параллельных текстах, ставит славянские языки в самый дорогой конец, а Petrov et al. (2023) для некоторых пар языков даёт разницу больше 4× — и у английского наценка наименьшая.
Кириллица платит дополнительно на уровне байтов: исследование по украинскому (Frontiers, 2025) напоминает, что кириллический символ кодируется как 2 байта, даже если его нет в словаре.

STRR (2025) на шести токенизаторах и семи языках подтверждает ту же картину: у английского токенов на слово стабильно мало, вне латиницы — много.

💡 Что это значит на практике. Тот же промпт на неанглийском языке — кратно больше токенов; для русского это примерно ×2: вдвое дороже и вдвое быстрее упираешься в окно. Не на проценты — в разы.

Отсюда же разваливается совет «пиши по-китайски, сэкономишь». Иероглиф плотный, но токенизатор дробит его на несколько токенов, и выигрыш съедается. Прямую проверку дал Mythbuster (2026) (препринт): экономия не подтверждается, зависит от модели, а качество на китайском в среднем ниже. Для популярных моделей китайский не дешевле — а нередко дороже и хуже. Так что сам по себе язык запрос не сжимает: весь выигрыш английского — в цене токенов и в качестве, а не в объёме.

Частый случай: английские инструкции — ответ на языке пользователя

Английский лучше живёт в инструкциях — но пользователю часто удобнее и эффективнее писать на своём языке, и это работает. Типичная схема: системный промпт и инструкции по-английски, а пользователь обращается на своём языке и хочет ответ на нём же. Схема рабочая; разберём её сильные стороны и места, где она спотыкается.

Почему английское ядро выгодно. Англоцентричность моделей — измеренный факт. Кросс-язычные исследования (2025) стабильно отдают английским инструкциям первое место по качеству — с важной оговоркой: у небольших post-trained моделей (7–9B) картина местами переворачивается, и родной язык работает не хуже. То есть «английский лучше» — про крупные фронтирные модели, а не закон природы. Плюс английское ядро дешевле по токенам.

Как не дать русскому выводу «поехать». Есть проверенные приёмы:

Команду о языке вывода давайте отдельной строкой и на полюсе (в начале или в конце), а не вплетайте в середину. Language Confusion (EMNLP 2024) прямо показывает: изолированная инструкция о языке путает модель заметно меньше интегрированной, а один пример поднимает долю правильного языка примерно до 80% даже там, где модель плыла.
Согласуйте язык ввода, рассуждения и вывода. When Language Shapes Thought (2025): принудительный mismatch («думай на одном, отвечай на другом») ухудшает извлечение знаний. Нужен нюанс на языке пользователя — пусть на нём и рассуждает; важнее точность фактов — английское рассуждение плюс перевод на язык пользователя в конце.

Где спотыкается:

Совпадение языков само по себе не спасает. Tears or Cheers? (2026): английские промпты в среднем лучше, а вот совпадение языка промпта с языком данных качество не улучшает. «Заодно всё на одном языке» — не аргумент.
Перевод теряет оттенки. Связка «английское ядро → русский рендер» точна на фактах, но беднее на нюансе и тоне, чем русское рассуждение. Для юридического или культурного нюанса это цена.
Безопасность. XSafety (2023): на не-английских запросах модели чаще выдают небезопасные ответы — для прод-систем с пользовательским вводом это отдельный риск, который английское ядро инструкций частично снимает.

📌 Короткий рецепт. Английские инструкции + явная изолированная команда о языке вывода + один пример. Рассуждение на языке пользователя — где важен нюанс; английское ядро с переводом в конце — где важнее точность и цена. И не ждите, что «всё на одном языке» само по себе что-то улучшит.

Про тон: вежливость и язык

Неожиданный, но проверенный нюанс. Mind Your Tone (2025) на небольшой выборке нашёл, что грубоватый промпт давал точность выше вежливого. Заманчиво вывести «хами модели» — но не спешите: кросс-язычная работа (2024) показывает, что оптимум вежливости зависит от языка, и точка баланса своя для каждого. Для большинства неанглийских языков отдельного замера нет, так что вывод скромный: лишняя вежливость («пожалуйста, будь добр, если не трудно») — это просто токены, можно срезать; специально грубить не стоит.

✅ Паттерн	⛔ Антипаттерн
Инструкции на английском; команда о языке — явно, на полюсе, + один пример	Сжать промпт, «переписав его по-китайски»
Согласованный язык ввода / рассуждения / вывода	Без нужды заставлять модель думать на одном языке, а отвечать на другом
Лишнюю вежливость — убрать (это просто токены)	Думать, что «заодно всё на одном языке» улучшит ответ

Приём 2 · ✂️ Телеграфный стиль (caveman)

«Пещерный», телеграфный стиль — это когда из промпта выкидывают «клей» (служебные слова, реверансы) и оставляют только содержание: правила, имена инструментов, значения. Пример:

Было: «Пожалуйста, не мог бы ты, если не сложно, просмотреть список ниже и убрать из него повторяющиеся записи».
Стало: «Просмотри список, убери дубликаты».

Смысл тот же, токенов втрое меньше. Полностью окупается такой стиль в агентах, в облегчённом виде — в системных промптах, а в обычном чате не нужен: одноразовый короткий запрос ужимать незачем. На инструкциях это экономит примерно 15–20%, а не вирусные «−75%».

Откуда берутся цифры. «−75%» — лучший случай и только по выходным токенам («до 75%» на болтливом ответе), а не экономия самого промпта. По замерам скромнее, но приятно:

На инструкциях — ~15–20% (по разным замерам 14–21%) при сохранении смысла. В одном воспроизводимом микро-тесте автора 85-токенный дистиллят бил 552-токенный промпт, сохраняя 100% фактов — это не большой бенчмарк, но показательно.
В многоходовых сессиях с кешированием набегает ~39%.
Агентные паттерны режут радикальнее: CaveAgent (2026) — −28% суммарных токенов при росте success rate за счёт схлопывания шагов.
Бонус не только про деньги: Hakim, «Brevity Constraints» (2026) на 31 модели и 1485 задачах — ограничение краткости подняло точность крупных моделей на +26 п.п. там, где многословность путала (модель сама себя загоняет в неверный ответ). Это пока одна работа, но эффект яркий.

Противовес от практиков остужает ожидания: экономия по всей сессии чаще выходит ~4–10%, и часть заявленного не доживает до счёта за токены.

Важная оговорка про reasoning. Телеграф применяйте к инструкциям и выводу, но не к внутренней цепочке рассуждений: у DeepSeek-R1 или Claude в extended thinking зажимать рассуждение вредно. И не переусложняйте сам компрессор — короткая директива «будь лаконичен, убери воду, сохрани все правила и значения» бьёт навороченный свод правил.

✅ Паттерн	⛔ Антипаттерн
Резать клей в переиспользуемых и агентских промптах	Включать телеграф на одноразовом чат-запросе
Сохранять дословно правила, имена, значения	Резать так, что теряется смысл
Краткость на финальном выводе	Зажимать внутреннее рассуждение reasoning-модели

Приём 3 · 🧱 Форматы: Markdown, XML, YAML, JSON

Markdown модели понимают лучше всего: им насыщены обучающие тексты, и токенизатор кодирует его экономно, тогда как JSON со скобками и кавычками дробится. И держите в уме, что сама разметка — это тоже токены: каждый тег, скобка и кавычка оплачиваются, поэтому тяжёлая разметка (XML, JSON) на одном и том же содержании выходит дороже лёгкой (Markdown).

А понятнее всего модели те форматы, которых она много видела в обучении, независимо от их теоретической стройности. Показательна судьба формата TOON: он экономит токены, но проигрывает в понимании, потому что примеров на него мало. Касается всё это прежде всего тела инструкции (системного промпта) и того, в каком виде вы подаёте данные.

🛠️ Из моей практики: структура окупается дважды. Пока разбиваешь инструкцию на секции и буллеты, ты сам её проясняешь — половина багов промпта чинится просто оттого, что пишешь структурно, а не сплошным текстом. И только потом вторая выгода: модель такую инструкцию читает точнее. То есть структура работает на вас ещё до того, как дойдёт до модели.

🛠️ Из практики: пишите читаемо, пока с промптом работает человек. Когда инструкции и ответы читаешь и отлаживаешь ты сам, человекочитаемый формат (Markdown, YAML) — половина успеха: глазами видно, где промпт сломался и что модель поняла не так. А если и промпт, и ответ генерит и потребляет только код — удобочитаемость уже не приоритет, оптимизируйте под машину.

Как применять:

Тело инструкции — Markdown (заголовки, буллеты). Размечайте промпт как небольшую статью: ## Роль, ## Контекст, ## Задача, ## Формат ответа, внутри — списки. Что формат влияет на качество, подтверждает He et al. (2024): у GPT-3.5 разброс по шаблонам доходил до 40% (крупные модели устойчивее). Единого оптимума нет, но Markdown — крепкий дефолт.
Границы секций — XML-теги (<instructions>, <context>, <examples>, <output_format>). Оборачивайте крупные блоки в теги, чтобы инструкция не «протекала» в данные, а пример — в контекст. XML многословен, поэтому это контейнер для границ, а не язык самого тела.
Вложенные данные — YAML, не JSON. Те же данные в YAML короче и читаются глазами — отступы вместо лесенки скобок и кавычек. В замерах improvingagents (2025) YAML обходит XML, который раздувает токены на +80% к Markdown (на большинстве моделей). Для таблиц хорош Markdown-KV (~60,7%, бенч на GPT-4.1-nano).
JSON — только на выходной границе, где результат парсит код (например, ответ уходит в API или в скрипт). Жёсткий структурированный вывод душит рассуждение: Tam et al., «Let Me Speak Freely?» (2024) фиксирует заметную просадку. Рассудочную задачу пусть модель решает прозой, а в JSON упаковывает уже готовый ответ отдельным шагом.

Про модные «экономные» форматы — осторожно. Регулярно всплывают сериализации с обещанием «те же данные, но в разы меньше токенов». Главный сейчас — TOON (Token-Oriented Object Notation): компактная переупаковка JSON — отступы вместо скобок, табличные строки для однородных массивов. Интерес реальный (релиз 1.0, тысячи звёзд, SDK под десятки языков), и подражатели уже плодятся. Прежде чем переводить промпт на модный формат — пара отрезвляющих фактов:

Дешевле ≠ понятнее, а экономию меряют против раздутого JSON. Заявленные «минус 40–55%» — это против JSON «с отступами»: против компактного JSON выигрыш падает примерно до 25%, против YAML — до 38%, а для плоских таблиц обычный CSV короче самого TOON. А в сравнении 11 форматов (improvingagents, 2025) самый экономный CSV дал худшую точность (~44%), а самый точный Markdown-KV (~61%) стоил почти втрое больше токенов.
Но и не «всегда хуже». На однородных табличных данных TOON в собственном бенчмарке обгоняет JSON сразу по обеим осям. Так что это не «экономия всегда убивает понимание», а компромисс, направление которого зависит от формы данных и от того, с чем сравнивать — независимый замер (Matveev, 2026) на коротких контекстах вообще отдал точность обычному JSON.

И не путайте формат со сжатием промпта (вроде LLMLingua, которое отдельной моделью выкидывает малозначимые токены) — это другой инструмент.

Вывод: гнаться за экономным форматом ради токенов почти всегда не окупается в теле инструкции. Для данных бывает оправдано — но только если вы замерили на своей задаче и форме данных, а не поверили заголовку.

✅ Паттерн	⛔ Антипаттерн
Markdown-тело + XML-границы секций	Писать всё тело инструкции в JSON
YAML / Markdown-KV для данных	Глубоко вложенный JSON как формат рассуждения
JSON только на парсимом выходе	Жёсткий JSON-вывод на рассудочной задаче

Приём 4 · 📍 Размещение и внимание

💡 Важное и сам вопрос — по полюсам окна, не в середину: туда внимание модели почти не доходит. Не рассчитывайте на всё окно: надёжной длины меньше, чем в спеке, и чем длиннее промпт, тем дороже промах с местом.

За этим — несколько сходящихся результатов. Lost in the Middle (2023): точность U-образна — выше, когда нужное лежит по краям, и проседает в середине (на многодокументном QA — разрыв порядка 20 пунктов). Found in the Middle (2024) вскрывает механизм: само внимание распределено к полюсам, независимо от того, где лежит ответ. Chroma «context rot» (2025): похожий, но нерелевантный контент активно сбивает — даже один лишний кусок роняет качество, четыре усугубляют. А рабочая длина окна меньше рекламной: «Context Is What You Need» (2025) фиксирует эффективный контекст в разы ниже заявленного, а бенчмарки NoLiMa (2025) и RULER (2024) — что уже на 32K половина моделей валится. Места, которому модель реально доверяет, меньше, чем написано в спеке, и слабее всего — его середина. Дальше — куда что класть по типам задач:

Чат: выше вставлен длинный документ — сам вопрос вынесите в самый конец.
Прод-промпт: формат-спеку и переменную часть — в хвост.
Harness: критичные правила — на полюсах: контекст огромный (200k+), и середина проваливается сильнее всего. Ставки тут в разы выше, чем в чате.
Данные: релевантные чанки — на полюса, ранжируйте по релевантности; не вываливайте всё «на всякий случай»: лишнее только сбивает.

Это касается и примеров (few-shot): работа о позиционном смещении few-shot (2025) показывает, что тот же самый блок примеров, переставленный по позиции, двигает точность вплоть до 50 п.п. Примеры — это не только «какие», но и «где».

И раз уж речь о примерах — форму ответа модели лучше задавать не запретом, а образцом:

📌 Пример бьёт запрет. «Не делай X» без показанного «делай вот так» работает плохо — модель цепляется за форму примера, а не за абстрактный запрет. Для структурированного ответа это правило железное: дайте хотя бы один образец.
⛔ Запрет без образца:
   «Не пиши длинно. Не используй markdown. Отвечай только JSON.»

✅ Структура + один образец:
   <output_format>
   Верни JSON строго по образцу:
   {"verdict": "pass", "score": 0.87, "reason": "одна короткая фраза"}
   </output_format>

Можно ещё явно направлять внимание, но с оговоркой: Attention Instruction (2024) показывает, что надёжно работает указание по индексу («блок №2», «секция X»), а размытое «обрати внимание на середину» — слабее. Inference-time методы вроде SEAL (2025) тоже помогают вытянуть нужное из длинного контекста (это обучаемый метод усиления внимания, не просто трюк в промпте). По моделям — отдельный раздел ниже.

✅ Паттерн	⛔ Антипаттерн
Ключевое, вопрос и примеры — на полюсах	Прятать главную инструкцию или примеры в середину
Один образец ответа для структурированного вывода	Голый запрет «не делай так» без «делай вот так»
Релевантные данные — к краям, ранжированно	Сваливать всё в окно «чтобы было»
Указание «смотри на блок №X» по индексу	Надеяться, что модель сама найдёт нужное в середине

Приём 5 · 🔣 Спецсимволы, эмодзи, разделители

Интуиция «компактные значки экономят место» ломается о токенизатор. Простой эмодзи весит около токена, а составные — флаги, модификаторы — разворачиваются в несколько байтовых токенов, иногда до десятка, тогда как слово «the» стоит один. Псевдографика и ASCII-таблицы тоже дороги: куча токенов уходит на рамки. Зато программные символы (===, операторы) дёшевы.

А вот разделители — недооценённый рычаг. Разделитель — это то, чем вы отбиваете один кусок промпта от другого: ### в заголовке, линия ---, теги <context>…</context>, тройные кавычки вокруг текста, вертикальная черта в таблице. Казалось бы, мелочь — но «A Single Character can Make or Break Your LLM Evals» (2025) показывает, что один лишь выбор разделителя сдвигает результат на десятки процентов, и — самое неприятное — хрупкость растёт с масштабом модели: подбором разделителя можно даже подкрутить, какая модель «выиграет» в сравнении.

📌 Вывод не «найди магический символ», а «выбери разумные разделители (Markdown-заголовки, XML-теги) и держись их по всему промпту».

Простой провал: в одной секции вы отбиваете блоки решёткой ###, в другой — звёздочками, в третьей — просто пустой строкой; модели труднее понять, где кончается инструкция и начинаются данные, и ваши же замеры превращаются в шум.

Так что для экономии значки бесполезны — эмодзи и псевдографика только в минус. Зато для надёжности выбор разделителя важнее, чем кажется. Структуру стройте заголовками и тегами, а не значками.

(И да — в этом посте эмодзи есть, но они для вас, людей, чтобы выхватывать главное на бегу. Внутри промпта для модели их ставить незачем.)

✅ Паттерн	⛔ Антипаттерн
Простые, консистентные разделители (Markdown/XML)	Менять разделители от секции к секции
Минимум декоративных символов	Обмотать промпт эмодзи «для фокуса»
Структура через заголовки/теги	ASCII-таблицы и рамки ради «красоты»

Как работают разные модели

Приёмы общие, но фронтирные модели расставляют акценты по-своему.

Сходятся все на одном: структурируйте промпт XML-тегами или Markdown с явными разделителями. И, как прямо пишет документация Gemini, сам выбор формата вторичен — важнее взять один и держаться его. А в режимах рассуждения совет у всех общий: не перегружать промпт, не навязывать примеры, давать высокоуровневую цель.

ChatGPT (OpenAI). Инструкции — вперёд, разделители — чёткие; отзывчив к разговорно-ролевому стилю. У GPT-5 — якорный системный слой.
Claude (Anthropic). XML-native: теги для секций, запрос — в конец длинного контекста (доки Anthropic фиксируют выигрыш «до 30%»). В гайде «Effective context engineering» — «наименьший набор высокосигнальных токенов» и «правильная высота» инструкций; в «Building Effective Agents» отдельно: описания инструментов заслуживают столько же внимания, сколько сам промпт.
Gemini (Google). Любит сжатые промпты; XML или Markdown — на выбор, но консистентно; по умолчанию краток. Граундинг через поиск — это включаемый инструмент, а не фраза в промпте.
DeepSeek. V3/V4 любят структуру: Markdown-заголовки, буллеты и XML повышают следование. Кеш работает сверху вниз: статику — вверх, динамический запрос — в конец, не перемешивать. R1 (reasoning) — без few-shot, высокоуровневые цели; JSON у R1 слабее, чем у V3. (Есть идея, что XML-маркеры помогают MoE-роутингу — модель из многих экспертных подсетей выбирает, какие включить, — но это догадка одного блога, не документированный механизм; не закладывайтесь.)

Финал: собираем под задачу

Общие решения — для любого типа задачи

Сначала — сквозные вопросы: ответ на них не зависит от того, чат у вас, прод-промпт или агент.

Нужно сэкономить? Сначала наведите порядок с местом и форматом, потом думайте про язык, а сжатие (caveman) оставьте напоследок: оно даёт меньше всех и легче всех ломает смысл.
Задача рассудочная? Дайте модели думать прозой — не зажимайте рассуждение жёстким JSON и не включайте телеграф на reasoning-цепочке; структуру наведёте на готовом ответе отдельным шагом.
Промпт длинный? Важное и сам вопрос — на полюса, не в середину, и не рассчитывайте на весь объём окна.
Ответ читает программа? JSON только на самой выходной границе и отдельным шагом — не там же, где модель рассуждает.
Пишете не по-английски? Английское ядро инструкций + явная команда о языке вывода на полюсе + один пример.

Стек под каждый тип

Чат — не усложняйте:

проза, удобный язык; команда о языке вывода — явно и на полюсе;
вопрос — в конец, если выше длинный текст;
токены не оптимизируйте, caveman не включайте. Цена ошибки — копейки.

Прод-промпт:

тело — Markdown, границы секций — XML;
caveman-lite: режьте «клей», но сохраняйте правила и имена;
пара канонических примеров (few-shot);
формат-спека и переменная часть — в хвост;
JSON — только на выходе, который разбирает программа.

Агентный harness:

caveman по полной; описания инструментов прорабатывайте как отдельный промпт;
критичные правила — на полюсах; память между окнами (прогресс-файл);
рассуждение не зажимайте; помните, что эффективное окно меньше заявленного.

Данные:

YAML или Markdown-KV вместо JSON/CSV; не переусложняйте формат;
режьте на куски и доставайте нужное, а не вываливайте всё;
релевантное — на полюса.

И короткий прогон перед отправкой большого промпта: ключевое и вопрос — на полюсах? тело — Markdown, границы секций — XML? JSON/YAML — только для данных, не для тела инструкции? «клей» срезан (если промпт переиспользуемый или агентный)? рассуждение не зажато? команда о языке — с примером? разделители выбраны и единые по всему промпту?

И последнее — чтобы вся эта гора цифр не сбивала с толку. Доверяйте крупным, многократно воспроизведённым эффектам (важное — на полюса, английское ядро дешевле, жёсткий JSON душит рассуждение) и спокойнее смотрите на одиночные сенсационные проценты: часть из них живёт только в способе замера (Flaw or Artifact?, 2025). Есть своя задача — померяйте на ней, а не на чужом бенчмарке.