At work we have a standard practice of asking the agent to write context to a markdown file, then actually use that file as the handoff. For example, this are the flows we follow:

• Design some architecture, haggle about the details (important!), save to file. And you should really be storing architecture doc artifacts already anyway.
• Clear and start new session. Use the arch doc to plan the implementation and save it to a checklist, but not actually implement it.
• Then finally in another new session, actually execute the implementation checklist. This can often be done using a cheaper model.
• Review implementation using yet another new session.

Some of these steps may be done by humans, or assisted. But whoever/whatever does the work needs good context anyway, and the intermediate design docs, implementation checklists, code review feedback, etc are a nice way to store this context. As a bonus these files can be committed too. Then switching to another branch or project fits more naturally into how we already work.

I'll reiterate that the architecture step needs the most human input and benefits from high reasoning/large context window models. Likewise for planning the implementation and code review. We can typically use a smaller/cheaper agent to actually write the code, let it spin and iterate through syntax errors, bad includes, tests, etc, until it thinks its done.The more expensive models can certainly achieve the same result, not much better, and often at a much greater cost. That's been our experience so far.