smolvla-tic-tac-toe-games-1-15-120k

SmolVLA SO-101 Tic-Tac-Toe — Games 1–15, 120K

<p align="center"> <a href="https://github.com/Hashtag-Robotics/so101-tic-tac-toe"><img alt="GitHub implementation" src="https://img.shields.io/badge/GitHub-End--to--end_implementation-181717?logo=github"></a> <a href="https://hashtagrobotics.tr/so101-tic-tac-toe"><img alt="Project story" src="https://img.shields.io/badge/Project-Readable_story-ff365d"></a> <a href="https://huggingface.co/datasets/HashtagRobotics/tic-tac-toe-so101-block-a-clean-v1"><img alt="Training dataset" src="https://img.shields.io/badge/Dataset-195_episodes-21b8a6?logo=huggingface"></a> <img alt="LeRobot 0.6.1" src="https://img.shields.io/badge/LeRobot-0.6.1-f3c623"> <img alt="License Apache 2.0" src="https://img.shields.io/badge/License-Apache--2.0-3b82f6"> </p>

A 450.05M-parameter SmolVLA checkpoint fine-tuned for language-conditioned, dual-camera, six-axis SO-101 tic-tac-toe placement.

Abstract

This artifact is a full fine-tune of lerobot/smolvla_base on the 195-episode Hashtag Robotics SO-101 Tic-Tac-Toe dataset. It consumes one six-dimensional robot state, two physical RGB observations, and a templated natural-language placement command. It predicts chunks of 50 six-dimensional joint/gripper actions through SmolVLA's flow-matching action expert.

The checkpoint is the low-level manipulation policy in a larger system. It does not decide which tic-tac-toe move is strategically legal or desirable. In the end-to-end project, a Strands Agent reads game state and selects a legal target, while Strands Robots provides the robot/policy integration seam; the policy converts the selected placement command into physical motion. This separation keeps game reasoning, deterministic validation, and robot actuation independently testable.

This card reports the exact serialized architecture, parameter inventory, training configuration, checkpoint cadence, and evaluation gaps of the pinned artifact. It does not manufacture an offline score or physical success rate where no published result exists.

Documentation map

Artifact identity

Policy contract

<p align="center"> <img src="./assets/model-contract.png" alt="SmolVLA policy input, processing, and action contract" width="96%"> </p>

Physical inputs

The preprocessor's serialized rename map is part of the checkpoint:

{
  "observation.images.top": "observation.images.camera1",
  "observation.images.wrist": "observation.images.camera2"
}

Use these semantic camera roles, not arbitrary USB enumeration order. A swapped top/wrist mapping is a severe distribution shift even when tensor shapes still validate.

State and action axes

Input state and output action are six-dimensional and use the same ordering:

0  shoulder_pan.pos
1  shoulder_lift.pos
2  elbow_flex.pos
3  wrist_flex.pos
4  wrist_roll.pos
5  gripper.pos

The values are normalized with training-set mean and standard deviation by the serialized pre/postprocessors. Visual features use identity normalization in the policy normalization map. Actions are unnormalized after policy output before the robot adapter consumes them.

Declared versus physical cameras

config.json retains the base policy's declared visual feature keys camera1, camera2, camera3, and empty_camera_0. The training preprocessor maps only the two physical dataset streams to camera1 and camera2; camera3 has no dataset mapping, and empty_cameras=1 configures a masked empty view for model compatibility. This release therefore has a two-physical-camera contract, not a four-camera capture system. Consumers should load the serialized preprocessor instead of synthesizing an undocumented third camera.

Action generation

At the dataset rate of 30 Hz, a 50-step action chunk spans approximately 1.67 seconds before runtime replanning or interruption behavior is considered. Operators should bound execution and retain a deterministic emergency-stop path; chunking is not a substitute for safety supervision.

Parameter inventory

The safetensors header contains 500 tensors and 450,046,176 scalar parameters.

<p align="center"> <img src="./assets/parameter-breakdown.png" alt="Model parameter breakdown by module and dtype" width="92%"> </p>

These counts describe the serialized checkpoint, not peak runtime memory. Actual memory and latency depend on framework version, device, attention implementation, batch size, image preprocessing, cache behavior, and execution precision.

Training data

The policy is specialized to the physical arrangement represented by this dataset. Consult the dataset card for task balance, temporal distribution, action/state diagnostics, camera statistics, and licensing status.

Optimization configuration

Training used a single NVIDIA A100 40 GB environment and LeRobot 0.6.1.

The 13.27× value is an optimizer-sample accounting ratio, not a guarantee of exact epochs: the 10% evaluation configuration, sampler behavior, sequence construction, and replacement behavior affect how often an individual frame is seen.

Checkpoint cadence

Six resumable checkpoints are published at 20K-step intervals. The learning rates below come from each serialized scheduler state. Elapsed time is reconstructed from the run identifier and Hub checkpoint commit times.

<p align="center"> <img src="./assets/training-profile.png" alt="Learning-rate schedule and Hub-observed checkpoint cadence" width="92%"> </p>

The resulting approximate throughput is 36.35 presented samples/s at batch size 16. This is a Hub-observed end-to-end cadence, including checkpoint serialization and upload intervals—not a controlled GPU kernel, data-loader, or inference benchmark.

Repository layout

The complete repository is approximately 15.856 GB because it includes the final inference package plus six checkpoint directories containing optimizer and RNG state.

The root inference package consists of seven required files:

config.json
model.safetensors
policy_postprocessor.json
policy_postprocessor_step_0_unnormalizer_processor.safetensors
policy_preprocessor.json
policy_preprocessor_step_5_normalizer_processor.safetensors
train_config.json

Download only those files when optimizer state is unnecessary:

from huggingface_hub import snapshot_download

MODEL_ID = "HashtagRobotics/smolvla-tic-tac-toe-games-1-15-120k"
REVISION = "48a6313b7e4983781dd72919105ca691a77cd26c"

model_dir = snapshot_download(
    repo_id=MODEL_ID,
    revision=REVISION,
    allow_patterns=[
        "config.json",
        "model.safetensors",
        "policy_postprocessor.json",
        "policy_postprocessor_step_0_unnormalizer_processor.safetensors",
        "policy_preprocessor.json",
        "policy_preprocessor_step_5_normalizer_processor.safetensors",
        "train_config.json",
    ],
)

Load-only example

The following reconstructs the policy and its serialized pre/postprocessors without commanding a robot:

from lerobot.policies import make_pre_post_processors
from lerobot.policies.smolvla.configuration_smolvla import SmolVLAConfig
from lerobot.policies.smolvla.modeling_smolvla import SmolVLAPolicy

MODEL_ID = "HashtagRobotics/smolvla-tic-tac-toe-games-1-15-120k"
REVISION = "48a6313b7e4983781dd72919105ca691a77cd26c"

config = SmolVLAConfig.from_pretrained(MODEL_ID, revision=REVISION)
config.device = "cuda"  # Select a device supported by your environment.

policy = SmolVLAPolicy.from_pretrained(
    MODEL_ID,
    config=config,
    revision=REVISION,
)
policy.eval()

preprocessor, postprocessor = make_pre_post_processors(
    config,
    pretrained_path=MODEL_ID,
    pretrained_revision=REVISION,
    preprocessor_overrides={"device_processor": {"device": config.device}},
)

print(type(policy).__name__)
print(config.input_features)
print(config.output_features)

For the guarded robot runtime, camera-role mapping, agent integration, simulation path, E-stop behavior, and task validation, use the versioned project implementation. A generic one-line rollout command is insufficient to reproduce the physical system safely.

Evaluation status

No numeric model result is inserted into Hub metadata because the published artifact does not contain a trustworthy metric record for this 120K checkpoint.

The repository's training configuration records eval_split=0.1 and max_eval_samples=2048, but no numeric evaluation log or metric artifact accompanies this checkpoint. Training loss, checkpoint completion, parameter integrity, and one successful robot video answer different questions; none is a substitute for repeated held-out physical trials.

Qualitative system context

<p align="center"> <img src="./assets/physical-gameplay.gif" alt="Earlier SO-101 tic-tac-toe system completing a physical game" width="86%"> </p>

The sequence above was recorded with an earlier Games 1–5, 80K-step policy in the same project family. It demonstrates the end-to-end agent/policy/robot interaction qualitatively. It is not an evaluation of this Games 1–15, 120K artifact and must not be counted as 120K success evidence.

Recommended evaluation protocol

A. Offline policy evaluation

Construct a revisioned, episode-disjoint evaluation set rather than splitting temporally adjacent frames.

Offline action error is useful for model comparison but does not directly predict closed-loop pick-and-place success.

B. Physical manipulation benchmark

Use at least 10 independent trials for each of the 18 task commands under the canonical setup, then add controlled perturbation suites. Freeze the policy, code revision, calibration, camera transforms, board/piece print revision, and safety thresholds before collection.

Primary outcome:

macro end-to-end placement success
= mean over 18 tasks of successful correct-piece / correct-cell placements

Also report:

• pick success, release success, wrong-piece rate, and wrong-cell rate;
• collision, timeout, intervention, and emergency-stop rates;
• median and P95 completion time;
• per-axis command range and saturation events;
• camera-to-action and command-to-motion latency; and
• trial count plus Wilson or exact binomial confidence intervals.

Evaluate separately under:

1. canonical in-distribution conditions;
2. source-piece translation/rotation perturbations;
3. board translation/rotation perturbations;
4. lighting and background perturbations;
5. partial board occupancy and visual occlusion;
6. camera-pose and calibration drift; and
7. a second mechanically equivalent SO-101 assembly.

C. Game-level system benchmark

Measure the policy and the game-playing agent separately. The agent should be scored on legal move selection and board-state interpretation; the policy should be scored on executing an already validated placement command. End-to-end game completion should additionally count perception errors, illegal-move prevention, turn handoff, recovery, and intervention. This prevents a strategic failure from being mislabeled as a motor-policy failure, or vice versa.

Intended use

Appropriate uses include:

• research and development for the matching SO-101 tic-tac-toe setup;
• controlled comparison of VLA fine-tuning and action-chunking methods;
• simulation, load-only validation, and guarded physical evaluation;
• analysis of two-view language-conditioned manipulation; and
• reproduction or extension of the associated open-source project.

This checkpoint is not a general-purpose game-playing model, not a safety controller, not a collision-avoidance system, and not evidence of reliable autonomous operation outside the recorded task distribution.

Limitations

• Specialized to one robot family, workspace, board, piece geometry, and camera-role arrangement.
• Trained on 18 templated placement commands with limited linguistic diversity.
• Trained without enabled image augmentation in the serialized configuration.
• No published numeric held-out metric for this 120K artifact.
• No published repeated-trial physical benchmark or confidence interval.
• A 50-step open-loop chunk can amplify calibration, latency, or scene-change errors if runtime interruption and replanning are absent.
• Camera swaps can pass shape checks while invalidating semantic input roles.
• camera3 is a retained declaration, not a third physical training stream.
• The policy does not verify tic-tac-toe legality, human presence, collision risk, joint limits, or emergency-stop state.

Safety and deployment boundary

Physical execution requires an independently enforced preflight and runtime safety layer. At minimum, verify calibration identity, joint limits, action dimension/order, control frequency, camera roles, workspace clearance, power state, communication latency, chunk interruption, and an operator-accessible emergency stop. Validate in simulation first, then with bounded low-speed hardware-in-the-loop trials. Do not allow language-model output to bypass deterministic move validation or robot safety gates.

License

The model artifact is released under Apache License 2.0. The training dataset's repository does not declare a dataset license at its pinned revision; the model license does not automatically grant rights to redistribute the underlying dataset.

Citation

If you use this checkpoint, cite the exact revision together with SmolVLA and LeRobot:

@software{hashtagrobotics_smolvla_tictactoe_120k_2026,
  author       = {{Hashtag Robotics}},
  title        = {SmolVLA SO-101 Tic-Tac-Toe: Games 1--15, 120K},
  year         = {2026},
  url          = {https://huggingface.co/HashtagRobotics/smolvla-tic-tac-toe-games-1-15-120k},
  note         = {Revision 48a6313b7e4983781dd72919105ca691a77cd26c}
}

References

• End-to-end project repository
• Readable project story
• Training dataset
• SmolVLA paper
• SmolVLA base checkpoint
• LeRobot
• LeRobot SmolVLA guide
• LeRobot SO-101 documentation
• Strands Agents
• Strands Robots
• Hashtag Robotics