Privacy policy
What Soba collects, what never reaches it, how long any of it is kept and who else sees it. Written to be checked against the product rather than to be agreed to without reading.
- Prompts and completions are not retained. A run's text passes through Soba in flight because it has to reach the machine that answers it. What is written down afterwards is who the run was for, what it cost and whether it worked.
- Provider credentials never reach us on the pairing path. Your user's Claude or ChatGPT login stays in their CLI, on their own machine. The one exception is the hosted ChatGPT channel, and it has a section of its own.
- No third-party analytics, no advertising, nothing sold. The site counts visits with a daily salt that is destroyed after two days, so nobody — us included — can follow a visitor from one day to the next.
- For your end users, we are a processor. You are the controller. We act on your instructions and we do not market to them.
This summary is not the policy. Where it and a clause below disagree, the clause is what we are held to.
1Who this covers
Soba is the LLM layer for agentic apps. A developer — a customer — builds on it; the people who use that developer's app and connect their own AI are end users. This policy covers both, plus anyone who simply reads soba.so.
The two relationships are not the same, and the difference decides who answers a request about data:
- For a customer's own account and billing, Soba is the controller. We decide what is collected and why, and requests come to us.
- For an end user's runs, usage and paired machines, Soba is a processor acting for that customer. We hold the records so the customer can bill and route; the customer decides what happens to them. See clause 12.
Soba is in private beta. The product is changing, and so is this page; clause 15 says how you find out.
2What we collect
Everything in this table, and nothing in it is collected for a reason outside the one stated.
| What | Why we have it |
|---|---|
| Account | Your email address, your display name, and the identifier your sign-in provider returns if you did not use a password. This is what a session is. |
| Workspace and app | Workspace name and slug, app names, members and their roles, invitations by email address, API key metadata — never a usable key, which is only ever shown once at creation. |
| Billing | Which Stripe customer, subscription and plan a user maps to, and every write we made to your Stripe account. Card details never reach Soba. Stripe holds them. |
| A run | One row: who it was attributed to, which machine and runtime served it, the cost class, the outcome, the environment and the time. Not what it said. |
| Usage | Model, provider, token counts, and cost in integer micros. This is the meter, and it is what an invoice is built from. |
| End users | The identifier you gave us for a person — opaque to us — and an email address if you sent one. We do not ask for more and the API does not accept more. |
| Machines | A stable machine id, the hostname the worker reported, any label the person typed over it, platform, architecture, agent version, online state and when it was last seen. |
| Setup conversations | If you use the setup assistant in the dashboard, that conversation and the changes it proposed are stored under your app, so you can come back to it. It is your text, in your workspace, and deleting the app deletes it. |
| Uploaded marks | A logo you upload for your app's connect screen. It is served to your end users, which is the whole point of it. |
| GitHub, if you connect it | The installation and the repository you pointed us at, so the quickstart can open a pull request. Nothing else in your account is read. |
| Support and waitlist | What you write to us, and the address you wrote it from. |
| Operational logs | Short-lived request and error logs at our hosts, which include network addresses. They exist to find a fault and they are not joined to anything above. |
A run's text crosses Soba and is not kept. The prompt or messages, the system slot, the schemas of your app-defined tools, the arguments the model passed to them, what your app answered, and every token of the output — all of it travels through us, because that is the only way it reaches a machine somewhere else and comes back. None of it is written to the record above.
That is a design property, not a promise about intent: the dashboard can tell you what a run cost and cannot tell you what it was about, because the column does not exist.
One consequence is worth stating plainly, because it is yours to design around: if one of your tools returns a customer record, that record crosses Soba on its way back to the model. Design your tool results the way you would design an API response to a third party, because for the duration of a run that is exactly what we are.
3What never reaches us
This half of the boundary matters more than the first, and it is enforced by where the code runs rather than by this page.
| What | Where it stays |
|---|---|
| Provider credentials | Your end user's Claude or ChatGPT login stays in their CLI, on their machine. The worker never reads it and we never receive it. |
| Files and directories | The model reads them on the machine. Their contents reach us only if the model quotes them into its own answer. |
| The shell | Commands run on the machine. We see a status event naming a tool, not a command line. |
| Your tool code | Only the schema is registered with us. The implementation runs in your app, against the data it already touches. |
| Your own provider keys | A run handed back to your app is served in your app, with your key. Only the usage is reported to us. |
| Approval decisions | Appended to a log on the end user's own machine, not ours. |
| Payment card details | Stripe. They never touch our servers. |
4The ChatGPT plan channel, which is the exception
Everything above describes the normal path, where compute moves to the credential. One optional channel does the reverse and moves the credential instead: an end user grants access to their ChatGPT plan and the loop runs server-side rather than on their machine.
If you enable that channel, we hold an access token and a refresh token for that user, the account identifier the issuer returned, a label for it — usually an email address, so a person with two accounts can tell which one they connected — and the times it was created, last used and revoked.
- Those tokens are sealed with AES-256-GCM before they are written, under a key held outside the database.
- They are used for one thing: running that user's own runs on their own plan.
- An end user can disconnect, which revokes the grant on our side; revoking it at the provider ends it everywhere.
- The channel ships no default OAuth client id. An operator supplies one they are entitled to use and owns that decision — see Provider terms.
5The website
Analytics, with no cookie and no third party
soba.so is counted by our own server. There is no Google Analytics, no advertising pixel, no third-party tracker, and no cross-site identifier of any kind.
A visit records the path, the referring site's hostname, any utm_* values in the link, the coarse location our host reports — country, region, city — and the device, browser and operating system family. Your network address is not stored. A visitor is identified as:
- a hash of today's random salt + your address + your user agent, truncated;
- where that salt is thirty-two random bytes which are deleted two days later.
Once the salt is gone the hash is one-way to us as well as to anybody who takes the database, so nobody can follow a visitor from one day to the next. This is the same construction Plausible uses, and it is why it needs no cookie banner.
The beacon
One small script measures how fast the page actually rendered and which outbound links are followed. It sets nothing, reads nothing from your browser, and sends no page text.
Cookies
| Cookie | What it does |
|---|---|
| Session | Keeps you signed in to the dashboard. Strictly necessary; set by our authentication provider. |
| Access code | Remembers that you entered a private-beta code, so you are not asked again for three months. |
| Exclusion | Set only if you ask to be left out of our own counts. It exists to collect less. |
There are no advertising or profiling cookies, so there is no consent banner to click past.
Fonts
Typefaces are loaded from Google Fonts, which receives the request your browser makes for them.
6How we use it
- To run the service — route a run to a machine its owner actually owns, return the answer, keep the dashboard truthful.
- To meter and bill — count what was spent, build an invoice, write the subscription records to your Stripe account.
- To keep it working and safe — find faults, enforce rate limits and spend ceilings, investigate abuse.
- To talk to you — service notices you cannot opt out of while you hold an account, and product email you can.
- To see what the product is doing — aggregate counts of signups, connections and activations.
We do not sell personal data, we do not share it for advertising, and we do not train models on your prompts, your completions or your tool results. We could not: they are not retained.
7Legal bases
If the UK GDPR or the EU GDPR applies to you, these are the grounds we rely on.
| Basis | For what |
|---|---|
| Contract | Your account, your workspace, running and metering what you asked us to run, and billing you for it. |
| Legitimate interests | Security, abuse prevention, fault-finding, and privacy-preserving counts of how the site and product are used — balanced against the fact that none of it identifies a person to us. |
| Legal obligation | Tax and accounting records, and anything a court or regulator can compel. |
| Consent | Product and marketing email, which you can withdraw at any time without losing the service. |
9Where it is held
The database and the functions that write to it are pinned to the same region — London — and sit a few milliseconds apart. Some of our processors operate globally, so data may be processed outside the UK and the EEA; where it is, transfers rely on the UK International Data Transfer Agreement, the UK Addendum, or the European Commission's standard contractual clauses, as applicable.
10How long we keep it
| What | How long |
|---|---|
| Prompts, completions, tool arguments and tool results | Not retained. They exist in memory for the length of a run. |
| Run and usage rows | While your account is open, because they are the ledger an invoice is built from, and for 24 months after it closes. |
| Account, workspace and app records | Until you delete them, then 30 days in backups. |
| Billing and tax records | 7 years, which is a legal obligation rather than a choice. |
| Hosted ChatGPT tokens | Until revoked or the end user is deleted, then erased. |
| The analytics salt | 2 days, after which the visitor hashes it produced cannot be linked to anyone, including by us. |
| Visit rows | 14 months, as pseudonymous rows that no longer resolve to a person. |
| Operational logs | 30 days at our hosts. |
Deleting an app deletes its end users, machines, setup conversations and uploaded marks by cascade. Billing records survive, because they have to.
11Your rights
Depending on where you live you may have the right to access what we hold about you, correct it, delete it, object to or restrict how we use it, take it elsewhere in a portable form, and withdraw consent you have given. Write to privacy@soba.so and we will answer within 30 days. We do not charge for this and we will not treat you differently for asking.
If you are in California: we have not sold or shared personal information in the preceding twelve months, and we do not offer financial incentives for it. If you are in the UK or the EEA and we have not resolved something, you may complain to your supervisory authority — in the UK, the Information Commissioner's Office.
If your data is with us because you use a customer's app, your request belongs with that customer first. See the next clause.
12If you are an end user of an app built on Soba
You have an account with that developer, not with us. They decide what their app does with your data and they are the controller of it; we hold the records they need in order to route and bill your runs, on their instructions.
- Send access or deletion requests to the developer whose app you connected. We will help them answer and we will act on their instruction.
- We do not market to you and we do not build a profile of you across the apps you connect to.
- Your pairing is a grant you approved in a browser where you were already signed in. No credential is ever displayed to you or pasted by you, which means there is none for either of us to lose.
- What your machine will and will not allow is a file on your own disk, and every approval decision is logged there rather than here.
13Security
- Everything is served over TLS, and tenant isolation is enforced in the database by row-level security rather than only in application code.
- API keys are stored as hashes. A key is shown once, at creation, and cannot be read back.
- Hosted provider tokens are sealed with AES-256-GCM under a key held outside the database.
- A run arriving over the network cannot widen a machine's grant, cannot reach a tool its owner did not permit, and does not inherit the owner's local agent configuration. The check runs on the machine, not here, which is the point: Soba is the component the architecture asks you to trust least.
No system is perfect. If you find a vulnerability, write to privacy@soba.so before disclosing it and we will work with you. If a breach affects you, we will tell you and the relevant regulator within the time the law allows.
14Children
Soba is a developer tool and is not directed at children. We do not knowingly collect data from anyone under 16. If you believe a child has given us data, write to privacy@soba.so and we will delete it.
15Changes
When this policy changes, the date at the top changes with it. For a change that materially affects what we collect or what we do with it, we will email account holders at least 14 days before it takes effect. Continuing to use Soba after that is acceptance; closing your account is the alternative and costs nothing.
16Contact
Privacy questions, access requests, deletion requests and vulnerability reports: privacy@soba.so. Anything about the agreement itself: legal@soba.so.
If you are filling in a security questionnaire, ask us for these claims in writing rather than citing this page. We will answer, and a signed answer is worth more to your reviewer than a URL.
Let your users run your AI features on the Claude or ChatGPT plan they already pay for.