We enjoy T3 Code because it makes serious agent work feel immediate: multiple conversations, real project context, previews, files, diffs, and a desktop shell that stays out of the way. But the version we use every day is intentionally a little ahead of the public live branch.
Our Alpha replay branch has three distinct layers: performance fixes that make the app kinder to the laptop, our own workflow customizations, and selected experimental pull requests we want before they land upstream. Keeping those layers separate matters. It lets us update quickly without pretending every experiment is the same kind of change.
The performance layer: cooler, quieter, longer-lived
The biggest reason we keep replaying this branch is not a flashy feature. It is that T3 Code behaves better during a long working day. Background CPU settles down, the machine runs cooler, and the battery goes further because less work happens when nothing useful has changed.
- Poll less when nothing is happening. Git-ref refreshes and local-port scans back off instead of running aggressively in the background. The project menu refreshes when we actually open it, and port discovery adapts to activity. See the wider idle-work and disk-churn proposal in PR #2679.
- Release idle VCS subscriptions. When a repository is no longer being observed, its subscription is torn down instead of quietly consuming resources—the lifecycle fix carried from PR #3573.
- Do not preload unopened conversations. The web client waits until we ask for a thread before loading its full detail, part of the large-history work in PR #3510.
- Make streaming cheaper. Incoming deltas no longer trigger a full thread-shell summary rebuild or repeated activity-history reads (PR #4009), and unnecessary visit writes are avoided while an answer is still arriving (PR #4093).
- Bound deep-history reads. Recent activity is loaded in a manageable window, while older history is paginated and fetched when we scroll upward. This avoids enormous SQLite reads and the heap pressure they caused; the full server-and-client implementation is in PR #3510.
- Keep the same history behavior on mobile. Older thread history is lazy-loaded there too, so a long-running workspace does not have to become a giant initial payload. The web and mobile paths are both included in PR #3510.
- Trim visible UI overhead. PR #3968 stops preview-loading progress from rerendering the preview, while PR #4345 skips expensive collapse animations for very large sidebars.
We have not run a controlled watt-hour benchmark, so we are not going to invent a percentage. The honest claim is experiential and architectural: Activity Monitor is calmer, fans are less eager, and our laptops last longer because the patched build performs fewer redundant reads, scans, writes, and renders.
Our customizations: the part that makes it ours
Performance keeps the app pleasant. Our customizations make it fit the way we work. These are separate from the media experiments, and we carry them because they reduce the small bits of friction we feel dozens of times a day.
- Persistent sidebar filters for Recent, Inbox, status, environment, provider, and archived threads, shared across both sidebar surfaces. This started in PR #4330.
- Reusable labels for organizing work across projects, based on PR #4351.
- Flat sidebar grouping that makes a large workspace easier to scan.
- Manual project visibility controls so the sidebar reflects current work instead of every project we have ever touched.
- Unread, snooze, and visit-state refinements that make T3 Code feel more like a dependable command center.
- Distinct Alpha branding—including its own icon and identity—so there is no ambiguity about whether we are running the stable app or our patched build.
How we stay ahead of the live branch
We treat the Alpha build as a replayable patch stack, not a mystery fork. The branch starts from the newest upstream nightly. We replay the changes we still need, retire any patch that upstream has made equivalent, run focused tests, then package a separately branded macOS build.
That distinction is important. A forever-fork slowly becomes its own product. A replay branch stays close enough to upstream that we can keep benefiting from the project’s pace while choosing when to adopt fixes that have not landed on the live branch yet.
- Start from the latest upstream nightly rather than an old comfortable base.
- Keep each carried fix as a reviewable commit or small commit series.
- Replay the stack and resolve conflicts while the context is still fresh.
- Drop patches as soon as upstream supplies the same behavior.
- Run focused tests around every touched surface, plus targeted type and lint checks.
- Package the result with a visibly different Alpha identity and keep a known-good recovery branch.
- Record the exact commit and artifact checksum so the build is reproducible and auditable.
Our current ARM64 build is 0.0.30-alpha.patched.20260728.111, based on the July 28 nightly and 111 carried commits. Its DMG SHA-256 is c898d60569d26ecf8d1171c7a11ece18d6b58ad063b9ba1b7288d1982830cf81. We keep that detail because “living on the edge” should still leave a paper trail.
Experimental media: making generated images feel native
The newest layer is media. We merged two open pull requests into Alpha because agents increasingly produce images, screenshots, and other artifacts, and a raw filesystem path is a poor way to experience them.
- PR #3984 renders generated images inline in the conversation, so visual output appears where it was discussed.
- PR #4427 recognizes generated-image links in the work log and opens them in T3 Code’s reusable right-side panel.
We also hardened the path between the transcript and the renderer. Local artifact links are parsed safely, Windows-style paths and trailing punctuation are normalized, malformed URI encoding cannot crash rendering, and local files are checked before they are exposed. The result feels simple in the UI because the awkward edge cases are handled underneath it.
A few more unmerged fixes we are watching
The fun of this workflow is that Alpha can be a proving ground. These are a few open changes we particularly like:
- PR #4195 improves Markdown file links containing spaces and other special characters.
- PR #4321 makes saved screenshots and recordings easier to surface as usable artifacts.
- PR #4249 explores attribution-aware diffs, a useful direction when several agents and humans touch the same work.
These are favorites, not promises. An open pull request can change, conflict with a later nightly, or reveal a reason it has not merged. We read the diff, understand the tradeoff, and test the behavior before adding anything to the replay list.
How others can try the same approach
You do not need our exact stack. Start with one fix that removes real friction for you. Put it on a branch based on the latest nightly, keep the commit isolated, and write down the smallest test that proves it still works. Add a second change only after the first can be replayed cleanly.
Keep the experimental build visually distinct. Never make it your only recovery path. Do not merge an unfamiliar branch merely because the screenshot looks good. And when upstream catches up, celebrate by deleting your patch.
That is how we enjoy T3 Code: close to upstream, curious about what is next, and willing to maintain the small set of changes that make a measurable difference to our day. We are living on the edge—but with a cooler laptop, a recovery branch, a focused test list, and a checksum.