In this part I’m sharing how I organize a working day with several Claude Code sessions: finding useful old context, moving independent tasks forward with Git worktrees, and leaving myself enough time to review what comes back.
An agent working on a substantial task can take thirty minutes, sometimes less and sometimes more. Reading unfamiliar code takes time. A database investigation can spend a long time waiting for queries. I can open another terminal tab with Claude Code while that happens. Unfortunately, opening another tab does not create another me to review the result :)
That is the balance I’m trying to find. I want useful work to continue while a task is running, but I also want to understand the changes when they arrive.
Part 2 in this series covered skills and technical review, and Part 3 covered scheduled maintenance. Here I’m concentrating on the small decisions between starting work and having something ready to review.
You can work through this guide with a repository you already know, Claude Code, Git, and two small tasks. One could be a frontend correction, the other could be an investigation in a different component. Choose work you can assess yourself. Your first experiment with parallel sessions should leave you with two understandable results.
We’ll start with choosing a conversation, then set up two workspaces and follow their results through review. The command examples use ordinary local Git operations. The prompts are suggested briefs for your own sessions, rather than quotations from the original project transcripts.
Before explaining a feature from the beginning, I usually try /resume and look for a session where I already worked on some similar task. For example if the task is related to cron job that will process the data I search for session with similar task to have a good context for start.
That can save quite a lot of rediscovery. The earlier session may already contain the relevant classes, a rejected hypothesis, or the reason we kept an unusual behavior. A ticket often contains the final decision, while the conversation contains the route we took to reach it. Also to keep important information I write Claude “memorize this and that” when it makes mistakes or something is a important nuance.
Resuming feels a little like a saved game, with one inconvenient difference: the rest of the team has kept playing. The conversation remembers where we stopped, but changes may have been merged, the ticket may have gained a new requirement, or another developer may have changed the implementation. I still need Claude to check the current repository and task state.
Open /resume and inspect the likely session before sending “continue.” I look for the last accepted decision, the last change, and anything explicitly left unfinished. A conversation that merely mentions the same class may carry a different task and several assumptions that no longer apply.
My first request after resuming would be:
Summarize where this task stopped.Separate accepted decisions, implemented changes, and unresolved ideas.List the files and branch we worked on, then verify their current state.Do not begin another implementation until you have compared the oldassumptions with the latest code and ticket discussion.
The distinction between a decision and an idea matters. A long conversation can contain three proposed solutions followed by a small accepted fix. The longest explanation can be the one we rejected. If Claude picks that up, we can spend another hour rediscovering why we rejected it.
If the useful context is short, I sometimes prefer a new session with a compact handover. For example:
Goal: correct mobile spacing on the product page.Keep: the approved desktop layout, one offer, and existing checkout.Previous work: redesign already merged; inspect the current default branch.New evidence: the latest review comment lists four phone-layout defects.Expected result: a separate follow-up change with screenshots at thereported widths and a clear account of remaining device testing.
That handover gives the new session the important conclusions without requiring it to reconstruct every discarded animation idea. It also makes the task easier to hand to another developer.
As a small exercise, take one completed session and write this kind of handover yourself. Then compare it with Claude’s summary. If the summaries disagree, settle the difference before using either as the next task’s starting point.
After the landing-page redesign, I asked Claude to address a set of mobile issues from a review comment. It reproduced the problems, changed the responsive styles, and pushed a commit to the branch used for the original page work.
Then I asked a short question:
are changes fixed on master?
The answer changed the situation. The original pull request had already been squash-merged, and its source branch had been deleted. The new push recreated that old branch. The mobile fix therefore existed remotely, but it was not on the default branch and was not attached to a new open pull request. The push had succeeded. It had just delivered the work to a place we had already finished using.
Claude moved the fix to a fresh branch based on the current default branch. In that session it could push, but it could not create the pull request with the available access, so it provided the link for me to open it.
At that point, the next action was mine: open the new PR. The branch problem had been corrected, but the fix still needed review and merging before it could reach deployment.
This is now something I want checked at the start of a resumed task: which branch are we on, what is the current default branch, and is the related PR still open? A familiar conversation can make an old working state feel current.
A brief I would use for a similar follow-up is
Resume the context of this feature, then check its current state.Read the latest ticket discussion and inspect the related PR.If the previous PR is already merged, prepare the follow-up fromthe current default branch in a new worktree and branch.Keep the change limited to the reported mobile issues.
it can be also added to CLAUDE.md file https://claude.com/blog/using-claude-md-files.
In a Git checkout, these commands provide a useful first look:
git status --short --branchgit branch --show-currentgit log -5 --oneline --decorategit worktree list
Then fetch the remote refs when you need the current remote state:
git fetch origin
These commands do not establish whether a PR is open. Check that separately in GitHub, Bitbucket, or the project tool available to Claude. A branch name can remain after a merge, and a deleted branch can be recreated by a later push, as happened in my example.
Ask Claude to report the result in one compact record:
Repository:Working directory:Current branch:Default branch and current commit:Related PR and its status:Uncommitted changes:Proposed branch for this task:
Keep this short enough that you will actually read it. A few lines can expose a mismatch between “the branch I remember” and “the branch we are actually changing.” If there are existing local edits, identify their owner and purpose before allowing a checkout, reset, or cleanup.
For a follow-up to a squash-merged PR, inspect the current default branch as the starting implementation. Reapplying the entire old branch can bring back changes that are already present under a different commit. Claude should identify the new correction you need, not assume that an old history should be merged again wholesale.
When I move to an unrelated task, I use /clear. It starts a new conversation with empty conversational context, project instructions and persistent memory can still apply.
There is a small but important correction to how I initially described this command. It does more than clean the terminal display. If I only want to redraw the screen while keeping the conversation, Ctrl+L does that. See the interactive-mode reference.
I think of /clear as wiping the conversation’s whiteboard. That can help when the previous task is finished and I want to start new unrelated one. For related work, I usually want to keep those useful notes and resume the session.
I also try to leave a useful handover before switching: what changed, what was verified, which branch holds it, and what remains undecided. That makes the next session easier for me as well as for Claude.
A practical experiment makes the distinction easier to remember. Ask a session to summarize an investigation, then press Ctrl+L and continue discussing it. The display changes, while the conversation remains available. For a genuinely new task, use /clear and state the new objective explicitly.
Do not use the new session as evidence that files were rolled back. Conversation state and repository state are separate. The code written during the old session is still in the working directory unless you deliberately changed it through Git or another file operation (command: git worktree remove <worktree_dir_name>).
My switching routine is therefore simple: finish the current handover, inspect the working directory, then choose the session for the next task. If the tasks need different branches, I use separate worktrees rather than relying on a cleared conversation to separate the work.
I tried for example/team-onboarding
/team-onboarding generates an onboarding guide from recent Claude Code usage, including sessions, commands, and MCP use. It generates a guidence for other team members based on your experience stored in Claude sessions.
I liked the idea. For a new team member, a description of how we actually work can be more useful than a general tool tutorial. It can show which integrations matter and which workflows we use repeatedly.
In my case, I eventually did not store the generated guide in the project. Much of it repeated information that was already available, and I did not want another document to maintain.
I would consider it again when someone joins the team. At that point I could review the output against that person’s needs and keep the missing pieces. A useful command does not always need to produce a permanent repository file.
To try it, run the command and read the guide as if you had never used the project before. Can a newcomer tell which repository to open, how to start the application, and which integrations they need? Which instructions point to maintained documentation, and which repeat information that will soon become stale?
I would then ask for a shorter version focused on gaps:
Compare this onboarding draft with the project's existing documentation.List genuinely missing setup or workflow information, with references.Propose additions in the appropriate existing documents.Keep personal account details and local-only paths out of shared guidance.
The result might be useful additions to the README.md.
/usage shows usage information and plan limits. I checked it particularly often when Fable 5.1 was my main model (before arrival of new king Opus 5.5… which is probably already replaced by a better model when you read this article :)).
When I am close to a limit, starting another long investigation may be inconvenient. I can use that time to review a finished PR, clarify a requirement, or prepare the next task while capacity becomes available again.
When I reach a session limit and have another Claude account available and authorized for the project, I use /login to sign into it. In my local workflow I can then continue (just by typing “continue”) the work, provided the relevant conversation is still open or has been resumed.
The word “continue” is useful only when there is something in context to continue. Signing in does not, by itself, reconstruct a missing session or move project access between accounts but it can access information from session in same tab and go forward from place where it was interrupted by the worst programmers circumstance — “running out of tokens” ;).
The Claude Code command reference documents these and some more commands. Availability can depend on the installed version, plan, and environment, so typing / in the current installation is a useful first check.
I also want a task to survive an interruption. Before starting a substantial investigation, I ask for intermediate results in a form I can inspect: the hypotheses considered, the commands that ran, and the location of any draft change. If the session stops at a usage limit, that record makes it possible to decide whether to resume, wait, or finish a small remaining step myself.
When changing accounts or restarting, next message can be slightly more precise than “continue”:
Continue the current task from the last verified step.First check the working directory, branch, and any running jobs.Summarize what completed and what was only planned.Do not repeat a migration, data change, or external write merely becausethe previous response ended before confirming it.
This is especially useful when the delay was in a tool call. An interrupted explanation does not necessarily mean the tool operation never happened. Establish the actual state before starting it again.
/loop command can be used when a task needs repeated attention during an active working session. For example, checking the status of a particular build every few minutes can be more convenient than remembering to ask again.
An illustrative request is:
/loop 10m Check the CI status of the PR for this branch.Report changes and stop checking once the build completes.Do not modify the branch or post comments.
I still verify that the scheduled check has stopped when the task is done. The scheduled-task documentation describes these as session-scoped tasks, a loop is not a replacement for the durable maintenance setup from Part 3. It also does not automatically turn the work into a team of agents.
/workflows opens the progress view for dynamic workflows, where I can watch, , resume, or save them. The dynamic-workflow documentation covers work distributed across subagents.
That scale can be useful when there are many genuinely independent units of work. I still prefer the smallest arrangement that meets the requirement. A single session is often enough. A separate reviewer is useful when I want a focused second pass. More agents become worthwhile when the work actually separates well.
My rule is: don’t shoot a fly from a canon.
Every additional agent may need to read context, use tools, and produce output. There is also another result for me to assess. For a small task, coordinating all of that can cost more than doing the work directly.
If fixing one margin requires the Avengers to assemble, I would first question my task breakdown. A larger group makes sense when its members have independent jobs. Otherwise, I am paying several agents to understand the same file. So I just start from friendly neighborhood Claude session which is usually more than enough and will solve most of needs before using more advanced parallel work methods like /workflows .
Before using a loop for real work, run the intended check once. Confirm that it finds the correct PR or build and reports a useful result. Repeating a check that watches the wrong target only gives you the wrong answer more often.
Then define what a change looks like. For a build, the interesting transitions might be pending to running, running to failed, or running to successful. If the state is unchanged, I usually want little or no repeated explanation.
Finally, make the end condition visible. A completed build, a closed PR, or a cancelled deployment should end the watch. Check the active scheduled work after completion instead of assuming the agent removed it because its prose says it is done.
For a larger dynamic workflow, I apply the same reasoning before thinking about agent counts. Suppose the job is to inspect a set of unrelated modules. Each worker needs a target, an expected report format, and a clear rule for whether it can edit. Someone also needs to combine duplicate findings and resolve conflicting recommendations.
A brief I would use before launching that kind of workflow is:
Propose how to divide this task into independent units.Explain which context every worker needs and what each should return.Start with the smallest useful number of workers.Identify shared files, services, or decisions that prevent independence.Estimate what will be repeated across workers before starting the run.
Before accepting the division, ask yourself which result you could review independently. If every worker needs to understand the whole project and change the same central service, the task may not divide well. A single implementation session followed by a focused review may be easier to manage.
When a workflow does make sense, use /workflows to follow its progress and look at where time and tokens are going. If several workers independently rediscover the same setup, improve the shared brief before scaling the next run.
When several Claude Code tabs use the same working directory, their edits share one set of files. Even if the instructions describe different tasks, a build, checkout, or unfinished change can interfere with another session.
A Git worktree gives another branch its own checkout and index while sharing the underlying repository. I can open Claude Code in each directory and keep independent tasks apart.
For example, starting from a repository whose default branch is main:
git fetch origingit worktree add -b feature/premium-mobile ../project-mobile-app origin/maingit worktree add -b fix/report-parser ../project-report-parser origin/maingit worktree list
Then, in separate terminal tabs:
The names are examples. Use the repository’s actual default branch, which is master in the page-work example above, and choose unused paths and branch names.
Think of these as separate workbenches in one workshop. Each task has its own files, but the benches may still share equipment. In our case that equipment includes databases, caches, application ports, and external accounts. Two development servers need different ports, and a fixture reset can still surprise another session using the same test database.
Set up those shared dependencies deliberately. I also avoid assigning two agents competing versions of the same architectural change. Giving a disagreement two directories does not resolve it.
With several tabs open, my day has become less linear. I might start one bounded implementation and another investigation, then review a completed change while both are running.
The sequence usually looks like this:
A skill supplies the procedure; the agent or session runs it. Keeping that distinction helps when deciding whether I need a different process, a separate context, or simply clearer instructions.
Parallel implementation can make the review queue grow very quickly. At some point the slowest part of the system becomes the person with the coffee, reading the diffs. That person is usually me. If several PRs are already waiting, finishing one review is more useful than starting another task whose requirements I may forget before I see the result.
The long-running task also needs an understandable status. “Still investigating” is less useful than knowing which hypothesis is being checked and whether the delay comes from model work, a build, or a slow query. More agents will not make the same shared database query finish sooner.
When the implementation is ready for technical review, pass the requirement and the actual source and target revisions to the reviewer. Part 2 explains that process in detail. Here the important coordination point is to keep the reviewed commit identifiable while several sessions are still working.
Reviewing while implementation continues is like proofreading a chapter while someone rewrites the next paragraph. Both people can do useful work, but they need to know which version they mean. Keep the commit identifiable and ask for a follow-up against later changes: which findings remain, and which disappeared because the code changed?
Then I review the proposal myself. For a UI task, I look at the page and the diff. For a parser task, I look at the reproduction and whether it exercises the same service lifecycle as the worker. I use the agent’s report to focus attention, while still judging the behavior that matters.
Keep decisions attached to the task they belong to. A conclusion reached in the parser tab will not automatically appear in the frontend session. If two tasks depend on the same architectural decision, settle that shared decision explicitly and update both briefs.
Two independent branches can become dependent when the first one is merged. The second branch still contains its original view of the default branch until it is updated.
Use the team’s usual merge or rebase policy and rerun the checks affected by the integration. If both changes touch a shared API or migration sequence, inspect that combined behavior deliberately. A clean textual merge does not prove that two behavioral assumptions still fit together.
For a simple example, one task might rename a field that another task reads. Git can merge both files without a conflict, while the application fails because the name no longer matches. The integration check needs to follow the dependency, not just count conflict markers.
Do not let Claude treat a conflict as permission to rewrite the surrounding design. Ask it to explain the intent on both sides and propose the smallest resolution that preserves the accepted requirements. This is another moment where your knowledge of the project can save an unnecessary refactor.
Once the change is integrated, mark the task state clearly. I distinguish a prepared patch, a pushed branch, an open PR, a merged PR, and a deployed change. Those stages can happen close together, but they answer different questions when someone asks whether a fix is available.
Before cleaning up, stop the development server or other task-specific processes and check for uncommitted work:
git -C ../project-premium-mobile status --shortgit worktree list
After confirming that the useful changes are preserved and the task no longer needs the checkout, remove it through Git:
git worktree remove ../project-premium-mobile
Do not add --force simply because removal refuses. Inspect the remaining files first. They may include an uncommitted correction or a reproduction that should be kept with the task.
The branch and the worktree have separate lifecycles. Removing the checkout does not mean its PR was merged or its branch should be deleted. With squash merges, branch-cleanup checks can also behave differently from a direct merge, so use the PR record and the team’s cleanup practice.
I keep useful discoveries in the ticket, code, tests, or maintained project guidance before removing the temporary workspace. Otherwise, the worktree can become the only place where a valuable reproduction exists.
For some time, Claude Fable 5.1 gave me the best results in my development work. Then OpenAI introduced GPT-6 Astra, and I started trying Codex even though I was already comfortable with Claude Code.
My experiment with that alternative lasted about two weeks before Anthropic’s Opus 5.5 release made me reconsider the balance again. For the release timeline, OpenAI’s changelog lists GPT-6 Astra on September 3, 2026; Anthropic announced Opus 5.5 on September 22.
There is a pricing detail I want to get right. In the Opus 5.5 announcement, Anthropic reports roughly 40% lower cost than Opus 5 on typical workloads. That is not a universal forty-percent discount against Fable 5.1 or GPT-6 Astra. The published input and output token prices fell by twenty percent relative to Opus 5, with other factors contributing to the workload-level claim.
Anthropic also describes Opus 5.5 as performing around Fable 5.1’s level on most work. Its comparison with Astra varies by benchmark. I would not turn that into a claim that all three models are equally capable for every project, or that my subscription bill will fall by the same percentage.
For my purposes, these releases are reasons to try the tools again. I care about whether they understand the existing architecture, how often I need to redirect them, and how much review the result needs. A model that completes the first implementation quickly can still leave me with more work overall.
I also try to distinguish the model from the application around it. Comparing Codex and Claude Code involves their tools, context handling, and workflow as well as the model. If I change all of those at once, I cannot confidently attribute an improvement to only one component.
Following every announcement would take a lot of time. My practical compromise is to notice the significant changes and try them on work I understand well enough to judge. Familiarity with one tool is useful, but I don’t want it to stop me checking an alternative.
In Part 1, I joked that project-management tools could have been Pokémon names. Model releases are becoming quite a collection too. I have no ambition to catch them all. I want to know whether a new one improves the work I actually do.
A simple personal comparison starts with a small set of representative tasks. I would choose one investigation in familiar code, one bounded implementation, and one review with a known issue. They should resemble the work that takes my time during a normal week.
Give each tool the same starting commit, requirements, and relevant evidence. If one has repository access and the other receives only a pasted function, you are comparing different working conditions. Sometimes that comparison is useful, but record what differed.
Run the tasks in separate worktrees so one model does not inherit the other’s implementation. Avoid feeding the first model’s answer into the second unless the exercise is specifically about critique. Otherwise, it becomes hard to tell whether the second tool found the solution or merely evaluated a supplied one.
I would record the result in a small table:
Do not give every correction the same weight. Changing a button label takes a moment. Discovering that a proposed architecture duplicates an existing subsystem can send the whole task back to investigation. Write down the most important intervention; that sentence may tell you more than the score.
Likewise, elapsed time includes builds and queries. A slower database does not establish that the model reasons more slowly. For subscription use, reported usage and interruptions may matter more to my day than an API price calculated under another billing arrangement.
This is a small working comparison, not a benchmark that proves one model is best. It can still answer a useful personal question: which tool currently gives me a result I can trust and review with the least unnecessary work?
Repeat a few meaningful tasks when the tools change, and keep the observations short enough to maintain. That gives model news somewhere practical to land without turning every release into a week-long evaluation project.
The Claude Code commands and Git worktrees help me use the time while an agent reads code, runs checks, or waits for evidence. I can move between implementation, investigation, and review instead of watching a single terminal.
I still have only one pair of eyes for the final review. Some days the best next step is another implementation. Other days it is closing a terminal tab and properly reading the PR that is already waiting. That is part of making parallel work useful too.
That’s all in this part. I invite you to Part 6 where I will explore some mistakes and misleading results delivered by Claude Code. I’ll propose how to deal with such problems and how to not miss the situation when delivered solution by AI is the wrong one.
Resuming Sessions, Working in Parallel, and Keeping Costs Sensible — Automating Project… was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.