llm-bench — Terms of Service

KAPUA Labs LLC 30 N Gould St Ste R, Sheridan, WY 82801, United States

These Terms of Service ("Terms") are a binding agreement between KAPUA Labs LLC, a Wyoming limited liability company ("KAPUA Labs", “we”, “us”, “our”), and the person or entity that opens an Account ("you", “your”, “Customer”). They govern your use of the llm-bench inference API service, its management console, and the evaluation and benchmark machinery behind it (together, the “Service”).

By creating an Account, accepting these Terms in the signup flow, or using the Service, you agree to them. If you are accepting on behalf of an organization, you represent that you are authorized to bind it.

The Data Processing Agreement forms part of these Terms. It is accepted electronically at signup on the free and shared_anon tiers, and executed by signature on the private tier. Where the DPA and these Terms conflict in respect of the processing of Customer Content, the DPA controls.

Read §6, §7, §8 and §12 carefully. They describe what we keep, what we reuse, what we publish, and the one thing we cannot give back. They are the substance of what you are choosing when you choose a tier, and they are written to be checkable rather than reassuring.

1. Definitions

These are the Service’s own terms of art. They are used consistently below, and the data clauses turn on the distinctions.

2. The Service

The Service accepts requests naming a Capability, selects a model to run each request unless you have pinned one using the forced_model field, calls the relevant Provider, returns the Output to you, and — for some Calls — evaluates the Output with a judge model to produce a Verdict. Verdicts roll up into Aggregates that inform future routing and, for the free and shared_anon tiers, our public benchmark rankings.

If a model’s Output fails our format checks, or a model does not return an Output at all, the Service tries an alternative model for that Call instead of simply failing it — unless you pinned an exact model with forced_model (§1), in which case there is no alternative and the Call fails.

A Call runs in one of two modes. In the default, synchronous mode, your request waits until the Service returns the Output. In batch mode — submitted as a file of many Calls at once, using the OpenAI-compatible Batch API — each Call is processed independently, and its result comes back as a line in an output file rather than as an immediate response.

Neither mode streams, and we do not offer streaming at this time. An Output is returned once, complete; no part of it is delivered to you while the model is still producing it. The OpenAI-compatible endpoint carries a stream field for wire compatibility, and setting it to true is refused with an error rather than served — in synchronous and in batch mode alike. We refuse rather than quietly ignoring the field, so that a client written against a streaming API fails visibly instead of appearing to stream. Streaming is a feature we may add under the last paragraph of this section; until we publish it in the API reference, treat stream: true as unsupported.

In batch mode, each Call has a maximum wait time for the model it is currently trying — either one you set per Call, or the batch’s own completion window. If that time passes without an Output, the Service cancels the attempt and reschedules the Call to an alternative model with a fresh full wait time, excluding the model that timed out. This can repeat until the Call succeeds, every eligible model has been tried, or the batch reaches its own 24-hour limit (§6.2), whichever happens first.

If you have registered a webhook endpoint, we notify you by webhook when a batch finishes, whatever the outcome — the notification carries no results itself, only a pointer to fetch them. Creating a batch does not register an endpoint, and we send nothing to an Account that has registered none. Webhook delivery is best-effort in any case, so you can also check a batch’s status and results directly through the API at any time, whether or not a webhook arrives.

We may change, add to or discontinue features of the Service. Where a change materially reduces the Service’s functionality or alters the data grant in §6, we will publish a new version of these Terms under §22 and ask you to accept it.

3. Eligibility and accounts

You must be at least 18 years old and legally able to enter into contracts. You must provide accurate registration information and keep it current.

Data subject to the EU or UK GDPR. You represent that you will not use the Service to process personal data subject to the EU or UK General Data Protection Regulation unless we have first executed the applicable transfer instrument with you as an addendum to the Data Processing Agreement (DPA §12.5). We do not verify this and we do not collect a location from you; like the representation in §21, it is yours to make and yours to keep accurate.

One Account per user. A user belongs to exactly one Account. There is no facility to switch between Accounts, and no user may span two Accounts. If you need a person to work in two Accounts, they need two logins.

Roles. An Account has members with one of four roles — owner, admin, billing or member. The role determines what that person may do:

admin and billing are separate roles, not ranks. An admin cannot change billing or payment details, and a billing member cannot manage API keys or Provider Credentials.

Accepting these Terms. In the console, acceptance is an owner’s action. It may also be made through the API with a management key, which is how an Account that integrates without using the console accepts a new version — §1 already binds you on creating an Account, accepting in the signup flow, or using the Service, under the authority-to-bind representation stated there. An acceptance made with a key is recorded against that key rather than against a person, and our record says which. We do not verify who holds a key; the API-key paragraph below makes that your responsibility.

Transferring ownership and closing the Account are handled by request to the address in §25 rather than by a console action — see §20.

Acts of any member of your Account bind your Account, and you are responsible for them.

API keys. Access to the API is by API key. A key is displayed once, at creation, and we store only a cryptographic hash of it together with a short display hint. We cannot recover a lost key — it can only be revoked and replaced. You are responsible for keeping your keys confidential and for all activity conducted with them. Notify us promptly at the contact address in §25 if you believe a key has been compromised.

4. Acceptable use

You will not, and will not permit anyone using your Account to:

1. use the Service in violation of applicable law, or of any Provider’s own terms, usage policies or acceptable-use policies;
2. use the Service to generate or distribute content that infringes third-party rights, or that the applicable Provider prohibits;
3. submit any personal data at all on the free tier, or personal data of any kind within a Template or a registered output schema on any tier including private — because free-tier prompt text is reused for our own purposes and replayed on our own keys (§6.5), Template text on free and shared_anon may be evaluated for and adopted into the canonical library (§9), and a registered schema is not erasable (§12.2). See DPA §3.4(a);
4. submit to the Service, on any tier, protected health information subject to HIPAA, cardholder data subject to PCI DSS, information subject to the Gramm-Leach-Bliley Act, government-issued identification numbers, biometric identifiers, or the personal data of children under 13, unless we have agreed to it in a signed written amendment — which is available only where the DPA has been executed by signature on the private tier;
5. attempt to circumvent the tier controls, quotas, rate limits or tenant isolation of the Service, or to access another customer’s data;
6. resell or sublicense access to the Service, or share Account credentials outside your organization;
7. use the Service to develop a product that competes with the Service, or to reverse engineer it, other than to the extent that restriction is unenforceable under applicable law.

You are responsible for the content you submit and for having all rights necessary to submit it and to have it processed as described in these Terms. We have no technical means of detecting a breach of items 3 or 4 — the Service imposes no schema on prompt content — and we rely on your compliance.

5. Provider Credentials and who pays the Provider

A Call is served in one of two access modes, and which one applies decides who your counterparty is. In bring-your-own-key mode (§5.1) you supply the Provider credential and the Provider bills you directly. In operator-supplied mode (§5.2) we supply the model access on our own credentials and bill you for it. Every Capability declares which mode it runs in, and the mode is visible to you on the Capability.

5.1 Bring your own key

In this mode you supply API keys issued from your own accounts with the Providers you want used, and we call those Providers as you.

How we hold them. Each credential is envelope-encrypted: the secret is encrypted with a freshly generated 256-bit data key using AES-256-GCM, and that data key is itself wrapped by a key-encryption key held for your Account alone in a managed key vault. The ciphertext and the wrapped data key are stored in our database; the key-encryption key never leaves the vault. No plaintext Provider Credential is stored. Plaintext exists only in worker memory for the duration of use, and is cached for a configurable period, currently 300 seconds — which is also the bound on how long a revocation at the Provider takes to be reflected in a warm worker.

Fail-closed. If the key vault is unavailable or an unwrap fails, the Call fails. We never fall back to any other stored key or to our own key to serve your traffic.

Audit. Materialization of a plaintext credential writes an append-only audit record naming the purpose and the Provider. Where the same credential is materialized repeatedly in quick succession the record is written once for the sequence rather than once per use, so the trail evidences that a credential was used and for what, not a count of uses. The record never contains key material. We display only the last four characters of a credential, for identification.

Your representations. You represent that you are authorized to supply each Provider Credential to us and to have us use it on your behalf, and that doing so does not breach your agreement with that Provider. Under your own keys, each Provider is your counterparty, not our subprocessor — your agreement with that Provider governs what it may do with the content we send it on your behalf, including whether it may use that content to train or improve its models. Two consequences you should act on:

• Unpaid Provider tiers. At least one Provider (Google’s Gemini API) applies materially different data-use terms to unpaid projects: on the unpaid tier Google states that it uses submitted content and generated responses to improve its products and services, and that human reviewers may read, annotate and process API input and output. If you vault a credential attached to an unpaid project, that treatment applies to your traffic. The Service does not detect the billing status of a Provider Credential and cannot warn you. Choosing a paid Provider project is your responsibility.
• Regional restrictions. Some Providers restrict which of their tiers may be used to serve users in particular regions — Google requires paid services where API clients are made available to users in the EEA, Switzerland or the United Kingdom. Complying with those restrictions is your responsibility.

The Service also supports a zero-custody mode, in which a Provider Credential is supplied on a per-request header, is used for that request only, and is never written to storage. It may not be combined with a vaulted credential on the same Account.

In this mode you control which Providers can receive your content, and from which region. Because credential resolution in bring-your-own-key mode never falls back to our keys, the eligible model pool for any Capability is the intersection of that Capability’s models with the Providers you have supplied a credential for — vaulted or per-request — and the Service enforces that constraint. Where a Provider operates region-scoped endpoints, the credential you supply is bound to one of them, so the same choice determines the region your call is served from. This applies to ordinary serving traffic and to benchmark execution on your uploaded benchmark sets (called Evaluation Inputs in the DPA). It does not apply to free-tier replay under §6.5, which runs on our roster and our keys.

5.2 Operator-supplied access

Operator-supplied access is the mode the Service, the portal and the documentation call managed (§1). The two names describe one arrangement; there is no third access mode.

In this mode we supply the model access ourselves. You do not vault a credential for the Provider concerned; we call the Provider on our own account, and we bill you for that usage separately from any Provider spend of your own. The commercial terms are in §14 and in the Pricing Terms.

Three consequences follow, and they are the mirror image of §5.1:

• The Provider is our subprocessor, not your counterparty. Because the call runs on our credentials, the Provider processes your content on our instructions rather than yours. The current set is published in our Subprocessor register, and the notice and objection rights in the DPA (§7.4) and the Privacy Policy (§7.3) apply to it.
• Your §5.1 representations do not apply, because you supply no credential. The representation that you are authorized to supply a credential, the unpaid-tier warning and the regional-restriction warning are all features of bring-your-own-key mode and are not asked of you here.
• The eligible model pool is ours, not an intersection with your credentials. We choose the roster and may change it; §2’s failover applies to it. Where a Provider operates region-scoped endpoints, the region is our choice and is disclosed with the model.

What does not change. The tier data grant in §6 applies identically in both modes — the access mode decides who pays the Provider, never what we may keep or reuse. Retention (§7), pooling (§8), taxonomy use (§9) and deletion (§12) read the same either way.

6. Tiers and the data grant

This is the clause the pricing tiers are actually selling. Choosing a tier is choosing what the Service may keep and reuse.

6.1 The grant table

This table is a rendering of a single retention matrix in the Service’s code, applied at one write chokepoint. Any change to that matrix is a change to this agreement and requires a new version of this document under §22.

This table applies by tier, from the moment a tier takes effect (§6.4) — not from the moment you accept the corresponding data-grant document. We ask you to accept the data grant for your tier and we record that acceptance against a specific version (§22); that record evidences what was disclosed to you, and it does not itself condition the treatment above. An Account that moves to the free tier is therefore handled under the free column from the time of the move, whether or not it has since accepted the free-tier data grant. Cancelling a paid tier moves you to free; §14 sets out what that changes.

6.2 How “never stored” is enforced

For shared_anon and private, prompt variables are dropped at the moment the Call record is written. They are not written and later deleted. Because the Service has exactly one Call-record creation site, the gate covers every path — synchronous calls, batch enrolment, image calls, judge calls, fan-out sibling records and internal repair calls alike.

What “never stored” does and does not mean. It means your prompt is not persisted on the Call record. It does not mean the prompt never exists in our systems: it is necessarily in worker memory while your Call is being served, including when we retry or fail over to a second model within the same request. Three qualifications, all real:

• shared_anon retains a routing embedding of your request, for a bounded purpose. An embedding is partially invertible, so we treat it as content rather than as metadata — which is why erasure hard-deletes it (§12.1). It is kept only as material for the one-time evaluation of the Capability under §9, and is deleted when that evaluation is complete. private retains no embedding.

• Batched Calls hold a working copy. A Call submitted through the Batch interface cannot be served without keeping its rendered request — the Provider submission reads it back, and a retry or resubmission needs it again. That working copy lives on the Call record’s operational metadata on every tier including private, is stripped when the batch finalizes, and is stripped again by a daily sweep that catches anything left behind (and any Call still in flight after 72 hours). A batch also carries a hard 24-hour expiry backstop. For batch traffic, “never stored” therefore means “not stored beyond the operational window” — hours to a couple of days — rather than “not written at all”.

• Benchmark inputs you upload are exempt, by design. If you upload a benchmark set (“golden set”) in order to measure models against it, those inputs are stored and re-run on every tier, because that is what you uploaded them for. They are listed in your Account. Uploading requires an explicit acknowledgement of this exemption, recorded with the identity of the person who gave it, the time, and the version of the applicable data-grant document once one is published; the Service refuses an upload without the acknowledgement, and refuses to start a benchmark run whose set carries none.

6.3 Unknown tier fails closed

An Account whose tier is missing or unrecognized is treated as private — the most restrictive setting — never as free.

6.4 Changing tier

A tier change takes effect going forward. It does not re-classify data already written, and it does not withdraw Verdicts already pooled (§8).

6.5 free-tier replay — the consideration for the free tier

On the free tier and only on the free tier, we retain your prompt text and use it for our own purposes: re-executing it against newly introduced models to measure them (“model-introduction replay”), and developing the canonical taxonomy in §9. That use is what you are giving in exchange for the free tier.

Two consequences you should weigh before choosing free:

• Replay runs on our Provider Credentials, not yours, against a roster we choose. Your choice of Providers under §5 does not constrain it, the work returns you nothing, and it is not billed to you. On that path the model Providers are our subprocessors (contrast §5, where they are your counterparties). If you do not want your content to travel that path, do not use the free tier.
• Because free-tier prompt text is used for our own purposes, we are not acting as a “service provider” under the CCPA in respect of it. The same is true of Template content on free and shared_anon, which we use for taxonomy under §9. We still do not sell or share either, as those terms are defined under the CCPA. If you need service-provider treatment for everything you send, use the private tier. See DPA §6.4.

What we use it for, and what we do not. Everything we keep on the free tier is used for one purpose: improving the Service for every customer — replaying your prompts against newly introduced models, re-checking models over time, and mapping your tasks onto the canonical library that routing is measured against. We do not sell it. We do not disclose it outside the Service, except to the model Providers that execute or evaluate it on our behalf as our subprocessors (DPA §7.3) and, for Template text only, under the library licence in §9. What we publish is Aggregates — scores and counts about models, carrying none of your content (§8).

On shared_anon and private, prompt text is not written and no replay of your content occurs.

7. Retention of model Output

How long we hold the model’s Output to your Calls depends on your tier, and on the two tiers you pay for it is bound to delivery. We say so plainly because the intuitive reading of “private” is that nothing is stored, and that reading is wrong in one respect: an Output has to be stored, on every tier, for the time it takes to give it to you.

We store Output because three delivery paths rebuild your own deliverables from it after the Call has finished:

1. Webhooks. Delivery records are deliberately content-free; the payload we sign and POST to your endpoint is rebuilt from the stored Output at send time.
2. Batch output files. The OpenAI-compatible Batch API’s output file is rendered from stored Outputs when the batch finalizes.
3. Your own retrieval. You can ask for a past Call and get its Output back, for as long as we still hold it — which is also the recovery path when a webhook delivery is lost.

Beyond those three, stored Output is used for the evaluation and judging operations you instruct (§11) and, on the free tier only, as a comparison baseline in model-introduction replay (§6.5). It is used for no other purpose.

7.1 shared_anon and private — deleted once delivered and evaluated

On these two tiers the commitment is:

We delete the Output of a Call promptly — typically within minutes — once it has been delivered to you and any evaluation of it we perform has finished. An Output we could not deliver is held for you to retrieve for at most 72 hours, then deleted. There is no retrieval of a past Output beyond that.

Four consequences follow, and you should design for them:

• Keep what you fetch. A synchronous response is delivered when it is written to you; a webhook result when your endpoint acknowledges it; a batch result when you fetch its output file. After that, the Service does not hold a copy for you to ask for again. A batch output file stays fetchable for a short time after the first fetch so a download broken in transit can be retried, and then goes.
• The 72 hours are the exception, not the rule. They exist for the result we could not deliver — a webhook that kept failing, a batch file nobody fetched, a response a client never read — so that it is not lost the moment it is produced. They are a ceiling on how long such an Output lives, not a period in which we promise to serve it, and once it has been delivered the clock no longer applies.
• Evaluation finishes first. Where a Call is selected for evaluation (§11), its Output is held until the judge has produced its Verdict — ordinarily within seconds of delivery, and never beyond the same 72 hours. The Verdict is content-free and survives; the Output does not.
• The one exception is yours to set. Where you judge a Capability on your own criteria, we keep a copy of each evaluated exchange for a review window you control, so that you can see what the judge saw and decided (§11). That copy is deleted when the window closes.

The prompts to a batch are held on the same terms: an uploaded batch input file is deleted once every line of the batch has reached a terminal state, and in any case within the same 72 hours.

7.2 free — retained

On the free tier we retain the Output, because it is the comparison baseline against which we measure newly introduced models (§6.5), which is the consideration for the tier. It is retained until you request erasure or close your Account (§12). Once its delivery is complete we may also delete an Output on our own initiative, at any time and without notice, to manage our storage.

7.3 What this is and is not

This section is a schedule we enforce, not a policy we intend: a sweep runs continuously against the rules above, and we monitor that it does. We do not describe the mechanism here, because the mechanism may change; the commitment is to the outcome. If we ever lengthen the retention of Output on shared_anon or private, that is a change to these Terms and will be published as a new version under §22; shortening it is not.

8. Pooling, and its irreversibility

8.1 What pooling is

If your Account is on free or shared_anon, the Verdicts produced when your Calls are evaluated are contributed to a cross-customer pool. The pool decides which models the Service routes work to, and it is the basis of the public benchmark rankings we publish.

A pooled Verdict contributes only the judged model, the Capability and the score to the pool; the judge’s rationale is not pooled. It does not carry your identity to the pool, and it does not carry your content to the pool — the pooled artifact is an Aggregate computed across many customers.

A Verdict pools only if all four of the following hold at the moment it is written: your Account’s statistics scope is global (that is, free or shared_anon); the Capability exists and is active; the Capability maps to a confirmed canonical Capability (raw, unmapped Capability names never pool); and the judging panel is your Account’s ordinary production panel (shadow and experimental panels never pool). Anything else, and the Verdict stays in your Account.

8.2 The irreversibility clause

Verdicts already contributed to the pool will not be un-pooled. Changing your tier, or leaving the Service, changes what happens to future Verdicts; it does not withdraw past contributions.

This is a commitment about what we will do, not a claim about what is technically possible. Un-pooling is mechanically possible — we can re-tag Verdicts and recompute the affected Aggregates — and we reserve that ability for repairs and for honoring erasure requests where we determine it is required. We do not offer it as a customer-triggered right.

8.3 Why it works this way

A pooled statistic is not a copy of your Verdict sitting in a shared table. It is an average — a number computed from many Verdicts across many customers, together with a confidence interval saying how sure we are of it. Once your Verdict has been folded into that average, the average is a new fact about a model, not a record about you.

Two consequences follow, and they are the honest reason for this clause:

1. Removing one contribution does not restore the previous state of the world. We can recompute the average without your Verdicts — and we will, where erasure requires it. But the recomputed number is a new number. It does not undo the routing decisions already made from the old one, the models already retired because the old one said they were worse, or the rankings already published.
2. The average is what makes the free and shared tiers cheap. Those tiers are priced on the assumption that the traffic contributes to the shared measurement. A per-customer right to retroactively withdraw contributions would make that measurement unstable for everyone relying on it.

If you do not want to contribute, that is exactly what the private tier is: your Verdicts aggregate only within your own Account and never enter the pool.

9. Taxonomy use of your Capabilities and Templates

The Service maintains a canonical library — a map from the many differently named Capabilities our customers define onto a smaller set of underlying tasks. That map is what lets a benchmark say something meaningful about “summarization” rather than about one customer’s summarize_ticket_v3.

On free and shared_anon, you grant us a non-exclusive, worldwide, royalty-free right to use your Template text for that purpose: to compare it with other Capabilities, to group it, and to derive the canonical task it belongs to. On free we may additionally use your prompt variables for the same purpose. On private we do not use your Template text for taxonomy at all — the tier gate is applied before your Template rows are read, so on a private Account the Template is not read for this purpose.

On every tier, we use the Capability’s own definition — its slug, display name and description — to build the routing index. That definition is Account configuration you author to declare what a Capability is, not content you send through it, and the index cannot function without it.

This grant is otherwise limited to deriving structure: outside the case below, it does not permit us to reproduce, publish or redistribute your Template text, and we do not do so. The derived structure — the canonical mapping and the statistics computed through it — is ours; the Template text otherwise remains yours (§10).

Common-capability adoption. On free and shared_anon, if we determine that a Capability you defined is suitable to become part of the canonical library made available to other customers, you grant us a non-exclusive, worldwide, royalty-free right to reproduce, publish and redistribute that Capability’s Template text, verbatim, as part of the published canonical set — including serving it, unmodified, to any other customer whose Calls route to that canonical Capability. We decide which Capabilities we adopt this way, at our discretion; you do not need to request or approve it, and we do not owe you notice, credit or compensation for it. This is a license, not a transfer of ownership — the Template text remains yours (§10) — but to the extent it is published or served to other customers under this license, it is no longer confidential, and it is used well beyond deriving structure.

The evaluation is one-time and bounded, and you may delete the text after it. On free and shared_anon, the comparison of your Template with the canonical library — the mapping in this section and the adoption decision above — is made once, within a bounded period of the Capability’s creation, and the console shows when it is complete. When it is complete, everything we kept for that comparison is deleted (the routing embeddings of §6.2 among it), and from then on you may delete the Template text yourself, from the console or the API. On private there is no evaluation, and you may delete the text at any time. Deleting the text does not delete the record that a given version of it ran a given Call — that record is content-free and survives — and it does not revoke a license already exercised: a Template adopted into the canonical library stays adopted. A Capability whose Template you have deleted cannot serve Calls until you register a new one.

10. Intellectual property

Yours. You retain all rights in your prompt variables, Templates, Capability definitions, uploaded benchmark sets and other content you submit ("Customer Content" — for the purposes of the DPA and of the precedence rules in these Terms, that phrase has the broader meaning given in DPA §1, which also covers model Outputs, Provider Credentials and webhook destinations). As between you and us, Outputs generated for your Calls are yours, to the extent the applicable Provider’s terms assign them to you. You grant us only the rights expressly stated in §6 and §9, plus the rights necessary to operate, secure and support the Service.

The shared_anon tier is an explicit ownership split, and you should read it as one: the data you send through a Template is never retained, while the Template itself and the statistics derived through it are retained and usable by us for taxonomy. “Anonymized” does not mean “we keep nothing”.

Ours. We retain all rights in the Service, its software, models, canonical library, Verdicts, Aggregates, benchmark rankings and published snapshots. Nothing in these Terms transfers any of it to you.

Feedback. If you send us suggestions, we may use them without restriction or obligation to you.

Publicity. We will not use your name or logo as a customer reference without your prior written consent.

11. Evaluation and judging

When a Call is evaluated, the Output is sent to a judge model — another model, running on Provider Credentials, which scores it.

Most Calls are not evaluated. How often a Call is evaluated depends on how much evidence the Service already has about the models eligible for that Capability. While a Capability is still gathering that evidence, a larger share of its Calls may be evaluated so its models’ quality can be established. Once a Capability is well-evidenced, evaluation drops to a small, ongoing check — typically well under 1% of Calls — with two brief, self-limiting exceptions: a temporarily higher rate when we introduce a newly released model into an already-evidenced Capability, and periodic re-checks to catch a model’s quality drifting over time. We control this rate through policy; it is not something you configure per Call.

Evaluation of your traffic is funded by you. Deferred organic judging, fan-out co-scoring and evaluation of your own benchmark runs are funded by you in whichever access mode serves the Task Model: in bring-your-own-key mode they run on your Provider Credentials and your Provider bills you directly; in operator-supplied mode they run on ours and reach you as the §14 pass-through, at cost and with no margin. Either way they carry no additional per-Call fee. Where funding is checked in advance, the Service hard-fails rather than falling back to our keys: a benchmark run whose target or judge models you have not supplied credentials for is refused, not silently funded by us. We fund only benchmark work with no customer Call behind it — introducing a newly released model, and judge-versus-judge comparisons.

This concerns the cost of model usage, not our fees. Judge and fan-out requests are charged to you the same way the rest of the chain is — by your Provider under §5 and §17 in bring-your-own-key mode, or as the §14 pass-through at cost in operator-supplied mode. They do not increase our usage fee: that fee is charged per Call as §14 defines it — one request you make to the Service — however many model requests the Service makes behind it.

A note on how this is felt. The rate above is expressed as a share of Calls. Because evaluation deliberately runs candidate models against each other, its share of your Provider spend is materially higher than its share of your Call count, and can exceed the share of that spend attributable to the Outputs delivered to you. We state this because a figure quoted only as a percentage of Calls would understate what you pay your Providers.

Shared judging. We do not evaluate your Output in the same judge request as another customer’s, on any tier, today — no code path does this. On private, this is also unconditionally forbidden by the DPA. On free and shared_anon, the DPA’s shared-judging exception (DPA §4.2(c)) already permits it — that is a standing legal permission, not a description of current behavior.

We reserve the right to enable this on free and shared_anon only — never on private. We state the reservation now, ahead of building the capability to do it, so that you are not asked to re-accept these Terms once we do. If we do it, the judge sees Outputs and not your identity, and what is retained from the request is the Verdict, subject to §8 and §12.

Reviewing evaluations made on your own criteria. Where you set your own evaluation criteria for a Capability, its Verdicts are yours alone — they stop contributing to the cross-customer pool (§8) from that point on — and you can review them. For that purpose we keep a copy of each evaluated exchange on that Capability — what the judge was shown, the candidate Outputs and the Verdicts — for a review window you control, up to a maximum we publish in the console, and delete it when the window closes. The window opens automatically when you first set your own criteria; you may shorten it, including to nothing, at any time, and you cannot lengthen it past the published maximum. It applies to that Capability’s evaluations only and extends the retention of nothing else. On shared_anon and private it is the one case in which an evaluated Output outlives its delivery (§7.1). Note that on those tiers a judge grading a single Output is not shown your prompt, so the copy carries none; a comparison of several candidate Outputs is, and the copy carries what the judge saw.

12. Deletion, and what survives it

12.1 What we delete

On your verified request, and on closure of your Account, we erase the content we hold for you. Most of that is done by a single idempotent, automated operation, which blanks or deletes:

Because several of these tables are append-only by design, erasure is performed by overwriting fields rather than deleting rows. A blanked row no longer matches the erasure query, which is what makes the operation safe to re-run. The operation defaults to a dry run, refuses to run against our own operator Account, and is followed by a verification query whose report is available to you.

Erasure completes within 30 days of a verified request or of termination, and we issue a certificate identifying what was erased and what was retained under §12.2 and §12.3.

Before we erase, you get your data out. Following termination we give you at least 7 days’ written notice before erasure begins. On written request made before erasure begins, we will provide, within 14 days, a copy of your retained prompt text, model Outputs, Batch API input files, benchmark sets and Templates in a structured, machine-readable format; while such a request is outstanding we do not begin erasing, and the 30-day period is extended accordingly. This does not cover Provider Credentials or webhook signing secrets, which we do not export.

12.2 What is not reached by the automated erasure

We list these because the alternative is a promise we would break. These stores hold content and are not covered by the automated operation described above:

We make no warranty that your content is absent from the stores above. If you need any of them erased, contact us and we will treat it as a specific request rather than declining it — but we do not represent it as automatic.

12.3 What survives, and why — the asymmetry

We can delete your content. We cannot un-derive an Aggregate. This asymmetry is stated identically here and in the Privacy Policy; DPA §8.4 states it subject to the qualification below. It is not a hedge; it is a structural property.

These survive an erasure request by design:

• Verdicts, and the Aggregates computed from them. A Verdict is a fact about a model — “model X scored 0.72 on Capability Y” — computed across many contributors. Once a free or shared_anon Account’s Verdicts have been folded into the global pool, the pooled Aggregate cannot be un-derived: we can recompute the average without them, and will where erasure requires it, but the recomputed number is a new number. It does not undo routing decisions already made, models already retired, or rankings already published. Our erasure report counts these rows explicitly rather than silently omitting them. One qualification, and it now runs in your favour: a Verdict also carries the judge model’s written rationale, which is free text produced by a model that saw your Output and can therefore restate or quote part of it (“the answer omitted the revenue figure…”). Erasure blanks that rationale, on every tier. What survives a Verdict is the score, the failure mode and the counts — the numbers the comparison rests on — and no free text.
• Aggregate usage and billing records, retained for the period required by applicable tax and accounting law.
• Access and audit records, including the append-only record of every time one of your Provider Credentials was decrypted and by which subsystem.
• Consent records. The fact that you accepted a specific version of our terms on a specific date is itself the basis on which we processed your data. These records are append-only and survive Account closure; withdrawal is recorded as a new superseding record, never as an edit or a deletion. On erasure we purge the incidental metadata attached to them (IP address, user agent) and retain the fact of acceptance.

13. Security

Each of the following is a description of what the Service does, not an aspiration:

• Tenant isolation is enforced at the data-access layer: models are Account-scoped by default, so a cross-Account read cannot be written by accident — it requires an explicit escape. Across the packages that store customer content and the records derived from it, every such escape must appear in a reviewed allowlist that an automated test enforces, and both new entries and stale ones fail the test suite.
• Provider Credentials at rest: per-credential data key, AES-256-GCM, data key wrapped by a per-Account key-encryption key in a managed key vault, fail-closed decryption, no plaintext at rest (§5).
• API keys at rest: SHA-256 digest only; the raw token is unrecoverable.
• Webhook destinations are validated at registration as HTTPS-only and public-IP-resolving, as a server-side request forgery guard. Signing secrets are vaulted and shown once.
• Error reporting disables request-body capture, which is the mechanism by which a prompt would ordinarily reach an error event, and drops the entire local-variable set of every module that handles credentials or plaintext secrets. Local variables elsewhere are retained, because a stack trace without them is materially harder to diagnose; they are subject to the scrubbing below. Two composed scrubbing layers then redact secret-bearing fields and Provider-key, authorization and cookie headers. The scrubbing fails closed: a failure in scrubbing destroys the carriers or drops the event entirely.
• Retention decisions are enforced at one write chokepoint that fails closed on any unknown or unreadable tier.
• Content is not logged. Prompt variables, batch messages and content snippets are excluded from application logging by policy. This is a policy, not a mechanically enforced invariant. We do not warrant that content can never appear inside an exception message produced by an upstream component.

Security incidents. We will notify you at your Account email address within 72 hours of becoming aware of a breach leading to accidental or unlawful destruction, loss, alteration, or unauthorized disclosure of or access to your content, describing what we know and what we are doing. Our detection is alert-driven; we do not operate a continuously monitored security operations function, so the 72 hours run from our actual awareness. See DPA §10.

Audit and compliance information. On written request we will give you our then-current architecture and security documentation, the subprocessor register, and — for your own Account — the erasure certificate and verification-query report described in §12.1. On 30 days’ notice, and no more than once in any 12-month period, you may assess our compliance with the DPA at your own expense and during normal business hours, subject to confidentiality and without access to any other customer’s data; more often following a security incident affecting your content, or where you have a reasonable and documented belief that we are not complying. See DPA §13.

Two notices we owe you. We will tell you within five business days if we determine we can no longer meet our obligations under the DPA or applicable privacy law (DPA §4.5), and we will tell you if, in our reasonable opinion, one of your processing instructions infringes applicable privacy law (DPA §4.1).

What we do not have. We hold no SOC 2 Type II or ISO 27001 certification. We do not represent that we conduct third-party penetration testing, formal business-continuity or disaster-recovery testing, or that we maintain documented recovery point or recovery time objectives. We have not verified whether database-volume encryption at rest is enabled by our hosting provider — the encryption described above protects Provider Credentials specifically, not the datastore as a whole. We will publish any of these when they change.

14. Fees, quotas, subscriptions and cancellation

• Fees. Fees are those published in the Pricing Terms — a document that forms part of this agreement under §24 — or agreed in an order form. Fees are exclusive of taxes; you are responsible for taxes other than those on our net income. The rates themselves live in the Pricing Terms rather than here, so that a rate change is not a change to this agreement; the structure below is, and changing it requires a new version under §22.
• The Service is prepaid. You buy credit in advance and your usage draws it down. Credit is not a deposit; it is a prepayment for Service usage. Credit you have bought but not used is refundable on request, less the purchase fee, as the Pricing Terms describe; credit you have used is not. A fee applies to each credit purchase, at the percentage and minimum published in the Pricing Terms, and it is charged on the purchase, never on your usage. Credit expires twelve months after the date of purchase, and where you hold credit from more than one purchase the oldest is spent first.
• What your tier buys. The tier you subscribe to determines how your data is handled (§6, §8) and the support and availability commitments you receive (§15). It does not buy a volume of Calls, and no tier restricts how many Calls you may make. Where a tier carries a subscription fee, that fee is payable in advance for the subscription period; the free tier carries none.
• Every Call carries a per-Call fee, in both access modes. It is charged per Call — one request you make to the Service, as defined in §1 — at the published rate, which decreases in bands as your monthly volume rises. Each band’s rate applies only to the Calls that fall within it, so crossing a threshold never increases the cost of the Calls below it. Every Account has a monthly allowance of Calls carrying no per-Call fee. The fee does not depend on which access mode served the Call, and it is charged once for the request however many model requests we make behind it (§11).
• Operator-supplied usage (§5.2) additionally passes through the Provider’s charge, at cost. On top of the per-Call fee, we charge you what the Provider charges us for the model usage your Calls consume, at that Provider’s own published rates for the model, context tier and service tier your request actually used. We add no margin to that pass-through. The Pricing Terms state which figures appear on your invoice and how.
• In bring-your-own-key mode (§5.1) there is no pass-through, because your Provider bills you directly — including for the additional model requests described in §11. The per-Call fee above still applies.
• What we charge for, and what we do not. The per-Call fee is charged once, when a Call completes (§1); a failed Call carries no fee. In operator-supplied mode while a Capability is still exploring, the Provider’s charges for the Call’s model requests pass through whether or not the Call completed — we pass through what the Provider charged us, at cost (Pricing Terms §1.4). We do not charge a second fee for our own retries of a Call, or for the additional model requests the Service makes behind a single Call — including the fan-out and judge requests described in §11. In bring-your-own-key mode those reach you as Provider charges under §5 and §17; in operator-supplied mode they reach you as the pass-through described two bullets above, at cost.
• Payment. Fees and credit purchases are billed through Stripe. Card and bank details never reach our systems — they are entered directly in Stripe-hosted checkout.
• Automatic recharge is optional and off by default. You may set a balance threshold at which we purchase further credit on your stored payment method. Doing so requires your explicit authorisation for off-session charges, given separately from these Terms, and you may withdraw it at any time.
• Quotas. Your Account has rate limits — how many requests you may make per second, how many Capabilities you may create in a day, and how many control-plane changes you may make in an hour. They apply to the Account as a whole, however many API keys or members it has. These exist to bound runaway usage and to stop one Account crowding out another; they are not the product you are buying. Exceeding a limit returns an error rather than silently billing on. Unset limits mean unlimited. No tier carries a limit on how many Calls you may make, or a ceiling on what you may spend. Your Account does carry a monthly ceiling on credit purchases — a bound on payment exposure, set per Account and shown on the Billing page of the portal, as the Pricing Terms describe; it is not a limit on usage, and changing it is not a change to this agreement.
• Accounts without a payment method. You may open an Account and use the Service without supplying one, and on Calls served with your own provider credentials you may never need to: your Provider bills you directly. What a payment method is required for is prepaid credit, which is what pays for Calls we serve on our own credentials — without credit, those Calls are refused rather than accruing a debt.
• Past due. We follow the payment processor’s own retry schedule before treating a subscription as cancelled.
• No trial. Paid tiers have no trial period. The free tier is the trial.
• Cancellation. On cancellation your Account moves to the free tier’s limits and continues to work, and its data grant moves to the free tier’s grant at the same time (§6.1). From that point your future traffic is pooled traffic — a material consequence of cancelling a paid tier. Cancellation never re-classifies anything already written (§6.4) and never pools past Verdicts (§8.2).
• Refunds. Credit you have bought but not used is refundable on request, less the purchase fee, on the terms in the Pricing Terms. Fees already paid — the purchase fee, per-Call fees and any tier fee — are non-refundable except where required by law.

15. Availability and support

We publish a 99.5% monthly uptime target for the data plane.

This is a target, not a warranty. Version 1 of the Service carries no service credits and no financial remedy for missing it. Where our sales or pricing materials use the word “SLA”, it refers to this target and to the support commitments in the table below, and to nothing else.

First-response times are measured during support hours: 08:00–20:00 Pacific Time, Monday to Friday, excluding US public holidays. A request that arrives outside those hours starts its clock when they next open. “Next business day” means the next such day.

Where we publish this table anywhere other than in these Terms, we reproduce it verbatim rather than in paraphrase.

16. Warranties and disclaimers

Each party warrants that it has the authority to enter into these Terms.

Model Outputs are probabilistic. We do not warrant that any Output is accurate, complete, current, non-infringing or fit for any purpose, and we do not warrant that a given Capability will be routed to any particular model. You are responsible for reviewing Outputs before relying on them, and you must not use Outputs as the sole basis for decisions requiring professional judgment.

EXCEPT AS EXPRESSLY STATED IN THESE TERMS, THE SERVICE IS PROVIDED “AS IS” AND “AS AVAILABLE”, AND KAPUA LABS DISCLAIMS ALL WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. Some jurisdictions do not allow the exclusion of implied warranties; in those jurisdictions the exclusions apply to the fullest extent permitted.

We disclaim all responsibility for the acts and omissions of Providers whose services you access using your own Provider Credentials (§5).

17. Limitation of liability

NEITHER PARTY WILL BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, EXEMPLARY OR PUNITIVE DAMAGES, OR FOR LOST PROFITS, LOST REVENUE, LOST DATA OR BUSINESS INTERRUPTION, EVEN IF ADVISED OF THE POSSIBILITY.

EACH PARTY’S TOTAL AGGREGATE LIABILITY ARISING OUT OF OR RELATING TO THESE TERMS WILL NOT EXCEED THE AMOUNTS YOU PAID US FOR THE SERVICE IN THE TWELVE MONTHS PRECEDING THE EVENT GIVING RISE TO THE CLAIM. For an Account that has paid nothing, that amount is one hundred United States dollars (US$100).

These limits do not apply to: your payment obligations; either party’s indemnification obligations under §18; your breach of §4 (acceptable use); or liability that cannot be limited under applicable law.

Provider charges are not capped by this clause and are not our liability. Because the Service calls Providers using your own credentials, charges incurred at a Provider are billed to you by that Provider under your agreement with it. You are responsible for setting spend limits at the Provider. The quotas described in §14 are set by us, not by you; they bound runaway usage and are not a spend control you configure.

18. Indemnification

You will indemnify us against third-party claims arising from: your Customer Content; your use of the Service in breach of §4; your supply or use of a Provider Credential in breach of your agreement with that Provider or of your representations in §5; and your violation of applicable law.

We will indemnify you against third-party claims that the Service, as provided by us and used in accordance with these Terms, infringes that third party’s intellectual property rights. This does not cover claims arising from Customer Content, from Outputs, from a Provider’s own service, or from combinations of the Service with anything we did not supply.

The indemnified party must notify the indemnifying party promptly, allow it to control the defense, and cooperate reasonably. Neither party may settle a claim in a way that admits liability for or imposes obligations on the other without consent.

19. Confidentiality

Each party may receive non-public information of the other. The receiving party will protect it with at least reasonable care, use it only to perform under these Terms, and disclose it only to personnel and contractors bound by comparable obligations. These duties do not apply to information that is or becomes public without breach, was already known without duty of confidence, is independently developed, or is rightfully received from a third party. Disclosure compelled by law is permitted with prompt notice where lawful. Customer Content is your confidential information, subject to the rights you grant in §6 and §9.

20. Suspension and termination

By you. You may cancel your subscription at any time from the console. You may close your Account at any time by writing to us at the address in §25; we confirm the request with the Account owner before acting on it, because closure is irreversible and triggers the erasure described in §12. Closure is a confirmed request rather than a console action deliberately: a single click that destroys an Account’s data is not a control we are willing to put behind a session cookie.

By us. We may suspend your Account, in whole or in part, on notice where practicable, if: you breach §4; your use threatens the security, integrity or availability of the Service or of another customer; a Provider suspends or terminates the account behind your Provider Credentials; your payment is past due beyond the processor’s retry schedule; or the law requires it. We will limit any suspension in scope and duration to what the cause requires, and lift it when the cause is resolved.

Either party may terminate for the other’s material breach not cured within 30 days of written notice.

On termination, your right to use the Service ends, accrued fees become payable, §12 governs your data, and §§10, 16–19, 22 and 23 survive.

21. Export control and sanctions

You represent that you are not located in, organized under the laws of, or ordinarily resident in a country or territory subject to comprehensive United States sanctions, and that you are not on any United States restricted-party list. You will not use the Service in violation of export control or sanctions laws. Note that some Providers are established outside the United States, the EU and the UK, including in the People’s Republic of China; the Providers you enable, and the compliance consequences of enabling them, are your choice.

22. Changes to these Terms

These Terms are versioned by date (this version: 2026-09-14). We record your acceptance of a specific version. Accepting one version is not acceptance of the next: when we publish a new version, your prior acceptance no longer satisfies the current requirement and we ask again.

We publish a new version in the console, which shows at all times which version is current and whether your acceptance is up to date. A new version takes effect for you when you accept it. Until you accept it, we may restrict Account actions that require current consent; the rest of the Service continues to work, and nothing you have already done is undone.

We do not undertake to email you about a new version. That is deliberate, and it is the same position §14 takes on billing notices: a commitment to deliver mail turns an undeliverable mailbox or a transport failure into a breach of this agreement, for something the console states plainly and at any time. If you do not wish to accept a new version, you may close your Account under §20.

Exactly one version of each document kind is current at any time, and we record the URL of the published text alongside the version.

The DPA is amended differently. This section does not govern it: the Data Processing Agreement is amended under DPA §14.4, which on the free and shared_anon tiers permits amendment on 30 days’ notice, with a right to terminate the affected service without penalty if the amendment materially reduces the protections given to your content. Where the DPA has been executed by signature on the private tier, no amendment takes effect without your written agreement, except one strictly necessary to comply with a change in law.

23. Governing law and disputes

These Terms are governed by the laws of the State of Wyoming, United States, without regard to its conflict-of-laws rules. The United Nations Convention on Contracts for the International Sale of Goods does not apply.

The parties will attempt in good faith to resolve any dispute by negotiation for 30 days after written notice. Any dispute not so resolved will be brought exclusively in the state or federal courts located in Wyoming, and each party consents to personal jurisdiction and venue there. Either party may seek injunctive relief in any court of competent jurisdiction to protect its intellectual property or confidential information.

Nothing in this section deprives a consumer of the protection of mandatory provisions of the law of their country of habitual residence.

24. General

• Assignment. Neither party may assign these Terms without the other’s consent, except to a successor in a merger, acquisition or sale of substantially all assets, on notice.
• Force majeure. Neither party is liable for delay or failure caused by events beyond its reasonable control, excluding payment obligations. A Provider outage is such an event.
• Independent contractors. The parties are independent contractors. Nothing creates a partnership, agency (except as expressly described in §5 in respect of Provider Credentials), joint venture or employment relationship.
• No third-party beneficiaries.
• Severability. If a provision is unenforceable, it is modified to the minimum extent necessary and the rest remains in force.
• Waiver. A failure to enforce is not a waiver.
• Entire agreement. These Terms, the Data Processing Agreement, the Privacy Policy, the Pricing Terms, the per-tier data_grant document you accepted, and any order form are the entire agreement, and supersede prior discussions. In a conflict: a negotiated data processing agreement executed by both parties prevails over the standard DPA; the DPA prevails over these Terms in respect of the processing of Customer Content; an executed order form prevails over these Terms; these Terms prevail over the Pricing Terms on matters other than the rates and charging mechanics the Pricing Terms exist to state; and these Terms prevail over the Privacy Policy on matters of contractual right.
• Notices. Notices to you go to the email address on your Account. Notices to us go to the address in §25.

25. Contact

KAPUA Labs LLC 30 N Gould St Ste R Sheridan, WY 82801 United States

General and legal notices: llmbench@kapualabs.com Support requests: support@kapualabs.com Privacy and data requests: privacy@kapualabs.com

Version 2026-09-14. Prepared by KAPUA Labs LLC. Every factual statement about the Service’s behavior in this document was verified against the running system on 2026-09-07, the §3 and §12.2 amendments of 2026-09-10 on that date, and the retention amendments carried by this version (§6, §7, §9, §11, §12: delivery-bound Output retention on shared_anon and private, the bounded one-time Template evaluation and the customer’s Template delete, the evaluation review window, and the erasure of Template text) on 2026-09-14, as were the §14 amendments (refunds of unused credit; the per-Account purchase ceiling). It describes the Service as built on those dates, not as planned.