ACT vs GR00T N1.7: the two extremes of the catalog

The one question that decides it

Will the policy ever face a situation your demonstrations did not contain? If the honest answer is no, because the part arrives in a jig and the camera is bolted to a frame, ACT wins on latency, price, reproducibility and how easy it is to reason about. If the answer is yes, ACT has nothing to fall back on: everything it knows came from your episodes, and outside them it is guessing without priors. Everything below is detail underneath that question, and the two models are far enough apart that there is no middle case where they are interchangeable.

Side by side

The parameter counts mislead in both directions

Three billion against eighty million sounds decisive until you look at what fine-tuning touches. Roughly forty million of GR00T’s parameters are trained, the same order of magnitude as the whole of ACT, so in terms of what your dataset has to teach the two jobs are closer than the headline suggests. The difference is what the training starts from. ACT constructs every visual feature and motor pattern out of your fifty episodes; GR00T starts from a representation built on a multi-robot corpus and spends your episodes pointing it at your task.

Two schedules that describe two different jobs

ACT         batch 8  accum 1  lr 1e-5  100 000 steps  ~800 000 sample views  24 GB
GR00T N1.7  batch 32 accum 1  lr 1e-4   20 000 steps  ~640 000 sample views  80 GB

Similar sample budget. Five times the optimizer steps on ACT at a tenth
of the learning rate: building a representation rather than nudging one.

ACT runs the longest schedule in the catalog, one hundred thousand steps, and still fits the two to five hour estimate because each step is small. GR00T reaches a comparable number of sample views in twenty thousand steps because it processes thirty-two at a time. Those two lines tell you more about the models than any adjective would.

Latency, and where it stops mattering

Twenty milliseconds is about fifty action steps a second, so the policy stops being the slowest part of the loop. One hundred and fifty-two milliseconds is six to seven a second, fast enough that a pick and place looks purposeful. ACT also has chunking exposed, chunkSize and nActionSteps at 100 by default, so it predicts and executes a block between inferences. GR00T exposes no chunk controls. If cycle time is a specification rather than a preference, ACT is the model with the knobs.

Reproducibility is an ACT advantage people forget

ACT exposes seed and logFreq alongside its chunk parameters. GR00T exposes only saveSteps and has no seed field, so two GR00T runs with the same settings on the same data are not guaranteed to be the same run. For a production policy that rarely matters. For a lab notebook or a report somebody will try to reproduce in three months, it matters a great deal, and no amount of discipline works around it.

Pick ACT if

• You are building a repeated cell: same jig, same part, same camera, cycle time in the specification. Fifty action steps a second with a tunable horizon is something GR00T cannot offer at any price.
• You want the answer for 1 to 3 USD instead of 4 to 12, and the trained policy on a 24 GB card you own rather than in a rented pool.
• You are writing the work up. A seeded run with documented chunk parameters is defensible in a way an unseeded foundation-model fine-tune is not.

Pick GR00T N1.7 if

• The object can appear anywhere in the workspace and you cannot demonstrate every placement. This is the case pretraining exists for.
• The task string has to matter. GR00T is language conditioned; ACT has no text input, so a second task means a second dataset, run and checkpoint.
• You already have a hundred or more episodes and an ACT policy that plateaued in a way more episodes of the same kind did not move.

What each one still does better

ACT, if you chose GR00T

Faster, cheaper, seedable, tunable, and it runs on hardware you can own. It is also honest in a way large models are not: with no pretraining, every behavior came from an episode you recorded, so a strange motion is always traceable to demonstrations you can go and watch.

GR00T N1.7, if you chose ACT

It generalizes, it reads the task string, and it gets through its schedule in a fifth of the optimizer steps. On a dataset large and varied enough, those priors separate a policy that works in your test setup from one that survives somebody rearranging the table.

Train ACT first even if you intend to use GR00T

ACT is the cheapest truth-teller you have about a dataset. If it cannot learn your task from the placements it was shown, the problem is the data, and GR00T reaches the same conclusion for four times the money. That holds even when you are certain the foundation model is where you will end up.

1. 1
   Train ACT at its defaults on your first fifty episodes

   Pick the dataset in Training, choose ACT, leave 100 000 steps, batch 8 and 1e-5 alone. Set a seed and write it down with the job id.

2. 2
   Evaluate ten nominal and ten off-nominal attempts

   Half from the region your episodes cover, half from outside it. That split is the measurement the whole decision rests on.

3. 3
   Read the split, not the total

   Weak on both halves means a data problem and the next step is a recording session. Strong on nominal and weak off-nominal is the GR00T case.

4. 4
   Confirm the dataset is LeRobot v2.1 before you spend

   ACT will happily train on a dataset GR00T then refuses. Check the version before renting the 80 GB card, not after the job fails.

5. 5
   Start GR00T N1.7 against the same dataset id

   Defaults again: batch 32, 20 000 steps, 1e-4. Lower saveSteps for more checkpoints, then re-run the identical attempts and compare the off-nominal half.

curl -s https://www.ay-robots.com/api/mcp \
  -H "Authorization: Bearer $AY_ROBOTS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{
        "name":"start_training",
        "arguments":{
          "dataset_id":"ds_7f31c0a4",
          "policy_name":"cube pick, act baseline",
          "model_id":"act",
          "max_steps":100000,
          "confirm_spend":true}}}'

# Then the comparison run: "model_id":"groot1.7", "max_steps":20000.
# chunkSize and nActionSteps are ACT-only and live in the web form, not here.

Nothing here is a one-way door

The dataset is the durable part of this project. Cameras, resets, task strings and discarded failures are hours you spent once; a checkpoint is a few hours of a card somebody else owns. Both models read LeRobot v2.1, so moving from the 24 GB tier to the 80 GB one is a new job against the same dataset id with a different value in one field.

Where to go next

• /policies/act: the specialist, its knobs and its ceiling
• /policies/groot-n1-7: the generalist and what it costs to rent
• /train/act-on-so-100: the 24 GB route, start to finish
• /train/groot-n1-7-on-so-100: the 80 GB route on the same arm
• /learn/train-your-first-policy for why the small model goes first

Frequently asked questions