> ## Documentation Index
> Fetch the complete documentation index at: https://servo.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Choose a model

> Point Servo at your checkpoint, read what it expects from your robot, and reach a private bucket.

Servo runs the model you already have. This page covers the handle you get from a path, what inspection tells you before anything is deployed, and how to reach a private bucket.

## Point Servo at the checkpoint

Give Servo the path where the checkpoint lives:

```python your computer theme={null}
import servo

sv = servo.Servo()
model = sv.models.get("hf://allenai/MolmoAct2-BimanualYAM")
```

`get` returns at once and pins the current content of that path; the weights are fetched when you deploy. Use `s3://` or `gs://` for a checkpoint in your own bucket, and `revision=` to pin a Hugging Face commit or branch. A handle never changes under you, so call `get` again to pick up a newer revision. `sv.models.list()` returns every model your team has pointed Servo at with `get`.

## Inspect it against your robot

Resolve the model's contract for one registered robot:

```python your computer theme={null}
robot = sv.robots.get("yam-cell-01")
report = model.inspect(robot)
print(report.compatible, report.reasons)
```

Inspection reads the checkpoint's metadata and the robot's registered type; it runs no inference, allocates nothing, and needs no connected hardware. `compatible` is false when the robot type or its camera and state layout does not match, and `reasons` says why. A compatible model still predicts nothing until `deploy` runs it and `start` binds it to a robot, as the [quickstart](/quickstart) shows.

## What the model expects

The report describes the inputs your robot supplies and the chunk that comes back, here for the YAM checkpoint:

| Field                   | For MolmoAct2 Bimanual YAM                                                                                                                       |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| `cameras`               | `top`, `left`, and `right`, each with the size the checkpoint was trained at; send frames as captured and the model's own processor resizes them |
| `state_dim`             | Fourteen values in training order: left arm joints, left gripper, right arm joints, right gripper                                                |
| `horizon`, `action_dim` | Thirty rows of fourteen channels per chunk, as absolute joint positions                                                                          |
| `dt_s`                  | The spacing between rows, which is the model's cadence and not a request latency                                                                 |
| `channels`              | The name and unit of every action channel, in order                                                                                              |
| `missing`               | Values the checkpoint's metadata leaves unspecified, with the reason                                                                             |

Arm joints use radians. The checkpoint's metadata leaves the joint zero and sign conventions and the physical gripper units unspecified, so confirm them with the model maintainer for a new robot. Send frames as captured and let the model's processor resize them, because pre-resizing changes the input path. The upstream [checkpoint metadata](https://huggingface.co/allenai/MolmoAct2-BimanualYAM/blob/8dcbed66f2380e4393189c303ea72488eb9e63c2/norm_stats.json) holds the normalization statistics.

## What a complete export contains

Keep every file your exporter produced together: the weights, the config that declares the architecture and its features, and the processor files that define observation normalization and action unnormalization. Upload the directory, or an archive of it, to your bucket. If inspection reports an unsupported model family, contact the Servo team with the path.

## Private buckets

For a public path, skip this section. For a private bucket or a gated Hugging Face repository, register the source once from your computer, and `get` resolves it from the path prefix.

<Tabs>
  <Tab title="Hugging Face">
    Make a read token available as `HF_TOKEN` in your environment, then register and verify the repository:

    ```bash your computer theme={null}
    servo source add hf://allenai/MolmoAct2-BimanualYAM --token-env HF_TOKEN
    servo source verify hf://allenai/MolmoAct2-BimanualYAM
    ```
  </Tab>

  <Tab title="Amazon S3">
    Register the AWS role that can read the bucket, give it the trust relationship the command prints, then verify:

    ```bash your computer theme={null}
    servo source add s3://lab-checkpoints/ --aws-role arn:aws:iam::123456789012:role/servo-reader
    servo source verify s3://lab-checkpoints/
    ```
  </Tab>

  <Tab title="Google Cloud Storage">
    Register the Google Cloud identity that can read the bucket, complete the workload identity trust the command prints, then verify:

    ```bash your computer theme={null}
    servo source add gs://lab-checkpoints/ --service-account servo-reader@lab.iam.gserviceaccount.com
    servo source verify gs://lab-checkpoints/
    ```
  </Tab>
</Tabs>

Verification checks the credential and the trust; `get` checks access to the files at the path. No secret ever appears in a path.

## You now have

* A model handle pinned to one revision.
* A compatibility report for your robot, read before any capacity exists.

## Next

<CardGroup cols={2}>
  <Card title="First motion" icon="hand" href="/guides/first-motion">
    Preflight without motion, then a guarded 30-second episode.
  </Card>

  <Card title="Keep your own loop" icon="rotate" href="/guides/your-loop">
    The two calls under `run`, and a session that keeps its connection.
  </Card>
</CardGroup>