How Generation API Billing Works: The Three Pricing Units

A generation API rate card gives you a unit price. That is not always enough to tell you what a request will cost.

To get from the published rate to the final charge, you need three things:

1. The rate — what one billable unit costs.
2. The meter — how many of those units the execution used.
3. Settlement — what is actually charged when the run finishes.

This is where labels such as per generation, per second, and per megapixel become less obvious than they look. “Per generation” might mean one execution, one output, or another model-defined unit. “Per second” might mean generated media duration or actual execution time. A megapixel-priced model still needs rules for rounding, multiple outputs, and which pixels count.

Failures add another layer. A run can consume measurable resources and still settle at zero if the billing policy says that failure class is not chargeable.

Billing method	What may be counted	Basic calculation	What you must verify
Per generation	Execution, output, or generation block	units × rate	What counts as one generation?
Per second	Media duration or execution time	billed seconds × rate	Which seconds are billable?
Per megapixel	Billed pixel quantity	billed MP × rate	Which pixels count, and how are they rounded?

These are common billing mechanisms, not an exhaustive list. The label tells you the rate unit; the API contract tells you how that unit is measured.

This article is about those mechanics, not about which model is cheapest.

Rate, meter, and settlement are different things

A lot of billing confusion comes from using “price” for three separate concepts.

Rate: what one unit costs

A model might be described as:

$R per generation

or:

$R per second

or:

$R per megapixel

That gives you the rate. You still need to know how the API decides how many units the run used.

A per-second rate needs a definition of which seconds count. A per-megapixel rate needs a rule for billed megapixels. A per-generation rate needs a definition of one generation.

The current each::labs pricing page makes the same distinction useful in practice: inference cost can depend on inputs such as duration, resolution, and other model-specific parameters. A public estimate helps you plan, but it does not replace the settled cost of an actual execution.

Meter: what the execution counted

The meter records the billable quantity.

Depending on the model or engine, that might be:

• number of outputs;
• generated media duration;
• processing time;
• image or video pixel quantity;
• another model-specific unit.

Two APIs can both say “per second” and mean different things.

One might count eight seconds because the generated clip is eight seconds long. Another might record eight billed seconds because an operation ran for 7.3 seconds and the billing rule rounds upward.

Same wording, different meter.

Settlement: what becomes a charge

Settlement happens after the execution outcome is known. Under the current each::labs Terms, an Execution is charged when it finishes.

rate
  +
metered quantity
  +
execution outcome
  =
settled charge

Suppose an engine records 14 seconds of compute before failing. The run can still have a meaningful internal usage meter. If that failure class is non-billable, however, the customer-facing charge can settle at zero.

That is why metered usage and settled cost are not interchangeable.

On each::api, the prediction response exposes the run cost as metrics.cost. Successful predictions on metered engines can expose additional counters showing what was billed.

Per generation: first define the unit

“Per generation” sounds simple because the unit is expressed as a count rather than time or pixels.

The difficulty is that “generation” is not a universal API primitive.

Depending on the model contract, one billable generation could mean:

• one execution;
• one returned image;
• one output in a multi-output request;
• one defined generation block;
• another model-specific unit.

Take a purely illustrative model that bills per returned output. If one request asks for three outputs:

3 billable outputs × R per output = 3R

One HTTP request produced three billable units.

So this is not a safe default:

1 POST request = 1 billed generation

It might be true for a particular model. The transport layer does not guarantee it.

Parameters can change the charge

Multi-output generation is the obvious case, but not the only one.

A model may expose settings such as:

• number of outputs;
• generation mode;
• quality tier;
• resolution;
• duration;
• other model-specific controls.

Those parameters can change the number of billable units, the applicable rate, or both.

The model's current cost definition matters more than the shape of the request.

This is also why an estimate shown before execution and the final cost returned after execution serve different jobs. The estimate helps you plan. metrics.cost tells you what settled.

Per second: which seconds?

This is the most important question in any per-second billing model.

“Per second” can refer to:

• generated output duration;
• input or reference-media duration;
• active execution time;
• another explicitly defined interval.

Those numbers can diverge sharply for the same job.

A video request might wait in a queue, execute for 12 seconds, produce a five-second clip, then spend more time uploading the result.

Which number belongs in the billing formula?

The rate card has to define that.

Output-duration billing

One common model bills against generated media duration:

generated seconds × rate per second

If the rate stays the same, a ten-second output contains twice the duration units of a five-second output.

Even that apparently simple formula can have additional rules around resolution, tiers, minimum duration, or permitted clip lengths. “Per second” tells you the primary unit, not necessarily the whole contract.

Execution-time billing

Execution-time billing uses a different clock: how long an operation actually runs.

The each::labs Video API billing documentation gives a concrete example. Its current compute meter uses:

billed_seconds =
  min(
    max(ceil(execution_wall_seconds), 5),
    3600
  )

That formula has three notable rules:

• actual media-command execution wall time is measured;
• the time is rounded up to whole seconds, with a five-second floor;
• the meter is capped at 3,600 seconds.

The meter here is not generated clip duration. It is execution wall time for the media operation.

The rest of the prediction lifecycle is separate. Under the current Video API contract, staging, queueing, and artifact upload are not included in billed_seconds.

So end-to-end latency and billed execution time can be very different numbers.

Runtime is not automatically billed time

A single job can expose several time measurements:

Time quantity	What it represents	Automatically billable?
Queue time	Waiting before execution starts	No
Execution time	Time the operation is running	Depends on the API
Output duration	Length of generated or processed media	Depends on the API
End-to-end latency	Full request lifecycle	No

If monitoring says a job took 18 seconds end to end, multiplying 18 × per-second rate is only valid if the billing contract defines end-to-end latency as the meter.

Likewise, metrics.predict_time should not be treated as billed time by default.

If the engine returns a billing-specific field such as billed_seconds, use that field.

A per-second rate is only useful once you know which clock it measures.

Per megapixel: the geometry is the easy part

Physical megapixels are straightforward:

physical megapixels = width × height / 1,000,000

A 2048 × 2048 image contains:

2048 × 2048
= 4,194,304 pixels
≈ 4.19 megapixels

That gives you the physical image size.

It does not necessarily give you the billable quantity.

Billed megapixels can follow extra rules

A model contract can add rules such as:

• round megapixels upward;
• apply a minimum billable quantity;
• bill each output separately;
• count input and output pixels differently;
• apply different rates in different modes.

Current generation-model contracts do use rules like these. Some per-megapixel models, for example, explicitly apply ceiling rounding.

So this:

width × height / 1,000,000 × rate

is only the final billing formula when the contract says the exact physical megapixel count is the billed quantity.

The pixel calculation is geometry. Billing begins with the rules applied after that.

Multiple outputs can multiply the billed quantity

For a model that bills output megapixels separately, a possible formula is:

billed MP per output × number of outputs × rate

That formula is only valid when the model contract defines the units that way.

When you encounter per-megapixel pricing, check:

1. Which media is counted?
2. How are pixels converted into billed megapixels?
3. Is there a rounding rule or minimum?
4. Are multiple outputs billed independently?
5. Can another parameter change the rate?

After that, the arithmetic is usually trivial.

What happens when a generation fails?

On each::labs, canceled Executions are not charged, and errored Executions are not charged by default. A Model can be an exception when its underlying Provider charges for failed requests; the current Terms say those error charges are identified in the Documentation. Video API provides a more detailed beta example: compute can be internally metered even when a non-successful prediction ultimately settles at metrics.cost: 0.

A request can fail before compute begins, during provider execution, after measurable resources have been consumed, or as part of a cancellation. Those cases do not have to settle the same way.

Rejected before execution

If a request is rejected before execution starts, there may be no generation work to bill.

The current Video API billing documentation explicitly lists invalid requests and pre-compute input rejections as zero-cost outcomes.

That is different from an execution that starts and then errors.

Both look unsuccessful from the application side. Operationally, they are different events.

Canceled executions

The current each::labs Terms of Service state that canceled Executions are not charged.

There is still an infrastructure distinction underneath that policy. Marking a prediction canceled does not necessarily stop already-running work immediately. The current Video API documentation describes cancellation as record-only: upstream work can continue even though the prediction settles as canceled.

For the customer, the settlement rule determines the charge.

For the infrastructure, work may still have happened.

Errored executions

The current each::labs Terms state that errored Executions are not charged by default.

There is one exception: if the underlying Provider charges for failed requests, a Model can carry an error charge. The Terms say those exceptions are identified with the error charge in the Documentation.

That means neither of these assumptions is safe:

HTTP error = free

compute started = charged

The execution contract determines settlement.

Video API makes meter versus settlement visible

The current Video API is a useful worked example because the distinction is unusually explicit.

During the beta, a compute failure can accumulate internally metered execution time. Every current non-successful Video API prediction still settles at:

metrics.cost: 0

The engine can therefore record that execution happened while the customer-facing billing system settles the charge at zero.

There is an observability wrinkle: failed Video API predictions do not return billed_seconds, output_gb, or tier. They return cost and predict_time; the failed-compute meter stays internal.

The documentation also warns developers not to depend on failed compute remaining free. That beta policy may change with notice.

A bad output is not the same as a failed execution

A generation can succeed technically, return a valid artifact, and settle normally while the user dislikes the result.

That matters for product economics, but it is not an API failure.

Keeping those concepts separate prevents a lot of muddled cost analysis later.

Retrying starts another billing decision

A common failure-handling bug is to resubmit a generation when the application really meant to recover the state of the existing one.

Polling and resubmitting are different operations.

What happened to this execution?

Resubmitting asks:

Run another execution.

The second execution has its own meter, terminal state, and settlement.

The current Video API documentation says prediction submits are not deduplicated. Retrying the submit creates a second, separately billed job.

If the goal is status recovery, persist the returned prediction ID and poll it.

This is one of the places where ordinary HTTP habits stop transferring cleanly to generation APIs. Retrying an idempotent read asks for the same information again. Retrying a paid, nondeterministic generation asks the system to generate another artifact.

Canberk Sinangil, Co-founder & CTO: “A retry here isn't a retry — it's a second purchase of a different product.”

That is not an argument against retries. It is an argument for making resubmission an explicit product and billing decision rather than a generic networking reflex.

How to verify what one run actually cost

Estimates matter before execution.

After execution, inspect the run.

The current each::api Get Prediction endpoint is:

GET /v1/prediction/{id}

Its response exposes a metrics object containing the run cost:

{
  "metrics": {
    "predict_time": 12.5,
    "cost": 0.05
  }
}

metrics.cost is the value to retain for the settled cost of that prediction.

A public estimate tells you what a run may cost. metrics.cost tells you what this one cost.

Successful metered predictions expose more detail

A successful Video API prediction can additionally contain billing-specific fields:

{
  "metrics": {
    "predict_time": 8.2,
    "cost": 0.0105,
    "tier": "cpu",
    "billed_seconds": 7,
    "output_gb": 0
  }
}

The predict_time value above is illustrative. The billing values are consistent with the current Video API compute formula for a seven-second billed execution whose output is zero GB in this example.

Each field answers a different question:

• cost — what settled;
• billed_seconds — the compute quantity used by the meter;
• output_gb — output size recorded by the metered engine;
• tier — the compute-tier value recorded in the response.

For the current Video API, shared cpu is the active compute infrastructure, and the legacy request-side tier field does not need to be sent.

If a charge looks surprising, this gives you something concrete to inspect. Instead of reconstructing the bill from total latency, you can look at the rate, the meter, and the settled cost separately.

Instrument the execution, not only the account

Canberk’s production rule: “Instrument the outcome, not the response.”

For billing, that means keeping enough execution-level context to explain one prediction later.

That can include:

• prediction ID;
• submitted model/request context;
• terminal state;
• relevant timing;
• settled run cost.

Aggregate billing tells you how much moved. Execution telemetry tells you why.

That becomes useful when a retry creates another execution or when someone needs to reconcile one generation without reverse-engineering the account total.

Account balance answers a different question

The current organization balance endpoint is:

GET /v1/billing/balance

using Bearer authentication.

It returns:

{
  "balance_usd": 53.475
}

balance_usd is the authenticated organization's current USD balance. Zero and negative values are valid, and fractional-cent source precision is preserved.

The balance endpoint tells you where the organization stands. It does not replace per-execution telemetry.

Balance reads are eventually consistent with top-ups and have no fixed refresh-time guarantee. A 503 from this endpoint must not be interpreted as a zero balance.

The two read paths answer different questions:

GET /v1/prediction/{id} → what happened to this execution and what it cost
GET /v1/billing/balance → where the organization balance stands

A useful reconciliation path is:

submit
  ↓
prediction ID
  ↓
execution
  ↓
meter
  ↓
terminal state
  ↓
metrics.cost
  ↓
organization balance

The prediction ID identifies the execution. The meter shows what quantity was counted when the engine exposes it. The terminal state tells you how the run ended. metrics.cost tells you what settled. The balance tells you the account-level result.

If you keep only the final balance, most of the explanation disappears.

A practical checklist before you estimate a generation bill

Before turning a public rate into a production cost estimate, answer these questions.

1. What is the billing unit?

Is the model billed per output, per execution, per second, per megapixel, or by another unit?

2. What exactly counts toward that unit?

If the rate is per second, which seconds?

If it is per megapixel, which pixels?

If it is per generation, what defines one generation?

3. Are there rounding rules, floors, ceilings, or tiers?

Those rules can make the billed quantity different from the raw physical measurement.

4. What happens on cancellation and error?

Read the execution contract. Do not assume all unsuccessful requests settle identically.

5. What value does the API return after settlement?

For each::api predictions, retain metrics.cost.

For successful metered predictions, retain the billing-specific counters too.

6. Does resubmission create another execution?

If it does, a retry starts another billing lifecycle.

Persist the original prediction identifier when the goal is to recover status rather than create another generation.

Once those questions are answered, the rate card becomes useful: you know which quantity the system counts and which value to inspect when execution is over.

FAQ

Are failed AI API generations charged?

It depends on the API contract and the failure class. On each::labs, canceled Executions are not charged, and errored Executions are not charged by default. A Model can be an exception when its underlying Provider charges for failed requests; the current Terms say those exceptions are identified with their error charge in the Documentation.

Does per-second billing always mean video duration?

No. Some APIs bill generated media duration; others meter execution or processing time. You need the API's definition of the billable clock before applying a per-second rate.

How do I calculate megapixels for API billing?

The physical megapixel count is:

width × height / 1,000,000

The billed quantity can differ if the API rounds megapixels, applies a minimum, counts multiple outputs, or treats input and output pixels differently.

Is one API request always one billed generation?

No. “Generation” is a model-defined billing unit, not a universal HTTP concept. One request can map to multiple outputs or otherwise contain more than one billable unit.

What field tells me what an each::api run cost?

Use metrics.cost from the prediction response for the settled per-run cost. Successful predictions on metered engines such as Video API can expose additional counters such as billed_seconds to explain the underlying meter.

A rate card helps you estimate before execution. The actual bill also depends on what the API counted and what settled when the run ended.

Canberk Sinangil

Co-founder & CTO, each::labs

I’m the Co-Founder and CTO of each::labs, where I focus on building the infrastructure and tooling that help developers bring AI models into production. My background spans computer vision, augmented reality, machine learning, and software engineering, including building AR and visual AI products before moving deeper into generative AI. I’m particularly interested in the engineering challenges behind making powerful AI models fast, scalable, and practical for real-world products.

LinkedInX

Build your Workflow on each::labs