Claude Pro: how to spend fewer tokens

A quick note first: strictly speaking, what a Claude Pro subscription has is usage / a usage allowance, not the exact per-token billing of the API.

But in everyday use, “saving tokens” is easier to understand, so I’ll stick with that phrase here.

How it’s counted

- Claude / Claude Code / Claude Cowork basically share the Pro plan’s usage allowance, which is mainly governed by a 5-hour rolling limit + a weekly limit

- The Claude API is billed separately by token / usage and isn’t included in the Pro subscription

- Claude Design has usage tracking and a weekly limit separate from regular Claude / Claude Code; go by what the interface shows

Choosing a model

- Pick the right model to spend your allowance more economically

- Opus is better for open-ended problems that need deep / broad reasoning and have no standard answer

- Sonnet can handle fairly clear execution-level tasks

- For example: early product positioning / brainstorming can use Opus; writing prompts / organizing checklists / the review stage can use Sonnet as much as possible

Managing chats

- Unlike ChatGPT, Claude’s usage depends on the length of the current conversation, so be careful with long chats, large images, big attachments and code files

- Each chat in Claude is best kept to one clear phase

- When you close a chat, you can have it produce a handover context prompt as needed, so the next phase can continue in a new chat

- Claude Code compresses context within a session, so the same task can keep moving; but across big tasks it’s better to start a new session so the context doesn’t get too messy

- In Claude Design I manage things as “one project = one deliverable”; a project can hold several chats, but I don’t recommend mixing too many different directions in one, which muddies the context and the aesthetic direction

Prompts

- Because usage depends on context length, for complex tasks a shorter prompt isn’t necessarily cheaper

- Structured prompts with context are actually better; they cut down on repeated explanations and rework

- The structure I often use is: Role / Goal / Task / Constraints / Context

- That is, say it all clearly in one go as far as possible: who you are, what I want, what the background is, what the constraints are, what the output should look like

Make good use of Projects

- Shared files can go in the project files, so you don’t upload / explain them again every time

- My own setup: each product I’m developing has its own project, with a project context.md inside

- A common chain is: organize the background and prompts in Claude → execute in Claude Code → come back to Claude for review / critique

Things not to worry about too much

- Don’t worry too much about adaptive thinking; turn it on for complex problems, and don’t fuss over it for simple execution tasks

- No need to switch off all agents / connectors out of fear of usage, but I also don’t recommend connecting everything just to “look powerful”

- They only noticeably add usage and noise when they actually read, call or execute

- The rule is still: turn things on when you need them, connect them when there’s a real task

The weekly “bonus”

- If you happen to have some allowance left before the weekly limit resets, you can use Cowork for housekeeping you needed to do anyway

- For example: organizing local files, archiving documents, cleaning out the Downloads folder, batch renaming

- But only if it’s something that genuinely needed doing, not a task you invented to use up the allowance

- Cowork uses more usage than a normal chat for complex multi-step tasks, so it isn’t suited to simple Q&A

My core principles:

Opus for judgment and complex reasoning

Sonnet for clear execution

Projects for stable background

Split long chats by phase

Agents / Cowork for tasks that genuinely suit multi-step execution