Execution Modes
Choose latency, duration, and isolation for Rebase functions, models, and workflows.
Rebase separates two decisions:
modechooses the execution lifecycle:interactivefor low-latency synchronous calls, orjobfor a fresh Cloud Run Job execution.isolationchooses where an interactive function or model runs:sharedordedicated.
The default is mode="interactive", isolation="shared". This is the lowest-latency path and is what rebase run uses unless you override it.
| Mode | Isolation | Functions and models | Workflows | Pick it when |
|---|---|---|---|---|
interactive | shared (default) | Already-running shared Cloud Run runner; no per-function service deploy. | Warm Cloud Run service worker orchestrated by Prefect. | Fast development loops and small trusted workloads. |
interactive | dedicated | Private Cloud Run service per function, with tagged revisions for immutable versions. | Not supported. | You need an isolated service but still want synchronous calls and warm-instance latency. |
job | Not applicable | One Cloud Run Job execution per run. | One Prefect-orchestrated Cloud Run Job per workflow run. | Long-running, cancellable, or resource-heavy work where startup latency matters less. |
@project.function() # interactive/shared; both values can be omitted
def add(a: int = 0, b: int = 0) -> dict:
return {"sum": a + b}
@project.function(isolation="dedicated")
def private_transform(value: float = 0) -> dict:
return {"value": value * 2}
@project.workflow(name="nightly-backfill", mode="job")
def backfill(day: str = "today") -> dict:
...rebase run pipeline.py::backfill --mode job
rebase run functions.py::private_transform --mode interactive --isolation dedicatedChoosing execution settings
| Concern | Guidance |
|---|---|
| Latency | interactive/shared avoids per-target provisioning and is fastest for the first call. interactive/dedicated can be fast once its private service is warm. job pays startup cost on every run. |
| Duration | Interactive runs must finish within the request lifetime. Use job for work that may run for minutes or hours. |
| Isolation | Shared interactive functions use the same runner process, environment machinery, import path, caches, API identity, and failure domain. Use only mutually trusted code there. Dedicated interactive functions get a private service; jobs get a fresh execution. |
| Cancellation | Function/model interactive calls cannot be cancelled after dispatch. Jobs and Prefect-backed workflow runs can be cancelled. |
The isolation setting applies only to interactive execution. Jobs always receive a fresh job execution. Interactive workflows use the shared Prefect service worker; dedicated interactive workflows are rejected.
Cancellation and logs
| Execution | Target | Cancellable | Logs (rebase run logs) |
|---|---|---|---|
interactive/shared | Function or model | No | Not available yet. |
interactive/dedicated | Function or model | No | Cloud Run service logs via Cloud Logging. |
job | Function or model | Yes | Cloud Run Jobs logs via Cloud Logging. |
interactive/shared | Workflow | Yes | Prefect logs. |
job | Workflow | Yes | Prefect logs. |
Migrating from run_type
run_type is deprecated but remains accepted for compatibility. Rebase translates it at the API boundary:
| Deprecated value | New function/model setting | New workflow setting |
|---|---|---|
quick_shared | mode="interactive", isolation="shared" | Not supported |
quick | mode="interactive", isolation="dedicated" | mode="interactive", isolation="shared" |
long | mode="job" | mode="job" |
Do not send run_type together with mode or isolation. The API rejects ambiguous combinations.
The older backend= option remains removed. Concrete provider values such as cloud_run, cloud_run_shared, and cloud_run_jobs are internal implementation details, not selectable public values.
Run records expose mode and isolation, plus the concrete execution_backend and optional backend_run_id for debugging. Job records report isolation: null because isolation is not a separate job setting.
Beta compute credits
Beta workspaces receive 20 EUR of compute credits per calendar month. Rebase reserves estimated credits before accepting a run and finalizes the charge when it finishes. New runs are rejected when used credits plus active reservations reach the workspace cap.
rebase usageA workspace is on one of two billing plans, set by Rebase:
- credits (the default): every run is charged at least one cent, so the monthly grant is a budget of runs as much as of compute.
- passthrough: Cloud Run cost is metered 1-to-1 at the regional rates, with a per-request fee for request-serving backends and no minimum charge. The monthly grant then acts as a spend cap rather than a prepaid budget.
Amounts are metered in microcents (one cent is 1,000,000) and shown rounded to cents.
Use the detailed pages for target-specific behavior:
| Page | Covers |
|---|---|
| Function Execution | Function isolation, dependencies, and latency. |
| Workflow Execution | Prefect-backed interactive and job execution. |