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:
| Class | Cloud operation | Status | Page |
|---|---|---|---|
rebase.Predictor | predict(...) | Deployable | Prediction |
rebase.Optimizer | optimize(...) | Deployable | Optimization |
rebase.Agent | act(...) | Deployable | Agents |
rebase.Simulator | reset(...) / step(...) | Local-only for now | Simulation |
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 defaultOr 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 stagingProduction 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 prodPublish 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.

