> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. --- title: Deadlines, capacity and the four refusals description: >- 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. route: /docs/compute/jobs/deadlines-and-capacity page_id: docs-compute-jobs-deadlines-and-capacity page_type: concept content_layer: guided documentation surface_profile: guided_docs audience: Compute customers planning timing, capacity and retry behavior voice: D reader_question: How long does work take, and what do the different refusals mean? primary_action: Set a deadline your work can actually meet source_locale: en-US source_status: APPROVED source_version: docs-compute-jobs-deadlines-and-capacity-en-us-2026-09-05-v1 last_updated: '2026-09-05' robots: index claim_registry_pinned: true claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write" --- ## 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](/docs/compute/configure/spend-and-approvals), then map each refusal class in your client using [the refusal vocabulary](/docs/compute/errors).