5 Claude Cowork Mistakes That Are Quietly Wasting Your Tokens

Cowork is insanely powerful, but there’s a problem. Right now, there’s no gold standard for how to set up your workspace, and a shaky foundation here means you’ll keep hitting the same avoidable problems over and over as you go.

After five months of using Cowork daily to run my entire life, and going into debt to pay for token usage, here are five essential things to get right from day one.

Tip 1: The Markdown Translator

Everything Cowork remembers and follows, its instructions, its memory, all of it, is stored as plain .md files. You’re free to open and edit those directly, but they’re rough to read in raw form and even more tedious to edit by hand.

So the first thing you want to do is install a free app called Obsidian. Open it, choose “Open folder as vault,” and point it to your Cowork workspace folder. Now every MD file instantly renders with proper headings, bold text, and bullet points, basically a much more readable format.

Let’s say I want to change something in my CLAUDE.md file. Instead of editing anywhere else, I select the CLAUDE.md tab in Obsidian and just replace the line I need to change directly there. Close it, reopen it, and the changes are already saved.

To be clear, you don’t need to learn Obsidian or use any of its other features. It’s just a lens to read and edit MD files.

A couple of pro tips: hit Command/Control + Plus to zoom in, and click the reading mode icon to lock the page so you don’t make accidental edits. You can also go to Obsidian’s settings under Files & Links and keep “Show all file types” turned on. That lets you see non-MD files, like spreadsheets, PDFs, and even images, right in the sidebar.

Tip 2: The 300-Line Rule

Your root CLAUDE.md loads every single session, so a bloated file wastes a lot of tokens. When I cut mine from over 600 lines to around 250, my token usage dropped by roughly 25%. Here are three tactics you can use right away.

Only include the bare essentials

My CLAUDE.md template has six sections:

• Memory system – tells Cowork to always read memory.md at session start, so it knows what we did before.
• Preferences – how you want Cowork to communicate: tone, length, format, and so on.
• Rules – behavioral guardrails. If you want Cowork to always do something (like ask clarifying questions before starting a complex task) or never do something (like edit files in your workspace without telling you what changed and why), it goes here.
• Routing map – a table Cowork checks to figure out which workstation to load based on the task. Writing an email loads the email HQ workstation. Working on a China-related project loads the China desk. Brainstorming loads the clarity partner workstation, and so on.
• References – one-line pointers to files Cowork loads on demand. For example, my voice-principles.md file doesn’t load every session, only when I’m actually writing content.
• Creating new workstations – tells Cowork how to build new workstations inside your workspace.

Pro tip: the rule of thumb is to keep your CLAUDE.md between 200 and 250 lines, with 300 as the absolute maximum.

Ask Cowork to relocate non-essential rules

You might be thinking there’s no way to stay under 300 lines once you actually start using Cowork. Here’s the test: does Cowork need this every session, or only when a specific task comes up?

In my own CLAUDE.md, there’s a section called “governance meta-principle” that says all instructions and rules in the workspace must be mutually exclusive and collectively exhaustive. Since that governs how every rule in the whole workspace is organized, it has to stay in the root CLAUDE.md.

Compare that to a “file creation rules” bullet point that only applies when I’m creating a new file. Since I’m not creating files every session, instead of keeping all 22 of those rules in the root file, I have a single pointer: “read this before creating any new file in the workspace.”

I applied this directly to my own setup. The “creating new workstation” section doesn’t need to load every session either, so I told Cowork to move it out of the root CLAUDE.md into a new reference file and replace it with a one-line pointer in the references table. After a few seconds, Cowork confirmed the move keeps the root file leaner while preserving the full template for on-demand loading. Opening it in Obsidian, the whole section was gone, replaced by a pointer: “read this when creating a new workstation,” linking to the template file now sitting in a resources folder.

The CLAUDE.md got shorter without losing anything. That’s the whole trick: find sections that only serve specific tasks, and ask Cowork to relocate them.

Write files in the right place

Most Cowork users put CLAUDE.md content in memory.md and vice versa, and that mix-up tanks output quality. The fix is a rule under your CLAUDE.md’s memory system section, using two simple tests:

• Test 1: If the entry is prescriptive and uses words like “always” and “never,” it belongs in CLAUDE.md.
• Test 2: If it describes a fact that could change, it goes into memory.md.

For example, “before drafting a new email, check if a related thread already exists with that recipient” is a version of “before doing X, do Y.” That’s prescriptive behavior, so it belongs in CLAUDE.md. Meanwhile, “my company uses Microsoft Copilot” is a fact that could change tomorrow, so it belongs in memory.md instead.

Here’s something you can do right now: tell Cowork to review your root CLAUDE.md and memory.md. In the CLAUDE.md file, have it flag any entry whose main purpose is recording a fact or status rather than prescribing behavior. In memory.md, flag any entry whose main purpose is telling Cowork how to behave rather than recording a fact. Then ask it to recommend where each flagged entry should move, and once you’ve reviewed the list, just say “proceed with changes.”

Tip 3: The Memory Diet

Just like your root CLAUDE.md, your root memory.md also loads every single session, so a messy one wastes tokens and makes Cowork’s output worse. Here are three things you can do about it.

Give memory.md a clear structure. My root memory.md has three sections: “active projects and work” (a list of everything I’m currently working on with a short status next to each one, so Cowork immediately knows what’s on my plate), a “scheduled tasks” section (tracks every automated recurring job so Cowork doesn’t accidentally create duplicates or miss one that already exists), and a “core memory” section (persistent facts about me, like my career before becoming a full-time YouTuber, my LinkedIn URL, and my business address).

Set a hard ceiling. In my root CLAUDE.md’s memory system section, there’s a pointer to the full set of memory system rules. Two things matter there. Under “entry format,” there’s a rule that says every memory entry should be one to two sentences max, so Cowork writes concise entries from day one instead of long paragraphs that bloat the file. Under “size ceiling,” there’s a rule that reads: root memory.md, 150-line ceiling. When the ceiling is breached, the fix is always compression and archiving, never raising the ceiling. In plain English, once memory.md hits 150 lines, Cowork automatically archives anything that’s no longer current, like something that happened two or three months ago.

Create an archive.md. Here’s a simple way to picture it: memory.md is a whiteboard with active projects and key facts you need every day. archive.md is the filing cabinet holding a complete record of everything you’ve ever done. The key detail is that Cowork does not read archive.md every session. It only checks it when you ask something like “what happened with the email list three months ago.” Because archive.md isn’t loaded at session start, it doesn’t need a size ceiling at all. You can preserve everything without paying any token cost for it.

Pro tip: create a separate memory.md for each workstation and each project inside your workspace to cut down on token usage further. When I ask Cowork something like “what’s going on with my latest email campaign,” it first checks the root memory.md to confirm the project exists, then jumps into that project’s own memory.md to pull project-specific details like Notion pages, subject lines, past decisions, and current status. That cascading setup is why my root memory.md has never gone above 100 lines, even after months of aggressive daily use.

Tip 4: The Project Transplant

A lot of people ask about the relationship between Claude Projects and Cowork. Long story short: migrate your Claude Projects into Cowork, because Cowork doesn’t have the same limitations.

I used to rely on a Claude Project to write my weekly newsletter. Inside it, I had project instructions, a project knowledge file, and an auto-generated project memory. Compared to Cowork, there are real problems here. If I wanted to update the project instructions, I had to manually click in and type or paste something. Clicking into project memory shows an AI-generated paragraph you can’t really structure or edit directly. And even though I could link a Google Doc of past newsletter editions as a knowledge file, Claude couldn’t write to that document directly either. I’d have to open it and paste everything myself.

Migrating a Claude Project into Cowork solves all of that. Project instructions essentially become the workstation’s CLAUDE.md file, project memory becomes memory.md, and knowledge files get added to the workstation’s resources folder.

Here’s how to actually do it: open a blank text document, select all the project instructions and copy them in. Press enter twice, go back, click into project memory, select all of that too, add a header (“Project Memory”), and paste it in below the instructions. Save the file as “project-info.md.” Then download your linked Google Doc as a markdown file as well.

Grab a simple migration prompt, paste it into Cowork, and share both the project-info.md and the Google Doc’s markdown file with it. Let it run.

In my case, Cowork created a full newsletter workstation folder. It built a workstation CLAUDE.md containing the same workflow as my original project instructions, a memory.md with a structure I can actually edit, and a resources folder with three separate files: one for audience and positioning, one for recent newsletters, and one that extracted style patterns from my existing newsletters. It even went back into my root CLAUDE.md and added a new entry under the routing map that points to the newly created newsletter workstation.

Now, whenever I want to make a change, I can just tell Cowork something like “add a rule to my newsletter workstation: each addition should have a maximum of three emojis,” and it updates the newsletter CLAUDE.md directly. When I publish a new issue, I tell Cowork to add it to the newsletter examples file, paste in the copy, and let it run, and a minute later it’s added to the recent-examples markdown file.

This is how a Cowork workspace compounds. Every improvement, every change you make today makes tomorrow’s output better.

Tip 5: The Skill Check

A lot of people ask about skills versus workstations. Here’s the difference in a nutshell.

When I tell Cowork “I want to work on my next weekly newsletter, what do I need to do again?” it first loads my newsletter workstation for context, then lays out the workflow. Notice how a lot of the steps surface a decision I need to make: do I have a topic in mind? Which Google application am I covering this week? That’s the point: this workflow can’t run on autopilot. I, the human, still need to make decisions and judgment calls as part of the process.

Compare that to what happens once a newsletter draft is finalized. I can trigger my newsletter subject-line skill, which takes the final draft and applies the instructions from the skill on autopilot, since it’s really just a checklist. It gives me five scored subject-line options every time. I know exactly what I’m getting back, and the only thing that changes is the content.

Another example: I have a workstation audit skill that checks for misplaced rules, bloat, and gaps within a specific workstation folder, to keep my workstations optimized and lean. The output is a report with an executive summary up front, followed by specific findings and recommendations.

So the test for choosing a workstation versus a skill is pretty simple: is this a place I work, or a thing I do? If it’s an ongoing area of work with its own voice and accumulated context, that’s a workstation. If it’s a repeatable process you want done the exact same way every time, that’s a skill.

Here’s the quick-reference version:

Question	Workstation	Skill
What is it?	A place you work	A thing you do
Structure	CLAUDE.md + memory.md + resources folder	A single checklist/instruction file
Requires human judgment?	Yes, decisions happen along the way	No, runs on autopilot once triggered
Example	Newsletter workstation	Newsletter subject-line skill
When to use it	Ongoing area with its own voice and context	Repeatable process, same output every time

Get these five things right from day one, and your Cowork workspace stops being a mess of bloated files and duplicated effort, and starts compounding, getting a little more useful every time you work in it.

FAQ

What’s the difference between a workstation and a skill in Claude Cowork?

A workstation is an ongoing place you work, like a newsletter or client account, with its own CLAUDE.md, memory.md, and resources folder. A skill is a repeatable process, like a checklist, that runs the same way every time without needing your judgment calls along the way.

Why use Obsidian with Claude Cowork instead of editing the MD files directly?

Obsidian renders your CLAUDE.md and memory.md files with proper headings, bold text, and bullet points instead of raw markdown symbols, which makes them far easier to read and edit. You don’t need to learn Obsidian’s other features, it’s just a cleaner lens for the same files.

How long should my CLAUDE.md file be?

Aim for 200 to 250 lines, with 300 as the absolute ceiling. Since CLAUDE.md loads on every single session, a bloated file quietly burns tokens on every message you send.

What happens when memory.md hits its 150-line ceiling?

Cowork compresses and archives anything that’s no longer current, like something from two or three months ago, into a separate archive.md file. The fix is always compression, never raising the ceiling, and archive.md itself only gets read when you specifically ask about something from the past.

Should I migrate my old Claude Projects into Cowork?

Yes. Claude Projects can’t write back to linked knowledge files or let you structure project memory directly, so you end up copying and pasting manually. Migrating into Cowork turns those same project instructions, memory, and knowledge files into an editable workstation that keeps improving over time.