T3 Code is free, MIT-licensed, and genuinely good, and a team of any size can adopt it tomorrow. What it does not have is an organization: no org billing, no seat management, no SSO or directory sync, no admin console, no role separation, no audit trail, no central spend visibility, no enforceable caps, and no support contract. Each engineer runs their own copy under their own provider subscriptions. That is fine for a small team that already trusts everyone with a company card, and it stops being fine at the point where somebody has to answer where the money went, who ran what, and what happens when a person leaves. This page maps each gap, gives you the do-it-yourself version, and shows what an organization layer replaces.
- Yes, individuals on a team can run it today. No, there is nothing in it that models a team.
- There is no org billing. Every engineer holds their own Claude, Codex, Cursor, or Grok subscription and expenses it.
- There is no seat management, no SSO, no directory sync, and no admin console. The app has one user: whoever is at the keyboard.
- T3 Code never proxies a token, which is excellent for confidentiality and means it structurally cannot report what a run cost.
- The offboarding gap is the sharpest one. Nothing central can revoke a CLI login that lives in a dotfile on a laptop.
- Support is GitHub issues and Discord. That is a real community and it is not a response-time commitment.
- Every gap below is coverable. The question is whether you want to be the person operating the cover.
The short answer
Can you run T3 Code for a team? Individually, yes, immediately, and at no cost. Every engineer installs the desktop app or runs npx t3, logs into the agent CLIs they already pay for, and gets a branch per thread, model switching mid-conversation, and one-click pull requests. Nothing gates that on a plan, a seat, or a sales call. If your definition of "for teams" is "can everyone on my team use it", the answer is an unqualified yes.
Organizationally, no. There is no org object in T3 Code. No billing that rolls up, no seats to assign or reclaim, no identity provider to federate against, no admin who can set policy for anyone but themselves, no audit log a reviewer could read, no spend ledger, no cap that stops a runaway session, and no support agreement. This is not an oversight the project is hiding. T3 Code has no paid tier at all, and its public position is that it resells nothing and marks up nothing, which is exactly why there is no billing surface for an organization to attach to.
| Team capability | In T3 Code | Who ends up owning it |
|---|---|---|
| Everyone can install and use it | Yes | Nobody. It just works |
| One bill for the organization | No | Finance, through expense reports |
| Seat provisioning and reclaim | No | A spreadsheet, if anyone |
| SSO or directory sync | No | Nothing. Access is per laptop |
| Admin console and role separation | No | Nobody. Every user is their own admin |
| Central spend visibility | No | Each provider dashboard, separately |
| Enforceable spend caps | No | Whatever ceiling each provider plan imposes |
| Model policy across the org | No | Convention, and a message in Slack |
| Audit trail of agent activity | Local thread history only | The laptop it ran on |
| Support with a response commitment | No | GitHub issues and Discord |
What T3 Code already gives a team, and it is not nothing
Any honest teams assessment has to start with the parts that genuinely help a group of engineers, because there are several and they are not trivial. The full T3 Code review covers the product in depth; this is the subset that matters when more than one person is involved.
- A common surface across a mixed toolchain. One engineer on Codex, one on Claude Code, one on Cursor, one on Grok Build, one on OpenCode, all describing their day in the same vocabulary. That alone kills a category of onboarding friction.
- Branch per thread, by default. Concurrent agents stay off each other and off main. Teams that adopt git worktrees by hand usually get there six months later, after the first collision.
- One-click pull requests with generated titles. Agent output lands in the review system your team already uses, rather than in a chat window somebody has to translate.
- Real Linux and Android clients. Most of this category treats Linux as an afterthought. If half your team is on Linux, that is a decisive advantage and no organization layer compensates for its absence.
- Remote control that a team lead will actually use. Local network, Tailscale, SSH launch, or the free T3 Connect tunnel. Approving work away from the desk is a team behaviour, not a solo one.
- MIT source you can fork. If your team has an opinion about the control plane, you can express it in code. No vendor roadmap sits between you and the change.
- Zero acquisition cost and zero procurement. No seat count to justify, no legal review to schedule, no budget line. Adoption can be bottom-up and finish in an afternoon.
Those are strong enough that plenty of teams should stop reading here. A four-person startup where everyone already has a Claude Max subscription and a company card has no organization problem to solve. Buying an org layer for that team is overhead in search of a purpose.
What a team needs that T3 Code does not have
The list below is the honest gap analysis. None of these is a bug report. They are the capabilities that appear on every serious internal review of an AI coding tool, and they are absent because the project deliberately has no commercial surface to hang them on.
Provisioning and identity
There is no way to say "these fourteen people are engineering, they get access, and this contractor does not". Access is whoever installed the app and logged the CLIs in. There is no SAML or OIDC to federate, no SCIM to sync a directory, and no invitation flow that an admin controls. Compare that with a product like Conductor, which does sell SAML SSO and SCIM as part of an enterprise tier, so it is not the case that nobody in this category ships it.
One bill, and a cost you can attribute
Every engineer pays their own provider. Finance receives N expense reports and no way to tell which repository, team, or project the money went to. There is no per-repo ledger and no chargeback path. Our guide to AI cost allocation covers the shapes that do work, and every one of them needs a system that sees the request.
Spend visibility inside the tool
T3 Code cannot tell you what a thread cost, because it never touched the billing relationship that would know. You get each provider dashboard, on its own axis, on its own reset schedule, with no team dimension. Reconciling five of those by hand every month is a job, and it is a job that gets skipped.
Caps that actually stop a request
An alert is not a control. The only ceiling in play is the one each provider plan enforces, discovered at the moment an agent stops mid-run. There is no organization budget, no per-person weekly limit, and no path for an engineer to request more from someone who can approve it. You can model the difference in the spend cap simulator.
Model policy
Any model any connected CLI exposes is available to anyone who has the CLI. If your organization has decided a model is not approved for your codebase, T3 Code offers no mechanism to express that. Enforcement is a convention and a Slack message, which is the same as no enforcement. See enterprise AI governance for what enforcement points look like when they are real.
An audit trail somebody else can read
Thread history lives on the machine that ran it. There is no org-scoped record of which agent touched which file, ran which command, or fetched which URL. When a security reviewer asks what an agent did in June, the answer is a laptop, and possibly a laptop that has since been wiped.
Role separation
The app has one user. There is no admin, no team lead with a delegated ceiling, and no member whose limits somebody else set. Every control that exists is a control the user sets for themselves, which is the correct design for a single-player tool and the wrong one for an organization.
Offboarding
This is the sharpest gap and the one most teams discover last. Removing someone from GitHub does not touch the Claude, Codex, Cursor, Grok, or OpenCode credentials sitting in dotfiles on the laptop they still have, nor the T3 Connect pairing sessions that let a phone drive that machine. Nothing central can revoke any of it. Our seat management guide treats this as the standard failure mode across the category, and T3 Code has no lever at all.
A support commitment
GitHub issues and an active Discord, which is a real and responsive community, and which is not a response-time commitment you can put in a risk register. The project is still numbered in the 0.0.x range on a nightly cadence, and its own README asks you to expect bugs.
Why the gaps exist, and why they are not a criticism
T3 Code is un-monetized on purpose. It resells no tokens, marks up no usage, and has announced no paid tier. Theo Browne has restated publicly that showing users exactly what they pay, with zero markup, is the trust position the project is built on. Every capability in the previous section requires a commercial relationship with the organization: someone has to be billed, someone has to be an admin, someone has to be on the hook for a response time. A project with no commercial relationship cannot build any of them, and building them would compromise the thing that makes it good.
This matters for how you evaluate it. "T3 Code has no SSO" is not a weakness the way a missing feature in a paid product is a weakness. It is a boundary of the category. The right question is not whether T3 Code should add org controls. It is whether your team is past the point where the absence costs you more than the tool saves you.
The order things break in
The gaps do not all arrive at once. They arrive in a predictable sequence, and knowing the sequence tells you how much runway you have before you need to do something.
| Stage | What starts hurting | The usual first symptom |
|---|---|---|
| Up to about 5 engineers | Nothing. This is the sweet spot | None |
| 5 to 15 | Cost visibility | Nobody can answer what AI cost last month without opening five dashboards |
| 10 to 25 | Caps and surprise bills | One engineer discovers a weekly ceiling mid-sprint, or an API bill triples |
| 15 to 40 | Model and data policy | Security asks which models touch the repository, and there is no answer |
| 20 to 50 | Offboarding | The first departure, and nobody can prove the credentials are dead |
| Any size with a customer contract | Audit and vendor accountability | A questionnaire asks for a DPA and an SLA, and there is no counterparty |
The audit and accountability row is worth calling out because it is independent of headcount. A three-person team selling into a regulated buyer can hit it before it hits the cost problem. If your customers send you security questionnaires, the vendor-accountability gap is your first gap, not your last.
Running T3 Code as a team anyway: the playbook
If you want to keep T3 Code and cover the gaps yourself, this is the honest version of what that takes. It is achievable. It is also somebody’s recurring job, and the estimate below assumes that person exists.
Standardize the provider relationship first
Pick one or two agent providers for the team rather than five. Buy those subscriptions on organization-owned accounts where the provider supports it, rather than on personal accounts expensed back. This single move converts most of the billing and offboarding problem into a problem the provider already solves.
Put an admin key or a gateway in front of the traffic you can
Anthropic and OpenAI both support organization-level administration over API traffic. Provider subscription traffic is harder, because a subscription login is per person by design. Accept that split and instrument the half you can see. Our BYOK guide covers where the seam falls.
Build the reconciliation you are missing
Export from each provider monthly, normalise to one schema, tag by person, and publish it. Budget a day a month, forever. The chargeback report tool shows the shape of the output you are aiming for.
Write the policy down and accept it is unenforced
A model allowlist that lives in a document is a preference, not a control. Write it anyway, because it makes the eventual enforcement point cheap to configure, and be honest in the risk register that it is currently unenforced. The model access policy builder produces the artefact.
Make offboarding a written checklist with real steps
Revoke each agent CLI login individually, rotate any API keys the person held, run t3 auth on their machines to revoke pairing links and sessions, and confirm the laptop is wiped rather than assumed. Every one of those is manual. Every one of those gets skipped under pressure.
Pin your version and read the diffs
A project on nightly builds in the 0.0.x range should not be tracking latest across a whole team. Pin a version, upgrade deliberately, and have someone read the changelog. This is normal open-source hygiene and it is real recurring work.
What an organization layer replaces
The alternative to running the playbook is buying a control plane that already models an organization. Continuum is one, and because this is a page on our own site, the useful thing to do is state exactly which gaps it closes, which it closes partially, and which it does not close at all.
| The gap | In T3 Code | In Continuum’s org layer |
|---|---|---|
| One bill | None | One subscription, billed by live member count, seats at the Plus, Max, or Ultra tier |
| Seat provisioning | None | Invite, appoint leads, set limits. Three roles: admin, lead, member |
| SSO and directory sync | None | Not today. Sign-in and invites run on WorkOS AuthKit with Google and Apple login. No screen for federating your own provider |
| Spend visibility | None | One ledger: who ran what, on which model, under whose key, at what cost. Dashboard, CSV, or a scoped API token |
| Enforceable caps | None | Weekly caps per person, per team, and org-wide. A hosted request past the cap returns a 429, not an alert |
| Approval flow | None | Members request more, an admin approves in one click and can approve part of the amount |
| Model policy | None | Allowlists and deny patterns at organization, team, and member scope. A lower scope narrows, never reopens. New models stay blocked until reviewed |
| Agent activity record | Local threads | Every session records the tool calls made and the URLs fetched. Org-wide allow and block lists are an Enterprise engagement, not a self-serve switch |
| Offboarding | Manual, per machine | Removal blocks provider access, revokes devices and tokens, and destroys the content key in one step |
| Support | Issues and Discord | A vendor relationship. Dedicated account management and highest priority support sit in the Enterprise tier |
The mechanism worth understanding is why the cap is hard. Hosted traffic runs through Continuum’s gateway, which speaks the OpenAI and Anthropic APIs including streaming, so Codex, Claude Code, and the official SDKs work through it with one environment variable and no code change. Policy and budget are checked before the request leaves. That is the only reason the cap can return a 429 instead of an email. Direct and bring-your-own-key sessions run laptop to provider, and on that path Continuum sees usage and never content, which is a genuinely smaller kind of control. The organizations page concedes that trade explicitly rather than blurring it.
Deciding
Three questions settle this faster than a feature matrix.
- Can you name what AI cost your team last month, by person, without opening more than one dashboard? If no, the visibility gap is already costing you and it only widens.
- If an engineer left today, could you prove within an hour that their agent credentials are dead? If no, that is your real exposure, and no amount of tooling elsewhere compensates.
- Does any customer contract or security questionnaire require a named vendor, a DPA, or an SLA? If yes, an un-monetized open-source project cannot be the counterparty, however good it is.
Answer no to all three and keep T3 Code. It is free, it is good, it is actively developed, and buying an organization layer for a team that does not have an organization problem is a way of spending money to acquire administration. Answer yes to any of them and you are choosing between running the playbook above yourself and buying a layer that already runs it.
If you want to price the second option before deciding, the team cost calculator takes headcount and usage and returns a monthly number you can compare against the day-a-month reconciliation cost. If you are still on individual subscriptions and want to know which tier each person should be on first, the plan picker is the cheaper starting move. And if you like T3 Code and want to keep it in the mix, the side-by-side comparison lays out where each product is plainly better, including the places where T3 Code wins without an asterisk.
Questions people ask
Does T3 Code have a team or organization plan?
No. T3 Code has no paid tier at all. It is free and MIT licensed, it resells no tokens, and there is no organization object, seat, or bill for a team plan to attach to.
Does T3 Code support SSO?
No. There is no SAML, OIDC, or SCIM support. Access to T3 Code is per installation, and access to each coding agent is whatever credential that agent’s own CLI holds on the machine.
Can an admin see what my team is spending in T3 Code?
No, and it is structural rather than a missing feature. T3 Code never proxies a provider token, so it never sees the billing relationship. Spend is visible only in each provider’s own dashboard, per person.
Can I set a spend cap for my team in T3 Code?
No. The only ceiling is whatever each provider plan enforces on each individual account, and it is discovered when an agent stops mid-run rather than announced in advance.
How do I offboard someone who used T3 Code?
Manually, on their machine. Revoke each agent CLI login individually, rotate any API keys they held, run t3 auth to revoke pairing links and sessions, and confirm the laptop is wiped. Nothing central can do this for you.
Is there paid support for T3 Code?
No. Support is GitHub issues and the project Discord. Both are active and responsive, and neither is a response-time commitment you can reference in a contract or a risk register.
What does Continuum add for a team that T3 Code does not have?
One subscription billed by live member count, three roles with delegated limits, model policy at organization, team, and member scope, weekly caps that return a 429 rather than an alert, an approval flow for cap increases, one spend ledger, and offboarding that cuts access, keys, and devices together. The organizations page lists each control and its limits, including that there is no identity-provider federation today.
Do I have to stop using T3 Code to add org controls?
No. Both products bring their own agent subscriptions, so the decision can be made per team or per project rather than as a permanent vendor bet. Teams commonly keep T3 Code where forkability, Linux, or Android is the requirement and add a governed layer where the money and the audit trail have to be answerable.
Sources
Every figure above was read from these pages on August 2026. Vendors reprice without notice; if you find a stale number, tell us.