Safata for organizations.
Safata is free for local, individual use, at home and at work. An organization that deploys it centrally is on a paid plan by default. The management layer that makes deployment possible is designed and not built. It will see spend and usage, never content, and only where an organization deployed it.
Today that means the individual product, which is the only thing there is: the same early build everybody gets, on a laptop, on a key. If your organization would deploy it, get in touch; that conversation is what starts the work.
Where the line is
Individuals adopt, free
At home and at work, employed or freelance. An employer-provided laptop or an employer-provided API key does not change what an individual is: local, individual use is the free product.
Nobody sells Safata itself
No resale, no bundling into something you charge for, no hosted or managed version, no redistribution for a fee.
Organizational deployment is paid, by default
An organization that provisions Safata, mandates it, or manages it centrally is deploying rather than adopting, and deployment is a paid plan. By arrangement, for now, because there is no product to buy yet.
Why the free product doesn't roll out
The free product doesn’t work as a rollout anyway. It runs on a personal API key in a personal keychain, stores everything on one person’s disk, and reports to no one: right for an individual, unusable as a fleet. No company hands a raw provider key to every employee, and no company can plan around spending it can’t see.
What an organization needs is the layer that fixes that. That layer can’t be local, which is why it’s a separate, paid product.
The management layer
Not builtDesigned and decided, with no code written. This is what it will be when an organization needs it enough to start it.
Central key custody
Provider keys held by the organization, never distributed to individuals; or model access billed through the plan itself, at provider prices, on one invoice. People get access; nobody gets the credential.
Budgets and spend caps
Limits set centrally, per team and per person, enforced the way the per-session cap already works: the run stops at the limit instead of reporting the overrun afterwards.
Permission and connector policy
The four-sentence permission rule with an administrator instead of a user setting the standing grants, and an allow-list for which connectors and MCP servers may be used at all.
Provider and model policy
Which vendors and which models a deployment may use at all, set centrally. It is the first rule most European organizations ask for, and one the individual product answers only per machine: a key is only ever sent to the provider it belongs to, so a provider that is not in the policy cannot receive anything. Data residency in Safata is the provider's, since nothing else is in the path; this is the switch that makes that a choice an organization can make once.
Single sign-on
Identity from the directory you already run, so joining and leaving are one event each, with no keys to hunt down.
Managed updates
Version pinning and staged rollout, so a fleet is on a version somebody chose.
A shared knowledge corpus
The filed, searchable history that makes Safata compound for one person, made shared for a team, with the same permission model, not a looser one.
Most of that list already exists in the free product, per machine: spend caps, permission modes, connector policy, the per-provider key binding, the knowledge corpus. The layer is a different administrator, not capability held back behind a price, and administration is the part that cannot be local.
What it will see
Spend and usage of the deployment the organization pays for. Cost by team, by person, by model, by month. Which seats are active. Which models are being used. The things finance and IT need in order to say yes.
Never content. Not prompts, not transcripts, not deliverables, not what anyone asked or what came back. Not summarised, not sampled, not "for quality." The work stays between the person and the model they chose.
And only where an organization deployed it. Somebody who downloads Safata for themselves is not in any such system and cannot be enrolled into one. There is no switch for that, on either side.
What I won’t build
No usage detection, no licence check inside the binary, no call home to find out whether the person running Safata is an individual or a fleet. Those mechanisms poison the trust of every honest user to catch the dishonest ones, and here they would contradict the product outright.
The boundary is enforced by procurement instead: an organization that wants Safata deployed properly will want the layer above anyway.
Charge for a capability you add or operate. Never for permission to run bits somebody already has.
Status
None of the management layer is built; what exists today is the individual product and this page. If your organization would deploy Safata, get in touch. That conversation is what starts the work.