## TL;DR

Use Stripe subscription item quantity for countable entitlements you set (seats, licenses): you control the number and proration handles changes. Use metered usage for consumption you measure (API calls, storage): events flow in and the meter totals them. Mixing them up causes real billing bugs: seats modeled as usage never prorate cleanly, and API calls modeled as quantity need constant manual updates. Decide by asking who sets the number: your app sets quantities, your instrumentation reports usage.

## The query

```text
Stripe subscription item quantity vs metered usage: when to use which
```

## Use this when

- Modeling a new pricing dimension in Stripe
- Seats vs API calls billing design
- Proration behaving oddly on a usage-like dimension

## Not for

- Flat subscription fees (neither primitive needed)
- One-off charges (use invoice items)

## Steps

1. List each pricing dimension and who sets its number: app/admin or instrumentation.
   Expected output: Each dimension has an owner.
2. Model admin-set counts (seats, licenses) as subscription item quantities.
   Expected output: Changes prorate and the app controls the count.
3. Model measured consumption (calls, GB, minutes) as metered usage with events.
   Expected output: Instrumentation reports; Stripe totals.
4. Verify the invoice shape for each: quantity lines vs usage lines.
   Expected output: The bill matches the mental model.
5. Document the mapping so future pricing changes pick the right primitive.
   Expected output: The next dimension does not repeat the mistake.

## Variant phrasings

### Stripe quantity vs metered usage

### when to use metered billing Stripe

### per seat vs usage based pricing Stripe

## Root cause

Quantity is a state you set (how many seats right now) while usage is an event stream you report (what happened); Stripe bills state with proration and streams with aggregation because they are different kinds of facts. The modeling error is treating a stream as state or vice versa.

## Edge cases

- You can combine both on one subscription: seats as quantity plus overage as metered usage
- Switching a dimension from one primitive to the other mid-flight needs a migration plan

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_q2kkkeCcMSxVGacOrPtGuA