Part One

The car nobody explained

Most chat tools are automatics. They do the ordinary jobs well, keep the risky controls out of reach, and they won’t let you stall. For most people, most of the time, that’s the right car.

Long-running work is where this gets unglued.

The kind of work I’m talking about is research and writing that builds over days or weeks — accumulating sources, developing ideas, moving from rough thinking to something you’d actually publish. Not a single task you hand off and collect. A project.

In most tools, that project ends the same way. The wheels start to slip in the turns. The engine misfires. I find myself covering ground I already covered — same problem, same dead ends. So I pull the draft to a separate document and finish it by hand. Claude is more resilient, but it can end up in the same pattern if you haven’t learned to drive it.

Most of what gets written about Claude is aimed at developers — token budgets, prompt caching, agent orchestration. Not much help if you’re doing research and writing.

What drew me to Claude was simple: it reasons better. It produces a clean diagram. It formats a document well enough that I’m not spending hours cleaning up drafts before I can share them. Real advantages, and they come with a real catch.

The capability is metered. Every plan runs on a usage window, and the strongest setup drains it fastest. At first that felt like a cost problem. It isn’t. It’s a design constraint that turns out to be a feature — it forces you to make choices about your work that make you a better driver.

Claude was demanding I learn to drive. Once I did, everything changed.

If you work the way I do — long research, multi-session writing, an LLM alongside you the whole way — this paper is the foundation. It covers the ideas you need to understand. Paper Two is the framework I built to put them to work.

Part Two

Choosing your gears and Loading the vehicle

The first move isn’t picking a model. It’s assessing the work in front of you — how complex is it, how much genuine uncertainty does it carry, does it need open-ended judgment or defined execution against a settled plan — and matching that to what you can afford. Model, effort, and context are how you spend.

What can you afford in your time window

Working in Claude for hours at a stretch means working within a budget. You’re not billed per token unless you buy additional credits, but you do have a rolling session window and a weekly limit, and both draw down as you work. Burning through either means stopping early.

The right model depends on the work. Deep reasoning and open-ended judgment go to the strongest model. Defined execution — drafting from a settled outline, producing from a spec — goes to the fastest capable one. Right now that means Opus to frame and synthesize, Sonnet to draft and produce, Haiku for the lightweight tasks.

My own path wasn’t clean. I defaulted to Opus because it handled everything. Then Anthropic released a new version and the token usage doubled overnight. I was burning through my session window in two hours instead of five, and just staying on the latest model was no longer a cost I could absorb. When I shifted to Opus for the framing work and Sonnet for execution, I got the same quality at half the cost — and kept working longer on the same plan.

As I came to the final draft of this paper, I shifted from Opus to Sonnet Max and turned off Claude’s extended thinking mode. The ideas were settled — I didn’t need deep reasoning pulling in bigger questions from the project. I needed clean, fast prose work, section by section. Sonnet is better at that. Turning off thinking kept it focused on the writing in front of it rather than re-examining the architecture behind it. And it iterates faster, which is exactly what you want in a drafting pass.

One thing I almost never do: switch models mid-thread. Bringing a new model into a long thread is like bringing a new person into a meeting that’s been running for two hours. They need to catch up, and the thinking gets inconsistent while they do. If I need to switch, I’d rather start a fresh thread than try to hand off mid-stream.

Context is what you’re carrying in the vehicle

Context is the other half of the equation. It determines what the model is actually working with — what facts it holds, what decisions it remembers, how much of your work is live in the thread.

Something shifted here while I was writing this paper. Claude used to hold your entire thread, word for word, until you hit a hard stop. Now the stop is softer. When a thread gets near the context limit, Claude summarizes the early material and keeps going — and it marks the spot when it does. Everything below that line is still held in full.

The other tools I’ve used do something different. They trim and compress continuously as the thread grows, and you find out what fell off when the model forgets it. With Claude you can see what the model is holding, because below the compression line, it’s holding all of it.

That difference matters because it means you can choose where the break happens and what survives it. A break you cut deliberately — carrying forward what you decided matters — produces better work than a break the system cut for you.

These habits pay off on work that builds over time. For a one-off question, skip them and just pick the right model for the task.

Is the process overhead worth it?

Managing context, breaking work across threads, writing a handoff note at the end of a session — that’s real work. Worth asking honestly whether it pays.

Working through multiple drafts and iterations with a model that isn’t losing the thread — isn’t quietly forgetting earlier decisions or drifting from the original problem — produces better work. That part is straightforward.

The thing that’s hard to see until you’ve lived it: when I write two thousand words the usual way, I get attached to the sentences. Tearing the structure down means rewriting all of them, so I defend what I have instead of improving it. When Claude holds the draft, the sentences stop being the investment. The ideas are the investment — what the piece argues, how it’s ordered, what it’s built to do. Those survive any rewrite. The prose is just the cheap layer, regenerated from the thinking you already banked. You can reshape the whole thing with a few prompts and feel nothing, because nothing you actually valued got destroyed.

Claude is a raw tool. Powerful, but raw. A software engineer has an IDE — one place that holds everything, tracks every change, keeps the project coherent across sessions. Nothing like that exists for knowledge work. So you assemble it yourself.

That assembly is what Paper Two is about.