Route your first workload.

Lists the four profile shapes and base credit rate. Authentication and an active Dyson entitlement are required.

Accepts profile, timeout, and requirements. Returns the selected profile, routing reason, bounded timeout, plan multiplier, and maximum credits.

Submits a source or SDK payload. Every request requires an 8–128 character Idempotency-Key; omission or malformed input returns 422, and reuse with different content returns 409. The create transaction checks the account-scoped stable job identity before plan concurrency, so an exact simultaneous replay that sees the winner fill the final slot returns that job with submission_replayed=true and never cancels their shared idempotent Ledger hold. If that exact race cannot be read authoritatively, Dyson preserves the bounded hold and returns a retryable service error rather than risking unbilled live compute. A Firestore create error remains ambiguous until an authoritative account-scoped read proves whether the exact job exists: a recovered commit continues, while an unavailable read preserves the bounded hold for exact replay instead of cancelling a hold that may already belong to live compute. Every account-scoped job, list-page, and cursor read binds the authenticated account collection and requested document ID to the private record's exact embedded account and job identities. It also requires a canonical 1–36 character private Ledger user ID whose stable lowercase SHA-256 prefix matches the account hash; missing, blank, padded, overlength, or cross-account Ledger IDs fail before external calls or state mutation. Each persisted job additionally binds the exact us-central1 region and ordered cpu-small, cpu-balanced, cpu-highmem, and gpu-l4 profile-to-worker mapping from active topology, a canonical 32-character launch token, canonical payload/result URIs under the channel bucket and account/job path, an operation that belongs to the exact project and region, and an execution that belongs to the exact persisted worker parent. Missing or substituted resource identity takes the same value-free retryable incident before Cloud Run, Ledger, billing, lifecycle, pointer, or capacity mutation. The same shared pre-mutation contract requires the complete seven-field public profile projection (name, cpu, memory, gpu, gpu_type, max_timeout_seconds, and queue) to match the canonical profile value-for-value and type-for-type, an integer workload timeout from 10 seconds through that profile's exact 900/1,800/3,600/3,300-second maximum, and a task timeout exactly equal to workload plus the reviewed 300-second worker overhead. Missing, extra, type-drifted, or forged hardware, a profile-over-limit workload, or task-timeout drift takes that same value-free retryable incident before those external calls or mutations. Every persisted row, including terminal history, must also retain submission_expires_at exactly equal to created_at + 300 from the topology-bound five-minute submission policy, and each pointer-referenced active target proves the same authority independently. A missing, shortened, extended, malformed, or type-coerced deadline raises the same value-free incident before Cloud Run, Ledger, Firestore, pointer, billing, counter, or capacity mutation; no fallback reconstructs missing authority. Schema-v30 release evidence requires persisted submission-deadline coverage to equal every scanned job, pointer-referenced coverage to equal the complete active population, and both population-bounded lifecycle/pointer-subset dedicated incident counts to be zero. Its sanitized projection retains only those four aggregate counts, never per-job creation or submission-expiry timestamps. Every active job must also retain billing_status=reserved and one exact pending Ledger hold. The source-bound contract fixes cpu-small/cpu-balanced/cpu-highmem/gpu-l4 at 0.02/0.05/0.12/0.30 credits per minute, recomputes the tier multiplier and minimum-one-minute rate estimate, requires included plus paid funding to equal that estimate in exact included-then-paid reservation order, forbids a paid fallback beside unlimited access, and binds the private account, job, profile, timeout, Ledger-v2 scoped idempotency keys, one monthly period and metadata, exact funding semantics, and a hold lifetime equal to the 60-second reservation-preparation allowance plus submission grace, start grace, task timeout, the 120-second result-publication grace, one-hour settlement window, 120-second active-job recovery allowance, and final 30-second Ledger dispatch. Reservation creation must be no earlier than 60 seconds before persisted job creation and no later than the fixed five-second event-clock-skew allowance after it. Missing, substituted, captured, cancelled, expired, cross-account, split-period, amount, metadata, stale/future creation, or legacy-short holds take the same value-free incident before Cloud Run, Ledger, Firestore, pointer, billing, or capacity mutation; partial hold creation is released on validation failure. Drift returns a retryable 503 with Retry-After before submission replay, status/result/cancellation handling, any Cloud Run or Ledger call, or lifecycle, billing, pointer, and capacity mutation; the managed incident is aggregate-only and contains no path, account, or job identity. Every transactional lifecycle update and final terminal settlement revalidates the same binding before pointer deletion or capacity release. A private preparation remains byte-exact and retryable for exactly five minutes before reconciliation atomically expires it and releases its hold and concurrency slot. If the create-only payload already exists, replay verifies its exact bytes under a caller-owned 20-second deadline with provider retries disabled; a metadata/download disappearance or generation-precondition race, Google API/auth, Requests/urllib3/stdlib transport, raw socket/SSL/DNS, checksum, or deadline failure returns retryable 503 with Retry-After: 60 without launching compute, claiming preparation failure, cancelling billing, or releasing capacity. Payload or signed-URL failure must first transactionally claim preparation_failed against launch_requested before cancelling billing or releasing capacity. A concurrent launch winner keeps its hold and active slot, and reconciliation resumes cleanup after a process exit or Ledger outage. Dyson atomically claims Cloud Run launch once and persists a private 192-bit, canonical 32-character launch token that is never returned publicly. The child process enforces the requested user-code timeout; the outer Cloud Run task adds a five-minute controller reserve for transfer, teardown, serialization, and result upload. Artifact URLs cover the 30-minute launch queue and full task lifetime, while the Ledger hold adds the preparation period and one-hour settlement window without allowing capture above the user-code reservation. Recovery follows at most ten 100-execution pages and accepts only the exact worker parent, job ID, private identity, user-code timeout, persisted task timeout, and post-claim creation time. Only an exhausted list proves no execution; an outage, malformed or cyclic pagination, a remaining page token at the bound, or identity/timeout conflict stays pending and cannot release billing or issue duplicate compute. The configured visibility grace begins at the launch claim. A failed launch operation is not execution absence: it first runs the same bounded exact execution discovery, an exact match resumes, the Ledger hold remains throughout the full start grace even after an exhausted early search, and only exhaustive exact-execution absence after that grace permits release. Ledger returns 200 only for an authoritative same-ID cancelled or expired reservation; every raw 409—including a captured reservation or another cancellation conflict—keeps billing and capacity unchanged. Dyson then validates the existing account/job-scoped read-only settlement audit: exact all-released truth becomes billing_status=cancelled. Only the scheduled reconciler may apply exact all-captured or captured-plus-released truth; it emits the managed aggregate incident, commits billing_status=conflicted with every authoritative nested status and captured total, then releases the active slot without calling the charge cancelled. API reads keep even audit-proven terminal conflict in pending_reconciliation until that alerting attempt. Pending, malformed, unavailable, or substituted audit state retains the slot and a private first/last-observation, attempt, and split-count record. The dedicated billing-conflict policy alerts immediately for terminal conflict or after unresolved age reaches the immutable 900-second bound, without logging account, job, or reservation identities. Before external work, the source-bound scheduler requires every active pointer to carry a canonical document/job identity and account hash. Missing, non-string, noncanonical, or substituted pointer state is retained and raises the same aggregate identity incident before external work, pointer deletion, capacity change, cursor movement, or completeness advancement. An exact pointer must then bind its loaded private job and prove that target is still queued, running, cancelling, or settling. Each active target must also satisfy its exact recoverable phase lineage: prelaunch preparation, durable launch, operation/execution, cancellation chronology, result grace, or immutable settlement intent as appropriate. One exact shared settlement-decision schema-v3 contract binds execution, profile, finite ordered chronology, authoritative Cloud Run start/completion timestamps, a six-decimal max(0.1, completion - start) duration for started work (or null start and zero duration for exact no-start cancellation), result availability, digest, canonical GCS generation, and provider-authored creation time, capture-or-release action, final status, and coherent outcome. Job creation must precede the durable launch request; provider start and completion may lead that request by no more than the reviewed five-second allowance; result creation must remain between start minus five seconds and completion plus five seconds; and optional cancellation request and dispatch markers must stay ordered from launch through settlement claim. The settlement-claim transaction rejects any start boolean/timestamp that drifts from authority already persisted while Cloud Run was running, and terminal projection must preserve the same provider start authority; persisted active and terminal intents are revalidated before API exposure, external work, lifecycle mutation, or pointer handling. An impossible queued/running/cancelling/settling combination or an active row carrying terminal fields is retained and raises the same aggregate integrity incident before direct API or scheduled Cloud Run, Ledger, pointer/capacity, cursor, or full-ring work. A terminal or unknown-status target is likewise retained; only an exact orphan is transactionally repairable. Job admission accepts only an absent or canonical nonnegative integer account capacity counter. Malformed counters raise the same aggregate integrity incident; terminal settlement and orphan repair retain job, pointer, billing, and capacity state if deleting the pointer would underflow that counter. The scheduler atomically backfills any exact legacy nested conflict missing from the private index and continuously proves a complete active-ring pass; release-clear evidence requires that pass to begin after the 120-second post-promotion quiescence boundary. Release clear additionally requires schema-v4 candidate and active topology to record and agree on the exact 300-second submission, 1,800-second start, 300-second worker-overhead, 120-second result-publication, and 3,600-second settlement policy plus the observed channel bucket's exact Delete action, age 31, jobs/ prefix, UTC/30-day interpretation, and disabled retention-policy, versioning, and soft-delete state. It then requires an exact-source, active-topology-bound read-only scan of the full persisted-job collection, complete active-pointer collection, and every top-level Dyson user counter after that quiescence and every acceptance artifact. The schema-v30 audit derives its bucket, location, lifecycle, minimum-retention, age, and UTC claims from the hashed active topology. Before reading customer state it independently describes the live bucket, requires enforced public-access prevention, uniform bucket-level access, the exact topology lifecycle, a canonical provider creation time predating active verification, and a positive metageneration, then spends exactly one marker read to obtain a server-issued Firestore read_time. Every collection page, exhaustion look-ahead, reverse-pointer read, and pointer-target read uses that exact snapshot after the retired-writer boundary. It repeats the bucket observation after all three scans and requires every field and metageneration to remain identical, so persistent drift, bucket recreation, and change-away/change-back during the scan cannot clear. It gives every active persisted job exact phase-lineage validation before one reverse-pointer validation, every canonical pointer one exact referenced-job read plus active-lifecycle and phase-lineage validation, and every account counter an exact comparison with its active persisted jobs. Persisted Ledger-account coverage must equal every scanned job, pointer-referenced coverage must equal the complete active population, and both dedicated ownership incident counts must be zero and remain subsets of aggregate identity/pointer incidents. Schema-v30 derives the exact region and ordered profile-to-worker map from the hashed active topology; persisted Cloud Run resource coverage must equal every scanned job, pointer-referenced resource coverage must equal the complete active population, and both dedicated resource incident counts must be zero and remain subsets of aggregate identity/pointer incidents. Schema-v30 also requires persisted execution-contract coverage to equal every scanned job and pointer-referenced execution-contract coverage to equal the complete active population; both dedicated execution-contract incident counts must be zero and remain subsets of aggregate identity/pointer incidents, while no per-job profile or timeout leaves the restricted report. Every active job in both directions must then pass the exact pending-hold contract against the reviewed 0.02/0.05/0.12/0.30 profile-rate table. Schema-v30 additionally requires exact aggregate authorities of 60 seconds for bounded pre-persistence reservation work and 30 seconds for final Ledger settlement dispatch; the full hold lifetime includes result publication and active-job recovery, and creation must remain within the reviewed minus-60/plus-five-second job chronology. Persisted and pointer-referenced hold-validated totals must each equal the complete active population; both dedicated billing-hold incident counts must be zero and remain subsets of aggregate identity/pointer incidents. Sanitized evidence carries only that rate table, the exact 60/30-second aggregate timing authorities, and aggregate coverage/zero-incident counts—never a Ledger user, reservation, launch/execution/result/cancellation chronology, idempotency, job, API-key, or monthly-period identity. It independently requires the private canonical account/job identity set from persisted active rows to exactly equal the pointer-target set, so an equal-count A-to-B swap between directional scans cannot clear. For every common active identity, the persisted scan and pointer dereference must also carry the exact same Firestore update_time generation, so two individually valid phases of one job cannot combine into clear evidence. Schema-v30 parses that canonical generation and requires every completed lifecycle event in every persisted active or terminal row, plus every pointer-referenced active target, to be no later than both the generation plus the fixed five-second API/provider clock-skew allowance and the shared snapshot. For execution-backed terminal rows, every canonical nested Ledger reservation created_at and exactly one terminal captured_at or cancelled_at join that completed-event set. Reservation expires_at, planned submission_expires_at, and planned result_grace_expires_at stay future deadline authorities outside it. Snapshot-time validated totals must cover every scanned persisted job and every pointer-referenced active job; both dedicated timing incident counts must be zero and consistent with aggregate lifecycle/pointer incidents. At that same snapshot, the schema-v30 audit cross-binds the topology's exact 300/1,800/300/120/3,600-second policy and a fixed 120-second recovery allowance, then requires every persisted active row and pointer-referenced target to remain at or before its recoverable phase deadline. Preparing is bounded by submission expiry plus recovery; pre-execution cleanup and result/Ledger settlement add the settlement window; launch discovery adds start plus settlement; running/cancelling adds start, the exact task timeout (user timeout plus 300-second worker overhead), result publication, settlement, and recovery. The exact boundary is accepted, but any later snapshot or malformed timing blocks clear. Persisted and referenced deadline-validated totals must cover both active populations, both dedicated incident counts must be zero and consistent with aggregate lifecycle/pointer incidents, and only privacy-safe incident classes leave the restricted report. It also validates every immutable settlement intent observed in persisted active or terminal history and pointer-referenced state against the shared contract; persisted and referenced intent, grace-state, and settlement-chronology validated totals must each exactly equal observed intent totals. The chronology proof covers creation-before-launch, launch-causal provider start/completion under the five-second allowance, result creation from start-minus-five through completion-plus-five, and optional cancellation request/dispatch order through claim; both population-bounded dedicated chronology incident counts must remain subsets of aggregate lifecycle/pointer incidents and equal zero. Every result-bearing intent also binds its canonical channel/account/job GCS URI, immutable generation, and provider-authored creation time; persisted and referenced result-artifact-provenance validated totals must each exactly equal observed provenance totals and may not exceed intent totals. Those totals split exactly into retention-eligible and age-31 UTC lifecycle-expired results, while the evidence separately binds a 30-elapsed-day minimum; active pointer references never expire. Every eligible persisted and referenced frozen generation must revalidate immutable metadata and the 6 MiB limit, then complete a one-byte ifGenerationMatch read within 20 seconds under the exact 200,000-read cap. Read attempts and bytes must match eligibility, the bound may not exhaust, and dedicated durability incidents must be zero. The release identity has bucket-scoped roles/storage.objectViewer alongside metadata-only bucket access, with no write or delete authority. A started resultless decision must retain a first observation no earlier than execution completion, expiry exactly 120 seconds later, and a claim no earlier than expiry; exact no-start cancellation forbids grace and retains null artifact provenance. A result generation observed after grace may settle only when its provider-authored creation time is no later than that exact expiry; a post-expiry generation is treated as absent and cannot authorize capture, while an in-window result may settle early. Every terminal job must carry one exact projection. An execution-backed terminal intent must project exact frozen status, failure/error, the same provider start timestamp, six-decimal derived duration, execution-start truth, result availability/digest/generation/provider creation time, completion and settlement chronology, and billing direction. Schema-v30 accepts that projection only when every nested Ledger item preserves exact positive requested credits and a canonical non-secret reservation ID, funding class (paid, included, or unlimited), terminal status, reserved/captured credits, job reference, creation/expiry, and exactly one matching capture or cancellation provider timestamp. Reserved credits equal requested credits except for an unlimited included reservation's zero provider hold; capture never exceeds that hold; top-level actual_credits reconciles to provider capture totals under the bounded unlimited rule; and cancellation audit/source truth stays exact. Schema-v30 independently re-derives each terminal row's profile/tier/timeout estimate, exact included-then-paid funding with no unlimited/paid mix, and included-first captured allocation. A fully captured row must equal the profile/tier/frozen-duration charge capped by its estimate; a mixed conflict may capture only an included-first prefix, with every later cancelled or expired reservation at zero captured credits. It additionally re-derives every terminal reservation lifetime from the persisted profile, workload timeout, and reviewed lifecycle policy; requires reservation creation within job_created_at - 60 through job_created_at + 5; and requires capture, cancellation, or expiration no earlier than the durable settlement claim or matching pre-execution cleanup authority minus five seconds and no later than both expires_at and persisted settlement or completion authority plus five seconds. Direct provider settlement must preserve the active hold's immutable fields, while account-scoped cancellation-conflict audits must match funding, reserved amount, job reference, creation, and expiry. Legacy-short, out-of-window, post-expiry, future-provider, or substituted audit rows fail closed before a terminal row is exposed or persisted. The only terminal history without an execution intent is an exact infrastructure release with private reason submission_preparation_expired, submission_failed, cloud_run_launch_failed, or cloud_run_execution_not_found, its matching phase and chronology, no execution, result, grace, cancellation, or duration state, one completion/update timestamp, and release-only nested billing truth. Direct/list reads and atomic terminal writes reject any drift before pointer deletion or capacity release. All-terminal observed and validated counts must each equal persisted terminal jobs; execution-backed settlement projections plus pre-execution projections must partition that total exactly; terminal billing-allocation and billing-lifetime validated coverage must each equal every persisted terminal job; and every pre-execution projection must validate. The population-bounded dedicated allocation and lifetime counts must remain subsets of aggregate lifecycle incidents, and settlement, terminal-allocation, terminal-lifetime, and dedicated pre-execution projection incidents must all be zero. A contradiction is a release-blocking aggregate managed integrity incident, and operators must never manually rewrite job, pointer, capacity, billing, or Ledger reservation state. All three scans must exhaust, every active account document must exist, and the summed counter must equal the active-job and pointer totals, the active identity sets must match with zero mismatch and identity-set incidents, persisted and referenced active state-generation totals must cover the full active populations, active generation match must be exact with zero mismatch and incidents, and there must be zero settlement-intent, persisted/referenced settlement-grace, persisted/referenced result-artifact-provenance, persisted/referenced result-artifact-durability, settlement-projection, terminal-billing-allocation, terminal-billing-lifetime, pre-execution terminal-projection, phase-lineage, persisted-job, pointer, user-counter, orphan, terminal-target, invalid-status, or reference incidents—including contradictory terminal history, terminal or legacy jobs with no active pointer outside the reconciliation ring, and stale low or high counters. Repository validation requires exact audit proof for conflicted terminal state and exact nested agreement for captured or cancelled state. Successful POST responses include idempotency_protected and request-specific submission_replayed so interrupted callers can distinguish exact recovery from first creation without exposing the key, launch identity, or private stage.

Returns newest-first job history, next_cursor, and has_more. Limit is 1–100.

Returns reconciled state, profile, reason, duration, errors, public billing fields, timestamps, authoritative execution_started, provider-authored execution_started_at when available, and authoritative result_available. Active jobs expose a start only after exact Cloud Run metadata proves it; Cloud Run may defer that timestamp until terminal convergence, so a temporary null is pending authority rather than proof that compute never started. Release cancellation evidence uses the terminal timestamp to prove start preceded the accepted request instead of depending on prompt active projection. Started one-task final counters remain provisional until Cloud Run supplies exactly one terminal outcome with complete, ordered create, start, and completion timestamps; incomplete or contradictory timing stays pending and can never become a guessed billable duration. The sole no-start exception is an exact cancelled execution with ordered create/completion timestamps and no startTime: it settles at zero duration and releases the hold. A success envelope is valid only with authoritative Cloud Run succeeded, and a failure envelope only with failed. A missing envelope or either contradiction is treated as no result, records its first observation no earlier than authoritative completion with expiry exactly 120 seconds later, remains settling until that grace expires, and cannot authorize capture; an unresolved contradiction then follows infrastructure release. A result may be observed after grace only when its immutable provider creation time proves that exact generation existed no later than expiry; a post-expiry generation is absent for settlement. Exact no-start cancellation carries neither grace nor artifact provenance. Started cancellation remains separately metered and may retain either already-published envelope.

Transactionally records cancellation against the exact live execution before calling Cloud Run. Reconciliation retries a lost dispatch, while concurrent terminal settlement cannot be overwritten back to cancelling. A cancellation before Cloud Run starts releases the full reservation at zero duration; once execution_started is true, consumed compute is settled with the one-minute minimum.

Returns stdout, stderr, safe error text, serialized result, measured duration, and public billing settlement only when terminal metadata says a result was present. Worker, repository, and parser share one immutable contract: a 6 MiB envelope, 4 MiB decoded result, 64 KiB captured stdout/stderr plus the exact truncation suffix, and an 8 KiB UTF-8 error. The repository rejects metadata-proven oversize without downloading it and generation-matches bounded reads. The customer endpoint starts one 20-second deadline before opportunistic reconciliation, selects the persisted frozen generation directly instead of resolving the live object name, and lets provider metadata plus payload consume only its remainder with retries disabled. A definitive metadata-to-payload NotFound or generation-precondition race is an absent exact generation. Google API/auth, Requests/urllib3/stdlib transport, raw socket/SSL/DNS, checksum, or deadline failure takes the typed unavailable path: reconciliation remains pending without result grace, the release audit records the generation unreadable and cannot clear, and a committed result request gets the same delayed retryable 502 instead of an untyped storage 500. Local programmer and metadata-integrity failures remain fail-closed and are never relabelled transient I/O. The private-launch-bound, create-only schema-v1 envelope must have its exact success or failure fields; success requires canonical python-dill-base64. The envelope's success bit must also agree with authoritative Cloud Run state: success requires succeeded, while failure requires failed. Duplicate or extra keys, malformed base64, oversized objects, ok: true without a payload, and either Cloud Run/result contradiction are invalid, enter the same durable result grace, and cannot authorize capture. A definitive NotFound or generation-precondition race is absence and may begin or continue grace; API/auth, transport, checksum, and deadline failures stay pending and cannot start it. Dyson freezes the valid envelope SHA-256, canonical GCS generation, and provider-authored creation time before Ledger mutation. A generation created after the exact 120-second deadline is treated as absent for infrastructure release, and /result revalidates all three fields before serving bytes. If a committed exact generation is missing before midnight UTC on provider creation-date + 31 calendar days, the endpoint returns a retryable 502 with Retry-After: 60; at or after that deployed lifecycle boundary it returns 410 and never serves substitute bytes. The dashboard waits for the server's retry delay and keeps that temporary state distinct from permanent expiry; every loaded payload must carry the currently selected job_id before logs, copy, or download controls appear. The Python SDK maps only this result endpoint's retryable 502 to DysonResultTemporarilyUnavailableError and its 410 to DysonResultExpiredError. Lifecycle protection is guaranteed for at least 30 elapsed days; download anything you need after the age-31 UTC eligibility boundary; resubmission creates a new billable job.