Make π0.5 Learn to Call Astra for Reliable Robot Manipulation

Paper: Make pi0.5 Learn to Call Astra for Reliable Robot Manipulation (arXiv:2610.14117v1)

Authors: Jianli Sun, Chengxiang Li, and Yonglin Tian

Affiliations: Institute of Automation, Chinese Academy of Sciences; School of Information and Intelligent Engineering, University of Sanya

Code: KykGeek/Pi05_CALL_Astra under the MIT license. The repository contains the integration runtime, controller, handoff gate, recovery executor, and Astra adapter. It does not distribute the pi0.5 checkpoint, OpenPI installation, trained CALL heads, provider credentials, or experiment artifacts.

One-sentence summary

The work freezes pi0.5 and trains a small local CALL head, with 479,937 parameters, to predict when the policy needs outside help from its existing semantic and action representations; GPT-6 Astra is activated only for selected recovery episodes, raising LIBERO success from 95.5% to 97.5% while limiting Astra to 5.49% of environment steps on three easier suites.

Why a second opinion should not be a permanent subscription

A general reasoning model can inspect a robot scene, reason about an instruction, and propose a corrective action. One straightforward architecture sends every policy proposal to that model for approval. The approach inherits broad world knowledge and can repair mistakes made by a smaller vision-language-action policy, but it also puts a network-dependent, token-intensive model in the normal high-frequency control loop. Correct proposals become as expensive to approve as incorrect ones.

The paper starts from this mismatch. A pi0.5 policy can often execute routine manipulation at useful speed, while GPT-6 Astra can provide stronger embodied reasoning when the ordinary policy is in trouble. The central design question is therefore not whether external reasoning helps. Existing experiments already show that continuous Astra review can improve a hybrid system. The unresolved problem is how to preserve that benefit without paying for external inference when the local proposal is already good.

The proposed answer separates three responsibilities. pi0.5 remains the default controller. A learned CALL detector estimates whether the current policy state is trustworthy. Astra becomes an on-demand recovery specialist. The detector reuses features from the same pi0.5 forward pass that produced the action proposal, so deciding whether to ask for help does not require another visual-language encoder. Control changes hands only after a temporal trigger.

This decomposition is less glamorous than making one model do everything, but it creates explicit engineering boundaries. The fast path has a local policy, a local score, and an action queue. The slow path has a clean queue handoff, a bounded external recovery interface, and a gate that checks whether pi0.5 is allowed to resume. Each transition can be logged and tested rather than hidden inside a single model's prose.

The evaluation is designed around that distinction. The authors report task success, the number of episodes that consult Astra, the smaller number that execute Astra actions, the fraction of environment steps taken by Astra, token usage, and wall-clock action throughput. Separating consultation from intervention is especially important: a system may ask an external model to inspect a state and then decide that the original policy is still the better controller. Such a consultation may be reasonable, but it is not equivalent to an actual takeover and should not be interpreted as one.

Background: action chunks, saved states, and competence labels

The base policy is the OpenPI pi05_libero checkpoint. A query produces a $10\times 7$ action chunk, and the runtime normally executes five actions before asking the policy for another proposal. The chunk is therefore a short plan, not a collection of unrelated one-step labels. A useful assistance detector should inspect both the robot's state and the shape of the plan the policy is about to execute.

Supervision comes from counterfactual continuation rather than human labels. The authors save a simulator state and ask pi0.5 to continue for $M$ independent trials. If $K$ trials succeed, the competence estimate and help target are

$$ q_\pi=\frac{K}{M}, $$ $$ y_{\mathrm{help}}=1-q_\pi. $$

These definitions turn assistance into a soft probability. A state with ten successes out of ten receives a help target of zero, while ten failures receive a target of one. Mixed outcomes preserve the observed uncertainty. Low-competence examples satisfy $q_\pi\leq 0.2$, high-competence examples satisfy $q_\pi\geq 0.8$, and intermediate cases keep their original fractional targets.

The training distribution combines failure states, saved pre-failure trajectories, and normally progressing pi0.5 states from LIBERO-Recovery. This mixture matters because a classifier trained only on catastrophes could learn a crude visual shortcut: if a scene resembles the failure collection, call Astra. Normal trajectories provide evidence about what routine execution looks like. The positive and negative examples also make the soft target meaningful rather than treating every trigger as an unavoidable near-failure.

Data are split by task into training, early-stopping, calibration, and test folds. The paper reports 5,055 competence-state examples across 37 held-out task folds. Runtime deployment contains 37 task-specific heads and two suite-level fallback heads. A known task uses its dedicated model; an unknown task falls back to the suite model. Both normal and hard trigger thresholds are calibrated before evaluation.

How CALL turns hidden policy state into a handoff decision

Figure 1: The paper's system overview. (a) CALL reuses frozen pi0.5 features to decide whether to hand off; (b) counterfactual continuations create competence labels; (c) wrist-camera frames show execution, a CALL trigger, Astra recovery, resumed pi0.5 control, and task completion.

A 3116-dimensional view of local competence

CALL does not encode the image again. A feature hook collects representations from the frozen policy. The input is the concatenation

$$ \begin{aligned} x &= [h_{\mathrm{sem}};h_{\mathrm{act}};u],\\ \dim(x) &= 2048+1024+44=3116. \end{aligned} $$

The first component, $h_{\mathrm{sem}}$, is a masked mean of the final vision-language prefix representation and has 2,048 dimensions. It summarizes the task and visual context available to the policy. The second, $h_{\mathrm{act}}$, pools the final action-token representation and has 1,024 dimensions. It captures how the model is constructing its action plan. The third, $u$, contains eight measured robot-state values and 36 statistics computed from the proposed action chunk.

The 36 action statistics are defined precisely. For a $10\times 7$ chunk, per-dimension means and standard deviations contribute 14 values. The L2 norm of the flattened chunk contributes one. The first action, last action, and their difference contribute three more seven-dimensional vectors. The total is

$$ 14+1+7+7+7=36. $$

Together with eight robot-state values, these features form the 44-dimensional auxiliary branch. A policy may be in an ordinary joint configuration while proposing a sharp or unusually large correction. The first-to-last difference exposes that temporal change, while the norm and per-dimension spread provide a compact description of action magnitude and inconsistency. The detector can therefore respond to an unusual plan even before that plan has moved the robot far from its current state.

A small model with three input branches

The semantic branch projects 2,048 features to 128, the action branch projects 1,024 to 128, and the state-statistics branch projects 44 to 64. Concatenation produces 320 values, which pass through LayerNorm, a 256-unit linear layer, GELU, another LayerNorm, and a scalar output. The complete CALL head has 479,937 trainable parameters. The base pi0.5 policy stays frozen.

Branch	Input size	Projected size	Purpose
Semantic representation $h_{\mathrm{sem}}$	2048	128	Task, scene, and vision-language context
Action representation $h_{\mathrm{act}}$	1024	128	Internal state of the proposed action plan
State and action statistics $u$	44	64	Robot state, motion scale, and first-to-last change
Fused representation	320	256	Nonlinear combination before scalar scoring

The scalar score is calibrated into a help probability:

$$ p_{\mathrm{help}}=\sigma\!\left(\frac{z_\theta(x)}{T}\right). $$

Temperature $T$ is not an extra source of policy reasoning. It controls how raw logits map into probabilities so that a threshold can be interpreted more consistently across task heads. The ordinary threshold, hard threshold, and temperature are all selected before the final evaluation. This is important because a raw score of 0.6 may mean different things under two task-specific distributions; a locally calibrated probability gives the trigger rule a common operating scale.

Immediate help versus sustained evidence

A single high score can be noise, but waiting for many confirmations can be unsafe when the state is degrading quickly. CALL handles both cases with a disjunctive trigger:

$$ \begin{aligned} \mathrm{CALL}_{t} ={}& \left[p_{t}\geq\tau_{\mathrm{hard}}\right]\\ &\lor \left[\sum_{j=0}^{4}\mathbf{1}(p_{t-j}\geq\tau)\geq 4\right]. \end{aligned} $$

The hard threshold fires immediately. The second condition requires at least four of the last five policy-query scores to exceed the ordinary threshold. After a trigger, the system enters a six-query cooldown so that control does not oscillate between the two models. Under normal execution, five actions are consumed between queries. The detector therefore operates at proposal cadence rather than simulator-step cadence, which balances early detection against repeated policy inference.

The trigger is evaluated wherever pi0.5 produces a new proposal, not on every execution step inside an already accepted chunk. This detail is visible in the public controller and is also reflected in the method description. It means the action statistics describe the plan that would have been executed, and a handoff must prevent the remainder of that plan from leaking into Astra's recovery phase.

flowchart LR
    O[External and wrist observations] --> P[Frozen pi0.5 policy]
    P --> A[10x7 action chunk]
    P --> S[Semantic feature h_sem]
    P --> H[Action feature h_act]
    A --> U[8 state values and 36 action statistics]
    S --> C[3116-D CALL head]
    H --> C
    U --> C
    C --> D{Calibrated help score}
    D -->|CONTINUE| E[Execute five actions]
    D -->|Hard threshold or 4 of 5| X[Clear remaining pi0.5 queue]
    X --> R[Astra observes and proposes recovery]
    R -->|30 to 50 EEF corrections| V[Execute bounded recovery chunk]
    V --> F[Refresh observation and policy proposal]
    F --> R
    R -->|Return control| G[Fresh pi0.5 proposal]
    G --> P
    E --> P

Handoff as a control-ownership protocol

Before Astra receives control, the host clears the remaining pi0.5 action queue. This is a semantic requirement, not housekeeping. If Astra starts a correction while queued pi0.5 actions continue to execute, the resulting trajectory mixes two controllers and cannot be attributed cleanly. Astra receives both external and wrist RGB images, the task instruction, measured robot state, the original pi0.5 proposal, and execution history. The queue boundary makes the external model the sole source of the next environment actions.

Astra can return control immediately or issue an end-effector correction. In chunk mode it may return 30 to 50 one-step EEF corrections. The host validates and executes the full chunk sequentially, with one correction per LIBERO environment step. It then refreshes the observation and asks pi0.5 for a new proposal before Astra decides whether to continue recovery. The bounded chunk prevents the external model from committing to an indefinitely long trajectory based on a single stale observation.

The return path is guarded as well. pi0.5 may resume only from a complete synchronized recovery checkpoint. The re-entry gate checks that recovery completed, the task has not already succeeded, the executor marked the state safe, intervention and resume step numbers agree, required visual views exist, and robot state is finite. A successful task does not resume because there is nothing left to control. An invalid or incomplete checkpoint keeps the system in the handoff state rather than executing an old plan.

Recovery blocks are not the same as full autonomy. Astra decides within a constrained interface, and the host owns observation refresh, action validation, step counting, termination, and the conditions for returning control. This separation is useful for safety review: the external model supplies local reasoning, while the testable runtime supplies ownership transitions and resource limits.

Source-level correspondence

The public implementation in models/call_astra_v1_head.py matches the branch dimensions and the compact MLP described in the paper. It defines the semantic, action, and state-statistics inputs, then projects them to 128, 128, and 64 dimensions before the 256-unit body.

SEMANTIC_DIM = 2048
ACTION_DIM = 1024
STATE_STATS_DIM = 44
_BRANCH_OUTPUT_DIMS = {"semantic": 128, "action": 128, "state": 64}

self.body = nn.Sequential(
    nn.LayerNorm(body_input_dim),
    nn.Linear(body_input_dim, hidden_size),
    nn.GELU(),
    nn.LayerNorm(hidden_size),
)
self.help_head = nn.Linear(hidden_size, 1)

models/action_statistics.py enforces the exact chunk shape and reconstructs the 36 values from means, standard deviations, the flattened norm, first action, last action, and delta. models/call_controller.py performs policy inference, calculates the score, evaluates the trigger, and either returns the full action chunk for continuation or constructs a handoff request containing the instruction, episode and query identifiers, current observation, robot and simulator states, original action chunk, frozen features, score window, thresholds, and decision reason.

This request is more than a convenient function argument. It is a snapshot of why the switch occurred and what evidence the recovery model received. The recovery executor in models/astra/executor.py describes the 30-to-50-action chunk contract and refreshes observation plus policy proposal after a chunk. models/recovery.py implements the conservative re-entry checks. The implementation therefore supports at least four concrete correspondences to the paper: the feature head, action statistics, trigger logic, and synchronization protocol for returning control.

The repository's scope note is equally important. It contains integration code, not model weights, the OpenPI runtime, trained task heads, or provider credentials. Reproduction requires a compatible GPU environment, the pi0.5 checkpoint, the trained fold checkpoints, LIBERO dependencies, the Codex CLI, and an external Astra provider. The public code clarifies mechanism and safety boundaries, but it is not a self-contained replication package.

Experiment setup and task success

The evaluation uses four LIBERO suites: LIBERO-10, Object, Goal, and Spatial. Each suite has ten tasks and each task is run for five episodes. Pure pi0.5 and the hybrid system therefore each cover 200 episodes. The authors measure success, handoff episodes, episodes containing any Astra action, Astra environment-step share, token consumption, and wall-clock action throughput. All experiments are in simulation.

Overall success rises from 191/200, or 95.5%, to 195/200, or 97.5%. The improvement is concentrated entirely in LIBERO-10, which moves from 43/50 to 47/50. Object remains at 50/50, while Goal and Spatial each remain at 49/50. The hybrid system therefore repairs four failure episodes in the hardest suite and does not improve the other three suites because their baseline success is already near the ceiling.

Suite	Pure pi0.5	Astra + pi0.5	Difference	Reading
LIBERO-10	43/50 (86%)	47/50 (94%)	+8 pp	Source of the overall gain
Object	50/50 (100%)	50/50 (100%)	0	Baseline already saturated
Goal	49/50 (98%)	49/50 (98%)	0	No net change
Spatial	49/50 (98%)	49/50 (98%)	0	No net change
Total	191/200 (95.5%)	195/200 (97.5%)	+2 pp	Four additional successes

Figure 2: Success and actual intervention results. The left panel compares task success; the right panel separates episodes containing Astra actions from the fraction of environment steps executed by Astra.

The intervention table gives the success result its operational meaning. Astra is consulted in 61 of 200 episodes, or 30.5%, but executes actions in only 13 episodes, or 6.5%. In 48 consultation episodes, Astra returns control without acting. Across all runs, Astra executes 4,561 of 36,654 environment steps, a 12.44% share. The ordinary policy remains responsible for 87.56% of environment steps.

Suite	Handoff episodes	Astra-action episodes	Astra steps	Step share
LIBERO-10	31/50	9/50	3,485	20.43%
Object	19/50	1/50	132	1.86%
Goal	8/50	2/50	560	8.97%
Spatial	3/50	1/50	384	6.14%
Total	61/200	13/200	4,561	12.44%

On Object, Goal, and Spatial together, Astra acts in only 4/150 episodes and executes 1,076/19,592 environment steps, or 5.49%. This is the clearest evidence that the design approaches selective intervention on easier tasks. The external model is not used as the normal controller; it is called for inspection and occasionally takes a small number of steps. LIBERO-10 is different because its longer and harder tasks expose more states in which pi0.5 needs recovery.

Does CALL trigger where pi0.5 is actually weak?

The authors save 59 first-CALL states and 13 states immediately before Astra's first executed action. They continue each selected state five times with pure pi0.5 and no external consultation. The groups share six states, leaving 66 distinct states and 330 trials. Pure pi0.5 succeeds in 229/295, or 77.63%, of trials from first-CALL states and only 33/65, or 50.77%, from pre-intervention states.

Evaluation subset	Sample size	Pure pi0.5 continuation success
Episodes without Astra consultation	139 episodes	139/139 (100%)
Episodes without executed Astra actions	187 episodes	187/187 (100%)
First CALL states	59 states	229/295 (77.63%)
States before actual Astra action	13 states	33/65 (50.77%)

These numbers support two conclusions at once. First, CALL is not firing on the routine episodes that pi0.5 handles perfectly: all 139 episodes without consultation and all 187 without executed Astra actions succeed. Second, the first trigger still overestimates danger in many states, because pure pi0.5 succeeds in more than three quarters of continuation trials. The detector finds a region of elevated risk, but that region is wider than the set of states where outside action is necessary.

The suite breakdown exposes the difference. At first-CALL states in LIBERO-10, pure pi0.5 succeeds in 103/150 trials, or 68.67%; immediately before an Astra action it succeeds in 25/45, or 55.56%. Goal falls from 25/40, or 62.50%, at first CALL to 3/10, or 30%, before intervention. Object is the counterexample: first-CALL states still succeed in 91/95 trials, or 95.79%. The same trigger event represents very different underlying difficulty across suites.

Object also has a 38% consultation rate, but only one of its 50 episodes executes Astra actions. The authors attribute this to comparatively easy, homogeneous scenes and an overrepresentation of failure states in the training data. The detector may be recognizing visual and action patterns that resemble training failures even when pi0.5 would recover. Because the false-positive state still triggers a consultation, it costs tokens and wall-clock time even if Astra wisely returns control without moving the robot.

This is the paper's most instructive failure mode. Assistance prediction is not the same as intervention-benefit prediction. A state can have low absolute competence and still not benefit from Astra; conversely, a state can have high continuation success and still contain a rare failure that matters. The soft target $y_{\mathrm{help}}=1-q_\pi$ estimates the first quantity from repeated pi0.5 rollouts, but it does not measure the counterfactual improvement obtained by calling Astra.

Token cost and throughput

Astra consumes 2,985,877 input tokens and 190,360 output tokens, for 3,176,237 tokens in total. Dividing the suite totals by 50 episodes gives 48,443.82 tokens per LIBERO-10 episode, 1,985.70 on Object, 8,004.70 on Goal, 5,090.52 on Spatial, and 15,881.19 overall. LIBERO-10 dominates the cost because it has the highest consultation rate and the largest number of executed recovery steps.

The easier three suites average about 5,027 tokens per test episode while retaining 100%, 98%, and 98% success. Of the total input tokens, 2,346,403 reuse prompt context through caching, and the output includes 35,648 reasoning tokens. Caching lowers the practical burden of repeated context, but it does not eliminate the need to transmit current observations, the policy proposal, execution history, and recovery state at each active consultation.

Throughput makes the latency cost explicit. Pure pi0.5 reaches 8.25 environment steps per wall-clock second overall. Hybrid episodes with CALL active and no Astra handoff reach 7.83, while all hybrid episodes together average 2.58. The no-handoff path is close to baseline in every suite: Goal is 8.25 versus 8.17, and Spatial is 6.94 versus 6.79. The large drop in the all-episode average comes from external inference and recovery.

Suite	Astra tokens/episode	Pure pi0.5 throughput	No-handoff hybrid	All hybrid episodes
LIBERO-10	48,443.82	8.84	8.11	1.93
Object	1,985.70	8.54	8.35	4.06
Goal	8,004.70	8.17	8.25	2.97
Spatial	5,090.52	6.79	6.94	4.07
Overall	15,881.19	8.25	7.83	2.58

Figure 3: Astra tokens per test episode on a logarithmic scale, alongside throughput for pure pi0.5, CALL-active no-handoff episodes, and all logged hybrid episodes.

The accurate claim is therefore not that the hybrid system is always fast. It is fast when no handoff occurs, and it spends most environment steps on that path. A recovery episode is substantially slower because it includes an external reasoning turn, observation refresh, and potentially dozens of Astra actions. On a physical robot, that delay could matter for dynamic objects, human interaction, or safety supervision. The reported result demonstrates selective use of a slow expert, not the elimination of slow recovery.

The token and throughput plots also suggest where the next optimization should focus. Episodes that trigger consultation but execute no Astra action are expensive checks with no direct motor benefit. Better recognition of "inspect but do not act" states could reduce context cost without sacrificing the handoff option. Conversely, once an action is taken, batching 30 to 50 corrections amortizes external reasoning over a useful recovery block.

What is genuinely new here?

The main contribution is the integration of four ideas into one operational loop: a frozen VLA, a lightweight help predictor built from its internal state, a temporal trigger, and a bounded external recovery protocol with a conservative return gate. The detector is not merely a confidence threshold on the policy's action logits. It combines semantic, action-token, robot-state, and action-chunk statistics, then calibrates the score by task.

The second contribution is evidence that assistance and execution should be evaluated separately. The system consults Astra in 61 episodes but acts in 13. Reporting only handoff count would exaggerate intervention; reporting only step share would hide the cost of external checks. The distinction between first-CALL difficulty and pre-action difficulty also shows how trigger timing changes the population of states being evaluated.

The third contribution is the control-transfer discipline. Clearing the pi0.5 queue, sending a complete proposal and execution snapshot to Astra, executing a bounded recovery chunk, refreshing observation and proposal, and checking a synchronized resume point are concrete mechanisms that make model switching auditable. These are the parts most likely to transfer to a real deployment, even if the particular CALL architecture is replaced.

The work is not a new general-purpose VLA, a new foundation reasoning model, or a full real-robot safety study. pi0.5 and Astra are external components. CALL is a small auxiliary predictor, and the experiments are a targeted 200-episode LIBERO evaluation. The novelty lies in the selective intervention system and its measured trade-off, not in proving that either large model is superior in isolation.

Limitations and open questions

The authors explicitly identify the Object false-positive problem. The suite consults Astra in 38% of episodes even though pure pi0.5 succeeds in 95.79% of continuation trials from first-CALL states. Only one Object episode executes an action. The training distribution's emphasis on failure states and the suite's homogeneous scenes likely contribute. Future work needs to rebalance data and penalize unhelpful triggers, not merely improve binary failure classification.

The second limitation is the simulation-only scope. LIBERO provides a clean simulator, standardized action conversion, fixed camera setup, and repeatable success checks. A real robot adds calibration drift, occlusion, communication failures, variable latency, and irreversible contact. The paper does not measure how CALL behaves under sensor degradation or how the re-entry gate interacts with low-level safety limits.

The third limitation is task-specific supervision. Thirty-seven task heads require competence examples from the corresponding folds, and the system relies on two suite fallbacks for missing tasks. The experiments do not establish open-world transfer to new embodiments, new object categories, or substantially different action spaces. Action statistics depend on a $10\times 7$ interface, so a new controller may require retraining the representation and recalibrating thresholds.

The fourth limitation is statistical and risk-sensitive. Five episodes per task and 200 total episodes are useful for an initial comparison but provide limited resolution for rare high-stakes failures. The paper notes that little weight is given to such events. A small number of successes repaired in LIBERO-10 is meaningful, but confidence intervals and broader seed coverage would strengthen the claim that the gain is stable.

The fifth limitation is cost when Astra acts. The overall hybrid throughput is 2.58 steps per second, and LIBERO-10 consumes 48,443.82 tokens per episode. Even with prompt caching, external reasoning remains a scarce resource. For deployment, a latency budget should be treated as part of the control objective, along with success and safety. A policy that calls less often but waits longer for each call may still be unsuitable.

There are also several missing ablations. The paper reports the full system but does not isolate the contribution of semantic features, action features, and state statistics, nor does it show how much the hard threshold, four-of-five confirmation, cooldown, or task-specific heads each add. These choices are plausible and mirrored in code, but their marginal effects would tell a reader which parts deserve reuse.

Conclusion

The paper treats external embodied reasoning as an on-demand resource. A frozen pi0.5 policy remains the default controller, while CALL estimates competence from features that are already present in its forward pass. A hard threshold or four of five high scores initiates a handoff. Astra then inspects a synchronized snapshot and may issue 30 to 50 EEF corrections before the host refreshes the state and decides whether recovery should continue or pi0.5 should resume.

Across 200 LIBERO episodes, the hybrid system improves success from 95.5% to 97.5%. On Object, Goal, and Spatial, Astra executes only 5.49% of environment steps and averages about 5,027 tokens per episode. No-handoff execution retains near-baseline speed, but actual intervention is expensive: all hybrid episodes average 2.58 steps per second. These results support the value of selective consultation while making its limitations visible.

The next step is to turn CALL from a difficulty detector into a benefit predictor. A better target would combine the probability that pi0.5 will fail with the expected improvement, latency, and safety impact of an Astra intervention. That would allow the system to distinguish a suspicious but recoverable state from one where an outside correction genuinely changes the outcome. The broader lesson is that an intelligent robot does not need to ask for help constantly; it needs to know when asking will make a difference.