MOLTamp 3.2: 50 Tabs, Agent Alerts, and the End of Babysitting

MOLTamp 3.2 shipped on July 30. It is the biggest change to how the app works since launch, and it started with a support ticket telling me my session limit was too low.

Short version of what is new: 50 sessions instead of 9, a scrolling tab strip, a Cmd+P session manager with search and rename and reorder, per-tab attention badges, and tabs that adopt the titles agents give themselves.

Why the 9-session cap died

The cap was 9 because the shortcuts were Cmd+1 through Cmd+9. That is the entire reasoning. I picked a number that matched a keyboard row and shipped it, and for about a year nobody complained.

Then a user opened a ticket. He was running agents across a stack of git worktrees, one agent per branch, and 9 was not enough. He was closing sessions he still needed to make room for new ones, which is exactly the kind of friction that means the tool is wrong rather than the user.

My first instinct was to say no. Nine felt like plenty, and I could not picture the workflow. So I tried to reproduce it: worktrees for separate features, an agent in each, plus a shell for git, plus a log tail, plus the app I was actually building. I hit 9 in about four minutes and understood the ticket completely.

That is the whole lesson. I had built for my own usage from a year ago and the usage moved. Agents got good enough to run unattended, so people run more of them, so the constraint that used to be invisible became the main thing in the way.

50 is the new number. It is arbitrary too, but it is arbitrary at a level nobody is going to hit by accident.

What shipped

50 sessions. Cmd+1 through Cmd+9 still jump to the first nine, because muscle memory is real and breaking it for no reason is rude. Everything past nine is reachable other ways.

A scrolling tab strip. Twenty tabs do not fit in a window. The strip scrolls, keeps the active tab in view, and does not shrink every tab to an unreadable sliver as you add more. Tabs hold a minimum width and the strip scrolls instead. That was a deliberate choice: a row of 3-pixel tabs is technically a tab bar and practically a decoration.

Cmd+P session manager. Fuzzy search across sessions, plus rename and reorder from the same panel. At thirty tabs, hunting visually stops working. You type three letters of what you are looking for and hit enter. If you have used a command palette in an editor, it is that, for terminal sessions.

Agent-set tab titles. When Claude Code runs /rename, the tab picks it up. So a tab reads "auth refactor" instead of ~/code/myapp-auth. Any agent that sets the terminal title through the standard escape sequence gets this for free, which turned out to include most of them.

Per-tab attention badges. The one I actually use most. When an agent is waiting on your input and the tab is not focused, the badge glows amber. When an agent finishes work while you are looking somewhere else, it goes green. Focused tabs never badge, because you are already looking at them.

The design decision I want to explain

Badges bind conservatively. That is the most important sentence in this release and it deserves the space.

The naive implementation is to watch all terminal output, guess which session is waiting, and light up whatever seems right. That gets you a badge that is correct most of the time. Most of the time is a failing grade for this feature.

Here is why. The value of an attention badge is that you can trust it enough to stop checking. If the badge is right 90% of the time, you still have to verify, and if you have to verify you may as well not have the badge. One wrong amber light on the wrong tab and you have retrained yourself to ignore the whole system. A notification you do not trust is worse than no notification, because it costs attention and returns nothing.

So the binding logic is strict. It ties a state change to a specific session through the process tree, not through pattern matching on output. If it cannot establish with confidence which session the event belongs to, it does not badge anything.

The tradeoff is real: there are situations where an agent is genuinely waiting and no badge appears. I chose that failure mode on purpose. Missing a badge costs you the same thirty seconds you were spending before this feature existed. A wrong badge costs you the feature permanently.

If you hit a case where nothing lights up and something should have, tell me. Those reports are how the binding gets less conservative over time, one verified case at a time, rather than by loosening the rules and hoping.

What it feels like

The workflow change is bigger than the feature list suggests.

Before: open four agents, cycle through tabs every couple of minutes checking whether any of them wanted something. That cycling is not free. It breaks whatever you were doing in the tab you were actually working in.

After: work in one tab. Colors change in your peripheral vision. Amber means somebody needs a decision, green means somebody finished. You respond when you see it instead of polling for it.

I did not expect the peripheral vision part to matter as much as it does. You stop reading the tab bar and start noticing it, which is a completely different amount of cognitive load.

If you want the full parallel-agent setup, running multiple AI agents in one terminal covers the pattern, and git worktrees with Claude Code covers keeping them from overwriting each other, which is the other half of the problem.

Credit where it goes

The ticket that started this was one user, politely, explaining a limit that was in his way. He described his actual workflow instead of just asking for a bigger number, which is why it was easy to understand once I bothered to reproduce it.

That is the second time this year a single well-written ticket has driven a release. I do not have a large enough user base for statistical signal on feature requests, so specific descriptions of real workflows are worth more to me than vote counts would be. If something is in your way, the ticket is read by me.

What is next

Tab groups. With 50 sessions available, people will use 20, and 20 flat tabs wants structure. Grouping by project or by worktree is the obvious shape.

Badge history. Right now a badge clears when you focus the tab. If three agents finished while you were at lunch, you get three green badges and no order. A small timeline of what finished when would help.

Per-session skins driven by config. Different colors per agent makes tabs identifiable at a glance, and doing it from a config file rather than by hand is the missing piece. The skinning docs cover the manual version today.

Session persistence across restarts. The most requested thing I have not built. It is harder than it sounds, because a restored tab that is not actually running anything is a lie, and I would rather ship it late than ship that.

3.2 is out now. It is a free update on the download page, and the marketplace that comes with a license is at community. If you have been running agents three at a time because the tenth was a hassle, try it at ten.

More on how this thing gets built in building MOLTamp in public.