Set deadlines and handle unavailable capacity

Compare the clocks before you submit

A fast response is not the same as fast completion. Choose a deadline your task can use, then check the signed quote before submission. Read the existing job to learn what Lithi recorded. Carry your prepared brief into the quote review: frozen instructions and rubric, input snapshot, output schema, required evidence and acceptance rule. A timing choice can bound that intent, but it does not authorize a broader prompt, different input or changed schema.

Use each clock for its own purpose

The signed quote can also expose eta_p50, protected_completion_at, latest_safe_start, deadline_state, capacity_state, forecast_expires_at, and forecast_basis_digest. eta_p50 is the median forecast; protected_completion_at is the protected-quantile forecast; and latest_safe_start is the latest forecast start for that protected completion. These values are time-bound forecasts based on the signed forecast basis. They are not guarantees, Mac selections or permission to change the job after approval.

A requested quote lifetime is not the final expiry, so read expires_at in the response. Capacity timing is not a guarantee that your result will be complete or delivered by that moment.

The job deadline is not an ISO 8601 duration. Use a date-time with an explicit offset, such as UTC, so the same instant is understood by every client.

Decide whether the deadline fits

For the current LithiJobV1 and LithiQuoteV1 REST path, admission requires both:

quote.expires_at > the admission check's current time
job.execution.deadline_at <= quote.expires_at

These are contract checks, not evidence of a successful run. Passing them does not prove that execution has finished. A quote whose deadline_state is at_risk remains a forecasted risk signal; an unavailable capacity state must be handled as a refusal or requote path, not silently converted into a looser deadline.

If the relationship does not fit the work, revise the timing and obtain the required fresh quote and approval. Changing a deadline changes the request body; do not hide that change inside an exact replay. Keep the rest of the brief fixed unless you deliberately review the changed work as a new intent.

Use booking when timing can be planned ahead

A capacity wait bound on a quote request is different from a future booking. Where the current quote/booking surface offers scheduling alternatives, use Booking and priority to compare ASAP, deadline, reserved-window and flexible-off-peak timing.

A reservation binds compatible capacity and a time horizon. It does not reserve a named Mac and it does not authorize execution. Priority remains a separate queue/placement choice.

Let Lithi place the work

The quote request's capacity bounds limit the priced request. They are not controls for choosing Macs, cells, queues, shard sizes, or physical runtime batches.

Provide your deadline, permitted data profile and approved workflow requirements. Do not split data into imagined hardware-sized pieces to force capacity. Preserve the semantic boundaries your work needs.

Handle the actual refusal

Read the HTTP status, typed error code, and any safe next action. The public error vocabulary includes INVALID_REQUEST, RATE_LIMITED, UNAVAILABLE, CONTEXT_OVERFLOW, DATA_PROFILE_REQUIRED, and CREDENTIAL_DETECTED.

Correct invalid input or policy selection before resubmitting. A rate limit or unavailable service calls for bounded retry handling, not a bigger spend ceiling or a new identity. A refused request and an unknown write outcome need different recovery paths. A transport retry keeps the same request identity; a deliberate timing change needs a fresh quote and approval.

When a response is lost, use safe retry and reconciliation steps. Never treat elapsed time or quote expiry as proof that an earlier submission did nothing.