Pricing

Per-model rates live at melious.ai/pricing — they're the source of truth. This page explains how API requests use energy and credits.

Two currencies: energy and credits

Melious accounts have two spendable balances:

• Energy — granted by your subscription plan. It regenerates on a fixed interval up to a cap. Web (Studio) usage draws from this by default.
• Credits — euro-denominated, bought in top-ups or included in some plans. Don't expire unless your account closes.

Payment depends on your plan and the request. The response identifies the payment source:

{
  "billing_cost": {
    "energy": "2.62",
    "credits": "0.000262",
    "paid_with": "credits"
  }
}

energy is the request's cost expressed in energy units; credits is the EUR equivalent of the same cost. When a response includes billing_cost, both fields describe the cost — they're the same cost in two currencies, not a split between balances, so on a mixed payment they don't show how much each balance contributed. Today 10,000 energy equal 1 EUR, which is how 2.62 energy becomes 0.000262 credits above. We can change the rate; the figures on melious.ai/pricing are the ones in force. paid_with names what actually paid:

Which balance pays

You choose the order on your account page: energy first, credits first, energy only, or credits only. An API key can carry its own setting that overrides the account's. Two rules apply regardless of the setting: a plan whose API requests can't use energy pays in credits, and a model outside your plan's allowance pays in credits. paid_with on the response tells you what happened; mixed means the first balance ran out and the second covered the rest.

Per-request cost

Chat completions, Embeddings, and Rerank responses give you the billed cost in billing_cost and estimated impact in environment_impact. Responses and Messages don't carry either field. A reasonable shape to log:

response = client.chat.completions.create(model="<MODEL_ID>", messages=[...])

# The OpenAI SDK keeps fields it doesn't know as plain dicts — index them, don't dot them.
cost = response.billing_cost
impact = getattr(response, "environment_impact", None)  # can be absent, billing_cost stays

print(
    f"tokens: {response.usage.total_tokens}",
    f"cost_eur: {cost['credits']}",
    f"paid_with: {cost['paid_with']}",
    f"cached_tokens: {response.usage.cached_tokens}",
    f"carbon_g: {impact['carbon_g_co2'] if impact else 'n/a'}",
    f"provider: {impact['provider_id'] if impact else 'n/a'}",
)

Costs come back as strings (arbitrary-precision decimals) to avoid float-drift on aggregation.

Streaming billing

A Chat completions stream ends with a usage chunk carrying usage, billing_cost, and environment_impact, unless you set stream_options.include_usage to false. Responses and Messages streams carry neither billing field.

billing_cost is only sent once a request has been settled. A stream that fails after output was generated, or one you disconnect from mid-way, arrives without it and can still be charged for the tokens generated up to that point. See Streaming.

Batch pricing

A batch line is billed at the same per-token rate as a realtime request to the same provider — there's no batch discount. What changes is the provider: batch routing weights price far more heavily than balanced routing, so lines land on the cheaper providers for a model more often, and you pay that provider's rate. The other saving is capacity: batches run outside the per-minute rate limit on the realtime endpoints.

How a batch line is paid depends on your plan. On a concurrency plan, the plan's price covers your interactive requests, not batch lines — every line is billed in credits at the normal per-token rate. The same applies if your plan doesn't allow API requests to use energy, or if you have no plan. On those plans, batch lines are paid in credits, and a positive energy balance doesn't fund them.

Before a line runs, we reserve its prompt plus a 1,024-token output allowance, priced at the most expensive provider that serves the model. The reservation ignores your max_tokens; a longer answer still settles at its real token count and can push your balance below zero, and the next line then fails. If a line cannot be paid for, the batch stops and lines that haven't started fail with insufficient_balance. Completed results are kept — see Batches.

Decision pricing

System One decision models bill input tokens only, at the input rate of the provider that served the decision — there is no output price. The rate shown on /v1/models is the cheapest provider for that model, so the charge can be higher when routing fails over. Decision responses carry no billing_cost or environment_impact; the body is model, answers, and usage. See System One.

What isn't billed

A few things are free:

• GET /v1/models and GET /v1/models/{id} — listing is free, you can poll it.
• POST /v1/messages/count_tokens — preflight token counts are free.
• Tool lists (GET /v1/tools) and schema fetches — free.

Requests rejected before generation starts are free — for example, invalid input or no provider available. A stream that fails or is disconnected after output was generated can be charged for the tokens generated up to that point, and such a stream doesn't carry billing_cost — an absent billing field is not a zero charge.

Refunds and withdrawal

EU consumer law grants a 14-day withdrawal window on subscriptions, within limits. Credits top-ups and consumed services are handled separately. See melious.ai/account/billing for the current policy.

Related

Work that doesn't need an answer now, outside the per-minute limit: Batches. Steering which provider serves a request, including the :batch flavor: Routing. How your plan pays for API requests: Authentication. Billing-related errors: Errors.