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. Deploys go to the active environment, which is dev unless you changed it with rebase environment use:
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
Every workspace starts with the deployment environments dev, staging, and prod, and rebase environment create adds more. 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.

