Apply to my task
arXiv:2606.24083 ★ 90 Jun 23, 2026

CAVEWOMAN: write short prompts and you pay more; ask for short answers and you save

Key result

The paradox: the shorter your prompt, the longer and pricier the answer. The CAVEWOMAN method cuts LLM costs by 1.4–2.4x with no loss in accuracy. The trick: an input token costs 4–8x less than an output token. Cut the answer, not the question. One line of system instruction and the expensive part shrinks.

01

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.

02

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.

03

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.

04

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
05

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.

06

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.

07

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.

08

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

09

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.

10

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)

Research digest

Key result

The paradox: the shorter your prompt, the longer and pricier the answer. The CAVEWOMAN method cuts LLM costs by 1.4–2.4x with no loss in accuracy. The trick: an input token costs 4–8x less than an output token. Cut the answer, not the question. One line of system instruction and the expensive part shrinks.

Principle

The standard advice: write short and you'll save. The reality: saving on input triggers spending on output. Strip the conjunctions and context out of the request and the model rebuilds them in the answer. You lose 15 input tokens and gain +10% output. And output is the expensive part. The right way: write the request in full. Shorten only the answer, with a direct format instruction.

Why it works

A model can't stay quiet when something is unclear. It sees an incomplete request and expands the context itself. Not malice, just built-in generation logic. But it follows answer-format instructions precisely. Say 'three lines max' and you'll get three lines. That's exactly where its obedience works in your favor. You leave the cheap input side alone and trim only the expensive output side.

When to apply

Regular API usage, especially daily data analysis, document review, report generation. Most profitable when a single system instruction covers hundreds of requests in a session. NOT suited to tasks where traceable logic matters: medicine, law, audit. There a compressed answer may be correct but reached by a different path. Check more than just the conclusion.

Mini recipe

1. Write the request in full: no telegraphic style. Conjunctions, context, details: keep them all. 2. Add a brevity instruction at the top: what to remove ('no introductory phrases, no repetition'), what to keep ('facts and numbers only'), what format ('event → impact → takeaway, one line per item'). 3. Move it into the system prompt: once for the whole session instead of pasting it into every request. 4. Give a structure template: without one, the model picks a format itself and bloats the answer. 5. Add exceptions if needed: 'except code snippets: write those out in full'.

Examples

[BAD]: `Fed rate 4.5% dollar S&P impact break down short` [GOOD]: System instruction, once: `Answer telegraphically. Facts only: nouns, numbers, verbs. No introductory phrases, no explaining the obvious. Format for each item: [event] → [impact mechanism] → [takeaway]. Maximum 3 lines per item.` Then a normal request: `The Fed held rates at 4.5% at Wednesday's meeting. Intel suspended its dividend for 2024. Brent crude at $68, down for the third session. Break down the impact on the dollar and the S&P 500.`

In plain words

The advice to write prompts in "caveman speak," cutting out conjunctions and prepositions to save money, is a harmful myth that hits your wallet. The CAVEWOMAN study showed that LLMs don't work like a telegraph but like overcompensating systems: when you hand the model a fragment of a sentence, it burns a ton of resources rebuilding the context so it doesn't botch the answer. So your attempt to save on input tokens ends with the model dumping twice as much text on the output side, trying to "fill in the blanks" for you.

It's like trying to save time by telling a contractor "wall, brick, fast" instead of handing over a proper blueprint. Afraid of messing up, the contractor starts asking questions, clarifying details, or builds extra stuff "just in case" to be sure to please you. You end up spending three times as long on discussions and redos as you would have if you'd just taken an extra minute to explain properly. The model behaves the same way: a compressed prompt makes it generate a bloated answer because it's trying to fill the logical gaps you left.

The researchers tested two approaches and found that only output compression actually works. If you write a normal, human prompt but add a firm "answer briefly" instruction at the end, your costs drop 1.4–2.4x. That's a concrete, measurable win. The model understands a command to be concise perfectly well, but it has no idea you're trying to save three cents on prepositions in the input. Linguistic compression on the input is a road to chaos and extra spending.

The principle is universal: whether you run a stock-market newsletter and have Claude break down the news, or write code with GPT-4. Feed the model dry headlines without context and it'll start hallucinating or padding to cover itself. But give it a clear structure and ask it to "give me just the essence in three sentences" and the savings magic kicks in. An SEO-style approach to prompts doesn't fly here: models love clarity, not skimping on letters.

Bottom line: stop playing caveman and mangling your requests; it's a total bust for your budget. Write prompts normally, like a human, without skimping on input tokens: that's the foundation of a decent answer. Want to pay less? Limit the length of the answer, not the length of the question. The 1.4–2.4x savings live in controlling the output; trying to compress the input is just self-deception that makes the result worse and more expensive.

AI lab assistant

Apply this study to your task

Describe what you're working on. AI takes the method and the measured results from this paper and adapts them to your case, or writes a ready prompt built on them.

Based on CAVEWOMAN: write short prompts and you pay more; ask for short answers and you save arXiv:2606.24083

Sign in to apply this study New accounts get 50 free credits.