Know when to start a fresh conversation

Forty-something turns into a coding session, the model reverses a decision it made back at turn twelve, quoting an assumption you dropped on purpose and never told it why. Nothing crashed. No error banner, no dropped connection. The thread just quietly stopped agreeing with itself.

That's the signal worth watching, not a turn counter and not a context-usage bar creeping toward its ceiling. Conversation continuity is useful right up until old turns start competing with whatever you're actually trying to get done this minute. Past that point you're not carrying context anymore, you're carrying weight.

Name the job before you touch the thread

My own reference case is unglamorous on purpose: one interactive coding session, one thread, three or four unrelated changes stacked back to back, because that's how real work actually shows up. No lab conditions, no claim that my machine or my workflow generalizes to yours. What I do insist on is naming the job before I touch anything. An interactive back-and-forth where I'm thinking out loud tolerates a messier thread than code completion firing on every keystroke. A document-extraction run has different stakes again, and an overnight batch nobody is watching has different stakes still. Each of those has its own tolerance for stale context, and "good" means something different in every one. Skip that step and you end up optimizing a number that felt satisfying in the moment, while the thing that actually mattered, whether the session still produced correct work, went unchecked.

The handoff is the whole trick

The method I actually use is boring: checkpoint the decisions that matter into a short handoff note, open a new thread, and paste back only the evidence that's still relevant, not the whole history. Then I treat that handoff the way I'd treat any other input: fixed, written down, attached to whatever result follows it, so I can tell later what the model actually had in front of it.

One clean run right after a reset doesn't tell you much. A fresh thread is a cold start, quick and unencumbered, and it will look better than the long thread almost every time regardless of whether the reset was warranted. So I check the run after that too, and a few more after it, because the slow, confused turn that shows up now and then, not every time, is the one that actually costs you, and it never shows up in the first exchange after a reset.

What I keep in that note, every time:

• what the current objective is, stated in one line
• which earlier decisions still bind and which were superseded
• any evidence, error output, or file state the next thread actually needs
• what quality bar counts as success this time, specifically, not vaguely

Don't grade a response on vibes

The common trap is keeping a chat alive for a week because the model once read a file that mattered, as if presence in a transcript were the same thing as relevance. It isn't, and treating a response that merely arrived without an error as proof of quality is the same old mistake as treating "it loaded" as a performance result for a local model that technically ran. A skim that felt fine isn't an evaluation. It's a mood.

For anyone running inference locally the mechanism behind a stale thread isn't mysterious. Every turn reprocesses the accumulated context, so time to first token creeps up with the transcript, the generation rate can sag once the card is holding more state than it has comfortable room for, and the memory footprint grows right alongside both. On a machine you're pushing hard, that eventually shows up as heat or as a GPU that's simply busier than the task deserves. It's the same instinct behind pointing out that context windows are a lie: a bigger number on the spec sheet doesn't mean every token in it is pulling weight, and a long thread doesn't mean every turn in it is still relevant. Check the actual logs and the runtime's own numbers before you trust a setting that claims to have handled this for you. When two threads behave differently, change one variable, the handoff, the model, the context length, and say out loud what you expect that change to do. And if trimming the thread changes what the model actually recommends, you haven't sped anything up, you've swapped in a different system that happens to answer faster. Otherwise you're not testing anything, you're collecting stories.

There's a maintenance cost to whatever heuristic you land on, too. A reset rule tuned to squeeze out a small win goes stale the moment the model, the runtime, or the context window size changes under you. Keep it retestable: a short script, a handful of prompts you actually recognize, a plain-text log of what happened. That's enough to check your assumptions again after an upgrade, and it's a long way from needing a dashboard.

What I actually give up

The rule I settled on: preserve state on purpose, not by default, and stop treating every token in a long thread as equally worth keeping. It's the same discipline behind copilot-token-diet: tokens are a budget you spend deliberately, not a pile you hoard because deleting felt risky.

In practice that means testing the smallest plausible fix first, trimming the handoff or dropping a stale file reference, before reaching for a full reset. It means leaving headroom rather than running a thread right up to its limit, because that spare capacity is what absorbs a longer prompt than usual or a background process you forgot was running. It's also what lets you try next month's model without rethinking the whole setup. And it means stopping once the thread meets its latency and quality bar rather than chasing a cleaner-looking number for its own sake.

None of this is chasing the single most dramatic-looking number. The setup worth keeping is the one whose behavior I understand well enough to trust without re-checking it every time, not the one that posted the best result once and then surprised me a week later.

What I give up, on purpose, is whatever context genuinely wasn't captured in the handoff: some throwaway remark, some half-formed reasoning the model won't see again. Sometimes that costs me a turn or two of re-explaining something I thought was obvious. I'd rather pay that small, known price than carry a week of conversation on the chance that one buried line in it still mattered.