Notes from a week of smaller Claude Code tasks
A Claude Code session can begin with a small bug and end with three unfinished refactors. The problem is not simply its length. It is the accumulation of goals, assumptions, and partial decisions that the assistant must keep distinguishing from the current task.
The useful comparison is between an open-ended session and a bounded one, not between an arbitrary number of minutes. Short sessions work best when each has a clear outcome and leaves enough evidence for the next.
§ The opening request
Open-ended session: “Investigate the failing login flow and improve the authentication code.” This combines diagnosis, repair, and redesign. Each discovery can expand the scope, making it difficult to tell when the work is complete.
Focused session: “Reproduce the expired-session redirect failure, identify its cause, and propose the smallest fix. Do not change the authentication architecture.” The assistant has a concrete question, an explicit boundary, and a natural stopping point.
A narrow request does not mean withholding useful context. Include the failing command, expected behavior, relevant files, and constraints. Remove unrelated history, not information needed to reason correctly.
§ The working context
Open-ended session: Earlier experiments remain in the conversation alongside current instructions. A discarded approach may still influence later suggestions, especially if the decision to abandon it was never stated clearly.
Focused session: Start a fresh conversation when the objective materially changes. Carry forward confirmed facts and unresolved questions rather than the entire exploration. Keep durable repository guidance in the appropriate project instructions, such as CLAUDE.md, rather than repeatedly explaining conventions.
Do not reset merely because the conversation looks long. If Claude Code is still resolving one tightly connected problem, preserving context may be more useful than rebuilding it. Compaction can help continue that work, but its summary should be checked for missing constraints.
§ The amount of code changed
Open-ended session: A bug fix grows into cleanup, dependency changes, and naming improvements. Those changes may be reasonable individually, but together they make review harder and obscure which edit actually resolved the failure.
Focused session: Ask for the smallest coherent patch, then inspect the diff before authorizing adjacent improvements. Put optional cleanup into a separate task. One session can investigate; another can implement an approved plan when that separation reduces uncertainty.
The boundary should follow the work. A change spanning several files can still be focused if those files implement one behavior and can be verified together.
§ The stopping rule
Open-ended session: “Keep improving this” offers no reliable finish line. The assistant can continue finding plausible work after the original issue is resolved.
Focused session: Define completion before editing: reproduce the issue, add or update a targeted test, apply the fix, and run the relevant checks. Ask for the commands actually run and their results, including failures and checks that could not be executed.
End with a small handoff: what changed, what evidence supports it, and what remains uncertain. A claim that tests passed is less useful than the exact command and observed outcome.
§ The cost of starting again
Open-ended session: Keeping everything together avoids repeated orientation, but later requests may involve more accumulated context. The effect on billing depends on the tokens processed, caching, model pricing, and client behavior.
Focused session: Fresh starts can reduce irrelevant context, but they also repeat repository discovery and setup. Compare similar tasks using actual usage records; shorter conversations do not automatically mean lower total cost.
Vana API works with Claude Code and bills per real token with no monthly fee. Its endpoint, https://api.vanaapi.com, supports OpenAI-compatible requests as well as Anthropic Messages and Gemini native protocols. For a useful workflow comparison, keep the model and task difficulty consistent. Create a Vana API account if you want to try this workflow through one endpoint.
§ A practical default
Keep a session open while its goal, constraints, and verification remain coherent. Start another when the task changes, the history becomes contradictory, or a clean handoff would be easier to review than the conversation itself. The aim is not less conversation at any cost. It is less ambiguity per change.