Models

The shared model lifecycle - versions, deployment, promotion, and publication.

rebase.Model is the shared base for model metadata and deployment config. Deployable models use typed emflow-style subclasses, each with its own page:

ClassCloud operationStatusPage
rebase.Predictorpredict(...)DeployablePrediction
rebase.Optimizeroptimize(...)DeployableOptimization
rebase.Agentact(...)DeployableAgents
rebase.Simulatorreset(...) / step(...)Local-only for nowSimulation

Deployable models are first-class Rebase targets. Each model version stores source, git metadata, runtime image metadata, and a backing Function version used for execution. This page covers the lifecycle every class shares; the class pages cover authoring and invoking each kind.

Plain rebase.Model is not directly deployable; use one of the typed subclasses. Add endpoint=rebase.endpoint(...) when a model should also be callable through an HTTP endpoint.

Deploy and Version

Deploy a model file to create a reusable, versioned model target. New models deploy to dev by default:

rebase deploy my_model.py
rebase model deploy my_model.py --env dev
rebase model versions my-model --project default
rebase model deployments my-model --project default

Or from Python:

import rebase

from my_model import model


rebase.deploy(model)

Promotion and Rollback

Models have fixed deployment environments: dev, staging, and prod. Workspace environment policies also apply. New workspaces allow direct deploys to dev and require GitOps deployment requests for staging and prod.

Promote from dev to staging:

rebase model promote my-model --project default --from dev --to staging

Production promotion requires approval:

rebase model request-promotion my-model --project default --from staging --to prod --reason "Validation passed"
rebase model approve-promotion <request-id>
rebase model promote my-model --project default --from staging --to prod --promotion-request-id <request-id>

When prod is GitOps-protected, direct model promotion APIs are rejected unless they run through the GitOps reconciler or an approved platform path. Use rebase deploy <file> --env prod for the policy-aware GitOps flow.

Rollback uses the previous environment pointer unless you pass a specific version:

rebase model rollback my-model --project default --env prod

Publish to Hugging Face

Install the optional Hugging Face extra when you want the SDK to create or update Hub repos:

uv pip install "rebase-toolkit[huggingface]"

Deployable models can publish a generated source/provenance package or a local artifact folder to Hugging Face. The platform records the returned Hub commit against the immutable Rebase model version.

import rebase

from my_model import MyPredictor


model = MyPredictor()

model.deploy(
    environment="dev",
    huggingface=rebase.HuggingFacePublishConfig(
        repo_id="rebase/my-model",
        private=False,
        artifact_path="./artifacts/my-model",
    ),
)

Hugging Face publication does not require GitHub or Git sync. The SDK writes a rebase_model.json provenance file to the Hub repo with the Rebase model version ID, fingerprint, source path, and any available Git metadata. When the Rebase model version has a clean Git commit, the SDK records that commit on the publication record by default; set sync_source_git=False to publish without the optional Git link.

Where Models Come From

Models are written by hand like any Python class — or searched for by coding agents: hillclimb searches explore candidate Predictors against a verifiable target and promote the winner into your workspace repo as ordinary versioned source that deploys through this same lifecycle.

On this page