Engineering brief

Why your coding agent costs explode and how to fix it

Weights & Biases3 min read · saves 19 min

At a glance

The brief is enough

Relevance
Practical value
Radar
Time horizon
Now
Warnings
None

Training a coding model to solve every problem is easy. Training it to solve problems efficiently requires a precisely tuned linear penalty on token length — and most teams get this wrong.

The reward design determines whether AI coding agents get smarter or just more verbose.

Watch if you're training a custom coding model and need the full infrastructure and stability details.

Summary

The core problem. Training a large coding model at scale requires optimizing a tradeoff between solving rate and inference cost. A model that solves every problem but takes an unbounded number of tokens is not useful. The talk, from a Cognition Labs engineer, walks through the infrastructure, stability, and reward design choices behind SWE-1.7 and SWE-2, arguing that the real frontier is not raw capability but how efficiently a model uses inference tokens.

Asynchronous infrastructure. The most basic RL loop is synchronous: sample rollouts from one model version, grade them, update weights. This forces idle GPU time when solving problems of very different difficulty. Cognition's solution is asynchronous RL: continuously submit new problems while updating the model mid-rollout. Each trajectory's tokens may come from different model versions. This keeps inference GPUs saturated, but introduces distribution mismatch between the policy that generated a token and the weight state used for the gradient update.

Weight synchronization and fault tolerance. Distributing inference across continents (SWE-1.7 trained across three) requires shipping weight updates efficiently. The key property: RL weight deltas are extremely sparse — only a tiny fraction of bits change per step. By compressing deltas by ~99% and uploading to cloud storage, each inference engine can pull updates asynchronously with only 3-4 seconds of pause. On the training side, Grace Blackwell racks of 16+ nodes require auto-swapping faulty nodes from a spare pool, a mechanism provided by CoreWeave.

Training stability through replay. The distribution mismatch from asynchronous updates introduces instability that can cause training runs to diverge. The fix: record and replay every inference-side decision during training. This includes quantization precision (FP8 for MLA attention layers, NBF4 for most weights), expert routing choices in MoE models, and sampling parameters like top-P. If inference discards low-probability tokens via top-P sampling, training must use the same truncated distribution. Without this replay, runs explode.

Preserving entropy for long runs. Long RL runs suffer from entropy collapse: the model becomes overconfident on a small set of tokens and stops exploring. The talk shows that penalizing a low-probability token actually reduces entropy further, because the highest-probability token gets upweighted more. The simple fix is changing the inference sampling distribution itself — using top-P to discard the long tail of improbable tokens. This alone lets training runs continue far longer and achieve higher performance.

The linear length penalty. The most important design choice is the reward function. A model that only optimizes solve rate will explode in inference cost, spending more tokens per problem without becoming more intelligent per token. The solution is a linear penalty on token length. The coefficient must be tuned so the reward function's iso-reward line is tangent to the model's test-time scaling curve.

My take

I find the linear penalty argument compelling and largely missing from the agent discourse. Most teams evaluate coding agents solely on pass rate, then wonder why costs spiral. The talk makes a clean, actionable point: the reward function is a strategic choice, not a hyperparameter. That said, I'm skeptical that the cherry-picked Pareto curve generalizes to real software tasks. Benchmarks like FrontierCode are synthetic. The entropy preservation trick is clever but smells like a fight against a fundamental limitation of RL. I expect more teams will hit the same ceiling and need identical workarounds. The infrastructure details are interesting but not portable, most organizations will consume these models, not train them. The reward design lesson, however, applies directly to vendor evaluation.

What to do with this

  1. Ask your AI vendor how they penalize token length in their training reward function.
  2. Run a simple audit: track tokens-per-problem for your current coding agent over a two-week period.
  3. If using a custom model, experiment with a linear length penalty coefficient tuned to your inference budget.

Watch the video

This video is blocked due to your privacy settings. To watch this video, please accept YouTube marketing cookies.

Related breakdowns

Get TL;DW

Too Long; Didn't Watch.

A concise breakdowns of the AI and devtools videos that actually matter for engineering leaders.

Free. Weekly. No hype.

Video and thumbnails remain the property of their respective creators. tldw.news provides editorial analysis, commentary, and discovery links to original content.