Introducing Particle-1
Today, we’re launching Particle to make highly optimized intelligence accessible to everyone. The cost of using capable models still limits who can use them, how often, and what they can build. We’re working to lower that cost by training models to solve problems more efficiently, so people can deploy more intelligence to solve more problems.
Particle-1, post-trained on DeepSeek V4.1 Flash, sees large improvements in token efficiency using around ~45% fewer tokens on average across a wide variety of tasks. Many improvements in token optimization only improve on reducing costs but, in this case, tasks finish sooner which is good for end-users. We trained the model in reinforcement learning environments developed internally, with the goal of solving tasks with fewer tokens while maintaining accuracy.
This first release focuses on software engineering. We plan to bring Particle to other domains in future releases.
Fewer tokens with comparable accuracy
Cost
USD per task
Mean tokens
Output per task
Accuracy
Task pass rate
- Particle-1
- DeepSeek V4.1 Flash
- GLM 5.3 Flash
Our reward function incentivizes the model to solve tasks successfully while using fewer tokens for reasoning and tool calls. We evaluated Particle-1 on four benchmarksa:
- Terminal-Bench 2.1 tests terminal workflows such as compiling software, debugging code, and configuring systems.
- ReactBench tests agents on building and fixing React applications, including functionality, performance, and accessibility.
- ADE Bench evaluates analytics and data engineering tasks using real dbt projects and databases.
- DeepSWE 1.1 evaluates longer software engineering tasks that require understanding codebases, implementing changes, and verifying solutions.
Across these benchmarks, Particle-1 uses 28.4%–52.2% fewer output tokens and achieves 34.4%–51.6% lower average cost per taskb than DeepSeek V4.1 Flash. Pass@1 rates are within the confidence intervals of the base model.
On general benchmarks outside our training domains, Particle-1’s accuracy stays close to base DeepSeek V4.1 Flash: GPQA Diamond 90.40% (base 90.91%), Tau Airlines 86.00% (base 88.00%), Standard MMLU 86.08% (base 85.98%), and BabyVision with tools 89.18% (base 89.60%).
Scaling RL for token efficiency
The graph shows token savings across two stages of RL training, up to the peak of the smoothed curve. For each rollout group, we compare the mean assistant-token count with the task’s fixed baseline, then average these reductions equally across groups. Higher percentages mean fewer tokens used.
The discontinuity marks the start of stage 2, when the training set shifted mainly toward data engineering. Although stage 1 focused entirely on coding, the model was already using about 20% fewer tokens on data engineering tasks compared with their baselines. This was our first glimpse of generalization.
To train Particle-1, we built an internal collection of coding and data engineering tasks in Harbor format with our autonomous synthetic data system called Datamaker. Each environment gives the model a problem to solve through the Terminus 2 agent and a way to verify the outcome. This process helped us internally validate that our data pipeline could construct generalizable tasks.
We split post-training into successive stages, following the Cascade RL approach. This structure let us focus training on different task domains in sequence.
Asynchronous training stack
Our training infrastructure is built on Miles, RadixArk’s open-source RL framework, with distributed asynchronous training and dedicated rollout and trainer nodes. We made multiple optimizations to the SGLang rollout engine and the Megatron training engine to maximize throughput for our workload and reduce trainer-inference mismatch.
We trained a rank-64 LoRA adapter covering the experts in all layers (Schulman et al.). Its trainable parameters are equivalent to about 1.25% of the model’s parameter count.
For the policy update, we used Group Sequence Policy Optimization (GSPO) which applies importance weighting and clipping to each sequence as a whole, not to individual tokens. In our experiments, training with a token-level loss oscillated and eventually diverged. We kept the learning rate constant at 5e-5 and following Dr. GRPO, did not normalize advantages by the group's standard deviation.
Where the token savings come from
To better understand the gains in token efficiency and uncover potential issues, we analyzed trajectories from both the base model and our post-trained model. We compared runs on the same task and seed where both models passed, looking at how their reasoning, actions, and verification differed. Four common patterns emerged.
- Less reasoning for the same actions. Particle-1 often needs less deliberation to choose and carry out the same steps. This can save tokens even when the number of actions stays the same or increases.
- Stop once the task is complete. After verifying a solution, the model spends less time reconsidering decisions, repeating checks, or writing a lengthy final confirmation.
- Fewer rounds of trial and repair. A more direct implementation means fewer repeated builds, patch repairs, and corrections before reaching a working solution.
- More focused exploration and verification. Particle-1 spends less effort exploring alternatives and revising edge cases. Extra tests and documentation can still be useful, so we look at what each run delivers when interpreting the savings.
Reasoning tokens account for roughly 90% of the token savings on Terminal-Bench 2.1, ReactBench, and ADE. On DeepSWE 1.1, tool-call text also contributes around 30% of the savings.
Here are some example rollouts across the benchmarks.
Git deployment
Terminal-Bench 2.1
66.2%
fewer output tokens
Particle-1 used much less reasoning around deployment checks and completion, reducing output from 43,907 to 14,840 tokens, despite making slightly more model calls. The final two confirmation calls alone dropped from 11,445 to 1,765 tokens, while both runs successfully verified the branch deployments.
pMARS build
Terminal-Bench 2.1
60.4%
fewer output tokens
Particle-1 inspected the Makefile and selected its build flags before compiling, while the base model revisited the flags, rebuilt, and repeated installation and verification. Avoiding that additional cycle helped reduce the trajectory from 18 to 12 model calls and 15,436 to 6,503 output tokens.
Calendar scheduling
Terminal-Bench 2.1
54.8%
fewer output tokens
Both models produced the correct calendar event using four model calls and six commands, so the gain came from shorter reasoning rather than fewer actions. Approximately 94% of the token savings occurred after the correct file had already been written, with completion and confirmation shrinking from 5,193 to 1,078 tokens.
cattrs partial recovery
DeepSWE 1.1
37.8%
fewer output tokens
Particle-1 completed the implementation and regression checks with fewer subsequent edge-case, documentation, and formatting rounds, using 68 model calls versus 111. Output dropped from 77,362 to 51,186 tokens.
Awilix async startup
DeepSWE 1.1
34.9%
fewer output tokens
Particle-1 began editing on call 11 versus call 20 and spent fewer later rounds revising dependency discovery, reducing output from 84,971 to 51,293 tokens. Both passed their local test suites.
go-git merge conflicts
DeepSWE 1.1
35.9%
fewer output tokens
Particle-1 began implementation on call 29 versus call 43, while the base model performed more preliminary Git experiments and later edge-case repairs, including repeating a manual test suite 20 times. The trajectory shrank from 118 to 86 calls and 105,837 to 67,216 tokens.
CoreUI navigation
ReactBench
52.2%
fewer output tokens
The base model spent several turns repairing patch application problems involving working directories, heredocs, and string matching, while Particle-1 reached a working patch with fewer repair attempts and retained targeted navigation tests. Together with shorter completion reasoning, this reduced the run from 43 to 29 model calls and 60,468 to 27,848 output tokens.
Recursive file drops
ReactBench
47.5%
fewer output tokens
Particle-1 spent less reasoning on implementation choices and made fewer successive revisions to path handling and fallback behavior, while still probing recursive traversal and multi-batch file drops. Output fell from 86,657 to 53,478 tokens, even though Particle-1’s final confirmation was longer; the savings came earlier in implementation, where the base model also explored potentially useful refinements.
Table row selection
ReactBench
43.5%
fewer output tokens
Particle-1 attempted its first patch on call 12, compared with call 27 for the base model, and obtained type-checking feedback earlier instead of extending the initial inspection. It also shortened the final confirmation from 10,589 to 662 tokens, contributing to a total reduction from 64,012 to 32,274 tokens.
Review primary key
ADE Bench
62.1%
fewer output tokens
Particle-1 reused the existing surrogate-key macro, while the base model implemented an incrementing key with additional bookkeeping and incremental validation; the main edit call used 1,602 versus 8,722 output tokens. This saved design and implementation effort, but the key-generation semantics differed, so the savings also reflect a different solution rather than merely a shorter explanation of identical work.
String product IDs
ADE Bench
45.1%
fewer output tokens
Both models implemented the same three staging-layer casts, but Particle-1 used 1,757 tokens for the edit call compared with 3,485 for the base model. Total output fell from 9,352 to 5,643 tokens despite Particle-1 making 15 rather than 13 calls, locating the gain primarily in shorter reasoning around the same fix.
F1 lap-time model
ADE Bench
61.4%
fewer output tokens
Particle-1 inspected the schema and used the correct milliseconds column immediately, while the base model initially used lap_time_in_ms and needed a correction. Particle-1 also reduced final confirmation from 3,519 to 198 tokens, which accounted for approximately 48% of this pair’s total token savings.
Generalization beyond coding
Although our post-training focused on coding and data engineering, we’re seeing early signs that the token-efficient behavior carries over to other domains, including legal work and cybersecurity.
For illustration, we gave Particle-1 a contract-review task from Harvey LABe. The agent reads four legal documents, checks whether an arbitration clause complies with the arbitration institution’s rules, and writes a Word report flagging each deviation, its severity, and a recommendation. We also scaled the strength of Particle-1’s LoRA adapter from 0.25× to 8× to see how the behavior changes as its effect grows.
Arbitration clause audit
Harvey LAB
24.6%fewer output tokens
The standard Particle-1 adapter strikes the best balance in this sweep. Its reports keep the explicit comparisons, caveats, and recommendations a complete answer needs, while using about a quarter fewer tokens than the base model.
DeepSeek V4.1 Flash spent the most tokens, writing long reports and checking them repeatedly, but that extra work didn’t reliably produce complete answers. At the standard 1× strength, Particle-1 used 24.6% fewer output tokens than the base model, and all eight of its reports passed every criterion under both judges. Stronger settings cut output further, by 47.8% at 2× and 60.2% at 4×, with one or two reports each missing a single criterion. At 8×, output fell by 78.7%, but only three of eight reports passed the strict check. The misses suggest that aggressive scaling compresses useful qualifications along with redundant analysis.
These early results make Particle-1 a promising foundation for adding new capabilities while keeping costs significantly low.
Build with Particle
Particle-1 is available today through the Particle API. Sign up for an API key and plug Particle-1 into your own harness or agent workflow. The docs walk you through connecting it.