The queue that can be empty: T3 Code's inbox sidebar

I've been using T3 Code to run coding agents for a while, and recently as a contributor to it on GitHub. It's a GUI layer over Codex, Claude, Cursor and OpenCode rather than a harness of its own. You bring your own subscription, and it gives you git worktrees, context handover between models from different labs, a diff viewer and a one-click path to a pull request.

On 22 July they shipped their v2 sidebar on the nightly build, behind a toggle in settings. It keeps sessions — threads, in T3 Code's language — in something closer to an inbox. I turned it on expecting a cosmetic change.

It wasn't. It changed how I finish work.

Fair warning on what this post is: first impressions from about a week of use. I don't have a before/after throughput number for you, because I never wrote mine down, and I'd rather say that than hand you a figure I made up. What I can do is describe the mechanism, quote the numbers of someone who did count, and point at a place where this workflow runs into my own research in an interesting way.

What the sidebar actually does

Theo, who builds it, described it like this when it landed:

The new T3 Code sidebar is available on the latest nightly build. It's a toggle in settings. It's a VERY different workflow.

Think of it more like an inbox. When you're done with a thread, click the "settle" button and it slides to the bottom.

— @theo, 22 July 2026

That's the whole feature. A thread is a single task or conversation with an agent. To settle a thread is to mark it finished, which moves it out of the active list to the bottom of the sidebar.

Two days later:

I've landed 11 PRs in the last 17 hours.

It's honestly kind of stupid that this simple UX change has improved my productivity so greatly.

— @theo, 24 July 2026

I want to flag the second sentence, because it's the honest part. He isn't claiming a clever insight. He's saying a button that hides finished work had an effect out of all proportion to what it is, and he finds that a bit ridiculous.

That matches my experience closely enough that I think there's something real underneath it.

The mechanism, as best I can tell

Before the sidebar, my agent threads lived in a list that only grew. Every task I started stayed visible. Finished, half-finished, abandoned, waiting on me — all the same visual weight, all still there.

A list like that has no state of "done". It has a top, and everything below the top is guilt.

An inbox has a floor. Settling a thread is a discrete act that removes something from view, and the list can, in principle, be empty. That turns out to change what I optimise for. I stopped starting things because starting is cheap, and started finishing things because finishing is what clears the view.

Theo put the same thing better than I can: "I've never felt so much drive to get PRs landed just so I can get them out of my sidebar."

I'd be careful about dressing this up as psychology. I don't have evidence for a mechanism beyond "this is what it feels like and two of us report the same effect", and that's a weak basis. What I'm confident about is the behavioural change, because I can see it in what I ship: fewer open threads, more merged work, and much less of the archaeology where I open a branch from ten days ago and try to remember what I was doing.

The thing I'd underline for anyone building agent tooling: the constraint that mattered wasn't model capability. It was a list that couldn't be emptied. Every other part of the stack was the same before and after.

Where this collides with my own data

Here's the part I find genuinely interesting.

T3 Code's contributing guide is unusually direct about pull request size:

What We Are Most Likely To Accept: Small, focused bug fixes. Small reliability fixes. Small performance improvements.

What We Are Least Likely To Accept: Large PRs. Drive-by feature work. Opinionated rewrites.

If you open a 1,000+ line PR full of new features, we will probably close it quickly and remember that you ignored the clearly written instructions.

— T3 Code CONTRIBUTING.md

They enforce it with automation. A size label is a bucket assigned automatically to every pull request based on how many lines it changes, so reviewers can see the cost of a review before opening it.

Label	Changed lines	Against my data
size:XS	0–9	Deep in the high-risk band
size:S	10–29	Deep in the high-risk band
size:M	30–99	Straddles the 55-line threshold
size:L	100–499	Crosses into where the gap closes
size:XL	500–999	No measurable difference
size:XXL	1,000+	No measurable difference

Now hold that against what I found when I analysed 24,560 pull requests across 447 repositories, matched on eight covariates:

• AI-authored PRs under 55 changed lines fail CI at roughly twice the rate of equivalent human changes — odds ratio 2.12.
• Above 400 lines the difference disappears entirely. The largest AI PRs slightly outperform human ones.
• AI PRs trigger 76% more lint violations overall.

Read those two things next to each other and the advice looks contradictory. A repository built for agent-driven development mandates exactly the size band where my data says AI-generated code is least reliable.

It isn't contradictory, though. They're optimising for different things, and that's the useful bit.

Their small-PR rule is about human review capacity and scope control — a maintainer can review a thirty-line fix properly and cannot review a thousand-line feature dump at all. My failure numbers are about what reaches CI without a human having looked at it. Both are true. They point at the same dial in opposite directions only if you forget the second variable.

And I've argued the resolution before, in the post on how I run agents: size is a proxy. What it actually measures is how much human involvement went into a change before it hit CI. A twelve-line diff generated in one shot and pushed unread is playing the worst odds in the dataset. A twelve-line diff someone prompted deliberately, read, and pushed on purpose behaves like a human change of the same size.

Which is, as far as I can tell, exactly what the settle step is. It's a point in the workflow where you have to look at the thing and decide it's done. Small and reviewed is a different proposition from small.

The label system has a second use

An aside, because it solves a problem I don't have but plenty of people do.

Alongside size:*, T3 Code labels every PR with a vouch:* trust status. External contributors get vouch:unvouched until someone is explicitly added to a vouched list in the repo. The guide is blunt about the reason — they aren't actively accepting contributions and would rather say so than quietly ignore people.

I don't maintain anything open source, so this isn't my problem. But if you do, and you're on the receiving end of agent-generated pull requests you never asked for, a trust label applied automatically at open time is a cheap filter. It doesn't reject anything. It just means the queue sorts itself into "someone vouched for this human" and "someone pointed a model at your repo", and you can spend attention accordingly.

Worth noting that the closed PRs you'd see in that repo under author:t3dotgg are Theo's own work in his own project, not inbound contributions. The volume isn't a community; it's one person with a workflow.

Next

The short version:

• A list that only grows has no "done" state. An inbox that can be emptied does.
• The change that moved my output was a UI affordance, not a model upgrade.
• Keep agent PRs small and reviewed. Small alone is the risky half — point another AI review bot at the PR if you're the only human in the loop.
• Read up to a hundred lines of code a day yourself. It finds things, and it stops you forgetting how to code.
• If you take inbound PRs, automatic trust labels cost nothing and sort the queue for you.

The obvious next thing: T3 Code labels every pull request by size automatically, and the repository is public. That's the same size data I built my study on, already collected, on a codebase that is itself developed by agents. I want to run my matching against it and find out whether the pattern I measured across 447 repositories shows up in one repo that's deliberately structured this way. If it doesn't, that's more interesting than if it does.

If you've tried a settle-style workflow — or if you've got a list somewhere that can't be emptied and you've made peace with it — I'd like to hear how you handle it.