Skip to main content
Run grid from your project directory. The shell keeps that working directory. The welcome screen offers robot setup, development, and simulation shortcuts. The examples below are commands inside the GRID shell; prefix them with grid when running from your system terminal.

​
Choose a cluster and check credentials

If you used an earlier CLI with context, use cluster with the same subcommand and arguments. Your saved clusters and credentials are retained. The cluster commands manage which GRID cluster the CLI uses. Use cluster list to see configured clusters, cluster show to inspect one, and cluster use to switch clusters. Development builds can also select local or SSH nodes. The example above uses GRID production. In grid-stage, use portal-stage.generalrobotics.dev; for a private deployment, use your own portal’s host. When adding a cluster, enter its full portal URL:
Adding a cluster also selects it. The interactive URL prompt shows the production Portal in grid and the Stage Portal in grid-stage as its example. In the interactive shell, run cluster show, use the arrow keys to select a cluster, and press Enter to inspect it. Press Esc to cancel. Inspecting details does not change the active cluster. Terminal and automation invocations need an explicit host. Use cluster use <host> to switch clusters. Cluster details show the stored API key’s name and team when the portal permits that lookup, alongside your team memberships. If metadata is unavailable, the CLI says so; a missing lookup does not mean the key is personal. Portal permissions can allow team membership lookup while denying API-key details, so your teams may appear even when the key name or key team is unknown. The key value is never displayed. Metadata lookups use an existing, unexpired portal login; log in again if those details are unavailable because it expired. A robot’s team comes from the API key used to register it. A key with no team registers a personal robot. Membership in several teams does not choose one for setup. The robot-add summary describes the selected API key; retaining an existing robot configuration does not change its team automatically.

​
Add a robot and open a development workspace

Replace lab-robot with your robot’s name. robot add collects its connection and configuration. skill run --dev opens a development workspace in the current directory. Pass a directory to use another project:
Use the configured editor’s terminal to iterate on Python files and notebooks. The CLI prepares the workspace’s interpreter and connection settings.

​
Run an existing Python file

The CLI’s skill run command accepts a Python file. It does not require a skill manifest or registry entry. The script controls its program logic, including any calls to other skills.
The first --robot selects the CLI target. Everything after -- is passed to the Python script unchanged. This example assumes the script itself accepts --robot; replace those trailing arguments with the arguments your script actually defines. Selecting a CLI robot does not invent arguments for a script. The script and its dependencies must be suitable for the selected robot. In the interactive shell, omitting the CLI’s --robot opens the robot picker. Without --, supported script arguments can be edited in a form. Headless invocations require an explicit robot and any required script arguments.

​
Development mode and deployment mode

  • skill run --dev opens a workspace. It does not execute a supplied script.
  • skill run file.py runs the file directly. If the script supports the deployment contract, the CLI supplies --mode dev.
  • skill run file.py --deploy requires the script to accept --mode deploy. The CLI supplies that mode and asks for confirmation. It rejects ordinary scripts that do not support the contract.
Do not pass your own --mode after --; the CLI owns it for scripts using this contract. --deploy is not a general-purpose upload command for arbitrary Python files.
These inspect and stop runs started from this machine. You can also supply a run ID when several runs exist.

​
Develop and validate in simulation

sim start creates a simulation session. sim open opens a running session’s browser workspace, where you can develop and test programs using the simulation SDK. With multiple running sessions, pass the session ID or choose one in the interactive shell. sim list shows simulation sessions in the selected cluster, including ended cloud sessions. It is not a list of available VMs. A session is the allocation you start and stop; its runtime and GPU resources serve that session. Adapt the program to the simulation backend and available robot APIs. The CLI does not currently provide a skill run --sim option or automatically turn an arbitrary physical-robot script into a simulation program. Use sim stop <id> to end a session and release its GPU resources. See the simulation guides for backend-specific development.