TL;DR
There's a popular tip: talk to the model telegraphically, in "caveman speak," supposedly to save tokens and money. The CAVEWOMAN study proves the opposite: shortening the prompt raises total cost, while telling the model to answer briefly cuts it by 1.4–2.4x.
Here's the problem. Input tokens (your prompt) cost 4–8x less than output tokens (the model's answer). When you write "write short manuscript editor errors," the model doesn't fully grasp the context and compensates for the incomplete request with a longer answer: it clarifies, assumes, elaborates. You saved 15 input tokens and got +10% output. Net result: cost went up, accuracy went down.
The fix flips the logic: don't shorten the request, shorten the answer. Add a system instruction at the start of the chat: "answer telegraphically, only keywords and numbers." That's the only direction of compression that works.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
Two approaches, two different outcomes:
❌ APPROACH A — Compressed prompt:
YOU → [short/telegraphic request] → MODEL
MODEL → [long answer, compensating for what's missing]
Result: -15% input tokens, +10% output → cost rises ~15-180%
accuracy drops
✅ APPROACH B — Compressed answer:
YOU → [complete, clear request] → MODEL
+ instruction "answer briefly, telegraphically"
MODEL → [short answer, only the essentials]
Result: cost falls 1.4–2.4x, accuracy holds
Both approaches can be done in a single message or via the system prompt.
Example in Action
Task: You run a Substack newsletter about the US stock market, and every morning you ask Claude for a quick breakdown of 5-6 news items from Bloomberg and the Wall Street Journal: what it means, how it affects the S&P 500, what to do.
You used to write it like this: "S&P yesterday -1.2%, Intel div suspended, Fed rate 4.5% oil 68, break down short", thinking you were saving. But you got long answers full of caveats and preambles.
Prompt:
System instruction (paste once at the start of the session):
Answer in telegraphic style. Facts only: nouns, verbs, numbers.
No introductory phrases, no explaining the obvious, no "it's worth noting," "keep in mind."
Structure for each news item: [event] → [impact mechanism] → [takeaway for the position].
Maximum 3 lines per item.
---
Break down:
1. Intel suspended its dividend for 2024. Shares fell 4.1%.
2. The Fed held rates at 4.5% at Wednesday's meeting.
3. Brent crude at $68.3, down for the third session in a row.
4. Apple announced a $110B share buyback.
5. JPMorgan reported: profit +12% y/y, ROE 23%.
Result: The model returns 5 blocks of 2–3 lines each: no preambles, no "on the one hand." Each block: what happened → why it matters for the market → a concrete takeaway (hold, watch, avoid). The answer shrinks 2–3x compared to the default mode.
Why It Works
The LLM's weakness: A model can't "quietly guess." When the prompt is incomplete, it doesn't stay silent; it fills the gaps with words. Strip out the conjunctions and prepositions and it rebuilds the context itself so as not to get it wrong. That's compensatory answer expansion: not malice, just built-in generation logic.
The LLM's strength: Models are excellent at following explicit format instructions. "Answer in three words" gets three words. "Facts only, no explanations" gets done. The answer format is far easier to control than the request format.
How the method sidesteps the weakness: You leave the input side alone (it's cheap there) and cut the expensive output side with a direct instruction. The model understands the full request, compensates for nothing, but answers concisely. That's the zone where its strength (following format) works in your favor.
Control knobs:
- Compression level → "keywords only" vs. "brief, but in full sentences": the stricter it is, the shorter and cheaper, but nuance gets lost
- Structure format → give a template ("event → mechanism → takeaway"), otherwise the model picks a structure itself and may bloat it
- Exceptions → "brief, except for code steps: write those out in full" for task-specific flexibility
- Where the instruction lives → a system prompt (one instruction for the whole session) is cheaper than pasting it into every request
Prompt Template
Answer {brevity_style}.
Remove: introductory phrases, repetition, "it's worth noting," explanations of the obvious.
Keep only: {what_to_keep}.
Answer format: {structure_template}.
{exception_if_needed}
{your_usual_request_unchanged}
What to fill in:
{brevity_style}: "telegraphically," "briefly, in 2-3 sentences," "conclusions only, no justification"{what_to_keep}: "facts and numbers," "actions and deadlines," "problem and solution"{structure_template}: "[problem] → [solution] → [next step]," "bulleted list with no explanations," "one line per item"{exception_if_needed}: "except tables: give those in full," or drop it entirely{your_request}: any normal question, written the way you usually write it; don't shorten anything
Style examples by task
| Task | Style |
|---|---|
| Quick news breakdown | Telegraphic: fact → impact → takeaway. One line per item. |
| Text review | List of problems, no quotes. Format: [error type]: [what to fix]. |
| Idea brainstorm | Ideas only, no justification. One line per idea. |
| Document summary | Three paragraphs: gist → key facts → next steps. |
🚀 Quick start: paste into the chat:
Here is a template for a compressed-output system prompt. Adapt it to my task: {your task}.
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask about the type of task and the compression level you want, because it needs to understand what must stay in the answer and what can go.
Limitations
⚠️ Different wording even when the answer is right: Under a "be brief" instruction the model gives the correct answer but may get there by a different route. In roughly half the cases, the final text doesn't match in meaning what the model would have written without the constraint, even though the answer is correct. For tasks where traceable reasoning matters (medicine, law, audit), check the logic, not just the conclusion.
⚠️ GPT-5.4 and reasoning models are a special case: Models with hidden chains of thought (an internal "thinking" block) don't shorten that block on the user's instruction. Savings on the visible text may not reflect real costs, because the internal tokens are billed too.
⚠️ Short tasks: a mechanical effect: If the question calls for a "yes/no" or a single letter (A/B/C/D), the shortening happens automatically, not because the model understands better but because the answer simply got shorter. Don't mistake it for a real quality gain.
⚠️ Don't compress the request: Writing telegraphically yourself ("Fed rate impact dollar break down fast") is worse on every metric. Costs go up, accuracy goes down. Write your requests normally.
How They Tested It
The idea was provocative: the team set out to test the popular "write like a caveman, save tokens" tip, and took it literally. They built a deterministic part-of-speech filter with five compression levels, from "remove conjunctions" to "keep only 15 tokens." The same tasks went through two channels: first they compressed the prompt, then instead they asked the model to answer in that same compressed style.
They tested eight models (including GPT-4o, GPT-5.4, both Claudes, Qwen, DeepSeek, Gemma) on 11,465 tasks from five datasets: math, yes/no questions, science and commonsense tests. They measured not just accuracy but actual cost (tokens × price), plus how closely the compressed answer matched the original uncompressed one in meaning.
The surprise came from the cost numbers: cutting the prompt by 15% raised total cost by 3–15%, and in the worst cases by 2.7x. The mechanism turned out to be simple: models "sensed" missing information in the request and compensated with more elaborate answers. Since output tokens cost 4–8x more than input, a small saving on the way in turned into a big overspend on the way out. On top of the accuracy drop.
The second surprise was about text agreement. Even when the model gave the correct answer under a "be brief" instruction, in roughly half the cases its text did not match the reference uncompressed answer in meaning. In other words: the right answer is reached, but by a different path. For most tasks that's fine, but worth knowing if you use the model's answers as part of a reasoning chain.
Original from the Paper
The authors publish the full system prompts for each compression level in Appendix H (not included in the main text). It also contains a verbatim example of how a single task is transformed through all five filtering levels.
Code and data: github.com/danielle34/cavewoman
Adaptations
💡 Adaptation for business email: Same principle: you have a "straight to the point" reply template and ask the LLM to draft emails exactly in it. Not "write a short email" (vague) but "write: context in one line, request in one line, deadline if there is one." A precise structural instruction = a predictable, concise result.
🔧 Technique: drop the format instruction → see the reasoning
If you need to follow the model's train of thought (say, on a hard problem), remove the compression instruction or add an explicit exception: "brief, except for the 'reasoning' section: write that in full." That lets you save on the final output while keeping the logic visible.
🔧 Technique: compression by block type
Instead of one compression level for the whole answer, give different instructions for different parts:
Answer structure:
— Conclusion: one line, fact only
— Justification: 2-3 key points, no fluff
— What to do: bulleted list, 3 items max
This keeps the structure and predictability but trims excess text surgically.
Resources
Paper: CAVEWOMAN: How Large Language Models Behave Under Linguistic Input and Output Compression
Code and data: github.com/danielle34/cavewoman
Authors: Morayo Danielle Adeyemi (Independent), Ryan A. Rossi (Adobe Research), Franck Dernoncourt (Adobe Research)