Short answer: switch when you need what a control plane with no account model structurally cannot give you: live quota gauges, spend attributed by repository and person, a plan-approval gate before an agent writes, native iPhone and Watch control, multiple provider accounts isolated on one machine, or an organization layer with seats and caps. Stay on T3 Code when the MIT licence, an Android client, or a Linux desktop is the reason it is installed. Nothing about your repositories, agent CLIs, or provider logins moves, so a parallel pilot costs almost nothing and is the right way to decide.
- Nothing migrates. Both drive the same CLIs on the same machines, so repositories, logins, and history stay untouched.
- Both are free. Cost is not a reason to move in either direction; run both during the pilot.
- Move for quota gauges, spend by repository, plan gates, native mobile, account isolation, or teams.
- Stay for the MIT licence, an Android client, or a packaged Linux desktop. Continuum offers none of those.
- Migrate habits and repository context, not transcripts. Durable instructions belong in version control anyway.
- Keep both installed for a release cycle. The rollback is uninstalling one application.
First decide whether to switch at all
Start by naming the problem. T3 Code is a good tool and it is free, so "a different one exists" is not a reason. The switch is justified when a specific thing you need is not merely missing from T3 Code but is ruled out by its architecture: a control plane with no account model and no token path cannot attribute spend to a person, cannot show a live subscription gauge, and cannot enforce a team cap, no matter how much it ships.
| Criterion | Move to Continuum | Stay on T3 Code |
|---|---|---|
| Licence and source | Closed source, free app | MIT, forkable, self-hostable |
| Your phone | iPhone, and a Watch you use | Android |
| Your desktop | Mac, or Windows and Linux in beta | Packaged Linux desktop |
| Quota visibility | Live five-hour and weekly gauges | Retrospective token estimate is enough |
| Spend attribution | By repository, provider, model, and day | Provider and model shares are enough |
| Before an agent writes | Read-only plan mode with approval | You review the diff afterwards |
| Multiple provider accounts | Isolated side by side on one machine | One login per CLI is fine |
| Teams | Seats, org weekly caps, admin dashboard | Single-player is the whole use case |
| Vendor relationship | A company with support and releases | GitHub issues and a Discord are fine |
| Stability expectation | Signed releases with canary gating | Nightly builds are a feature, not a risk |
Honest reasons to leave T3 Code
- You cannot see your quota. Parallel agents exhaust a weekly cap faster than anything else, and finding out by being cut off mid-refactor is the most expensive way to learn it. Continuum polls the provider’s own rate-limit signal and renders live five-hour and weekly gauges on the Mac, the web, the phone, and the Watch.
- You cannot answer "what did this repository cost". T3 Code’s Usage page estimates API-equivalent token cost, and its docs say subscription billing is separate. Continuum builds a ledger keyed by repository, provider, model, and day from the same local history.
- Review happens too late. T3 Code shows you the diff after the agent wrote it. A plan gate holds the agent in read-only mode until you approve the approach, which is the cheapest possible place to catch a wrong assumption.
- You run more than one account per provider. A personal Claude subscription and a work one on the same machine need isolated config and credentials, or the wrong subscription pays. Continuum isolates them per account and refuses to spawn rather than silently billing the primary.
- Your phone should interrupt you. A companion app you have to open is not the same as run progress on the Lock Screen and a plan approval you clear from a notification. See the mobile comparison for the row-by-row difference.
- You have a team. Seats, per-team model policy, weekly organization caps with approvals, and one spend view are not late features in T3 Code; there is no organization concept to attach them to. The organizations plan is what that layer looks like.
- You need somebody to answer. A free MIT project owes you nothing, correctly. If an agent workbench is load-bearing for a company, a vendor with releases, canary gating, and a support obligation is a different risk posture.
- Nightly breakage is not acceptable. The project says it is very early and ships several builds a day. That is fine for an enthusiast and a real cost for a team on a deadline.
Honest reasons to stay on T3 Code
- The MIT licence is the point. You can read every line, fork it, add a provider, change the interface, and ship your own build. Continuum is a free application, not an open one, and that is a genuine loss on this axis rather than a footnote.
- You use Android. T3 Code ships an Android client. Continuum does not offer one. If your phone is the device you supervise from, this ends the discussion.
- Your desktop is Linux. T3 Code has a packaged Linux desktop, Arch-first through the AUR, and the Node quick start everywhere else. Continuum’s Linux and Windows desktop clients are in beta and its Mac and iPhone clients are the mature ones.
- You want to self-host the whole thing.
npx t3 serveplus a self-hosted relay means no vendor is in your path at all. That is an architecture some environments require and Continuum does not offer. - You are one person and you already know what you spend. If you hold one subscription and never hit a cap, the gauges and the ledger solve a problem you do not have.
- You like the release cadence. Several builds a day from a maintainer who ships in public is a real advantage if you enjoy being early and reporting bugs.
- The community is the product for you. A large, active, audience-driven project has a support surface a smaller vendor cannot match on volume.
What actually moves
This is the section that makes the migration cheap, and it is short. Almost nothing moves, because neither tool owns anything.
| Artefact | Owned by | Migration work |
|---|---|---|
| Repositories and branches | Git, on your machine | None |
| Agent CLIs | Your package manager | None. Both drive the same binaries |
| Provider logins | Each CLI’s own credential store | None |
| Session history | Each CLI’s local JSONL files | None. Continuum reads the same files for its ledger |
| Repository instructions | Version-controlled files | None, if they are already in the repo |
| Worktrees from open threads | Git | Land or close them before you stop using the old tool |
| T3 Code thread transcripts | T3 Code’s local state | Do not migrate. Move decisions into the repo instead |
| T3 Connect device links | The hosted account | Revoke with npx t3 auth when you are done |
Step-by-step migration
Land or close open threads
Every worktree-backed thread has a branch. Merge it, close it, or note it. Two tools writing to the same branch is the only way this migration can actually hurt you, and it is entirely avoidable.
Move durable context into the repository
Build commands, test rules, architecture constraints, service ownership, and review standards belong in version-controlled instruction files that any agent reads. Do this first; it improves results in both tools.
Install Continuum alongside, not instead
Both can be installed at once. They drive the same CLIs and neither locks a credential. Do not uninstall anything yet.
Connect one provider and run one golden task
Pick the last real task you completed in T3 Code. Run it again in an isolated worktree session with the same brief and the same acceptance checks, and compare the diff, the elapsed time, and how much you had to intervene.
Turn on the plan gate for one risky task
Choose something that touches auth, billing, migrations, or permissions. Let the agent plan in read-only mode and approve it. This is the workflow with no equivalent in the old tool, so evaluate it deliberately rather than discovering it later.
Pair the phone and verify the notification path
Sign in on the phone, start a run, lock the device, and wait. What you are testing is whether an approval reaches you without you remembering to check, and whether reconnection survives a network switch.
Check the gauges against reality
Run a heavy afternoon and watch the five-hour and weekly gauges move. Confirm they match what the provider CLI reports when it warns you. A gauge you do not trust is worse than no gauge.
Confirm the ledger attributes correctly
After a few days, check that spend lands on the right repositories, and that work in a worktree is bucketed to the parent repository rather than to a stray path. Add any second provider account now and confirm it is isolated.
Enrol a second host if you use one
If you run agents on a Linux or Windows box, install the host agent there and reproduce a real task from a clean checkout, including secrets and services. This is where a migration finds its surprises.
Run both for one release cycle
Route new work through the new tool and keep the old one installed. Do not run the same task through both; matched tasks are for measurement, duplicate implementations are for regret.
Decide, then clean up
If you are staying, revoke T3 Connect device links with npx t3 auth and uninstall. If you are going back, uninstall the other one. Either way, keep the repository instruction files. They were the real upgrade.
Run a pilot that can actually fail
Because both tools are free and drive the same agents, a pilot that only runs clean feature work will show no difference and prove nothing. Deliberately include the cases where the operating layer is the variable.
| Test | How to run it | What it tells you |
|---|---|---|
| A weekly cap collision | Work hard enough to approach the cap | Whether a live gauge changes your behaviour before it fires |
| A wrong-approach task | Brief something ambiguous on purpose | Whether a plan gate catches it before the diff |
| A long unattended run | Start it and walk away with the phone | Whether supervision actually reaches you |
| Three parallel worktrees | Same repository, three agents | Whether isolation and the sidebar hold up under load |
| A month-end cost question | Ask what one repository cost | Whether either tool can answer it at all |
| A second provider account | Add a work account beside a personal one | Whether the right subscription pays |
| A broken provider login | Log a CLI out mid-session | How legibly each tool fails and recovers |
Keep the same reviewer for matched tasks where you can. Review style moves outcomes more than tool choice does, and a pilot that changes both variables at once answers nothing. Record which provider and model ran each task; a multi-provider workbench can otherwise look inconsistent for reasons that have nothing to do with the workbench. Reviewing AI-generated code is the discipline the whole comparison rests on.
Rollback, which is genuinely trivial
The rollback plan for this migration is one sentence: keep T3 Code installed until you are sure, then uninstall the one you are not using. Nothing is locked in, nothing was converted, and no data was moved, because neither tool owns your code, your credentials, or your history.
- Rollback trigger: the features you moved for do not change your behaviour, a platform you need is beta rather than mature, or the closed-source tradeoff turns out to matter more than you expected.
- Rollback action: land open worktrees, stop starting new sessions in the new tool, and resume in the old one. There is no export step.
- Git hygiene: the only real risk in the whole migration is two tools automatically writing to the same branch or pull request. Never let that happen in either direction.
- Credentials: revoke device links you no longer use in whichever tool you stop using. A stale pairing credential is a live credential.
- Keep the instruction files. The AGENTS.md and CLAUDE.md work you did during the migration is tool-independent and is the part you would actually miss.
After the switch: the operating contract
If you do move, write down the operating rules once, especially if more than one person is involved. The features that justified the switch only pay off if somebody owns them.
| Control | Minimum rule |
|---|---|
| Isolation | One worktree and branch per autonomous session |
| Plan gate | Required for migrations, auth, billing, permissions, and broad refactors |
| Quota | Somebody checks weekly headroom before a heavy batch |
| Cost | Monthly review of repository and provider spend against the upstream invoices |
| Accounts | Each session names which subscription pays, and the pin sticks |
| Mobile | A phone approval never bypasses repository review and merge policy |
| Merge | Human merge authority stays explicit |
| Team caps | Weekly organization caps set, with a named approver for increases |
Questions people ask
Is it hard to switch from T3 Code to Continuum?
No. Both drive the same agent CLIs on the same machines, so your repositories, provider logins, and session history do not move at all. Install the second one alongside the first, run one real task, and keep both until you are sure.
Why switch from T3 Code to Continuum?
For the things a control plane with no account model and no token path cannot provide: live five-hour and weekly quota gauges, spend attributed by repository and provider, a plan-approval gate before the agent writes, native iPhone and Watch control, multiple provider accounts isolated on one machine, and an organization layer with seats and weekly caps.
When should I stay on T3 Code?
Stay when the MIT licence matters to you, when your phone runs Android, when you need a packaged Linux desktop, or when you want to self-host the entire control plane and relay so no vendor is in your path. Continuum offers none of those.
Do I lose my threads and history?
Your agent session history lives in each CLI’s own local files and is untouched. T3 Code thread state stays in T3 Code, and it is not worth migrating: move any durable decision into a version-controlled instruction file instead, which is worth doing regardless.
Can I run T3 Code and Continuum at the same time?
Yes, and that is the recommended way to decide. They drive the same binaries and neither locks a credential. The one rule is not to let both write automatically to the same branch or pull request.
Is Continuum open source like T3 Code?
No. Continuum is a free application but it is not open source, and T3 Code is MIT licensed. If source availability is a requirement rather than a preference, that difference decides the question on its own.
Does Continuum have an Android app?
No. Continuum ships native iPhone and Apple Watch clients plus a web app that also runs as the Windows and Linux desktop client. T3 Code ships Android, which is a genuine reason to stay if the phone is where you supervise from.
Does switching cost anything?
No. Both workbenches are free, and both run on the agent subscriptions you already hold. Continuum sells hosted inference as an option for people who would rather not hold a provider subscription, but the workbench itself does not require it.
Sources
Every figure above was read from these pages on August 2026. Vendors reprice without notice; if you find a stale number, tell us.
- pingdotgg/t3code on GitHub MIT licence, star count, provider list, install commands, alpha warning
- t3.codes product positioning, provider list, user count claim
- T3 Code remote access docs serve, pair, Tailscale, SSH launch, pairing security model
- T3 Code usage docs API-equivalent token cost, ranges, subscription-billing caveat
- Continuum pricing Free, Plus, Max 100, Max 200, Ultra and weekly hosted-usage allowances