Which pricing models can Credyt bill customers across?

Updated

Credyt is built to bill customers across per-token, per-request, per-seat, and per-output pricing, and to let you mix or change those models over time. It does this by streaming the real cost of each API call, model, and customer in real time, then checking a customer's balance before usage is authorized rather than after an invoice is generated. That combination is what makes usage-based and hybrid pricing practical: you can see what a user costs you as it happens and block the action when the balance is insufficient.

The four models Credyt names

Credyt's own framing of the problem lists the choice AI builders face: charge per token, per request, per seat, or per output. Its stated capability is to "bill your customers across every pricing model you use today or might use tomorrow." In practice that means:

Model What the customer pays for Where Credyt's real-time cost data matters
Per token Volume of model tokens consumed Token cost is the dominant variable cost, so per-token billing needs per-call cost visibility
Per request Each API or app call Each call has a real cost; billing per request only works if you know that cost
Per seat Named users or accounts Seat pricing is flat per user, so per-customer cost attribution tells you whether each seat is profitable
Per output A delivered result (summary, image, analysis) Output pricing hides variable model cost behind a fixed price, so margin depends on knowing cost per output

The page does not publish rate cards or a feature matrix mapping each model to specific configuration steps. What it does state is the design intent: support the models you use now and the ones you might adopt later, without a rebuild.

Why mixing and changing models is the real requirement

Most AI products do not settle on one model on day one. The page describes the common starting state directly: "You built something people use. But you don't know whether to charge per token, per request, per seat, or per output. So you're either not charging at all, or you slapped on a flat fee that has nothing to do with usage."

That flat fee is the failure mode Credyt is positioned against. A flat fee decouples revenue from the cost of serving each user, which the page frames as either leaving money on the table or burning it. Supporting multiple models matters because it lets you start with something simple and move toward usage-aligned pricing as you learn your cost structure — rather than being locked into the first model you shipped.

The mechanism: cost in, balance check, bill out

Credyt describes three connected capabilities, and the pricing-model question depends on all three:

  • Observe. Real-time cost streaming for every API call, every model, every customer. The page's example event log shows individual calls with model and cost — for instance a contract analysis on gpt-5.2 at $0.0187, a document summary on claude-4-opus at $0.0412, a chat response at $0.0029. The point is that you know what each user costs "not at month end, but as it happens."
  • Control. Hard budget ceilings per customer, per agent, per team. Credyt checks the balance before usage is authorized; if the balance is insufficient, the action is blocked. The page's claim is "no threshold overruns."
  • Bill. Charge customers across the pricing models above, using the same real-time cost and balance data.

The order matters. Per-token and per-output billing are only safe if you can see cost as it accrues; per-seat and per-request billing are only profitable if you can attribute cost per customer. The page's example of the risk: "Customer A generates $5K/month but costs you $6K in compute" — scaling losses and calling it growth.

A concrete example of the decision

Suppose you ship an AI document-analysis tool. Early on you charge a flat monthly fee because you don't know your cost per document. Under Credyt's framing, that flat fee is the problem: heavy users may cost more than they pay, and light users subsidize them invisibly.

With per-customer cost attribution, you can see that a document summary on one model costs roughly $0.04 per call while a compliance check on another costs roughly $0.03. That gives you the numbers to choose: bill per output (per document analyzed) at a price above measured cost, or bill per token and pass through the variable cost, or keep seats but set a hard ceiling per customer so no account can run past its budget. The page does not prescribe which to pick — the choice depends on your margin target and how predictable your customers' usage is.

What to verify before committing

The page supports the following claims, and these are the things worth confirming for your own setup:

  • Whether all four models can be combined in a single customer's plan, or whether mixing is limited to plan-level changes over time. The page says "every pricing model you use today or might use tomorrow" but does not detail per-customer mixed billing.
  • How the pre-authorization balance check behaves for each model — for per-seat pricing, for example, the check applies to usage beyond the seat, which the page does not spell out.
  • Pricing. The site lists "Pricing $1 per active wallet," and the page offers "Start for free." Treat the free start as an entry point to evaluate, not as confirmation that production usage is free; confirm current terms on the pricing page.

The team background is offered as a reason to trust the infrastructure: the page states Credyt's team comes from Visa, Checkout.com, TrueLayer, and SumUp, and built monetization infrastructure at scale. That is context for reliability, not a substitute for testing the billing behavior against your own usage patterns.