Model and runtime artifact
A checkpoint contains learned parameters and configuration. An export prepares an artifact for a particular runtime. Check the expected inputs and actions, then compare exported behavior with the reference.
Tether Studio / The interface for TetherRun and improve policies
Run and improve policies
through one workspace.
Tether Studio: Private beta
Tether Studio is a robot policy desktop app in private beta. Record demonstrations, check datasets, and develop policies using your own compute. Download the macOS or Linux beta and read its verification limits before starting.
Example journey / Product directionThe policy is too slow.
The policy is too slow.
Does a faster version still work?
Suppose your policy misses its timing budget. You want to try an optimization without losing task performance. This example explains the intended workflow; it is not a customer result or a claim that every step is verified in the private beta. Read the beta verification limits.
- 01
Record the baseline.
Choose the model, task, target, and execution settings. Run the baseline and retain its observations, actions, timings, and outcomes so the candidate has a meaningful reference.
- 02
Inspect where time is spent.
Select a slow request and examine the recorded timing breakdown. Identify whether the evidence points toward inference, transport, or another part of execution before choosing a change.
- 03
Prepare one candidate.
Choose a compatible inference setting or acceleration path. Preserve the baseline and record the exact settings or exported artifact that define the candidate.
- 04
Repeat the comparison.
Test under matching task conditions. Inspect the timing change alongside success and failure counts, action differences, and any regressions.
- 05
Keep the evidence with the decision.
Keep the baseline if the tradeoff is unacceptable, or select the candidate for further evaluation. Carry the results and outstanding checks into deployment review.
What you take forward
An identifiable candidate, a matched comparison, and a saved decision. Faster inference alone does not establish a better policy.
Understand the setupModel, compute,
Model, compute,
connection, target.
Tether handles the underlying runtime operations. Studio’s role is to make their configuration and results understandable in one workspace.
Compute
Inference runs on the selected compute target. Model compatibility, memory, and runtime support determine which execution paths make sense. The machine running the interface and the machine running inference can have different roles.
Connection
The simulator or robot sends observations to the policy service and receives actions. Transport, authentication, timing, and failure handling are part of this connection, not properties of the model weights.
Simulator or robot
The target supplies observations and interprets actions through its configured mapping. Keep units, action dimensions, control timing, and target constraints explicit. A matching tensor shape does not establish a correct physical mapping.
Choose what to changeFaster execution.
Faster execution.
Different learned behavior.
Optimization and training lead to different candidates. Studio should help you choose the appropriate operation, preserve the baseline, and evaluate the result.
Optimize execution
Investigate the measured bottleneck, then choose a compatible export, acceleration path, cache policy, or inference setting. Many such changes preserve the source checkpoint but still alter numerical results or action behavior.
Fine-tune a policy
Use a selected dataset to update learned parameters for your task. Preserve the starting checkpoint, training configuration, examples, and resulting checkpoint so the change can be reproduced and evaluated.
Distill a policy (planned)
Planned, not in the private beta. Use a teacher to train a student policy. Keep the teacher, student configuration, training data, and outputs identifiable. Evaluate whether the student meets the task and performance requirements.
Compare the result
A candidate may improve latency, task outcomes, both, or neither. Review matched experiments and a separate holdout evaluation where appropriate. Keep regression evidence with the decision.
A closer lookQuestions about
Questions about
the workflow?
Open a topic for more detail on the decisions and requirements behind each step.
How is the workspace organized?
Workspace brings the current policy, execution view, inspector, and timeline together. Runs keeps recordings and comparisons available for review. Devices covers connections, installed versions, and deployment or recovery.
Models, datasets, jobs, and reports belong in the Assets drawer and relevant workflows. Assistance opens when requested; ordinary operations remain available through direct controls.
Link to this explanationWhat is the relationship between Tether and Studio?
Tether supplies the runtime and tools for preparing, serving, optimizing, inspecting, improving, and reviewing robot policies. Studio is the desktop workspace in private beta around those capabilities.
The goal is to expose the relevant configuration, validation, job progress, and outputs through one connected interface while keeping the underlying operations consistent.
Link to this explanationWhat goes into the first run?
Start with a model or checkpoint, its expected observations and actions, the task, and the simulator or robot target. Review compatibility, compute, connection, and execution settings before running.
A recording should preserve the configuration actually used, including policy identity and repeatable experiment settings. That makes the next run or comparison easier to set up.
Link to this explanationWhat does optimization involve?
Depending on the model and target, optimization may involve export and acceleration paths, runtime execution settings, caching, or inference-step configuration. The useful choices depend on compatibility and the bottleneck you measured.
Tether includes model-specific ONNX, TensorRT, and fast-inference work. Studio’s role is to guide the applicable operation and help compare the result. Export parity, latency, and task behavior need separate checks.
Link to this explanationHow do failures become improvement jobs?
Select a failure or segment and inspect the available evidence. Decide whether to change configuration, collect examples, prepare a dataset, or configure a supported fine-tuning job.
Keep the job inputs and outputs linked to the source evidence. Compare the resulting candidate with the baseline before selecting it for use.
Link to this explanationWhat belongs in a comparison?
Show the baseline and candidate, what changed, and which test conditions match. Make recordings and per-scenario outcomes available alongside timing measurements.
Separate behavior from performance and deployment readiness. Preserve regressions and missing checks even when an average metric improves.
Link to this explanationWhat happens at deployment review?
Package the chosen version with its settings, dependencies, and relevant evidence. Verify that package against the intended checks, then review the results and outstanding questions before selecting a deployment target.
Deployment sends the selected version to a target. Confirmation establishes what the target acknowledged and which version became active. Keep these outcomes separate from successful package creation or a favorable release recommendation.
Recovery should identify the version to restore and report what happened on the target. Preserve deployment history, comparison evidence, and the recovery plan together so the next decision has a reliable reference.
Link to this explanationWhat is holding
your robot back?
Tell us which policy and target you are working with, and whether setup, performance, behavior, or deployment is the problem.
Discuss your policy workflow