Your workspace is always named. Your customers never are.

Two of them, no — there is no setting anywhere, on any plan, in any workspace. Every prompt is scanned for injection patterns and scrubbed of personal data before it reaches the model, and before it reaches the copy we keep. A separate layer on top of those two is configurable: restricting which tools an agent may call, putting a ceiling on the value of an action, and requiring a confidence score before something proceeds. That layer is a deployment-level setting rather than a plan feature, so if you are relying on a specific part of it, ask us to confirm it is switched on for your workspace rather than assuming it from this page.

You get a refusal — an HTTP 402 with an upgrade message — rather than a larger invoice, and the important detail is that the refusal happens before the call, not part-way through it. A call has to fit in what is left of the month: if you have four credits and the action costs five, it does not start and you are not charged four. Two honest caveats. Whether reaching the cap hard-blocks is a deployment switch, so confirm it with us before you treat the number as a wall. And no plan in our catalogue carries a metered price today, which is what actually makes credit use un-surchargeable — it is a pricing fact, not a lock in the code.

Google Gemini, exclusively. There is no multi-model routing, no model picker, and no GPT or Claude path — a request naming another provider is still served by Gemini, and we deliberately do not publish the specific model versions on this page because they are configuration and they change. Prompts go to Google’s Generative Language API to serve your call and nowhere else. Oneop has no training pipeline of its own; there is none in the codebase to describe. How the model provider handles what it receives is governed by Google’s terms for that API rather than by us, and we will not characterise a third party’s practices on our own marketing page — the current data-processing terms are at /trust/dpa.

Not until somebody deliberately switches those actions on, and they ship off. While they are off they are refused at the single point where every action is dispatched — which means the refusal holds in the most permissive autonomy mode, and it holds even after a human has approved the action, because the check sits underneath the approval rather than beside it. Switched on, money and stock actions create draft records through the same services your staff use and under the same invariants: posting a bill to the ledger still needs its own separate human approval, and stock still cannot go below what is physically available.

No, and this is the one place we would rather show the table than describe it. Our plan catalogue differentiates exactly one AI dimension: how many credits a month you get. Injection screening, redaction, the workspace attribution on every call, the money-and-stock lock and the evidence trail are identical on the free plan and on Enterprise. There is no security tier here, because a governance control that only paying customers get is a governance control we would have to argue was optional — and it is not.

No, and we would rather say so than let you find out. Where a call is retried with the same idempotency key it is deduplicated and charged once, and where an approved action is dispatched it happens inside a single transaction with the approval, so a failure rolls the approval back rather than leaving it in limbo. But a longer-running process that is interrupted and resumed can re-enter the step it stopped in, and not every step is safely repeatable. If you are automating something whose second occurrence would be a problem — a payment, a shipment, an outbound message to a customer — put the approval step in front of it rather than relying on us to promise exactly-once, because we do not.

Three different times, and they are worth telling apart. Before the model runs, the credit reservation is written in the same transaction that charges it — so the spend record cannot exist without the workspace on it. After the call, an execution record is written on the success path and the failure path alike, carrying which model actually served it, how many tokens it used, how long it took and the error text if there was one; an audit row goes alongside it. And the honest third: a refusal is not written to that history. A prompt blocked for injection, or a call stopped at your ceiling, is refused before the record is created, so you will see it in your error handling rather than in your AI history. We are working on that, and we would rather tell you than let you assume an empty history means nothing was attempted.