NVIDIA ASPIRE Uses Claude Opus 4.6 with 1M Context as Robotics Coding Agent: What It Costs Per Task

What ASPIRE Actually Does

On July 4, NVIDIA and researchers from Michigan, UIUC, and UC Berkeley published ASPIRE, a continual-learning framework for robotics that uses an LLM as the programming brain. The architecture splits into a coordinator, an executor, a skill library, and an evolutionary search loop. The interesting choice — and the one with real cost implications — is that the programming agent runs on Claude Opus 4.6 in its 1M-token context mode, not a smaller local model.

Results are strong. On LIBERO-Pro, ASPIRE beat the strongest prior baseline by 77 points. Bi-manual handover success on Robosuite jumped from 20% to 92%. On BEHAVIOR-1K, the "pick up the radio" task went from 56% to 88%. Most striking, on LIBERO-Pro Long — a suite of long-horizon tasks the model had never seen — ASPIRE's zero-shot success rate reached ~31% where prior methods saturated near 4%.

The question a robotics team has to answer before adopting this in production is not whether the numbers are impressive. It is: what does each successful task cost in inference dollars?

The Per-Task Token Breakdown

ASPIRE's paper does not publish exact token counts per trial, but the architecture pins the numbers to a narrow range. Every task involves the coordinator receiving the goal, retrieving relevant skills from the library, generating or amending control code, and (crucially) iterating with the executor when execution feedback comes back. On a long-horizon task, that iteration loop typically fires 4-8 times.

A reasonable estimate for a single BEHAVIOR-1K trial:

• System prompt + skill library context: 200,000-400,000 input tokens (with prompt caching, only ~10% billed on second+ calls).
• Per-iteration new context: 5,000-15,000 tokens (task state, previous execution trace, sensor feedback).
• Per-iteration generation: 2,000-6,000 output tokens of new/patched control code.
• Iterations per successful task: 4-8.

At Claude Opus 4.6 pricing (roughly $15/M input, $75/M output, with cached input at ~$1.50/M), one long-horizon task lands in the $1.20-$4.50 range per successful trial. Failed trials — where the loop runs out of budget or the executor keeps rejecting — can consume 2-3x that before hitting a cutoff.

The Success-Rate Multiplier

Naive per-task cost is misleading because failed tasks still cost money. What matters is cost per successful trial. Compare the numbers:

The LIBERO-Pro Long number is where the cost story gets interesting. A 31% success rate against a $4 per-attempt cost translates to $12-18 per successful zero-shot completion. That is expensive for a single robotic task — but the honest comparison is not $0, it is "we could not do it at all." A prior baseline at 4% success would cost ~$100 per success even at half the per-attempt price. ASPIRE is not just cheaper per successful task, it is a category of task that was not previously reachable.

Why 1M Context Matters for the Bill

The architectural choice of Claude Opus 4.6 in 1M-token mode instead of a chunked 200k-token workflow is the single biggest cost lever. In 1M mode, the skill library, the full task history, and the execution trace can live in a single prompt — which means prompt caching hits ~90% on successive iterations. Without caching, ASPIRE's per-task cost would balloon 4-6x because every iteration would re-send the skill library.

This is a case study in how model choice interacts with prompt design. A cheaper model with a smaller context window could technically run the same architecture but would require the coordinator to actively select which skills to include per turn — a routing decision that adds latency, error surface, and additional LLM calls. The paper's authors implicitly chose to pay Opus prices in exchange for eliminating that routing complexity, and prompt caching makes the exchange sustainable.

If You Are Building Something Similar

1. Do not skip prompt caching in the design. A robotics agent that iterates 4-8 times per task will burn budget in weeks without it.
2. Instrument success/failure early. Cost per attempt is not the number you optimize; cost per completed goal is. Log both.
3. Consider a Haiku router. Even with 1M context, some tasks are simple enough that a Haiku 4.5 first pass can filter out easy cases before invoking Opus for the hard ones.
4. Budget for evolutionary search separately. ASPIRE's skill-library growth loop runs occasionally but expensively; those runs should be on a different budget line from live task execution.
5. Track per-hardware costs. Physical robot time is scarcer than API tokens — if your robot pool sits idle waiting on the LLM, the true cost per task is much higher than the API bill suggests.

The Bigger Signal

ASPIRE is the clearest signal yet that frontier LLMs are now viable as the top-level orchestrator of physical robotics — not just as vision-language commentators. The cost per successful task is high in absolute terms but small relative to the alternative of hand-programming every long-horizon skill. For robotics teams already budgeting hundreds of thousands per year on manipulation policy development, moving 10-20% of that budget to Opus 4.6 inference is a defensible line item.

The wildcard for 2026 is what happens when Opus 5 lands with cheaper 1M-token pricing. ASPIRE's cost curve compresses immediately, and the failed-attempt tax that currently gates broader deployment shrinks with it.