Keeping Context When You Juggle Multiple Repos

Most developers I talk to assume KeepGoing is just for side projects. You know, the kind of thing you touch on a Friday night and forget about until the following month.

But the developers who get the most out of it often have a different problem. They are professional developers working across multiple repos every single day. A frontend app, a backend API, a shared library, maybe an infrastructure repo. Each one is a separate context. Each one demands its own mental state. And every time you switch, you pay the price.

The real cost of repo-hopping

The “context switch cost” gets cited a lot as a general productivity concept. But there is a specific form of it that hits hard when you are working across multiple codebases: the re-orientation penalty.

You were deep in the API repo. Something was half-done, a refactor that touched three files, a decision pending about how to handle retry logic. Then a Slack message arrives. There is a bug in the frontend, someone is blocked, it is your area. You switch.

An hour later, the frontend bug is resolved. You switch back to the API repo.

And then you stare at it.

Which branch were you on? What was the half-finished refactor trying to do? Why is that function commented out? The code has not changed. Your brain has. Everything you had loaded up about that codebase is gone, replaced by frontend concerns.

Studies on context switching in software development put the re-orientation cost at 15-25 minutes per context switch. If you are hopping between two or three repos in a day, that adds up quickly. It is not the switching itself that costs you. It is the reconstruction afterward.

How KeepGoing handles multiple repos

KeepGoing stores its data in a .keepgoing/ directory at the root of each git repository. Not in a central database, not in the cloud. Right there in the repo, local to it.

This means each repo has its own completely independent session history. When you are working in the API repo, checkpoints get written there. When you switch to the frontend repo, checkpoints get written there. The two never mix.

When you come back to the API repo, KeepGoing surfaces the context from that repo specifically. Not a global log of everything you have touched. The specific thing you were doing in that codebase, the last decision you made, the exact next step you left for yourself.

It works across VS Code, Claude Code, GitHub Copilot, JetBrains, and the CLI. Whichever tool you pick up in a given repo, the context is there.

The Desktop Tray: all projects at a glance

The context is useful when you are inside a repo. But what about before you even open one?

The KeepGoing Desktop Tray sits in your macOS menubar and watches all your configured projects simultaneously. A single click shows you every active project, with per-project session status.

my-app (2 active)
  ● Claude Code @feat/auth · 2m
  ● Cursor @fix/webhook · 8m
api-server (1 idle)
  ◦ Claude Code @main · 24m
infra (no active sessions)

You can see at a glance that the API server has a session that went idle 24 minutes ago. That is probably where you left off. Before you open a terminal, you already know which repo to go back to and roughly what state it is in.

The tray also surfaces the re-entry briefing for any project with a click, so you can read your last checkpoint before even opening the editor. That 15-minute re-orientation window shrinks significantly when you have already read the briefing by the time VS Code finishes loading.

A concrete scenario

Here is what a realistic workday looks like with this in place.

You start in the API repo at 9am. You are working on retry logic for a webhook handler. At 10:30, a Slack message: the frontend team cannot reproduce a CORS issue that is blocking their release. You save a checkpoint before switching. The checkpoint says: “Mid-way through retry handler in webhookService.ts. The decision was to use exponential backoff with a 3-attempt ceiling. The function signature is finalized but the test is not written yet. Next step: write the failure case test, then wire up the route.”

You switch to the frontend repo. Fix the CORS configuration. It takes 45 minutes.

After lunch, you look at the tray. The API repo shows a session from this morning, idle. You click on the tray, open the briefing, and read your checkpoint from three hours ago. By the time you open VS Code and navigate to webhookService.ts, you already know what you are doing. No staring at code trying to remember where you were. You just write the test.

That is the re-orientation cost going from 15-25 minutes to about 90 seconds.

Continue On: when you move context between tools

Sometimes the switch is not just between repos. It is between tools entirely. You were working in VS Code, now you want to hand off to Claude or another AI assistant. Or you want to continue on a different machine.

The Continue On feature handles this. It exports a structured briefing from any project as a markdown prompt you can paste directly into any AI tool. The briefing includes your last checkpoint, recent commits, active decisions, and the suggested next step.

This is useful for multi-repo workflows specifically because each export is scoped to a single project. You can export the API context, hand it to an AI assistant, switch to the frontend in your editor, and have two separate workstreams running with their own context intact.

It helps teammates too

The .keepgoing/ directory lives at the git root, which means it can travel with the repo. If you commit it or share it through other means, a teammate who opens the project can see your session history, your last checkpoint, and the decisions you logged along the way.

This is not a replacement for code review or documentation. But for a teammate picking up something you were in the middle of, a recent checkpoint is often more useful than reading the git log. It says where you were, not just what changed.

---

The assumption that context-switching pain is just about side projects misses a much bigger group: professional developers who live in multiple repos every day. If that sounds like your workflow, the problem is not your memory. It is that your tooling has no concept of per-repo context. KeepGoing does.