CoreWeave, NVIDIA and You.com Lift BrowseComp Accuracy to 45.45% in Three Weeks

What the sprint achieved

In early September, the three companies post-trained an open-weight model for agentic web search. The workflow combined web-grounded search data, supervised fine-tuning (SFT), reinforcement learning (RL) and managed RL Rollouts. According to CoreWeave, the final result was 45.45% accuracy on BrowseComp, against 36.97% for the original baseline. That is a 22.94% relative improvement.

Average tool calls fell from approximately 168 to 115 per task, a 31.55% reduction. CoreWeave describes the base model's failures as three patterns: death loops, where it searched repeatedly for the same information; weak tool use, where it did not extract value from results; and second-guessing, where it found the right answer, doubted it, and then answered incorrectly.

The company gives one illustrative BrowseComp trace about identifying a car model through clues about a CEO. In the reported comparison, the base model made 313 tool calls and never worked out who the CEO was. The optimized agent finished in 7 tool calls.

Data and training strategy from You.com

You.com argued that open datasets age quickly and lean heavily on Wikipedia, while real questions live on the real web. It built multi-turn question-answer pairs grounded in objective facts on real web pages. The team sampled from the middle popularity band, skipping the spam-heavy tail and the boilerplate-heavy head, and followed 1-hop links to pull page content from its index.

It then filtered by difficulty. Each question was run eight times through Nemotron 3.5 Lightning using You.com's search APIs, with an LLM judge scoring each attempt. Questions were bucketed from too easy (8/8) to too hard (0/8). The reasoning, according to the post, was that if a model sometimes solves a question it is trainable, and if it never does, it is not worth the compute budget yet.

The team used 4,932 SFT traces generated with You.com Search and NeMo Automodel, followed by 1,480 RL tasks trained with group relative policy optimization (GRPO) and a binary reward signal. CoreWeave says its infrastructure ran the whole job in about 9 hours. You.com also reports that tuning its search endpoints for post-training consistency improved performance by about 4% before any training happened.

Hot-Load: faster weight updates for RL rollouts

CoreWeave frames the main infrastructure problem as inference cadence. In an RL loop, rollouts are generated, scored, and used to update the policy, and the new weights must reach serving replicas before the next cycle. In a conventional rolling redeploy, each replica restarts, downloads the full checkpoint from object storage and waits for the engine to initialize. During that time the replica is unavailable and its unfinished requests can be lost.

CoreWeave RL Rollouts replaces this with in-place weight updates called Hot-Load. The trainer publishes a checkpoint and calls the Hot-Load API while earlier rollouts are still running. CoreWeave's control plane coordinates the update, while NVIDIA Dynamo, NVIDIA ModelExpress and vLLM handle it within each replica. The replica pauses serving but keeps in-flight requests and cache in memory, then resumes on the new weights. For strictly on-policy training, the trainer can request a prompt-cache reset and wait for every replica to finish updating.

• Delta weight sync publishes a compressed delta against a baseline checkpoint. In the Nemotron 3.5 Lightning tests, deltas were roughly 0.14%, 0.95% of the full BF16 checkpoint size.
• One replica reconstructs the checkpoint locally, and the others receive weights through GPU-to-GPU transfers over CoreWeave's InfiniBand network or NVIDIA NVLink.
• In a benchmark with four replicas on CoreWeave's NVIDIA GB300 NVL72 systems, the fastest delta Hot-Load was roughly 15× faster than the average cold-start redeploy.

Rollout responses also return token IDs and per-token logprobs, plus expert-routing data for supported mixture-of-experts deployments where enabled.

What it means for teams building search agents

For teams building search agents, CoreWeave says the outcome is more questions answered correctly with fewer tool calls. For teams running RL post-training, the company says faster updates can reduce waiting between rounds and keep GPUs doing useful work for more of the cycle. It cautions that the impact depends on how much of a workflow is spent loading weights.

The companies present the effort as a repeatable pattern rather than a one-off. Their recommendations: start with strong search, build questions from the real web and decontaminate them against your evaluation, filter by difficulty before training, then run SFT on your own traces followed by GRPO with a binary judge reward.