What is the model playground?
The model playground is the interactive detail page that lives at/{workspace-slug}/models/{model-slug} (or /models/{uuid} for models
without a slug). It lets you explore, test, and integrate any AI model
registered in your workspace or visible in the public catalog.
Access the playground from the Model Detail Page. Every card on
/models also ships a Playground button that deep-links straight
into the ?tab=playground view.What you can do
Start with a task. In the model catalog, More filters → Tasks narrows models by their declared task contracts. On a model page, Services explains its tasks, required inputs and output meaning; expand the input/output details when configuring a mapping. This lists supported interfaces, not deployed integrations or tested robot compatibility. Models that support several tasks share one task picker. Plan steps takes a goal and returns a task plan; Free prompt leaves the prompt open-ended. Task prompts come from the shared task catalog, with model-specific examples where available. Image points, local paths, task plans and joint commands require different downstream services and adapters. The workflow node uses the same task contracts: select Task, choose a compatible Model, then provide the required observations. Use example prompt fills an empty prompt from the selected model’s task example. Existing input mappings are retained. In an editable environment workflow, Configure with AI opens the existing workflow assistant for the selected node. Edit the request, choose Plan edit, then review the proposal before Review and apply. This does not activate the workflow. Some models include recorded examples showing a previous input and result. Their captions identify the checkpoint and whether depth is relative or metric. They do not run inference. If weights or an execution adapter are unavailable, the page explains the missing setup and keeps its examples readable. The playground auto-detects the model’s capabilities (deployment, provider, tags, input modalities, output format) and renders the right UI for each kind:How inference is plumbed
- Synchronous cloud models (Google GenAI, OpenAI, or models with an
endpoint_urldeployment) go throughPOST /api/v1/mlmodels/{uuid}/runand return200 OKwith the output payload (MLModelRunResultSchema). - Asynchronous cloud-node workloads (e.g.
im2mesh) return202 Acceptedwith aworkload_uuidand apoll_urlpointing at/api/v1/cloud-node-workloads/{uuid}. The UI polls the workload and renders the artifact (GLB, image, etc.) once the workload completes. - Edge models are not invoked from the browser. The playground shows the exact CLI / SDK commands needed to run the model locally through a Cyberwave edge worker.
When a robot prediction needs setup
Assisted joint setup for SmolVLA
After choosing a robot, Assist joint setup proposes how the policy’s output columns and units map to that robot. Include details from the checkpoint’s training configuration, particularly the gripper convention. Review the assistant’s assumptions and edit the mapping or conversion values as needed. Changing an example policy value updates the pose in the 3D viewer immediately. Save new binding version stores the mapping in your workspace. You only need read access to the model and robot catalog, plus permission to create in your workspace. Select a saved version explicitly; subsequent saves preserve previous versions. Controller inference and prediction playback use the same conversion. If the source contract changes, or the original model is removed, select an accessible replacement model and use Adapt an existing binding. The assistant compares the retained old contract with the selected model and shows changes for review. Saving creates a replacement version; it does not restore deleted weights or automatically activate a controller. Pin checkpoint revisions for reproducible evaluations. The blue ghost is the reference pose from the robot preview. The solid robot shows the converted policy values, with numeric differences displayed per joint. The preview shows the converted pose; it does not run physics or demonstrate task success. This adapter supports absolute joint-position SmolVLA checkpoints whose input and output dimensions match the robot. It cannot turn a generic 32-column base policy into a trained six-joint policy by dropping columns.Checkpoint sources
A SmolVLA model can declare a stored checkpoint or a Hugging Facepolicy_repo_id with optional policy_revision. Stored checkpoints take
precedence. If a declared artifact is missing, execution reports the missing
artifact instead of silently running a different base model. Hub checkpoints
use the same downloaded snapshot for weights, configuration and processors.
Compatible hardware lists the robots declared for a model. A prediction
also needs an output mapping, and pose predictions need the robot’s kinematics.
These checks happen before a trajectory can replay.
- Model output or joint mapping: a model editor can choose Review model setup to open the existing model settings. Under Metadata, compare the output declaration with the checkpoint’s training configuration. Joint outputs need their trained joint order; Cartesian outputs need a configured IK service.
- Robot kinematics: choose Review robot setup to open that asset’s Control section and review its end-effector and IK configuration.
- Unreachable pose: choose another target or initial pose before making a new prediction.
Using a model from your code
Every playground tab also surfaces copy-paste-ready snippets for the Python SDK, thecyberwave CLI, and curl. These snippets are
specific to the selected model.
Cloud model (Python SDK)
Edge model (CLI)
Direct HTTP (cURL)
See also
- Model catalog
- Edge Worker
- Deploying Models
- Playground API reference — endpoint URLs, request/response schemas, output formats