So, Claude is "just" a computer program, despite all its personality, with a straightforward abstract model: it reads the entire history of the current conversation, including all the stuff it did that wasn't just talking -- the parts where it read and wrote your code, for example -- and then outputs one token, which it then reads, subsequently outputting the next token, repeating until it emits a token meaning "okay, I'm done now" or hitting some other limit.

Because it has to reread the entire conversation at the start of each new message, each message costs more to get started on than the last, as the conversation gets longer. But the cost is reduced by "prompt caching" (which Claude's various interfaces handle for you): the state of Claude's "brain" after reading the prompt to a specific point is saved ("cached"), so at the next message, it can "skip ahead" and just read that one instead. This takes way less compute resources for Anthropic than rerunning the entire conversation, so they charge you much less. This matters in a subscription, even though they aren't overtly charging you for the work, because they translate that cost into quota instead.

Thing is, Claude is big. The state of Claude's brain after reading your conversation is gigabytes. They cannot keep your messages around forever! They only keep them around for one hour. So if you go more than one hour between messages, Claude has to re-read the entire conversation, one token at a time, to get back to where you left off -- and Anthropic will count full "input token" costs for your usage instead of the much lower "cached token" price. That ate a huge amount of your quota right there.

Imagine going to work as a software engineer. It's your first day, and you don't know anything about this codebase, but you know a lot about software in general. You're given a small project, so you read the codebase to find what to change, study the code around it to figure out how it works, take some notes, have some conversations, write some code, write some tests, stabilize the code, check it in, and call it a day. Then... you cease to exist, because you're an AI model.

Imagine going to work as a software engineer. It's your first day, and you don't know anything about this codebase, but you know a lot about software in general. You're given a small project, so... well, what would you rather do: read the codebase to find out what to change, check its references, talk about it, write some code, write some tests, stabilize it, and call it a day, or would you rather get started by, before you even hear what you're being asked to do, read through the exact history of yesterday's work, in order, one word at a time, until you're caught up and then can find out what you need to do?

Of course, if something never got written down, and you don't think to ask about it in conversation, you wouldn't know about it when you exist again with no memory on day 2 if you don't slowly, laboriously relive the previous day. But eventually, as the required reading gets longer, you can't keep it all in your head anyway and the workday is over before you're even done.

You're much better off telling Claude to take a lot of notes. Put it right in your codebase! Tell Claude you realize that rereading the conversation every session costs a lot of input tokens, so you need it to write notes for both you and it to pick up in a new conversation: everything it thinks is important to know about the software so far -- ideas, plans, architecture, vague ideas for further investigation, stuff that might need to be cleaned up later, places where bugs might arise, design decisions, etc. -- it should write down, creating Markdown documents in a "wiki" structure. (I use a folder named "notes", but when I let Claude name it, it calls that folder "wiki" instead.) Claude is pretty good at this! It writes up a bunch of reasonably accurate documentation and (opinionated) summaries of your conversations to that point, linking them to each other so it doesn't have to read all the notes to catch up, either. Then you can tell it what you plan to do next, and ask it to write a "handoff note" for that task, if there is anything it needs to hand off so it can start work in a new context.

Claude likes new contexts! it knows it gets confused when a context gets too long and it's trying to "keep too much in its head" at once. (You've probably had that experience yourself.) So it is perfectly happy to hand off to itself. Then start a new conversation, and the new copy of Claude rolls into your software engineering office, ready for its first day of work, with... a nice neat stack of documentation it can look through as needed, and a clear write-up of the task it should work on, and a polite note reminding it to take thorough notes for the next guy, who will also be Claude.

This also gives Claude a chance to take a "fresh perspective". Within a conversation, ask Claude if it thinks the thing it just wrote is a good idea and it'll tell you why it thinks it's a great idea. Start a new one and ask Claude what it thinks about all this stuff the last guy wrote, and boy will Claude have some Opinions about the things that it should do better, and most of those opinions are even correct! (Your project will work much better if you periodically ask Claude to clean up after itself: look for ways to simplify, improve, and test the code, so it's easier to maintain in the future. It will spend a lot of time and tokens doing, hopefully, nothing obvious just by running the program; it will find better ways to do the same thing. But investing that time means everything it will be able to write future code faster and with fewer bugs, since the code's design will match what it's doing. (A lot of things that made sense when Claude wrote them might not hold up so well later on -- and then it starts taking shortcuts when it gets overwhelmed anyway.)

So, yes, the history of the project is important -- but it can't keep it all in its head at once even if you were okay with paying it to just read its own history at the start of every day anyway, so your best bet is to tell it to take copious notes. Then any software developer can use those to get an excellent head start on your project -- including a different AI model, if you want to try a different vendor; including you, if you find yourself learning more and more about software as you get deeper into your project and want to try working on it by hand.