Function Run Types

Rebase Functions are private Python callables invoked through the SDK. They use run_type="quick" by default, which runs each call synchronously on an isolated Cloud Run service that stays warm after the first call:

For the full run-type overview across functions, models, and workflows, see Run Types.

import rebase as rb

project = rb.project("energy-tools")

@project.function(name="add")
def add(a: int = 0, b: int = 0) -> dict:
    return {"sum": a + b}

project.deploy()

result = add.remote(a=40, b=2)
print(result)

Run Type Options

Set the run type on the decorator:

@project.function(name="add-quick")
def add_quick(a: int = 0, b: int = 0) -> dict:
    return {"sum": a + b}

@project.function(name="add-shared", run_type="quick_shared")
def add_shared(a: int = 0, b: int = 0) -> dict:
    return {"sum": a + b}

@project.function(name="add-long", run_type="long")
def add_long(a: int = 0, b: int = 0) -> dict:
    return {"sum": a + b}

@project.function(name="add-quick-warm", min_instances=1, concurrency=1)
def add_quick_warm(a: int = 0, b: int = 0) -> dict:
    return {"sum": a + b}

The old backend= argument is removed and raises an error with a migration hint: backend="interactive" becomes run_type="quick", backend="batch" becomes run_type="long". Concrete provider values such as modal, prefect, and prefect_cloud are gone; see Run Types.

What Each Run Type Maps To

Rebase resolves the run type to concrete Cloud Run infrastructure. Run records report the resolved value in the internal execution_backend field.

Quick: Cloud Run Isolation

run_type="quick" creates a dedicated private Cloud Run service for the Rebase function. Each immutable function version becomes a tagged Cloud Run revision under that service. Rebase stores the version tag URL on the function version and invokes that URL for exact-version execution.

On first deploy, Rebase creates the Cloud Run service. On later deploys of the same function, Rebase updates the service template to create a new tagged revision and preserves tags for older versions. Deploy waits for the revision to become ready, then verifies private invocation by calling the tagged revision health endpoint with a Google-signed identity token before treating deploy as complete.

Use concurrency=1 when you do not want two user calls executing inside the same Cloud Run instance:

@project.function(
    name="single-tenant-transform",
    min_instances=1,
    concurrency=1,
)
def transform(value: float = 0) -> dict:
    return {"value": value * 2}

min_instances=1 keeps the function warm, which reduces cold-start risk but creates steady Cloud Run cost. Beta workspaces force min_instances=0 and cap concurrency, timeout, CPU, memory, and maximum Cloud Run instances to keep usage inside the monthly credit grant.

Quick runs execute synchronously, so they cannot be cancelled once started. Use run_type="long" when you need cancellable runs.

Private isolated Cloud Run invocation uses two layers:

Quick Shared: the Shared Runner

run_type="quick_shared" runs the function on a shared, already-running Cloud Run runner service. Because there is no per-function service deploy, registration and the first call are very fast. The tradeoff is isolation: multiple functions share the same runner process and boundary, so reserve it for trusted development workloads. Runs execute synchronously and cannot be cancelled, and rebase run logs does not support this path yet.

Long: Cloud Run Jobs

run_type="long" creates or updates a Cloud Run Job for the exact function version and starts one job execution per run. The API marks the run submitted, then the job task writes running/succeeded/failed status back to Rebase. This is the right choice for batch-style work, backfills, and long model executions where scale-to-zero isolation matters more than call latency. Long runs are cancellable: rebase run cancel cancels the Cloud Run Job execution.

Dependencies

Add public PyPI dependencies with dependencies=[...]. Rebase records them in the function version fingerprint and installs them with uv pip install in the runner cache:

@project.function(name="flatten-and-add", dependencies=["boltons==24.0.0"])
def flatten_and_add(a: int = 0, b: int = 0) -> dict:
    from boltons.iterutils import flatten

    values = list(flatten([[a], [b]]))
    return {"sum": sum(values)}

Use rb.Image when you want the dependency spec to be explicit:

image = rb.Image.python("3.13").uv_pip_install("boltons==24.0.0")

@project.function(name="image-backed-add", image=image)
def image_backed_add(a: int = 0, b: int = 0) -> dict:
    from boltons.iterutils import flatten

    return {"sum": sum(flatten([[a], [b]]))}

Pin exact versions for reproducible function versions.

GPUs are not supported in the toolkit. Image specs only accept Python version, public PyPI dependencies, and an optional uv version; fields such as gpu, cuda, or accelerator are rejected.

Latency Shape

As a rough guide for a trivial a + b function:

Read these numbers as a shape, not a product guarantee. quick pays its provisioning cost once at deploy, then serves warm calls quickly. quick_shared skips provisioning entirely. long pays job startup on every run, which is irrelevant for runs that take minutes or hours.