CLIFT Pushes Gemini Robotics to Near-Perfect Task Mastery

Q: What is CLIFT and how does it improve humanoid robot performance?

CLIFT (Closed-Loop Iterative Fine-Tuning) is a method that converts deployment-time reward feedback from a real humanoid robot into supervised training data compatible with a managed fine-tuning API. By iterating this process — deploy, collect rewarded rollouts, fine-tune via API, repeat — it achieves closed-loop policy improvement without requiring access to model weights, gradients, or training internals. The paper reports near-perfect task success after two such cycles on Gemini Robotics On-Device.

Q: What is a managed SFT API in robot foundation models?

A managed supervised fine-tuning API allows downstream users to submit labeled training data to a proprietary model provider and receive back a fine-tuned policy, without ever accessing the underlying model weights or training infrastructure. It mirrors the fine-tuning APIs offered in the LLM space. For robot foundation models, this is increasingly the commercial access paradigm — you get the capability of a large proprietary model without the provider exposing their core IP.

Q: Why does pure imitation learning fall short for contact-rich humanoid tasks?

Demonstration data captures nominal task execution but doesn't cover the full state distribution a deployed robot encounters: novel object configurations, controller-specific latency, actuator tracking dynamics, and failure modes that never appear in clean human demonstrations. For agile manipulation tasks where contact forces and precise timing matter, this demo-to-deployment gap is large enough that policies trained purely by imitation consistently fall short of deployment-level mastery.

Q: How does CLIFT differ from standard reinforcement learning on humanoids?

Standard RL on a humanoid requires access to policy internals — gradients, loss functions, or at minimum the ability to compute policy likelihoods — to update model weights based on reward signals. CLIFT sidesteps this entirely: reward signals from real hardware rollouts are used only to select and label data, which is then submitted as supervised training examples through the API. No internal model access is required at any point.

Q: Does CLIFT work across different humanoid platforms, or only on GROD?

The paper instantiates CLIFT specifically on a real humanoid running Gemini Robotics On-Device. The method is conceptually platform-agnostic — it requires only that the platform's model provider offers a managed SFT API — but whether the flywheel cycle count and performance gains transfer to other embodiments and model pairings is an open empirical question not addressed in this work.


# Does Closed-Loop Fine-Tuning Unlock Humanoid Task Mastery Without Model Access?

Two flywheel cycles. That's all CLIFT needed to push Gemini Robotics On-Device (GROD) to near-perfect success on agile, contact-rich humanoid manipulation tasks — without ever touching model weights, gradients, likelihoods, or internal losses. The result, published August 3, 2026 by researchers from UC Berkeley and Google, is one of the most practically significant fine-tuning results for deployed humanoids to date, and it reframes a question the field has been quietly wrestling with: when robot foundation models are locked behind managed APIs, is reinforcement learning permanently off the table?

According to the paper, the answer is no — but getting there requires rethinking what "closed-loop" means in a weight-restricted world.

**The core finding:** Direct supervised fine-tuning (SFT) through the managed API substantially outperforms a leading open-weight [Vision-Language-Action Model](https://humanoidintel.ai/glossary/vision-language-action-model) trained on identical demonstrations, yet still fails to reach deployment-level mastery on contact-rich tasks. CLIFT closes that remaining gap by converting deployment-time reward signals into API-compatible supervised training data, enabling iterative closed-loop improvement within the API's constraints.

---

## The Managed API Problem No One Wants to Admit

The LLM industry normalized managed fine-tuning APIs years ago. You submit data, receive a tuned model, never see the weights. For language, this works well enough — the distribution shift between training and deployment is bounded, and pure [imitation learning](https://humanoidintel.ai/glossary/imitation-learning) via SFT gets you far.

For humanoids, the same approach hits a harder wall. The CLIFT paper identifies exactly why: novel states, action tracking dynamics, latency, and controller-specific failure modes create a gap between what the policy learned from demonstrations and what it actually needs to do when deployed on a real robot body. This is the sim-to-real problem's less-discussed cousin — call it the demo-to-deployment gap — and it's particularly vicious for agile manipulation where contact forces matter and timing is unforgiving.

The closed-weight API regime, as the authors frame it, restricts policy improvement to pure imitation. You can't run RL on a model you can't see inside. You can't use policy gradients. You can't compute losses. You're working with supervised data submission and that's it.

This is the practical reality facing most commercial humanoid operators today. Unless you're [Physical Intelligence (π)](https://humanoidintel.ai/companies/physical-intelligence) with a fully open training stack, or running your own in-house VLA infrastructure, you're almost certainly interfacing with some flavor of managed model API. The question of how to improve policies in that regime isn't academic — it's the bottleneck for every enterprise deploying humanoids on contact-rich tasks.

---

## What CLIFT Actually Does

CLIFT — Closed-Loop Iterative Fine-Tuning — operates on a deceptively simple insight: you don't need access to model internals to run closed-loop improvement. You need reward signals and iteration.

The method works as follows:

1. Deploy the current policy on the real humanoid running GROD
2. Collect rollouts and assign reward feedback based on task outcomes
3. Convert those reward-labeled rollouts into supervised training examples compatible with the managed SFT API
4. Submit to the API, receive an updated policy
5. Repeat

The authors call these cycles "flywheel cycles." By their account, two cycles were sufficient to reach near-perfect success on the target tasks. The paper describes this as doing closed-loop improvement "without opening the model box" — the reward signal is external, the training data format is standard, and the API never needs to expose anything proprietary.

Critically, the paper notes this is "one of the first empirical studies of managed-API adaptation on a real humanoid." That qualifier matters. Simulation results on this class of problem are plentiful; real hardware results on actual humanoid platforms are not.

---

## The Open-Weight Baseline Result Deserves Attention

The paper's comparison between GROD-via-SFT-API and a "leading open-weight VLA trained on the same demonstrations" is one of the more pointed data points in the work. The source text states directly that direct SFT through the API "substantially outperforms" the open-weight VLA baseline.

The authors don't name the open-weight VLA they benchmark against — a deliberate choice that should prompt some skepticism about the generalizability of this comparison. Performance gaps between VLA architectures on specific manipulation tasks are notoriously task-dependent, and "substantially outperforms" without a defined success-rate delta is a claim that wants numbers behind it in the full paper.

That said, if the result holds at even moderate statistical power, it's a meaningful signal for the field: the performance advantage of large proprietary foundation models may be durable enough that even a restricted managed API interface beats the full flexibility of an open-weight alternative. That's a real tension for operators who prefer open stacks for customization, auditing, and cost reasons.

---

## Why Contact-Rich Humanoid Manipulation Is the Right Stress Test

The choice of agile, contact-rich tasks as the evaluation domain is deliberate and correct. This is where pure imitation learning fails most visibly on real humanoids.

[Dexterous manipulation](https://humanoidintel.ai/glossary/dexterous-manipulation) tasks that require sustained contact — tightening fasteners, inserting connectors, handling compliant materials — expose all the failure modes the paper identifies: novel states not covered in demonstrations, latency between policy output and actuator response, controller-specific dynamics that differ from whatever hardware the foundation model was originally trained on. These aren't edge cases. They're the core of what industrial humanoid deployments actually require.

The CLIFT approach's near-perfect success after two cycles on these task classes, if it generalizes, suggests a practical deployment playbook: initial SFT via API, two rounds of on-hardware reward collection and iterative fine-tuning, and you're at deployment-level mastery without needing to own or modify the underlying model.

---

## Industry Trajectory Implications

The managed API fine-tuning paradigm is going to be the dominant access model for powerful robot foundation models for the foreseeable future. Google's GROD, and any successors, will be available to partners and enterprise customers in this form. The alternative — open-sourcing models trained on proprietary robot interaction data at scale — is not commercially rational for the companies building them.

CLIFT's contribution is demonstrating that this constrained access model is not a ceiling. The flywheel cycle approach effectively smuggles closed-loop RL-style improvement into a regime designed to prevent it, using nothing more than reward-labeled rollout data and standard API calls. That's a meaningful unlock.

The broader implication for humanoid operators: data flywheel infrastructure — the ability to systematically collect deployment rollouts, label them with reward signals, and pipe them back into fine-tuning APIs — may matter as much as the underlying model choice. Companies like [Skild AI](https://humanoidintel.ai/companies/skild-ai) building general-purpose robot AI stacks will need to think about how their architectures support or obstruct this kind of iterative deployment-time improvement loop.

The research also raises a practical question for operators using multiple humanoid platforms: does CLIFT's flywheel approach transfer across embodiments, or is each robot-model pairing its own separate closed loop? The paper instantiates on a single platform (a real humanoid running GROD), and that embodiment-specificity question is likely the most important open thread for follow-on work.

---

## Key Takeaways

- **CLIFT achieves near-perfect task success in two flywheel cycles** on agile, contact-rich humanoid manipulation using Gemini Robotics On-Device, without accessing model weights or gradients
- **Direct SFT via managed API substantially outperforms** a leading open-weight VLA trained on identical demonstrations, according to the paper's findings
- **The method converts deployment-time reward signals into API-compatible supervised data**, enabling closed-loop improvement within the strict constraints of a managed fine-tuning API
- **This is among the first empirical studies of managed-API adaptation on a real humanoid**, making the hardware validation unusually significant
- **The managed API paradigm is the dominant near-term access model** for powerful proprietary robot foundation models — CLIFT suggests it's not a hard ceiling on policy quality
- **Data flywheel infrastructure** — systematic rollout collection, reward labeling, and iterative API submission — emerges as a critical operational capability for humanoid deployers

---

## Frequently Asked Questions

**What is CLIFT and how does it improve humanoid robot performance?**
CLIFT (Closed-Loop Iterative Fine-Tuning) is a method that converts deployment-time reward feedback from a real humanoid robot into supervised training data compatible with a managed fine-tuning API. By iterating this process — deploy, collect rewarded rollouts, fine-tune via API, repeat — it achieves closed-loop policy improvement without requiring access to model weights, gradients, or training internals. The paper reports near-perfect task success after two such cycles on Gemini Robotics On-Device.

**What is a managed SFT API in robot foundation models?**
A managed supervised fine-tuning API allows downstream users to submit labeled training data to a proprietary model provider and receive back a fine-tuned policy, without ever accessing the underlying model weights or training infrastructure. It mirrors the fine-tuning APIs offered in the LLM space. For robot foundation models, this is increasingly the commercial access paradigm — you get the capability of a large proprietary model without the provider exposing their core IP.

**Why does pure imitation learning fall short for contact-rich humanoid tasks?**
Demonstration data captures nominal task execution but doesn't cover the full state distribution a deployed robot encounters: novel object configurations, controller-specific latency, actuator tracking dynamics, and failure modes that never appear in clean human demonstrations. For agile manipulation tasks where contact forces and precise timing matter, this demo-to-deployment gap is large enough that policies trained purely by imitation consistently fall short of deployment-level mastery.

**How does CLIFT differ from standard reinforcement learning on humanoids?**
Standard RL on a humanoid requires access to policy internals — gradients, loss functions, or at minimum the ability to compute policy likelihoods — to update model weights based on reward signals. CLIFT sidesteps this entirely: reward signals from real hardware rollouts are used only to select and label data, which is then submitted as supervised training examples through the API. No internal model access is required at any point.

**Does CLIFT work across different humanoid platforms, or only on GROD?**
The paper instantiates CLIFT specifically on a real humanoid running Gemini Robotics On-Device. The method is conceptually platform-agnostic — it requires only that the platform's model provider offers a managed SFT API — but whether the flywheel cycle count and performance gains transfer to other embodiments and model pairings is an open empirical question not addressed in this work.