Compute
Deadlines, capacity and the four refusals
Why a fast API answer says nothing about when work finishes, how to declare a deadline you can live with, and why four different refusals must never be handled as one rate limit.
Two clocks, not one
There is the time an API call takes to answer, and there is the time the work takes to finish. They are unrelated numbers, and confusing them is the most expensive planning error on this page.
An admission answer arrives quickly. It tells you the request was accepted, and it carries a request identifier, a typed state, an observation time and a next action. It does not tell you when output will exist.
End-to-end completion is the second clock. It covers materializing your input, running the work, verifying it and aggregating the result, and it is the one your business cares about.
We publish no completion-time figure
Lithi publishes no service-level number, no uptime figure and no completion-time commitment. There is no measured figure to publish, so nothing here will invent one.
Design for a system whose finishing time you observe rather than assume. Read the job's status, and treat the result manifest as the only completion signal.
Your deadline is a requirement you declare
Your task submission carries a limits object with a deadline, written as an ISO 8601 duration, and a maximum_price. Both are your bounds, stated up front.
A deadline is a requirement Lithi works against, not a promise Lithi makes back to you. Where a bound cannot be met, you get a typed outcome such as EXPIRED. It carries a safe reason and a next action, never silence.
Four refusals with four different owners
These four classes exist precisely because they are not interchangeable. Each one has a different owner and a different next action.
| Refusal | What it means | Who resolves it |
|---|---|---|
EDGE_ABUSE_LIMITED | The perimeter is shedding load right now | Nobody's account is at fault; retry later with growing backoff |
CANONICAL_ADMISSION_LIMITED | Your key or account has reached its request authority | An administrator adjusts that identity's limits |
CANONICAL_BUDGET_EXHAUSTED | Spend or reservation authority is used up | Someone with spend authority raises the ceiling or approves |
CELL_CAPACITY_UNAVAILABLE | Capacity is unavailable at this moment | Resubmit later, or widen your deadline |
Why collapsing them into one rate limit hurts you
A single retry branch labeled "rate limited" will retry a budget refusal forever. The work never runs, the backoff grows, and the one person who could approve more spend is never told.
The same branch treats an administration problem as weather. Read the refusal class and the next action on the envelope, then route each class to the party who can actually clear it.
What to do next
Set your spend ceiling and approval rule before volume matters, so a budget refusal is a decision rather than a surprise. Start with how spend ceilings and approvals work, then map each refusal class in your client using the refusal vocabulary.