Share this letter & I’ll send you some rewards for the referrals.
Every Claude session starts with context:
conversation,
your prompts,
your CLAUDE.md,
instructions added by the Anthropic team,
and everything Claude knows about the task.
But Claude has a “limit”…
Every file you paste, every tool you connect, and every long conversation you keep alive uses part of that limit.
So if your context is draining quickly, the simplest & best option is to start a new conversation instead of waiting for Claude to compact everything.
In this newsletter, we’ll cover habits that help you use Claude’s context more efficiently & wisely.
To do that, we won’t just follow practical tips.
(We’ll also test different approaches & compare the results side by side.)
Let’s get started!
§
If you have multiple interests, please take advantage of AI agents
Software engineers were encouraged to specialize for years.
Backend. Frontend. Infrastructure.
But AI agents are making it easier to explore disciplines outside your expertise.
So how do you actually use them in a real-world workflow?
I focus on backend engineering, but recently wanted to try full-stack development for a personal project. I needed a consistent design system, polished screens, and all the UI states a frontend needs.
So I used Figma agent to help review and refine my existing designs.
I started with my design context and ran the /ui-state-expander skill to identify missing loading, empty, error, and interaction states.
The result was a workflow I could use to move from existing designs toward implementation:
Start with an existing design
Give Figma agent your design context
Expand missing UI states
Review the generated output
Refine the designs directly in Figma
Build the frontend
I still reviewed the output and made the design decisions myself.
The agent helped me work through parts of the process where I had less experience. If you’re a software engineer interested in exploring full-stack development, I recommend you give it a try:
(Thanks to Figma for partnering on this newsletter.)
§
I want to introduce Gencay as the guest author.
He has been building with AI since ChatGPT first shipped in 2022.
For years, he built for clients on Upwork: 7,300+ hours of it.
Now he builds in the open and shares every piece of it on LearnAIWithMe, every Monday, Wednesday & Friday.
Not just theory for its own sake. One real build at a time, from idea to running system.
§
Here’s what you’ll find inside this newsletter:
The budget most engineers blow in an hour. What quietly drains your context window, and how fast your daily and weekly limits go with it.
The signal that a conversation is past saving. When to close it, and the one prompt to run first so nothing important gets lost.
A project memory that lives outside the chat. Nested CLAUDE.md files, Auto Memory, and path-scoped rules, so the conversation itself stays disposable.
A setup that gets smarter every week. The correction, rule, skill loop, and what happens when the setup meant to save tokens becomes the thing spending them.
A real audit of a real project. An actual token bill, a 5-step cleanup, a token-saving skill tested head to head & five skills worth installing.
§
Context window is a budget
The context window is Claude’s working memory.
It holds your instructions, files, & entire conversation… and every model has a “fixed” size…
Opus 5 carries a 1M context on the Max plan,
Fable 5 draws down your usage faster than the older models.
So the window & your limits are connected.
Claude has daily & weekly limits, and some models spend them quicker than others.
This is why management matters…!
If you fill the window with noise, your limit drops early, and you sit there waiting for the reset instead of working.
§
Token saving habits that compound
If you repeat a job in every conversation, put it in a CLAUDE.md
Here is why:
Even a 1M window fills up, and when it does, Claude compacts the conversation on its own. Compacting is a summary, and summaries drop details. So the instructions you typed at the start may not survive into the rest of the conversation.
But a good CLAUDE.md never gets compacted away, because Claude reads it fresh from disk every session.
Plus, do not stretch one conversation forever. The bigger it grows, the more each compact costs, and those compacts eat into the same limit you wanted to save.
A new conversation is the cheapest fix…and here is the signal for when to switch:
When Claude starts compacting every few messages, or the answers begin forgetting rules you gave an hour ago, the conversation is past saving. Each compact now eats your limit while dropping details, so closing it costs less than keeping it alive.
But you do not want to lose what the old one knows, so ask this before you close:
Summarize this conversation in 5 sentences.
But first, ask me 5 questions to make sure the things I care about end up in the summary.Then paste the summary into the new conversation & you continue where you left off at a fraction of the cost.
These three commands help you manage the window without leaving it:
/clearresets the context to zero./compactcondenses the conversation, and you steer it with an instruction like/compactfocus on the code changes./contextshows what is sitting in your window right now, so you see the problem before it costs you.
§
Grow your project in MD files, not in the chat
A big project inside one chat gets heavy.
Some users hold onto the conversation because valuable information lives there, and they are afraid to lose it.
The better way is a folder & an MD file.
Add a folder to the conversation, and then use this:
Create a CLAUDE.md for this project.
Make sure to include the decisions we made in this conversation
and the rules I gave you.Now the knowledge lives in the file instead of the chat.
Every time you open this project, the saved context comes with it, and the conversation itself stays disposable.
You could even switch models/tools, and the work survives because the files are the project.
§
Memory at scale
Let’s say your project is big, with tens of folders.
A nested CLAUDE.md system is a good road here.
Your main CLAUDE.md stays short & it says something like this:
This project has 10 folders.
Each folder holds its own CLAUDE.md explaining it.
Read the nested file only when you work inside that folder.And each folder carries its own CLAUDE.md with the details.
The gain is double…
In a normal conversation, the nested files stay unread, so your context stays light & the session runs longer.
And when you need the details, one prompt like
Check this folder and read its CLAUDE.md…loads only the part you asked for.
You save time & tokens with the same move.
Two more layers work alongside your files:
Claude keeps its own notes with Auto Memory, saving what it learned from your corrections per project, and /memory opens them for editing. So the memory system runs both ways: you write instructions, and Claude records what it learns.
And for larger projects, “rules” split the load further…
A rule is a small MD file under .claude/rules/, one topic per file, and it could carry a “paths” field limiting it to matching files. So your API conventions load only when Claude touches the API folder, and they cost nothing on the frontend days.
§
Compound engineering
Every correction you make is worth money, but only if you write it down.
Claude makes a mistake, you fix it once, and then you turn the fix into a rule in your CLAUDE.md or a skill.
The next session starts smarter, and the mistake never comes back.
I run my entire setup this way. When a correction repeats twice, it becomes a rule.
When a workflow repeats twice, it becomes a skill.
So the system compounds, and the setup I have today is the sum of every mistake Claude made this year.
§
Reminder: this is a teaser of the subscriber-only newsletter, exclusive to my golden members.
When you upgrade, you’ll get:
A complete Claude Code setup, from your first session to a fully automated one.
Deep dives into how MCP, subagents, agent orchestration & hooks actually work inside Claude Code.
How real Claude Code projects handle context, scale, and running without you.
(If this newsletter has helped you become a better software engineer, consider subscribing to support my work.)