Stalled and failed jobs
Recover the original operation without duplicating paid inference or learning.
Find the durable job ID first. If your application saved the receipt, read that job directly. If the submission response was lost, recover it by repeating the original idempotency key and unchanged payload.
Queued or running for longer than expected
Read the latest status, phase, and updated_at. The API does not promise a fixed execution duration or expose a percentage-complete value. Continue bounded observation and preserve the job ID rather than submitting a replacement because a loading indicator lasted too long.
A client or SDK polling timeout only ends observation. Resume with the same ID. The public API has no cancellation endpoint, so closing the browser or aborting a fetch is not evidence that work stopped.
If the state remains unexpectedly unchanged, collect the job ID, timestamp, phase, and last update time for support. Do not send the learning passage or entire answer as the first diagnostic step.
Failed or rejected
For failed, inspect error.code, settlement, and any result metadata. A known inference failure can still carry billable usage if generation occurred. Zero visible output is not the same as zero tokens.
For rejected, the candidate did not pass the learning gate and the active subject was not replaced. Review source clarity and the independent evaluation before making a deliberate new update. The fixed successful-internalization fee does not apply to a rejected job.
A new attempt after a known terminal outcome is a new operation. Use a new key only after deciding that new work is intended, not as an automatic reaction to every error.
Reconciliation required
This state means the platform cannot safely establish the outcome or complete usage. A worker may have lost its lease after execution started, a dispatch may be unconfirmed, or a provider result may be incomplete.
Keep the original job and reservation. Do not treat the reserved amount as released, infer a refund, or create a replacement job. An operator must inspect durable execution receipts and provider evidence to settle the original operation without replaying it.
Your application can mark the operation as needing investigation and continue occasional read-only checks. If an operator resolves it, the same job can later expose a known terminal outcome and settlement.
Ready but knowledge appears unchanged
Inspect result.activated. A saved candidate is not always active. If activation_conflict is true, another update changed the subject during training. Read current routing and make a deliberate release decision.
If activation succeeded, compare the later inference job's adapter_version. It may have been admitted before the route changed, or it may target another subject or project. Only after confirming the route should you diagnose model quality.
Balance held after an interruption
Open reservations remain held until the outcome is settled. Reconciliation is intentionally conservative about ambiguous paid work. Look up the pending jobs in Activity and match their reservations to Billing before reporting an unexplained balance discrepancy.
Use safe diagnostics for escalation and Polling and recovery to prevent duplicate work in your integration.