Papers
Topics
Authors
Recent
Search
2000 character limit reached

DIRECT: When and Where Should You Allocate Test-Time Compute in Embodied Planners?

Published 10 Jun 2026 in cs.RO, cs.AI, and cs.CV | (2606.12402v1)

Abstract: Vision-LLMs (VLMs) are increasingly deployed as high-level planners for embodied agents, with an emerging strategy of scaling test-time compute to improve capability. However, we observe that doing so increases latency, token usage, and FLOPs while yielding uneven, often diminishing gains in downstream success, limiting where embodied agents can be deployed. We argue that choosing when and where to spend test-time compute is central to bringing frontier performance to the real world. We introduce DIRECT, a routing framework that uses multimodal scene context to allocate compute per prompt, improving the success--cost Pareto frontier over fixed model selection. Across three dominant scaling axes, namely chain-of-thought depth, model size, and memory history, our experiments on VLABench and RoboMME show that test-time compute is not a uniform lever: different axes yield qualitatively distinct capability gains. We validate these insights on a physical Franka arm in a DROID setup spanning zero-shot manipulation and long-horizon chaining, where our router matches or exceeds a stronger model's success rate at up to 65% lower average latency. Ultimately, our results show that naively scaling test-time compute is wasteful, and that DIRECT can provide frontier-level embodied planning in robotic systems at a fraction of the cost. Project page can be found at jadee-dao.github.io/direct/.

Summary

  • The paper introduces DIRECT, a dynamic inference router that selectively allocates test-time compute to achieve near-frontier task success with up to 65% lower latency.
  • It evaluates multiple planning axes—chain-of-thought depth, model size, and memory augmentation—using embedding-based features for optimal compute routing.
  • Empirical results from VLABench and RoboMME show that DIRECT outperforms static, uniform compute scaling by invoking high-cost planners only when necessary.

Test-Time Compute Allocation in Embodied Planners: The DIRECT Framework

Introduction

The increasing deployment of vision-LLMs (VLMs) as high-level planners for hierarchical embodied agents raises urgent questions about the efficient allocation of test-time compute. Recent practice often allocates compute uniformly by scaling model size, chain-of-thought (CoT) depth, or memory horizon, aiming to bridge capability gaps for complex tasks. However, these strategies entail significant increases in latency and resource demands, particularly when deployed in robotics scenarios where such inefficiencies become operationally prohibitive. This paper introduces DIRECT (Dynamic Inference Router for Embodied Compute Tradeoffs), a selective routing framework that dynamically allocates test-time compute for each inference, optimizing the tradeoff between task success and compute/latency.

Problem Context and Motivation

While VLMs serve effectively as instruction decomposers—mapping high-level language instructions and scene observations to executable skill sequences—indiscriminate upscaling of planner compute leads to wasted resources without consistent downstream gains. Latencies from deliberate reasoning (e.g., CoT prompting) or the use of large models can constrain system applicability in real-world settings, especially in closed-loop robotic control. Baseline model routing approaches (e.g., FrugalGPT, RouteLLM) are limited by their reliance on linguistic features alone and do not consider the multimodal complexity of robotic planning, such as physical scene difficulty or temporal dependencies.

Empirical Analysis: Non-Uniformity of Compute Scaling

The paper presents a systematic investigation into the impact of different test-time scaling axes in embodied planning:

  • Chain-of-Thought Depth: Deliberate planning through CoT can resolve subtler constraints, but many tasks do not benefit. Notably, on VLABench, 44% of cases with Qwen3-VL 8B Instruct matched or outperformed CoT-enabled planners at <2% of the latency, establishing that most tasks can be addressed efficiently without recourse to heavy test-time reasoning.
  • Model Size: Empirical results across Qwen3-VL models (2B–235B) show no monotonic relationship between size and either performance or latency; smaller models sometimes outproduce more expensive ones due to verbosity rather than parameter count. Crucially, gains from larger models concentrate on tasks requiring broader skill coverage, not uniformly across all inputs.
  • Memory Horizon/Augmentation: On RoboMME, lightweight token/frame selection strategies outperform sophisticated memory-augmented variants on easy tasks, while architectures like MemER and GroundSG excel only on the hardest tasks requiring long-horizon recall. This reveals the absence of a dominant memory scheme and substantiates the necessity for per-task adaptation.

The DIRECT Routing Framework

Router Architecture

DIRECT formulates embodied test-time compute allocation as a selection problem over a fixed pool M={m1,,mK}\mathcal{M} = \{m_1, \ldots, m_K\}, each a VLM planner with distinct quality–cost characteristics. For each input (I,)(I, \ell)—scene observation and instruction—DIRECT encodes multimodal context with a frozen SigLIP-family vision encoder and BGE-M3 text encoder, concatenating these to obtain task features ϕ(x)\phi(x). The router is instantiated via efficient architectures (Linear, KNN/PR-KNN, MLP, k-means, OVR), keeping inference overhead negligible relative to any planner call.

Figure 1

Figure 1: DIRECT routes tasks by predicting the planner with the best quality–cost tradeoff given scene and instruction context.

Data Collection and Synthetic Training

For each planner, quality (QQ) and inference cost (CC) are measured across all training tasks. For real hardware, data collection leverages synthetic task generation and LLM-based scoring to avoid combinatorial cost of full-trajectory robot executions.

Routing Objective

Routing is formulated through utility functions U(q,c)U(q, c) combining quality and cost per planner, supporting regression heads for direct prediction and flexible objective specification (including harmonic mean efficiency metrics to compare routers across cost-quality frontiers).

Evaluation and Deployment

Routers are compared using mean task success and either latency (for autoregressive axes such as CoT reasoning) or FLOPs (for memory/configuration axes). The router predicts the optimal planner for each new task independently, enabling dynamic compute allocation with minimal prediction overhead.

Experimental Results

Chain-of-Thought Routing

DIRECT achieves superior routing efficiency η\eta compared to baselines, consistently matching or exceeding the success rate of costly CoT planners at 30–65% less latency across VLABench, hardware, and real-world robotic evaluations.

Figure 2

Figure 2: DIRECT selectively escalates planner compute, invoking expensive reasoning only where necessary, and routes to minimal planners where adequate, matching frontier-level performance at a fraction of the cost.

Figure 3

Figure 3

Figure 3

Figure 3: Main results corroborate that only a subset of tasks benefit from heavyweight planners across all compute axes.

Direct per-step routing on temporally extended tasks (e.g., grocery bagging) matches high-reasoning planner performance while eliminating unneeded computation on simple steps—a crucial result for real-world robotic viability.

Model Size Routing

DIRECT seamlessly composes capabilities from multiple model sizes. While the standalone performance curve of individual planners is non-monotonic, cumulative routing over size variants produces monotonic, strictly Pareto-optimal frontiers. The router leverages smaller models on basic tasks, escalating to larger models only when necessary for skill breadth.

Memory Routing

On RoboMME, DIRECT traces a success–cost Pareto frontier above all individual memory architectures, spending only as much on memory augmentation as each task requires. No single memory model is optimal across all difficulty tiers or task suites; routing discovers complementary decompositions for optimal efficiency.

Figure 4

Figure 4: DIRECT's routed Pareto frontier for memory routing on RoboMME outperforms all static memory architectures, highlighting the inefficacy of uniform large-memory deployment.

Figure 5

Figure 5

Figure 5: Enlarged memory-routing frontiers split by difficulty and task suite; routing tracks or surpasses the best specialist at reduced TFLOP budgets.

Numerical Highlights and Contradictory Claims

  • In multiple regimes, DIRECT attains the strongest model's average success with up to 65% less latency, which directly contradicts the prevailing assumption that uniform compute scaling is the sole viable path to peak performance.
  • For memory architectures, DIRECT's curve sits strictly above the best individual memory system, indicating that the diversity of induced computations is critical and single-model specialization is suboptimal.
  • Static deployment of large planners results in substantial resource waste on tasks where lightweight planners suffice without degradation in success rate.

Implications and Future Directions

This work demonstrates that effective task-conditioned routing based on multimodal context can routinely subsume the performance of any single planner configuration at a fraction of the cost across multiple axes. The strong results validate embedding-based feature routing for complex embodied planning and indicate that, as diversity in planner architectures grows, router-based dynamic selection is a necessary system design for real-time robotic control.

In practical terms, DIRECT enables deployment of frontier-level VLM-based planners in latency-sensitive, resource-constrained domains by ensuring that high-compute planners are invoked exclusively on tasks with demonstrated marginal utility. Theoretically, this reframes the role of model variety and scaling in embodied AI: planner diversity and dynamic selection should be considered primary control levers, not just brute-force scaling.

A major limitation is that the router operates on a fixed planner pool, requiring retraining for pool changes, and does not synthesize new policies. Future work should investigate continuous planner space traversal via policy interpolation, meta-routing over evolving model families, and tight theoretical bounds on routing regret in embodied task distributions.

Conclusion

DIRECT operationalizes multimodal context-aware test-time compute allocation in embodied planning, attaining near-frontier success metrics at dramatically lower computational and latency costs. Empirical results advocate for embodied AI systems to cast high-level planner selection as a dynamic, context-sensitive optimization, rather than as a single static choice. This work suggests that embedding-based router architectures, lightweight and efficient, are sufficient to realize most of the available gains in cost-aware planning and underscores the need for continued research in dynamic system orchestration for real-time robotics.

Figure 6

Figure 6: Held-out test-set Pareto frontiers with DIRECT-selected routers, marking cost–quality tradeoffs that approach the oracle upper bound.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Explain it Like I'm 14

A simple explanation of the paper

What this paper is about (overview)

Robots often use AI models that look at pictures and read instructions to decide what to do next. These models can “think” more or less at test time: they can answer quickly with little thought, or take more time to reason step by step. More thinking usually helps, but it also makes the robot slow and costly to run.

This paper introduces Direct, a tiny “traffic controller” that decides, for each task, how much thinking the robot’s planner should do and which planner to use. The goal is to get almost the same success as the strongest (and slowest) model while using much less time and compute.

The main questions the paper asks

  • When is extra thinking worth it, and when is it just a waste of time?
  • Which “knobs” for spending test-time compute actually help on different tasks?
    • Deeper step-by-step reasoning (called chain-of-thought)
    • Bigger models (more parameters)
    • Longer memory/history (keeping more past frames or summaries)
  • Can a small router read the scene and instruction and pick the cheapest planner that will still succeed on this task?

What they did (methods, in everyday terms)

Think of the robot’s “planner” like a team of different problem-solvers:

  • A fast sprinter (quick but not very deep)
  • A careful thinker (slower but reasons step by step)
  • A bigger brain (knows more skills but is heavier and slower)
  • A planner with a long memory (remembers past steps but costs more to use)

Direct is a tiny coach that looks at:

  • The current camera view(s) of the scene (images)
  • The instruction (text) It then decides which teammate to send in for this specific task.

How the coach learns:

  • The authors collected lots of tasks. For each task, they tried all the different planners and recorded:
    • Quality: how well the task was completed (success or progress)
    • Cost: how long it took (latency) or how much compute it used (FLOPs, which is just the amount of math work)
  • This creates a “map” of which planner works best for which kind of task and at what cost.
  • The coach (router) learns from this map to predict, from the scene and instruction, which planner is the best trade-off for a new task.
  • For real robots (hardware), fully testing every planner on every physical task is impractical. So they also create realistic “synthetic” tasks offline to train the router, and then deploy it on the robot.

Key ideas to know:

  • Chain-of-thought: the model writes out its reasoning step by step before deciding. Helpful, but slow.
  • Model size: bigger models know and can command more kinds of skills, but are slower.
  • Memory/history: giving the planner more past frames or summaries helps with long tasks that depend on what happened before, but adds overhead.
  • Pareto frontier: the best possible trade-offs between success and cost. You can’t do better on one axis without getting worse on the other.

The router itself is very light (milliseconds) compared to any planner (seconds), so the overhead is tiny.

What they found (main results) and why it matters

Here are the most important takeaways, shown in simulation benchmarks (VLABench, RoboMME) and on a real Franka robot:

  • Extra thinking is not always needed:
    • On many tasks, a fast, non-thinking planner does just as well as the slow, thinking version.
    • Example: On one benchmark, the simple planner matched or beat the thinking planner in about 44% of cases—at a tiny fraction of the time.
  • Bigger isn’t always better (alone):
    • Larger planners can command a wider variety of skills, but their benefits come in bursts, not smoothly. Some sizes even run slower than bigger ones due to verbosity.
    • Direct picks the small model for easy tasks and escalates to bigger ones only when a task truly needs those skills, turning a bumpy “scale curve” into consistent improvement with less waiting.
  • Memory helps only when history matters:
    • Memory-heavy planners shine on long, history-dependent tasks, but can slow things down on easy or short ones.
    • Direct learns to turn memory on only when it matters, beating any single memory setting on the success–cost trade-off.
  • Real robot wins:
    • On a physical Franka arm, Direct matched or exceeded the strong model’s success with up to 65% lower average latency.
    • On a multi-step bagging task (heaviest to lightest), it used fast planning on easy steps and switched to deep reasoning on tricky steps, getting high success with much less waiting.

Why this is important:

  • Robots working in the real world can’t wait tens of seconds before every move. Smarter allocation of “thinking time” makes robots more responsive, cheaper to run, and practical outside the lab.

What this means going forward (implications)

  • Smarter compute budgets: Instead of always using the biggest, slowest planner, robots can adapt their “brainpower” per task and even per step. This brings near–frontier performance to real-time settings.
  • Wider deployment: Faster, cheaper planning makes it easier to use robots in homes, warehouses, hospitals—anywhere delays are costly or annoying.
  • General strategy: The idea of a tiny router selecting the right tool at the right time could apply to many AI systems, not just robots.

Limitations to keep in mind:

  • The router chooses among a fixed set of planners it was trained on. If the set changes, it needs retraining.
  • “Cost” (like latency) depends on the device and setup, so exact numbers vary.
  • The router decides per call based on the current scene and instruction; it doesn’t yet model long cross-stage dependencies inside the router itself.

In short: Don’t always crank the “think harder” dial. Use a small coach (Direct) to pick when and where extra thinking, bigger models, or more memory are actually worth it—so robots stay fast, capable, and affordable.

Knowledge Gaps

Knowledge gaps, limitations, and open questions

Below is a single, concrete list of what remains missing, uncertain, or unexplored, framed to guide future research.

  • Online adaptation to changing model pools: Direct is trained offline for a fixed candidate set. How to update the router efficiently when models are added/removed or improved (e.g., new VLM checkpoints, new memory schemes) without recollecting the full Q/C matrix or retraining from scratch?
  • Continual/active learning on-robot: The router does not learn from ongoing execution outcomes or human feedback. Can we design online, budget-aware updates (e.g., bandit or meta-learning) that improve routing with real robot interactions while satisfying safety and latency constraints?
  • Joint routing across combined axes: Experiments route along a single axis at a time (CoT vs. size vs. memory). What policies and utility formulations are needed to jointly route over the full Cartesian pool (e.g., size × CoT depth × memory architecture), including interactions and cross-axis synergies?
  • Granular control of test-time compute: CoT is treated largely as a binary choice (instruct vs. thinking). How to route over fine-grained knobs (variable chain length, number of samples/votes, verifier depth, speculative decoding parameters) and adaptively stop “thinking” early based on confidence?
  • Budgeted, horizon-aware allocation: Routing is myopic and per-call. How to allocate a global compute budget across multi-stage tasks (or multiple concurrent tasks/robots), trading early vs. late-stage computation under deadlines and real-time constraints?
  • Cross-stage dependency modeling: The router conditions on the current observation/instruction only. How to incorporate long-horizon dependencies and plan-wide context (e.g., dependencies between steps, task subgoal structure) without incurring excessive router overhead?
  • Theoretical guarantees and learnability: There is no analysis of regret, sample complexity, or approximation guarantees relative to the oracle. Is the residual gap to the oracle due to irreducible noise or model misspecification, and can stronger routers (e.g., calibrated uncertainty, causal features) provably close it?
  • Robustness to distribution shift: The router’s generalization to new environments, sensors, lighting, and task styles is underexplored. How robust is routing to domain shift (simulation-to-real, household-to-industrial) and to adversarial or out-of-distribution scenes?
  • Data efficiency and labeling fidelity: Q/C collection at scale is costly; hardware training uses synthetic tasks with an LLM judge. What is the sensitivity to the amount/quality of synthetic data, and how reliable are LLM-judged quality labels for training robust routers?
  • Uncertainty- and risk-aware escalation: The router does not expose calibrated confidence. Can it estimate uncertainty to trigger escalation/fallback, enforce worst-case latency bounds, or satisfy safety constraints (e.g., high-stakes steps always use safer planners)?
  • Cost modeling fidelity: Costs are proxied by latency or FLOPs, which vary with hardware, batching, and load. How to build portable cost models (including energy and $ cost) and make routing robust to runtime variability and scheduling effects?
  • Integration with dynamic memory policies: Memory “architectures” are static choices. Can the router select memory content/length adaptively (e.g., learned video/frame/keyframe selection, compression level) and switch memory strategies mid-episode?
  • Interplay with low-level policy quality: Success confounds high-level planning and low-level execution. How to disentangle failures to learn routing that accounts for low-level skill competence, or to co-adapt routing as the skill library evolves?
  • Diagnostic interpretability: What scene/instruction cues drive routing decisions? A systematic error analysis and interpretable feature attribution could reveal failure modes (e.g., misclassification of tasks needing spatial reasoning vs. world knowledge).
  • Safety and verification: Routing errors can trigger unsafe plans or wasted motions. How to integrate verifier models, constraint checks, or formal safeguards before executing plans chosen by cheaper planners?
  • Multi-robot and multi-query scheduling: The framework ignores system-level scheduling when many robots or tasks compete for limited compute. How to route under shared-resource constraints with fairness, priority, and SLA guarantees?
  • Beyond manipulation: The evaluation is focused on language-conditioned manipulation. Does the observed non-uniform benefit of compute—and the routing gains—transfer to mobile navigation, locomotion, human–robot interaction, or partially observable exploration tasks?
  • Coverage of model families: Results emphasize Qwen, GLM, Gemini. Do conclusions hold for other frontier families (e.g., GPT-4o-class, Llama-VL variants), especially with different prompting behaviors and latency profiles?
  • Confidence-triggered replanning: Transition detection triggers replanning, but there is no policy for escalating compute upon detected plan failures or partial progress signals mid-execution. Can online signals guide dynamic re-routing within an episode?
  • End-to-end feature learning: The router uses frozen vision/text encoders. Would task-adaptive or lightly fine-tuned embeddings materially improve routing accuracy without sacrificing speed or overfitting?
  • Generalization to edge hardware: Router overhead is negligible on server GPUs. On constrained edge platforms, is the embedding + router still negligible, and how do routing gains trade off against on-device acceleration and model compression?
  • Token/monetary accounting: While latency/FLOPs are reported, token costs and API pricing are not systematically analyzed. How do different routing policies affect dollar cost under real provider pricing and rate limits?
  • Evaluation breadth and statistical rigor: Physical validation spans 245 trajectories and a limited task set. Larger-scale, diverse real-world studies with confidence intervals and per-task variance analysis would strengthen claims about generality and reliability.
  • Automatic capability profiling: The method assumes intuitive “capability profiles” (reasoning, skill breadth, memory). Can we automate discovery of these profiles (e.g., via unsupervised clustering of failure modes) to inform pool design and routing features?
  • Combining planners’ outputs: Direct selects a single planner. Could ensembles, verifier-guided mixtures, or plan fusion improve reliability for ambiguous scenes while controlling cost?
  • Handling non-stationary goals and scenes: Tasks with moving objects/humans or rapidly changing goals are not extensively evaluated. How should routing adapt when scene dynamics invalidate earlier compute investments?
  • Carbon footprint and energy: Energy usage and environmental impact of different routing choices are not measured. Can routing incorporate energy-aware objectives alongside success and latency?
  • Hyperparameter and metric sensitivity: The harmonic efficiency metric η and tradeoff parameter β are fixed. How sensitive are conclusions to the choice of utility/metric, and can we learn user-specific utility functions that reflect deployment priorities?

Practical Applications

Practical Applications of “Direct: When and Where Should You Allocate Test-Time Compute in Embodied Planners?”

Below we distill actionable, real-world applications arising from the paper’s findings and the Direct framework. Each application is grouped by time horizon and includes sectors, example tools/workflows, and feasibility notes.

Immediate Applications

These can be deployed with today’s VLMs, skill libraries, and standard robotics stacks.

  • Robotics planning router for production cells
    • Sectors: manufacturing, logistics/warehousing, retail fulfillment, micro‑fulfillment centers
    • What it enables: Reduce latency and cloud spend in pick-and-place, kitting, sorting, palletizing, and QA cells by routing each planning call to the cheapest capable planner (e.g., non-thinking for routine steps; thinking or larger model for ambiguous constraints; memory only for long-horizon subgoals).
    • Tools/workflows:
    • A ROS 2 “Planner Router” node using SigLIP + BGE-M3 embeddings to pick from a pool of planners (e.g., small instruct, large instruct, thinking, memory-augmented).
    • Utility-tunable routing (quality vs. cost) with per-line/per-cell SLAs.
    • Stepwise routing with a transition detector for multi-stage tasks (e.g., grocery bagging or bin packing).
    • Assumptions/dependencies:
    • Access to multiple planner variants (e.g., Qwen/GLM/Gemini “instruct”, “thinking”, and memory-augmented modes).
    • Existing low-level skills (grasp, place, fold, wipe) and a stable orchestration layer (SayCan-style stacks).
    • Representative routing training data (or synthetic tasks and LLM judging as in the paper) to estimate per-planner quality and cost.
  • Edge–cloud orchestration for embodied agents
    • Sectors: hospitality robots, hospital logistics, retail restocking, last‑meter delivery, field service
    • What it enables: Run a small, fast planner on device; escalate to a larger/thinking model in the cloud only when the scene/instruction indicates higher cognitive demand or long-horizon recall.
    • Tools/workflows:
    • “Local-first routing” policy with on-device fallback, network-aware utility weights (latency, bandwidth, token/FLOP budgets).
    • Cost/quality dashboards and budgets (per shift, per robot) tied to the router’s Pareto settings.
    • Assumptions/dependencies:
    • Reliable connectivity for cloud escalation; privacy policies for image/video offloading.
    • On-device accelerators sufficient for small VLMs and the lightweight router (20–50 ms overhead as reported).
  • Memory-on-demand for long-horizon manipulation
    • Sectors: household/service robotics, assembly lines with multi-step processes, lab automation
    • What it enables: Provide long video/context only when the task is history-dependent; otherwise avoid memory overhead (FLOPs/latency).
    • Tools/workflows:
    • Memory budgeter that switches between FrameSamp/TokenDrop/SimpleSG/GroundSG/MemER based on inferred recall need and difficulty.
    • Rolling video buffer plus text summaries of subgoal histories, activated selectively.
    • Assumptions/dependencies:
    • Cheap, reliable logging of frames and subgoal summaries; compatible memory interfaces in chosen VLMs.
  • Cost-aware planner choice in MLOps/LLMOps for robotics
    • Sectors: software tooling, platform teams in robotics companies
    • What it enables: A reusable “planner switchboard” that learns Q (quality) and C (cost) matrices per deployment, exposes a knob for β/α tradeoffs, and enforces per-mission cost caps while preserving success.
    • Tools/workflows:
    • SDK with: (1) embedding extractor, (2) router heads (regression or pairwise), (3) utility tuning, (4) conformal/OOD fallback, (5) logging and audit.
    • A/B tests: static strongest planner vs. Direct-style routing; Pareto reporting integrated into CI.
    • Assumptions/dependencies:
    • Calibrated benchmarks or synthetic tasks to produce initial Q,C; periodic re-calibration for distribution shift.
  • Energy- and sustainability-driven deployment policies
    • Sectors: operations, sustainability/ESG, facilities
    • What it enables: Immediate energy savings by routing away from heavy CoT/large models when they don’t help; track energy per task and per planner mode.
    • Tools/workflows:
    • “Green routing” utility with energy/FLOP penalties; peak/off-peak heavy inference windows in fleets.
    • Assumptions/dependencies:
    • Accurate metering (FLOPs/energy per inference) and integration with ops dashboards.
  • Safer, more responsive assistive and home robots
    • Sectors: consumer robotics, eldercare/assistive tech, education
    • What it enables: Faster responses for routine tasks; escalate to deliberate reasoning for tricky instructions (e.g., spatial relations, safety-critical placements) and use memory only when goals are occluded or history-dependent.
    • Tools/workflows:
    • On-device router + privacy-preserving escalation (blurred frames; local-only routing for sensitive scenes).
    • Assumptions/dependencies:
    • Robust low-level skills; reliable perception; user consent and data handling for any cloud escalation.
  • Academic benchmarking and curriculum modules
    • Sectors: academia, research labs, teaching
    • What it enables: New embodied routing assignments and benchmarks (VLABench/RoboMME + routing metrics), ablations across CoT depth, model size, and memory choices.
    • Tools/workflows:
    • Open-source reference router, datasets of Q,C pairs, utilities for plotting Pareto frontiers and efficiency (η).
    • Assumptions/dependencies:
    • Access to open-weight and/or API models; compute to run baselines.
  • Procurement and ROI evaluation for service-robot deployments
    • Sectors: finance/ops, enterprise buyers of robotics
    • What it enables: Evaluate vendors on “frontier-level success at fraction of cost,” using routing efficiency and Pareto frontiers as buying criteria.
    • Tools/workflows:
    • Pilot trials with Direct-style routing toggled on/off; cost-per-success and latency SLAs.
    • Assumptions/dependencies:
    • Comparable skill libraries across vendors; agreement to collect and report Q,C metrics.

Long-Term Applications

These require further research, scaling, or standardization.

  • Fleet-level compute orchestration and multi-robot budgeting
    • Sectors: logistics fleets, smart factories, airports, hospitals
    • What it could enable: Global routing of planner compute across many robots under shared budgets; dynamic reallocation based on queue length, shift targets, or energy prices.
    • Potential tools/workflows:
    • “Fleet router” that optimizes utility over a compute/latency/energy budget; coordinated cloud-bursting for rare hard tasks.
    • Assumptions/dependencies:
    • Robust cross-robot telemetry; scheduler integration; fairness and QoS policies.
  • Safety- and certification-ready compute allocation
    • Sectors: regulated environments (healthcare, aviation, public spaces), policy
    • What it could enable: Standards that cap test-time latency while guaranteeing success on safety-critical steps by provably escalating to higher-capability planners when risk signals are detected.
    • Potential tools/workflows:
    • Verified routing policies, formal risk triggers, audit trails of planner selections.
    • Assumptions/dependencies:
    • Verified low-level safety envelopes; certifiable logging; standardized difficulty/risk signals.
  • Router–hardware co-design and on-sensor difficulty estimation
    • Sectors: robotics hardware, embedded systems, edge AI
    • What it could enable: Difficulty estimators embedded in camera/IMU SoCs to make routing near-sensor; customized accelerators for embedding extraction and router inference.
    • Potential tools/workflows:
    • Low-power SigLIP-class encoders; microcontroller-friendly router libraries; DMA pathways to VLM accelerators.
    • Assumptions/dependencies:
    • Hardware vendor support; tight latency and memory budgets.
  • Continual/online learning routers with automatic data synthesis
    • Sectors: all robotics verticals
    • What it could enable: Self-improving routers that update Q,C models from field logs and generate new synthetic tasks for coverage gaps; policy-gradient or bandit-style routing.
    • Potential tools/workflows:
    • On-device/offline retraining loops; LLM-judge pipelines with human spot checks; safety filters.
    • Assumptions/dependencies:
    • Data governance, robust LLM-judge reliability, drift detection.
  • Domain extension beyond manipulation
    • Sectors: autonomous mobile robots, drones, construction, agriculture, autonomous driving/AD-enabled ADAS
    • What it could enable: Compute-aware planning for navigation, inspection, crop handling, or driving—routing between lightweight planners and heavy reasoning/memory when occlusions, unusual semantics, or long temporal dependencies arise.
    • Potential tools/workflows:
    • Multi-sensor routing (RGBD/LiDAR); temporal gating for map/history loading; cross-modal utility functions.
    • Assumptions/dependencies:
    • High-stakes safety validations; broader skill libraries; domain-specific constraints.
  • Privacy-first routing and compliance toolkits
    • Sectors: healthcare, home/consumer, EU/regulated markets
    • What it could enable: Policies that default to local models; escalate to cloud only with redacted views or consent; on-device memory summarization that avoids raw video retention.
    • Potential tools/workflows:
    • Differentially private summaries; policy-aware utility functions; consent-aware escalation gates.
    • Assumptions/dependencies:
    • Clear regulations, privacy-preserving model support, robust on-device performance.
  • Commercial products and standards
    • Sectors: software platforms, integrators, standards bodies
    • What it could enable:
    • Planner Router SDKs embedded in popular orchestration stacks (e.g., ROS 2, OpenVLA).
    • “Compute-aware planning” badges/benchmarks and procurement standards (Cost/Success Pareto and η scores).
    • Potential tools/workflows:
    • RouterArena/VL-RouterBench-like embodied suites; conformance tests for CoT/memory/size routing.
    • Assumptions/dependencies:
    • Community adoption; cross-vendor cooperation; stable APIs for planner variants.
  • Memory and “thought” economy services
    • Sectors: cloud AI services, data platforms
    • What it could enable: Pay-as-you-go memory retrieval and “deliberation budgets” exposed as first-class APIs; automatic selection of MemER/GroundSG/video length given scene difficulty.
    • Potential tools/workflows:
    • Cloud endpoints that accept a router’s utility function and return an optimal plan with itemized compute use.
    • Assumptions/dependencies:
    • Provider support; standardized telemetry and billing; robust performance across models.

Notes on feasibility across applications

  • The Direct approach presumes a pool of interchangeable planners with distinct cost–capability profiles; benefits diminish if only one viable planner exists or if models are tightly cost-locked.
  • Training relies on Q (quality) and C (cost) estimates; if these are collected with synthetic tasks and LLM judges, bias and coverage must be monitored.
  • Real-world latency and energy vary by hardware, model provider, and network; utility weights should be deployment-specific.
  • Safety requires fallbacks when misrouting occurs; guardrails and human-in-the-loop handoff may be necessary in high-stakes settings.
  • Distribution shift can erode routing gains; periodic re-calibration or continual learning is advisable.

Glossary

  • Affordances: Action possibilities offered by objects or environments, used to ground LLM planning in what a robot can do. "Early work grounded LLM reasoning in robotic affordances"
  • Autoregressive axis: An inference mode where outputs are generated sequentially token by token; differences along this axis affect latency. "We use latency when planners differ along an autoregressive axis (e.g., reasoning depth),"
  • BGE-M3: A multilingual, multimodal text embedding model used to encode instructions for routing. "and \ell with a frozen BGE-M3 \cite{multi2024m3} text encoder,"
  • Chain-of-thought (CoT): A prompting technique that elicits step-by-step reasoning from models. "CoT depth helps on tasks with implicit semantic, physical, or spatial constraints;"
  • Conformal prediction: A statistical method for distribution-free uncertainty quantification, used here to detect out-of-distribution inputs. "detected via conformal prediction~\cite{sinha2024realtime}"
  • Deliberate search: Structured exploration of reasoning paths (e.g., trees/forests) to improve solution quality. "deliberate search \cite{yao2023tree, bi2024forest},"
  • Diffusion controller: A low-level policy based on diffusion models that controls robot actions. "routes within a low-level diffusion controller, selecting integration-step budgets by difficulty."
  • DROID: A physical robot setup/benchmark environment used for embodied manipulation experiments. "a physical Franka arm in a DROID setup spanning zero-shot manipulation and long-horizon chaining,"
  • Embodied agents: AI systems that act in the physical world through sensors and actuators. "Vision-LLMs (VLMs) are increasingly deployed as high-level planners for embodied agents,"
  • Embodied planning: Planning for agents that operate in the physical world, integrating perception and action. "a routing framework over VLM planners for hierarchical embodied planning."
  • FrameSamp: A memory scheme that reduces visual context by sampling frames. "FrameSamp and TokenDrop reduce raw visual tokens,"
  • Franka arm: A specific robotic manipulator (Franka Emika Panda) used in physical experiments. "a physical Franka arm in a DROID setup"
  • GroundSG: A memory scheme that summarizes history as grounded language subgoals. "SimpleSG and GroundSG summarize history as language subgoals,"
  • Harmonic-mean efficiency score: A metric combining success and cost to evaluate routing policies. "We compare routers via a harmonic-mean efficiency score (η\eta)"
  • Integration-step budgets: The number of iterative steps allocated to a diffusion-based controller, tuned by task difficulty. "selecting integration-step budgets by difficulty."
  • Latent reasoning: Approaches where reasoning is performed or represented implicitly rather than via explicit chains. "latent reasoning \cite{liu2026last, bai2026latent, Chen25-ecot-lite}."
  • Long-horizon: Tasks requiring extended sequences of decisions or memory over many steps. "long-horizon chaining,"
  • Majority voting: Aggregating multiple sampled outputs by choosing the most common answer. "parallel sampling with majority voting or verifier-guided selection"
  • MemER: A memory retrieval mechanism that recalls prior keyframes to aid long-horizon tasks. "MemER~\cite{sridhar2025memer} recalls prior keyframes."
  • Multimodal scene context: Combined visual and textual input used to infer task demands and route compute. "uses multimodal scene context to allocate compute per prompt,"
  • One-versus-rest (OVR): A classification strategy training one binary classifier per class against all others. "one-versus-rest (OVR)~\cite{rifkin2004defense},"
  • Oracle: A non-deployable upper bound policy that selects the best model per task using full outcome knowledge. "the oracle selects the per-task optimal variant with full knowledge of QQ and CC."
  • Out-of-Distribution (OOD) detection: Identifying inputs that differ from the training distribution to trigger more robust inference. "OOD detection, in which tasks whose embeddings are out-of-distribution (detected via conformal prediction~\cite{sinha2024realtime})"
  • Pairwise preference aggregated KNN (PRkNN): A k-nearest-neighbors variant that aggregates pairwise preferences for routing. "pairwise preference aggregated KNN (PRkNN)~\cite{zheng2023efficient},"
  • Pareto frontier: The set of solutions that optimally trade off success and cost without being dominated. "improving the success--cost Pareto frontier over fixed model selection."
  • Regression heads: Model components that predict continuous quantities (e.g., quality and cost) for routing decisions. "predict q^i,k\hat{q}_{i,k} and c^i,k\hat{c}_{i,k} via regression heads"
  • Router: A lightweight model that selects the most appropriate planner per task based on context. "a lightweight router predicts which planner offers the best quality--cost tradeoff"
  • SigLIP: A family of vision encoders leveraging a sigmoid loss for image-text alignment. "encoding II with a frozen SigLIP-family~\cite{zhai2023sigmoid, tschannen2025siglip} vision encoder"
  • SimpleSG: A memory scheme that summarizes history into simple language subgoals. "SimpleSG and GroundSG summarize history as language subgoals,"
  • System 1–System 2 decomposition: A separation between fast, intuitive responses and slow, deliberative reasoning in planning. "an explicit System 1–System 2 decomposition~\cite{kahneman2011thinking},"
  • Test-time compute: The computational resources spent during inference, not training, to boost capability. "this cost is known as test-time compute~\cite{snell2024scaling}"
  • TFLOPs: Tera-floating-point operations, a measure of inference compute cost. "Success rate versus inference cost (TFLOPs) for individual memory architectures"
  • TokenDrop: A memory scheme that reduces visual context by dropping tokens. "FrameSamp and TokenDrop reduce raw visual tokens,"
  • Transition detector: A component that triggers replanning when the environment state progresses across task stages. "while a transition detector triggers replanning for multi-stage tasks."
  • Utility function: A scalar objective combining success and cost to guide routing decisions. "We capture this through a utility function U(q,c)U(q, c),"
  • VLABench: A benchmark for language-conditioned robotic manipulation with long-horizon reasoning. "On VLABench~\cite{Zhang_2025_ICCV}, 44\% of cases"
  • Vision-LLMs (VLMs): Models that process and reason over both visual inputs and text. "Vision-LLMs (VLMs) are increasingly deployed as high-level planners"
  • Vision-Language-Action (VLA) models: Models that map language and vision inputs into executable robotic actions. "recent hierarchical VLAs adopt an explicit System 1–System 2 decomposition"
  • Verifier-guided selection: Choosing among sampled outputs using an auxiliary verifier to score correctness. "majority voting or verifier-guided selection"
  • Zero-shot manipulation: Performing robotic tasks without task-specific training, relying on generalization. "spanning zero-shot manipulation and long-horizon chaining"

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Tweets

Sign up for free to view the 4 tweets with 147 likes about this paper.