Skip to main content

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_url deployment) go through POST /api/v1/mlmodels/{uuid}/run and return 200 OK with the output payload (MLModelRunResultSchema).
  • Asynchronous cloud-node workloads (e.g. im2mesh) return 202 Accepted with a workload_uuid and a poll_url pointing 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 Face policy_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.
If you cannot edit the model, the result explains that a model editor must review the configuration. Saved results retain the configuration used for that run. Saving a correction does not approve an old failed result or start a robot. For robot operation, configure the input and service in Catalog → Control, then add the asset to an environment. The twin inherits that setup; changes in Workbench → Control apply to the twin. Connection and runtime readiness are checked separately when using a control. Monitor lets you inspect the setup without changing it.

Using a model from your code

Every playground tab also surfaces copy-paste-ready snippets for the Python SDK, the cyberwave CLI, and curl. These snippets are specific to the selected model.

Cloud model (Python SDK)

Edge model (CLI)

Direct HTTP (cURL)


See also