Session Strategies

One Task Per Session

This is the simplest strategy and the one I recommend starting with.

Let’s say you are developing a UI which has a new page with table, filter, sorting, and then of course you will need to do some adjustments and bug fixes.

If you try to work in a single session, then your context might bloat and agent will start performing poorly. The quality drops.

What you can do instead is using multiple sessions for this single assignment.

That way you are going to have more focused context windows and much less chance for hallucination.

When you see the task growing bigger than expected — stop. Start a new session.

The Drifting Challenge

One task per session works well for most cases. But sometimes even a single task is too big for one session.

Imagine you need to migrate a module from one API to another. You start by exploring the existing code — what does it use, what are the edge cases, what needs to change. By the time you finish the investigation, your context is already at 50–60%. Now you start coding, and the agent drifts. It forgets constraints you discussed earlier. It makes shortcuts.

The problem is not the task itself — it’s that investigation and execution compete for the same context window.

Clear Context Feature

Claude Code has a feature that lets you clear context after planning mode, before execution starts. You discuss the task, build a plan, and then start fresh with just the plan. I use this for smaller, straightforward features — plan it, clear, execute.

But when the task is bigger or more complex from a product or technical perspective, clearing context is not enough. I need investigation sessions.

Investigation vs Execution Sessions

Not every session is the same. I use two types of sessions — investigation sessions and execution sessions.

Side note: I often use dictation to explain my thoughts to Claude. It handles text with no punctuation and typos surprisingly well — so do not worry about formatting your prompts perfectly.

Investigation Sessions

In my investigation sessions, I ask the agent to explore, analyse, ask questions, and maybe rubber duck with me. This is usually read-only mode. No code changes, just understanding.

At the end, I offload the summary or the detailed feature description into a document. Even this rubber ducking and exploration can easily consume 50%+ of the context window. I would not want to start development of a feature when my context is already at 50%.

# Example of exploration prompt
We have 15 features that use Gemini API directly.
Each feature uses different Gemini capabilities (context caching,
tool calling, grounded search, media files, etc).

Analyse each feature and create a summary document that lists:
- Every feature in our application that uses Gemini LLM
- Which Gemini capabilities each feature relies on
- Whether OpenRouter API supports each of those capabilities

Read documentation and see if OpenRouter has all capabilities we need.
I want to make sure we do not miss anything before we start the migration.

Save the summary to docs/openrouter-migration-analysis.md

After this session I had a clear picture of what we use and what OpenRouter supports. No code was changed. Just a document I could review, share with my team, and use as input for the execution sessions.

Investigation sessions often go through multiple iterations. As I change technical requirements, discover new constraints, or rethink the approach — the exploration document evolves with me. It is a living document until I’m ready to execute.

Execution Sessions

Execution sessions are about executing the plan or part of the plan. They usually start with planning mode, and then I accept the edits. By splitting investigation and execution, execution sessions have a more focused context. The summary or detailed plan from the investigation session becomes the starting point.

Context stays low. Results stay consistent. The output of execution sessions is working code.

The Workflow

When working on a bigger feature, the workflow looks like this.

Investigation — asking questions. Can we implement this? Does the API support that? How does it affect existing features? You explore, you analyse, you build understanding.

Then you save your research, ideas, and all of the details into an exploration document. This document becomes the bridge.

Then you use this document in the execution session, starting with planning mode.

Output from investigation session is input for execution session.

Exploration Document vs Agent Plan

These are two different things.

The exploration document is a free-form document that captures your research and your thoughts. It might list every module in the codebase that uses a specific pattern, edge cases you discovered, ideas for how to approach the migration. I often use swarms to generate these — for example, analysing the entire codebase to find all validation points and checking which ones are compatible with a new library. The result is a clear picture in a document, not in an agent’s context.

The agent execution plan is different — file-by-file changes, execution steps, order of implementation. This is generated by the agent in planning mode and verified by you.

When to Use Which

If you are just exploring or not sure how or what to build — use read-only mode. Speak with the agent, explore, and build a document.

If you already know what you need but need a detailed implementation plan — you are ready for planning mode.

When your plan is ready and you like the proposal — start the execution.

However, if the task is really small, straightforward, and obvious — I usually skip planning and go straight to execution.

Just remember that planning mode itself can consume a lot of your context window.

Real Example: LLM Provider Migration

We had to migrate from LLM providers like Gemini and Claude to start using OpenRouter. We had around 10 modules that used the LLM API directly.

Four focused sessions instead of one bloated session. Each one had a clear scope and clean context.

Takeaways

• Start with one task per session — when the task grows bigger than expected, stop and start a new session
• Split complex tasks into investigation and execution sessions
• Investigation is read-only: explore, analyse, build a document
• Execution starts from that document with a fresh, focused context
• Never start coding in a session where investigation already consumed half of your context