For works councils

This page is for a works council, a data protection officer, or anyone who has to agree to the team plane before a company turns it on. It says what the service measures, what it never receives, what each person can see, what you can set, and what it does not protect against. Each claim is enforced by the server and recorded in ADR 0012, so you can hold the service to it.

In Germany a system that can observe employees' behaviour or performance is subject to co-determination (§ 87(1) no. 6 BetrVG), whether or not the employer means to use it that way. The team plane is built to be agreed on, not worked around: every setting below is one a works agreement can fix. This page is not legal advice.

What it is for

The team plane answers questions about AI coding tools as a resource: which plans are too large or too small, where usage is avoidable, what the tools cost the organisation, and whether TokenOps' own interventions saved anything. It is not built to rank people, and it refuses to show figures that would amount to that.

What never leaves a machine

No prompts, no code, no file contents, no transcripts, no file paths, no model names. A machine uploads only derived figures (counts, sums and dates) keyed by day, repository label, kind of work and provider. The upload format is open source (pkg/teamwire in the public repository), and the server refuses an upload with any field it does not expect. What leaves a machine lists every figure.

Nobody joins without running tokenops team join on their own machine. team.enabled: false pauses uploads; tokenops team leave stops them and erases that machine's figures.

Who sees what

Who	Sees
Every member	Totals by team, repository, kind of work and plan, for weeks that ended at least three days ago, with every group under the minimum group size withheld (repositories: under five, or the minimum when higher), plus as many more as needed that no sum or difference of what is shown gives a withheld group back
The member	All of their own figures, including how their work turned out, their plan advice and their units of work per week (commits and reverted commits)
A grant holder	One member's usage and spend, and their units of work (commits per week, reverted commits included), for a team or for everyone, after an owner has granted it with a reason
Nobody else	How a member's work turned out (first try, rework, interruptions, escalations, rejections) and their plan advice, grant or no grant

Roles alone grant nothing: an owner without a grant cannot open a colleague's figures. Each grant names the person who holds it, its scope and its reason. The member covered sees it on their own page, along with every time someone looked at their figures. A view is written to the audit log before the figures are read; a view that cannot be recorded is not shown.

What you can agree

Setting	Range	Default	Where
Minimum group size	3 to 50 people	3	Manage → Privacy, or PUT /api/v1/settings
Retention of figures	30 to 3650 days	400	the same
Retention of each member's own rows	30 days to the retention of figures	90	the same (personal_retention_days)
ε of the organisation trend	0.1 to 5 per figure per week	1	the same (trend_epsilon)
Retention of the audit log	fixed	730 days	none
Who may hold grants, and for what	owners decide; each grant has a reason	none exist	tokenops team admin grant, revocable at any time

A works agreement typically fixes:

1. The minimum group size. Three is the floor the server enforces; repositories are held to at least five whatever it is set to, since who works on which repository is widely known. A larger organisation, or teams whose members everyone knows, may want five or more.
2. Who may hold grants, for which purpose, and for how long. For example: only team leads, only for one-to-one coaching the member has asked for, revoked after the quarter.
3. What the figures may not be used for. For example: performance reviews, pay or promotion decisions, or any comparison of named people.
4. Retention. How long figures are kept. Two periods: released team totals, which name no one, and each member's own rows, which serve only the member's own view and grants. Once a week is released, its members' own rows are deleted after the second period (90 days by default, never before the week is released, since the release reads them), so a member's own view, and any grant, covers that window. An agreement can fix both. The audit log is kept 730 days, so that views can be checked after the fact.
5. Who reads the audit log. Owners and admins see all of it; each member sees the entries about them. A council can ask for a regular export (tokenops team admin audit --json).

How changes behave

• Released weeks never change. A week is computed once, three days after it ends. Late uploads, members leaving and team changes do not alter it, because any recomputation would show the difference.
• Raising the minimum group size withholds more of the weeks already released, at once. It cannot take back figures someone has already seen. Agree the size before the first week is released.
• Lowering it applies to new weeks only.
• Removing a member erases their figures from the member views and from weeks not yet released; released weeks keep the totals they were released with.

The one differentially private figure

The withholding above is a thresholded, rounded aggregate method: exact for the reader it models, not differentially private. One section is: the organisation trend on the Overview (and GET /api/v1/trend). Each released week it shows four organisation totals (instructions, tokens, value at list prices and commits), each member's week counted up to a bound (1,000 instructions, 200 million tokens, $2,000, 200 commits), with random noise added once when the week is released and never drawn again.

• ε = 1 per figure per week by default. A week's four figures together spend 4ε. A member present for N weeks is covered at N·ε per figure (4N·ε for all four), by sequential composition.
• ε is a setting (0.1 to 5, Manage → Privacy, trend_epsilon in PUT /api/v1/settings, or tokenops-team privacy --trend-epsilon). A smaller ε adds more noise and protects more: at 0.5 the noise is twice as large as at 1. A change applies to weeks released after it; each released week keeps the ε it was drawn with, shown beside it.
• What it protects: whether any one member's week is in the totals at all changes what can be seen by at most a factor of e^ε, whatever else a reader knows. This holds for these figures only.
• What it costs: for a small organisation the noise is large against one week's figures; read the trend over many weeks.

What it does not protect against

The withholding is exact for the reader it models. The reader may know every released figure, which groups exist and who is in them. Even so, some things remain:

• Collusion. If all but one of a group's members share their own figures, the last one's follow. No aggregate method prevents this; a larger minimum group size makes it harder.
• Outside knowledge. Someone who knows, for example, that only one person worked on a repository on a given day learns that person's figures for it. Such a cell has fewer than the minimum number of people and is withheld, but knowledge of who was on holiday can narrow a group.
• Close figures. Released amounts (tokens, money, time) are rounded: tokens to three significant figures, money to four and never finer than a cent, time to the minute. Counts are exact. Rounding blurs a small difference between two figures; it does not hide a large one, which is what the withholding is for. Your own figures are never rounded.
• One person doing most of the work. A total where one member did 85% or more is close to that member's figure, however many others contributed. Such a cell is withheld, and no sum or difference of the rest gives it back. The same holds for two people: a total of three or more where two members together did 90% or more is withheld, and no sum or difference of the rest gives it back, so neither of the two can work out the other's share. Three or more people sharing most of the work are not covered by these rules; the minimum group size is what protects them.
• Bounds. Figures cannot be negative, so a large total over a group bounds what each person in it could have done.
• Plan advice over time. Each week's plan advice counts are published only when they differ from the last published ones by nobody or by at least the minimum group size. A change in the summed saving with every count unchanged is still published.
• Being in the team plane at all. Membership of the organisation, team names and display names are visible to its members.

On 1 November 2026 we found a gap: spend shares the work figures' turns, and plan tokens nearly do, so either could be combined with the work figures to estimate one person's use of a provider. Spend is now withheld together with the work figures, by the same exact check, so weeks released since show spend by repository and provider. Weeks released before the fix keep the interim rule they were released under (spend by team only, and no FOCUS rows), since a released week never changes. Plan cells show their coverage share instead of their token sums, for every week. No other section shares the work figures' turns this way.

Questions to ask us

• Where is the service hosted? In the EU, by klarlabs.
• Can we audit what a machine sends? Yes: the client is open source, and tokenops team preview shows the exact upload before anything is sent.
• What happens when we stop? Members leaving erase their machines' figures. When an organisation stops paying, its uploads are refused, and its figures are purged 30 days later. To have the organisation itself deleted, with its grants and audit log, ask us.