Run Types

run_type decides where Rebase runs user code after a function, model, or workflow has been registered. It replaces the old backend option: pick an intent — quick or long — and Rebase maps it to concrete Cloud Run infrastructure for you.

There are three run types:

Run type	Functions and models	Workflows	Pick it when
`quick` (default)	Isolated Cloud Run service per function. Runs execute synchronously and stay warm after the first call.	Warm Cloud Run service worker orchestrated by Prefect.	You want low-latency calls: SDK invocations, `Function.map` fanout, synchronous endpoints, manual workflow runs.
`quick_shared`	Shared Cloud Run runner. No per-function service, so it has the fastest cold start, but functions share the runner's isolation boundary.	Not available for workflows.	You want the fastest possible first call for small trusted functions and can accept weaker isolation.
`long`	Cloud Run Jobs. One job execution per run.	Cloud Run Jobs orchestrated by Prefect. One job per workflow run.	The run may take a long time and startup latency does not matter: batch processing, backfills, heavy model runs.

Set it on the decorator or the CLI:

@project.function(run_type="quick")       # default, can be omitted
def add(a: int = 0, b: int = 0) -> dict:
    return {"sum": a + b}

@project.workflow(name="nightly-backfill", run_type="long")
def backfill(day: str = "today") -> dict:
    ...

rebase run pipeline.py::backfill --run-type long

Defaults

Target	Default
Functions	`quick`
Models	`quick`
Workflows	`quick`
Workflow steps	No run type. Steps execute in-flow inside the workflow's run.

Choosing a Run Type

Concern	Guidance
Latency	`quick` runs synchronously against a warm service. `quick_shared` skips the per-function service deploy entirely, so it is fastest on the very first call. `long` pays Cloud Run Job startup on every run.
Duration	`quick` and `quick_shared` are for calls that finish within a request lifetime. Use `long` for anything that should keep running for minutes or hours.
Isolation	`quick` gives each function its own private Cloud Run service with a tagged revision per version. `long` gives each run its own Cloud Run Job execution. `quick_shared` shares one runner process across functions.
Cancellation	Only runs with an asynchronous execution path can be cancelled. See the matrix below.

Cancellation and Logs

Run type	Target	Cancellable	Logs (`rebase run logs`)
`quick`	Function or model	No — executes synchronously; cancel returns `409`.	Cloud Run service logs via Cloud Logging.
`quick_shared`	Function or model	No — executes synchronously; cancel returns `409`.	Not available yet.
`long`	Function or model	Yes — the Cloud Run Job execution is cancelled.	Cloud Run Jobs logs via Cloud Logging.
`quick`	Workflow	Yes — the Prefect flow run is set to cancelling.	Prefect logs.
`long`	Workflow	Yes — the Prefect flow run is set to cancelling.	Prefect logs.

See rebase run cancel and rebase run logs for the full behavior.

Migrating from `backend`

The backend option is removed. Passing backend= to a decorator raises an error with a migration hint, and the API rejects legacy values such as interactive, batch, modal, prefect, prefect_cloud, cloud_run, cloud_run_shared, and cloud_run_jobs. The Modal, GKE-Prefect, and Prefect Cloud execution paths no longer exist.

Old value	New value
`backend="interactive"`	`run_type="quick"` (or omit — it is the default)
`backend="batch"`	`run_type="long"`
`backend="cloud_run"`	`run_type="quick"`
`backend="cloud_run_shared"`	`run_type="quick_shared"`
`backend="cloud_run_jobs"`	`run_type="long"`
`backend="modal"`, `backend="prefect"`, `backend="prefect_cloud"`	Removed. Use `run_type="quick"` or `run_type="long"`.

Run records still expose the concrete infrastructure that executed them in an internal execution_backend field (cloud_run, cloud_run_shared, cloud_run_jobs, prefect_cloud_run_service, prefect_cloud_run_jobs) plus a backend_run_id for debugging. These are read-only outputs; user code selects only run_type.

Beta Compute Credits

Beta workspaces receive 20 EUR of compute credits per calendar month. Rebase enforces this as a hard cap for all run types, since every run type executes on Cloud Run.

Before accepting a run, Rebase reserves estimated credits from the active workspace balance. When the run finishes, the reservation is released and replaced by an estimated finalized charge. If used credits plus active reservations reach the monthly grant, new runs are rejected until the next month or an administrator changes the workspace policy.

GPUs are not exposed in the toolkit or accepted in image specs.

Check the current balance:

rebase workspace usage

Use the detailed pages for examples and target-specific notes:

Page	Covers
Function Run Types	Function decorators, Cloud Run isolation, dependencies, and function latency notes.
Workflow Run Types	Workflow decorators and the Prefect-backed quick and long paths.