Reducing Token Consumption

Several points are specific to Claude Design, though most guidance is relevant for all models. 

TLDR: LLMs are stateless at inference time and need relevant context supplied for each response; as that working context grows, usage generally grows, although modern applications use techniques such as summarization, retrieval, caching, and memory to manage it.

Note: The concepts that follow are generalizations and will not be universally true across all models. There are exceptions to almost every point and those exceptions are not included in this article. AI is rapidly advancing and companies utilize a variety of techniques to improve model's memory, token use, and context windows.

Concept 1: The Models Read and Write in Tokens

Terminology

• Token: a few characters or small chunk of text
  • Input tokens: what the model reads before it answers
  • Output tokens: what the model writes - almost all models charge much more for output than input
  • Examples of tokens (generic examples - most companies do not publish their tokenizer details)
    • we
    • $
    • ()
    • ,
    • 100
    • Supercalifragilisticexpialidocious (13 tokens): su • per • cal • if • rag • il • istic • ex • pi • al • id • oc • ious
• Turn: one exchange - you send a message, the model replies
• Context or context window: all of the text, including attachments and the entirety of the conversation up until that point, sent with your message to the model
• Context rot: degraded quality in a long conversation as the context fills with clutter - often solved by starting a new conversation
• Usage limit: total number of tokens available per user
• Patch or diff: small edit within coding affecting only the relevant lines of code

Your Claude Team usage limit counts both input and output tokens. Reading is not free. Writing is not free.

Concept 2: Models Memory is Not Like Ours

There is no dedicated instance of a model for your conversation or session. It does not remember the previous turn - not your prompt, nor its response. 

Instead, the entire conversation is sent to the model along with every one of your prompts in a session. This includes attachments provided as reference - not just the relevant parts, but 100% of every attachment. This is referred to as the context, and as the conversation continues, it grows. The limit of what a model can process is known as the context window.

Let's think of the context window as the model's desk. Your prompt is a piece of paper and every attachment you add is a piece of paper. The model reads each and responds on a new piece of paper. After every model response, the desk is cleared - the papers are all put in a pile next to the desk. On the next turn, a copy of every previous piece of paper is reproduced and put back on the desk with a new piece of paper for your latest response. The model reads it all as if for the first time, adds a response on a new piece of paper, then all papers are added to the stack next to the desk. 

The papers on the desk are the context. The desk can support a finite number of papers, which is the context window. The growing stack next to the desk is the token spend. 

Starting a new conversation brings it back down to one piece of paper for your prompt and one piece of paper for the model's response. The token spend stack grows much slower. 

Consequence 1: Each Revision is a Full Regeneration (Claude Design Specific)

In normal software, a small edit is a patch or a diff. Those words mean a change record that touches only the affected lines. If you change one word in a document, a patch describes that one word.

Claude Design does not work this way when it produces a design. It writes the design out again in full.

So the cost of a change is set by the size of the design, not the size of the change. Changing a button color on a large landing page costs about the same output as changing the entire page. This is why the advice is "generate once, then edit narrowly." You are not paying for the edit. You are paying for the rewrite that the edit triggers.

Consequence 2: Context Compounds

Turn 1 has almost nothing on the desk. Turn 10 has turns 1 through 9 on the desk.

Now combine that with Consequence 1. Every earlier turn contains a full design, because every revision regenerated the whole thing. So the desk does not grow by a sentence per turn. It grows by an entire design per turn.

This also causes a quality problem, not just a cost problem. When the history gets long, the model tracks your earlier instructions less reliably. It may drift from your design system or reintroduce something you already corrected. Practitioners call this context rot. Rot causes more corrections. More corrections cause more regenerations. The two problems feed each other.

Consequence 3: Uploads are a Recurring Cost

An upload joins the context like anything else. Images are converted into tokens too. A single screenshot can be worth more than a thousand tokens. A slide deck is worth far more.

Because the whole context is re-read every turn, the upload is paid again on every turn that follows it in that session.

So a large upload on turn 1 is not one cost. It is one cost multiplied by the number of turns still to come. This is why a 60-slide company deck is a bad way to communicate brand rules, and a one-page brief is a good way. It is also why an image that was useful for one component should not stay in a session for another twenty turns.

Consequences Combined:

The three effects multiply rather than add:

• A vague first prompt causes a correction (Consequence 1: full rewrite).
• That rewrite lands in the history (Consequence 2: bigger desk next turn).
• A large upload sits underneath all of it (Consequence 3: paid every turn).

Ten vague corrections on a large design with a heavy upload is not ten times the cost of one. It is worse than that.

What that means for the practical rules

Each rule you saw earlier attacks one specific mechanic:

• Decide direction in text before generating. This removes whole regeneration cycles.
• Scope each edit and name what must not change. This reduces how much Claude rewrites.
• Batch changes into one numbered list. This turns ten regenerations into one.
• Start a new project per initiative. This resets the accumulated desk.
• Upload small, upload late, remove what is no longer needed. This lowers the multiplier.
• Set up the organization design system once. This is stored configuration, not a per-session paste, so Claude stops guessing and stops self-correcting.