Team plane
The team plane is a service klarlabs hosts in the EU. It rolls up what TokenOps measures on each member's machine — by team, by repository and by kind of work, per day or week — into the shared view a team lead or a platform group asks for, without anyone's prompts, code or transcripts leaving their laptop.
The hosted team plane is this site's own server, https://team.klarlabs.de: create an account or sign in there, or start an organisation from a terminal with tokenops team create --server https://team.klarlabs.de (below).
The part that runs on your machine is open source, in this repository: the tokenops team commands, the daemon's uploader, and the upload format itself (pkg/teamwire). The server is klarlabs' and is not published, so you never have to trust it about what it receives: what leaves your machine is decided, and checkable, here.
What leaves a machine
Only after tokenops team join, every hour, the daemon sends the last 14 days recomputed, one row per UTC day × repository × kind of work:
| Figure | Meaning |
|---|---|
| sessions, instructions | agent sessions with work in the row; instructions typed |
| turns, tool calls | the agent's turns and tool calls answering them |
| active seconds | time spent waiting on the agent, summed |
| first try, reworked, interrupted, escalated, rejected | outcome counts, each a subset of instructions |
| tokens | input and output tokens |
| cost, value | what was billed, and the same work at API list prices |
| unpriced turns | turns on models with no list price |
The repository is a label: owner/name from its origin remote, the directory's name, or hidden (team.repo_names); work outside a repository is none. The kind of work — lookup, research, edit, deep or unknown — is classified on your machine from the instruction's opening words, and only the kind is sent.
Plan use, waste, savings and plan advice
When the team server accepts them (upload schema 2), each upload also carries what a team lead asks of the plans everyone pays for, computed by the same code as tokenops scorecard, tokenops spend waste, tokenops coach stats and tokenops plan advise:
| Section | One row per | Figures |
|---|---|---|
| plan use | UTC day × provider × plan | utilization (mean peak of the plan's longest window that reset that day) and how many windows; coverage (share of the provider's tokens the plan carried) with the plan and billed tokens; lockouts and minutes blocked |
| waste | UTC day × repository × kind of work × waste class | turns, tokens and API-equivalent value that were avoidable, in one of the six classes of spend waste (each token in at most one) |
| savings | UTC day | interventions and tips held back for the holdout, re-reads refused with their tokens and value, the holdout's measured saving, the total realized and what stayed avoidable |
| plan advice | provider | the plan in force, the verdict (stay, switch, upgrade), the recommended tier, its monthly difference, lockouts on each, confidence and the days replayed |
Providers, plans, waste classes, verdicts and confidences are names from TokenOps' own catalogs, checked on both ends; the advice's summary and caveats are sentences and stay on your machine. A server that does not say it accepts schema 2 gets exactly the upload above and nothing more: tokenops team status says which the server reads (asked once a day), and tokenops team preview shows these sections either way, marked as withheld when the server does not accept them yet.
Never sent: prompts, file contents, file names or paths, transcripts, commit messages, branch names, model outputs, model names or session IDs, and the project, client and cost-centre tags of your allocation rules. The upload format has no field that could carry them, a test fails the build if one is added, and the server refuses anything else (ADR 0012). Check it yourself:
tokenops team preview # the next upload as a table; sends nothing
tokenops team preview --json # byte for byte as it is sentJoining and leaving
Your organisation's owner or an admin sends you an invite: a server address and a single-use code, valid for seven days unless they chose otherwise. There is no default server; join takes the address from the invite. Before joining, see what would be sent:
tokenops team preview # computed now from this machine; sends nothing
tokenops team join <url> <invite> --name "Ada Lovelace"
tokenops team status # what the server holds, who may see it, who looked
tokenops team sync # upload now instead of within the hour
tokenops team web # a single-use link to the web view
tokenops team leave # stop, and erase this machine's figures on the serverteam.enabled: false (or TOKENOPS_TEAM_ENABLED=0) pauses uploads while staying joined. See Configuration.
Who sees what
- Everyone in the organisation sees totals by team, repository and kind of work, per day or week, for weeks that ended at least three days ago. Any group fewer than three people contributed to is withheld — a "team total" of one person is that person's figures — repositories fewer than five, and so are as many other groups as needed that no sum or difference of what is shown gives a withheld group back. A week is computed once and never changes, so asking again, with another window or after more uploads, shows nothing new. The organisation can raise the threshold, never lower it below three. Raising it withholds more of the weeks already released; it cannot take back figures someone has already seen. Amounts in these totals are rounded (tokens to three significant figures, money to four, time to the minute); counts are exact. Weeks released before November 2026 keep the exact amounts they were released with.
- Spend is checked together with the work figures. Spend is the same turns as the work figures, split by provider, so it is withheld until no combination of the two describes fewer than the minimum. Weeks released before November 2026, when we found that the two could be combined to recover one person's use of a provider, keep the interim rule they were released under: spend by team only, and no FOCUS rows. Plan cells show their coverage share, not their token sums, always.
- One part is differentially private: the organisation trend. Each released week, four organisation totals (instructions, tokens, value and commits) are drawn once with noise, ε = 1 per figure per week by default (an owner can set 0.1 to 5 on Manage → Privacy; smaller is more noise and stronger protection, for weeks released after the change), each member's week counted up to a bound. They are on the Overview and in
GET /api/v1/trend, labelled with ε, the bounds and what the guarantee adds up to over weeks. Everything else here is a thresholded, rounded aggregate, not differentially private. - While you are your organisation's only member, you see all your own figures, marked "only you". Once anyone else joins, groups under the minimum are withheld for everyone.
- Your individual figures are visible to you, and to nobody else unless an owner grants it: to a named lead, admin or owner, for one team or for everyone, with a reason. Being an owner is not enough by itself.
- How your work turned out is yours alone. Your first-try, rework, interruption, escalation and rejection figures, and your plan advice, are never shown to anyone else, grant or no grant. A grant shows your usage and spend, and your units of work.
- Your units of work. Your page shows your commits per week and the value placed on them, with those a later revert undid. They are yours, and a grant holder's; they are never shown per person to anyone else and never ranked.
- You are told. Your page in the web view and
tokenops team statuslist every grant that covers you, with its reason, and every time someone looked at your figures. Owners and admins see the whole audit log.
The server enforces these; they are recorded publicly in ADR 0012, so a works council can hold the service to them.
This is built for EU workplaces with a works council: the threshold, who may hold grants and why, and how long figures are kept are the points a works agreement settles, and each is visible to the people it concerns. For works councils puts it all on one page, including what the withholding does not protect against.
Retention
Released team totals are kept 400 days by default (30 to 3650, per organisation); each member's own rows 90 days by default once their week is released (30 days up to the first setting), so your own view and any grant cover that window; the audit log 730 days. Leaving erases your machine's figures unless you pass --keep-history; an admin removing you erases all of them.
Start a team
The team plane is a hosted service klarlabs runs; it is not available to self-host. Hosting is in Germany, under a GDPR Art. 28 data-processing agreement.
Anyone can start a team for their organisation. The team plane is free during the beta, with no card:
tokenops team create --server https://<team server>This opens the server's sign-up page in your browser. Either sign in with GitHub — the server reads your verified primary e-mail address and your name, nothing else from your account — or sign up with an e-mail address and a password of at least 12 characters; the address must be confirmed with the link sent to it before you can continue. Then name your organisation; you become its owner.
Password accounts can turn on two-factor authentication (an authenticator app) in the account settings, and reset a forgotten password by e-mail, which signs out every other session. An e-mail address belongs to one account: if you signed up with GitHub and later want a password for the same address (or the other way round), sign in to the existing account first and add it there — accounts are never merged automatically. The terminal shows a short code: type it into the page to approve this machine. The code is never part of a link, so only someone who can see your terminal can approve it. This machine then joins the organisation and receives an administrator's credential for tokenops team admin, kept beside the enrolment (mode 0600) and valid for a limited time.
On another machine, or when the credential expired:
tokenops team admin login --server https://<team server> # the same code-in-the-browser step
tokenops team admin logout # revoke itInvite your team
tokenops team admin create-team platform
tokenops team admin invite --team platform --email ada@example.com # e-mailed; also prints the join line
tokenops team admin invite --team platform --role leadEach invite is single-use and valid for seven days (--ttl to change). Nobody invites above their own role. With --email (or the address field in the web view) the person gets a mail with the join line and a page that explains installing TokenOps; otherwise send each person their own line. They run tokenops team join <url> <invite> on their machine.
Manage it
Owners and admins run their organisation themselves, in the web view (a Manage section) or from the CLI, on the same API. Every change is in the audit log.
tokenops team admin teams # teams and how many members each has
tokenops team admin members # names, roles, teams, sign-in addresses
tokenops team admin role "Ada" lead # member, lead, admin or owner
tokenops team admin remove "Ada" --yes # revoke their machines and erase their figures
tokenops team admin grants # who may see individual figures, and why (--all: revoked too)
tokenops team admin grant "Lars" --team platform --reason "1:1 coaching, agreed with the works council"
tokenops team admin revoke <grant-id>
tokenops team admin audit # newest first
tokenops team admin billing # billing state and seats
tokenops team admin boundaries # the organisation's boundaries
tokenops team admin boundaries --set org.yaml # replace them (owners and admins)
tokenops team admin approvals # requests waiting on your role (--all: answered too)
tokenops team admin approve <id> [--session]
tokenops team admin deny <id>Boundaries set here apply on every member's machine, beside their own, and only tighten. A rule naming approver:<role> sends its request to everyone with that role or above, by e-mail; they answer in the web view (Approvals), and owners and admins also with approve. Through the CLI nobody answers their own request.
Members are named by ID, sign-in address or exact name. The listing commands take --json. Granting is an owner's; the member covered sees the grant and its reason on their page. TOKENOPS_TEAM_ADMIN_TOKEN with --server uses an administrator's token you were given instead of admin login.
Billing
The team plane is free while it is in beta: no card, no trial clock, and uploads are never paused for billing. tokenops team admin billing and the web view's billing page say so.
After the beta it will be billed per active member per month, through Paddle as merchant of record. Every organisation's owners hear by e-mail, at the verified address they signed up with, well before anything changes, and nothing is paused or deleted without that notice.
When figures appear
Totals are released per week, three days after the week ends (Monday to Sunday, UTC), and only for groups at least three people contributed to, so a new organisation's first week appears up to ten days after it starts. The web view and tokenops team status name the date; until then the overview says what will appear and when, and each member's own page shows their figures as soon as they are uploaded.
Single sign-on
Single sign-on to the web view with your OpenID Connect provider (Google Workspace, Microsoft Entra ID, Keycloak, Okta, or Dex in front of GitHub) is available beside GitHub sign-in and single-use sign-in links; it signs in only existing members whose verified address an owner set, and never creates anyone.