Pricing Terms

KAPUA Labs LLC, doing business as Fronset — Fronset inference and evaluation API

Version 2026-10-10 · Last updated 10 October 2026

These terms describe what you are charged and why. They are the Pricing Terms named in Terms of Service §14 and listed in §24’s entire-agreement clause, and they form part of that agreement. Where these terms and the Terms of Service differ on anything other than rates and charging mechanics, the Terms of Service govern.

They are written to be read, not skimmed.

1. No markup on inference

You pay the same rate for model usage as you would pay the provider directly. We do not add a percentage to token prices, and we do not adjust the token counts we bill you for.

When you make a request, we record the tokens the provider reports — input, output, cached input and cache creation — and charge them at that provider’s published rate for the model, context tier and service tier the request actually used. Your invoice shows those figures per model.

We make no money on the inference pass-through itself. Our revenue is the per-call fee in §3 — which applies to every call, on both access modes — and the credit-purchase fee in §2. Where a request to one of our tasks is billed at a published rate of ours instead of the pass-through, §1.3 says how that rate is set — from what the work costs us, aiming at no markup — and how it is corrected when the estimate behind it turns out to be wrong. A task of your own — one you created, or a copy you made of one of ours — is never on a published rate. A published rate covers the model calls that produce your answer and the evaluation calls that grade them; any further exploration on a request billed at that rate is ours.

1.1 What “the same rate” means precisely

Provider prices vary by more than the model name, and we bill the rate that applied to your specific request. Input and output tokens are priced separately, at the provider’s own rates for each — as are cached input, cache-creation and reasoning tokens where the provider distinguishes them, and every other category the provider bills. Your invoice shows each separately rather than as one blended figure.

The other axes we bill on:

• Context tier. Several providers charge more above an input-size threshold. You are billed at the tier your request’s input token count fell into.
• Service tier. Batch requests are billed at the provider’s batch rate, which is lower than the synchronous rate.
• Time of day. One provider we route to prices some hours differently. You are billed at the multiplier in force when your request ran, not when it was invoiced.
• Cached, cache-creation and reasoning tokens are billed at their own rates where the provider distinguishes them.

Every one of these appears on your invoice as its own line, so you can see which rate applied and why.

1.2 What you are billed for when a task is charged at cost

A request is charged at cost — every model call in the chain on your invoice, per model — whenever it is not billed at a published rate of ours: while one of our tasks is still being measured, and always on a task of your own. Some tasks run more than one model while we establish which performs best for that task — this is how the benchmark is produced. Every model call in the chain of a request charged at cost appears on your invoice, per model. That includes calls whose output was not returned to you: alternatives, and the evaluation calls that compare them. It also includes calls that failed, and our own retries after a provider error — the provider billed those to us, so at cost they reach you too.

We show this rather than averaging it away, so you can see what you paid for. Once a request to one of our tasks is billed at a published rate, you are billed that rate instead and further exploration is ours to fund. On the private plan a task’s evidence is your Account’s own, so it reaches its published rate when your own evidence has matured.

1.3 How a published rate is set, and when it changes

For tasks where we publish our own rate rather than passing a provider’s through, that rate is set from measured cost: what the model calls behind that task have actually cost us, at the providers’ own prices, over the requests we have measured. It is set by a person, not by a job. An estimate is produced from that measurement, reviewed, and released deliberately; nothing reaches your bill because a background process recalculated something. The input a published rate is charged on includes the task’s own template, not only the variables you send.

A published rate aims at cost, with no markup. We do not set one to earn money on the model usage behind it — as everywhere else in these terms, our revenue is the per-call fee (§3) and the credit-purchase fee (§2). But a published rate is a prediction: it is set from what the work has cost so far and charged on the work that follows, and a prediction can miss in either direction. Provider prices move, a different model may come to serve the task, and measurement lags what it measures. So we do not promise that a published rate equals cost at every instant, and we do not claim that it can never exceed what the same work would have cost at the provider’s own price.

What we promise is to keep measuring, and to correct. We compare the cost behind every published rate with what that rate is charging, on an ongoing basis. Where the prediction proves too low — the work costs more than the rate recovers — the rate goes up. Where it proves too high — a provider cut its prices, a cheaper model now serves the task as well, or the estimate overshot — the rate comes down. The correction runs in both directions, and by the same procedure as the original: a person reviews the measurement and releases a new rate.

A published rate is effective-dated and never edited in place. Changing one creates a new rate from a future date; usage already billed is never restated, in either direction. Which tasks are on a published rate, the current rate for each, and every change to one are published in the portal and through the API, each rate with the date from which it applies.

Published rates exist only for our tasks. A change you make to how one of our tasks is measured is never made to it: made explicitly, it creates a task of your own, which is charged at cost; our task and its published rate are unchanged (Terms §2.1). Some settings of ours cannot be changed at all.

1.4 Failed requests and retries: the rule differs by mode

A request can fail, and a model call inside it can error and be retried. Whether either reaches your invoice depends on how that task is charged, so each of the three charging modes states its own rule rather than sharing one.

A task on a published rate (§1.3). A request that failed (Terms §1) is not billed — no token charge and no per-call fee. A retry after a provider error is ours, and so are the alternatives and evaluation calls. A published rate is one blended figure set from measured cost, so we carry that variance instead of itemising it to you.

A request charged at cost (§1.2). This mode is billed at cost, and at cost means what the provider billed us — so it includes the model calls that did not work. Failed attempts, our retries after a provider error, the alternatives we try alongside the one we return and the evaluation calls that compare them all appear on your invoice. The per-call fee in §3 is charged on top, once, when the request completes.

A request of yours that failed (Terms §1) carries no per-call fee. Its pass-through still appears: the rule in this mode is what the provider billed us, and a provider bills for a model call whether or not we accepted its output. That includes a call whose output failed our format checks, and every call behind a request that never completed.

Your own keys (§3.2). We charge the per-call fee and nothing else, and only for a request that completed — a request of yours that failed carries no fee from us. What your provider charges you is a separate matter, and it is not limited in this way: see §3.2.

Our internal traffic is never on your invoice, in any mode. We are a customer of our own API; that usage is billed to us, not distributed across yours.

2. Credit purchases

Fronset is prepaid. You buy credit, and usage draws it down.

A fee of 5.5% applies to each credit purchase, with a minimum of $0.80.

The fee covers payment processing and account servicing. It is charged on the purchase, never on your usage — which is what allows §1 to be true.

The minimum binds on purchases below $14.55; above that the percentage governs. The two are never added together.

When you buy credit by bank transfer, the same fee applies and is taken from the amount we receive (§2.4).

2.1 Credit is valid for 12 months

Credit expires 12 months after the date you buy it. Where you hold credit from more than one purchase, the oldest is always spent first, so a balance you keep using does not expire underneath you.

2.2 Automatic recharge is optional and off by default

You may set a balance threshold and a recharge amount, in which case we purchase credit on your stored payment method when your balance falls to that threshold. Doing so requires your explicit authorisation for off-session charges, set out separately from these terms in the Off-session payment mandate — turning automatic recharge on is how you give that authorisation, and turning it off withdraws it. It is off unless you turn it on, and you can turn it off at any time.

Each automatic recharge carries the same purchase fee as any other credit purchase, so the sum charged to your card is the recharge amount plus that fee. Three limits bind it: the per-purchase range in §2.3 ($500 is the most any single charge may be), your recharge amount must be at least twice your threshold, and your Account’s monthly ceiling on credit purchases by card (§2.3), which counts automatic and manual card purchases together. You may set a lower daily limit of your own. Reaching a limit stops the charge; it never produces a larger or a deferred one.

If your card is declined, we do not present it again for that recharge. No credit is added and nothing further is charged. A declined card is not re-presented repeatedly — that is how a card issuer locks a card out. Where a payment fails for a reason that is not a decline — the processor was unavailable, or returned a temporary error — it may be attempted again a small number of times over the following days.

We do not send you a message when this happens, and the reason for a particular failure is not always recorded on your account. Where it is, it is readable in your billing settings. If you rely on automatic recharge, check your balance rather than waiting to be told.

2.3 Purchase limits, and refunds of unused credit

Each credit purchase by card is between $5 and $500, whether you make it yourself or automatic recharge makes it for you. A purchase by bank transfer has its own limits (§2.4).

Your Account carries a monthly ceiling on credit purchases by card, counting automatic and manual card purchases together. Purchases by bank transfer do not count toward it. The ceiling is set per Account: it bounds payment exposure while an Account is new, and it is not a limit on how much of the Service you may use — Terms of Service §14 says no tier carries one. Your Account’s ceiling is shown on the Billing page of the portal, which also says how to have it raised. Reaching it stops the purchase; it never produces a larger or a deferred one. A change to your Account’s ceiling takes effect at once and is not an amendment of these terms.

Credit you have bought but not used is refundable. Ask us at the address in Terms of Service §25. We refund to the payment method that bought the credit — the card, or for credit bought by bank transfer the bank account that sent it (§2.4) — less the purchase fee, once any work in flight on your Account has settled — and with automatic recharge turned off first, so the refund is not immediately bought back. We process a refund within 14 days of the request; a refund to a bank account reaches you once you have given us, or our payment processor, any account details it needs. Credit that has been used is not refundable: the usage records on your Account are the evidence of what was delivered. Expired credit (§2.1) is not restored.

2.4 Buying credit by bank transfer

Where bank transfer is offered for your Account, you may buy credit by sending US dollars from your bank to a bank account our payment processor, Stripe, holds for you. Once you turn bank transfer on, the Billing page of the portal shows that account’s details. It accepts ACH credits, domestic wires and international wires in US dollars. Nothing can be charged through it: money moves only when your bank sends it.

The fee is the one in §2, taken from the amount we receive. We treat the amount that reaches us as the total you pay, fee included, and add the credit that total buys. Where that does not come to a whole number of cents, we round in your favour. Banks that handle a transfer, including intermediary banks on an international wire, may deduct their own charges before it reaches us; your credit is calculated on what arrives.

Limits. A purchase by bank transfer is at least $500 received. A smaller transfer is held, not credited, until further transfers bring the total to $500, and is then bought together with them. There is no upper limit, but a transfer above the amount shown on the Billing page is credited after we have reviewed it. Purchases by bank transfer do not count toward your Account’s monthly ceiling (§2.3).

When credit is added. Credit is added once the transfer can no longer be reversed by the bank that sent it. For a wire, that is when it reaches us. For an ACH credit, it is after the number of business days shown on the Billing page, because the sending bank can reverse an ACH credit for a period after it arrives. Credit bought by bank transfer is bought, for §2.1, on the day it is added.

Send from an account in your name. When you turn bank transfer on, you tell us the name of the account holder you will send from. A transfer from an account in another name is held until we have confirmed with you that it is yours to spend. We may also hold a transfer we have other reason to review, and credit it when the review is complete.

Money we cannot credit is returned to the account that sent it. That covers a transfer below the minimum that later transfers do not make up, a transfer from another name that is not confirmed, and money that arrives after your Account has closed. A bank that handles the return may deduct its own charge.

If a transfer is reversed after we have added its credit, we remove that credit from your balance. If any of it has already been used, your Account owes the amount used.

Refunds. Unused credit bought by bank transfer is refundable as §2.3 describes, less the purchase fee, and only to the bank account that sent the transfer, held in the name that sent it. Where we or Stripe need that account’s details to make the refund, the money reaches you once you have given them.

Buying credit by bank transfer does not change automatic recharge (§2.2): if it is on, it still buys credit on your card when your balance reaches its threshold.

3. The per-call fee

Every call carries a per-call fee, whichever access mode served it. It does not matter whether we supplied the model access (§1) or you supplied the provider credential (§3.2) — the fee is the same, and it is charged once for the request however many model calls we make behind it.

What differs between the modes is only who pays the provider for the tokens: we do in the operator-supplied mode — the mode the service, the portal and the documentation call managed (Terms of Service §1 and §5.2) — and pass that through at cost under §1; you do in bring-your-own-key mode, directly. If you bring your own keys, read §3.2 — your provider bills you for every model call we make on your behalf, not only the one that produced your answer.

The per-call fee is graduated, and identical on every plan:

The bands are marginal: calls in each band are charged at that band’s rate, so crossing a threshold never increases the cost of the calls below it.

3.1 What counts as a call

One request you make is one call, regardless of how many model calls we make to serve it. Exploration alternatives, evaluation calls and our own retries never add a call — they are further model calls inside the one request, not further requests. A batch of 10,000 items is 10,000 calls; submitting it is not.

A request that failed carries no fee, in any mode. We charge for a call once, when it completes — a request completes when a model returned an output and it passed our format checks (Terms §1); a request that failed is not a completion. §1.4 states what the pass-through does in each mode.

That is how our fee is counted. It is not what your provider counts — see §3.2.

3.2 Bring your own keys: your provider bills you for the whole chain, not only the answer

Every model call we make to serve your request runs on your keys, and your provider bills you for all of them. That includes calls whose output you never see: the alternatives we try alongside the one we return, and the evaluation calls that compare them. It includes repairs when a model returns malformed output, and our own retries after a provider error.

We charge one per-call fee for the request. Your provider charges for the work.

A single request against a task that is still exploring can therefore look like this on the two bills:

§1.4’s rule for this mode is about our invoice only. A failed request and a retry cost you nothing from us; if your keys served them, your provider still charged for them.

Who decides how much runs. On one of our tasks we decide how many alternatives run and which judge evaluates them, by the rule below; they run on your keys, and if your keys can run no judge model the request is not evaluated and no alternatives run. To change that for a task, make a copy of your own (Terms §2.1). On a task of your own, exploration is yours to set: you can turn it off for a single request or for the task as a whole. With it off there are no alternatives and no evaluation calls, so your request runs one model — though a retry after a provider error, or a repair of malformed output, can still add a call.

Work we schedule for ourselves is never billed to you. Separately from your requests, we run comparisons of our own to produce the public benchmark; those never run on your keys. If we re-evaluate one of your requests ourselves, the evaluation runs on the same credentials as the request — on your keys in bring-your-own-key mode, where your provider bills you for it — and we never charge you for it.

We hold the chain to what the measurement needs. When alternatives do run, we do not run every model eligible for the task. We choose them by what would actually improve the comparison — favouring the models we have least evidence about, and weighing what each one costs — so the chain is a fraction of the eligible set rather than all of it. This is the same rule we apply when we are paying, and we do not widen it because you are.

And a failure never widens the chain. If the machinery that chooses the alternatives cannot run, we serve your request with one model rather than falling back to running all of them.

4. Plans

Your plan determines privacy and support, not your usage rates. Every plan pays the same rates in §1 and the same fees in §2 and §3.

5. Changes

We will publish a change to these terms before it takes effect. A change to a provider’s own rates reaches you as it reaches us, because §1 passes those rates through — that is not a change to these terms. Nor is a change to a rate we publish ourselves under §1.3: those are set, corrected and announced as §1.3 describes, in the portal and through the API.

6. Questions

Billing questions: support@fronset.ai

Version 2026-10-10. Published by KAPUA Labs LLC, doing business as Fronset, as part of the Terms of Service (§24). This version supersedes 2026-10-03: it adds buying credit by bank transfer (§2.4), limits the per-purchase range and the monthly ceiling in §2.3 to purchases by card, and says where a refund of credit bought by bank transfer goes (§2.3, §2.4). No rate or fee changed.