Energy
How the energy balance regenerates and where to read the live numbers
Energy is the spendable balance your subscription plan grants you, and it refills on its own — a fixed amount at a fixed interval, up to a cap.
Two numbers describe it: the balance you have now, and the ceiling it regenerates toward. Spending pulls the balance down; regeneration pushes it back up until it reaches the ceiling, then stops. Per-plan figures are on melious.ai/pricing.
Energy versus electricity
Melious uses the word "energy" for two unrelated things, and the field names are the way to tell them apart.
| Field | What it is |
|---|---|
billing_cost.energy | What a request cost you, in energy units. |
energy_cost | The same figure on image responses, which bill per image rather than per token. |
environment_impact.energy_kwh | Physical electricity the request consumed, in kilowatt-hours. |
The first two are money-shaped and come out of the balance this page describes. The last one is a measurement of the real world, and it's never debited from anything — see Environmental impact. The two aren't convertible into each other.
How regeneration works
Regeneration is a tick, not a monthly reset. At a fixed interval your balance goes up by a fixed amount, and that interval defaults to 45 minutes (energy_regen_interval, 2700 seconds).
The clock is anchored to your last grant (last_energy_regen_at), not to midnight and not to your billing date. If a tick landed at 14:37, the next one is due at 15:22, and that holds whether or not you were logged in for it.
We don't run a scheduler for this. We bring the balance up to date whenever something reads it, so the figure you see is current at the moment you ask.
A full day of ticks adds up to your plan's daily energy allowance, which is the figure quoted on the pricing page. The cap sits at four days' worth, so a balance you haven't touched in a while stops filling rather than banking indefinitely.
Regeneration stops at the cap. A tick that would carry you past it tops you up to the cap exactly, and the remainder isn't banked — energy that arrives on a full balance is energy you don't get.
Where to read the numbers
Your subscription page shows the live balance, the time remaining until the next tick, and how much that tick will add. That's the reliable place to look — it reads the same fields we bill against.
Over the API, GET /v1/billing/balance returns the same state:
| Field | What it holds |
|---|---|
energy | The balance right now. |
energy_max | The cap regeneration stops at. |
energy_regen_rate | How much regeneration adds, as configured for your plan. |
last_energy_regen_at | Timestamp of the most recent tick — the anchor the next one is measured from. |
GET /v1/auth/session/me reports the same state under different names — current_energy and max_energy rather than energy and energy_max — plus energy_regen_interval, the number of seconds between ticks.
Running out
An API request with no energy left returns BILLING_2001 with HTTP 402. Retrying won't change that; the fix is credits or the next tick. See Errors.
Whether a request draws on energy at all depends on your plan's api_usage benefit — plans without it pay API calls in credits even when energy is positive. That rule, and the two-currency model behind it, is on Pricing.
Plans without energy
Some plans aren't metered in energy. Concurrency plans bound you by how many requests you can run in parallel and a daily request cap instead, so there's no balance to regenerate. Unlimited is available on the pricing page for anyone to subscribe to, so if your subscription page shows an energy bar, you're on an energy plan.
Related
What a request costs and which balance pays for it: Pricing. Request-rate ceilings, which are separate from energy and apply on top of it: Rate limits. Plan benefits that gate API access: Authentication.