How to Run AREX-2 Locally: Hardware, Setup, and Real Performance
AREX-2 is a 27B open-weight agent model built on Qwen3. Here's the hardware it needs and how it performs against the base model in long agent loops.
What is AREX-2?
AREX-2 is an open-weight 27B model released by the Beijing Academy of Artificial Intelligence (BAAI) along with two university partners, built as a fine-tune of Qwen3-27B. It’s released under Apache 2.0, so you can run it, modify it, and use it commercially without restriction. The thing that makes it worth a dedicated setup guide isn’t its size. It’s what it’s trained to do: run long, self-directed agent loops where the model itself decides when to retry, what to keep, and when to stop, instead of leaning entirely on your harness code to manage that logic.
If you’ve built an agent before, you know the pattern: try something, check the result, decide whether to retry, keep the best version, figure out when to quit. That loop usually lives in your orchestration code. AREX-2 tries to move a meaningful chunk of that decision-making into the model’s own weights, trained specifically on long machine learning engineering and algorithmic programming tasks.
TL;DR
- AREX-2 is a 27B dense model fine-tuned from Qwen3-27B, released under Apache 2.0, which means standard local-LLM tooling and quantization paths already work with it.
- It beats GPT-5.6 Sol on MLE-Bench Light, scoring 81.8 versus 72.7, though it trails by about six points on Frontier CS, a benchmark of open-ended algorithmic problems.
- The model keeps improving across a 5-hour budget in testing, hitting 54 after one hour, 66 after two, and 70.7 after five, while a comparison model (DeepSeek-V3.2 Pro) flattens out around 45 after two hours and stays there.
- Skills in context matter more than the fine-tuning itself, based on BAAI’s own ablation: task-specific skills push the base Qwen3-27B from 28.8 to 68.2, and only the final 14-point jump (68.2 to 81.8) comes from AREX-2’s training.
- Training data came from kept failures, not just successes, with teacher agents running for hours on GitHub-derived tasks and the full messy trajectory, including dead ends, retained so the model learns how to recover rather than just what a clean answer looks like.
- This is test-time self-improvement, not true recursive self-improvement, since the model’s weights don’t update between tasks. Every new problem starts the 20-attempt process from scratch.
- Running it locally requires enough VRAM for a 27B dense model, which puts it solidly in high-end consumer or prosumer GPU territory depending on quantization, not something that fits on a typical single consumer card at full precision.
What hardware do you need to run AREX-2 locally?
AREX-2 is a 27B parameter dense model (not a mixture-of-experts model), which determines your hardware floor pretty directly. At full 16-bit precision, a 27B dense model needs roughly 54GB of VRAM just to load the weights, before accounting for context and KV cache. That puts it out of reach of a single consumer GPU without quantization.
In practice, most people running a model this size locally will reach for 4-bit or 8-bit quantized versions (GGUF, AWQ, or similar formats), which is standard practice for Qwen-based models and should apply here since AREX-2 shares Qwen3’s architecture. At 4-bit quantization, you’re looking at something closer to 16-18GB of VRAM for weights alone, which fits on a single high-end consumer card (a 24GB card with headroom for context) or a prosumer setup. At 8-bit, expect to need closer to 28-30GB, which pushes you toward multi-GPU setups or higher-VRAM professional cards.
The bigger practical constraint isn’t the model weights, though. It’s the context window. AREX-2 is designed for long-horizon agent loops that run for hours and accumulate context across dozens or hundreds of tool calls and rounds. If you’re planning to actually use it the way it’s designed, that is, giving it a multi-hour budget to iterate on a problem, you need enough memory headroom for a KV cache that grows substantially larger than a typical single-turn chat session. Budget extra VRAM beyond the base model size if you intend to run genuinely long agent sessions rather than short one-off prompts.
How does the long-horizon agent loop actually work?
The core mechanic has two parts, and both need to be present for the loop to be useful.
The first is reflection: after each attempt, the model looks at its current result and the feedback it got back (a score, an error log, test output) and decides whether it can produce a better attempt. This isn’t new on its own; reflection has been a known technique for improving LLM outputs for a few years.
The second part is longer-horizon execution: the ability to sustain that reflect-and-retry process across many rounds without losing track of what it already tried, and to recover gracefully when a change makes things worse rather than better. This is the harder problem, because without it, reflection alone tends to plateau after a handful of rounds.
The two parts compound. Weak reflection with a long horizon just burns tokens retrying ineffectively. Strong reflection with a short horizon hits a ceiling quickly. The interesting design choice is that AREX-2 is given an explicit budget (for example, 5 hours) and paces itself inside it, using early rounds to explore and later rounds to exploit what it’s learned works.
For anyone debugging their own agent setups, this framing is useful even if you never touch AREX-2 itself: when an agent stalls, the question is whether it’s making bad changes (a feedback-signal problem) or losing track of what it already tried (a state and memory problem). Those are different failures with different fixes.
Without shadow IT.
How was AREX-2 trained?
BAAI built custom training data rather than using the typical approach of keeping only successful agent runs and discarding failures. Their pipeline has three steps. A teacher model converts GitHub repositories into structured tasks with clear scoring functions. A teacher agent then works each task for hours, running hundreds of tool calls, reading code, searching papers, and running small experiments. Full trajectories are kept based on how they ended, including the failed attempts and dead ends along the way.
Two domains were chosen deliberately: machine learning engineering and algorithmic programming. Both give unambiguous feedback (a validation score moves up or it doesn’t, a test passes or it doesn’t) and both allow for long stretches of incremental improvement rather than a single pass/fail outcome.
Critically, the training process keeps failed rounds in the model’s context during training but only computes loss on the steps that actually moved the solution forward. That distinction, training on outcomes rather than every intermediate step, is described in the source material as directly reusable for anyone fine-tuning their own agent traces: keep trajectories based on how they end, and mask the loss so the model only learns from genuine progress, not from replicating every exploratory dead end.
One clarification worth making: despite some launch language describing this as “reinforcing” tasks, this is supervised fine-tuning on curated trajectories, not reinforcement learning. The training data was also mixed with deep research data from the earlier AREX model line.
Is AREX-2 actually better than the base Qwen3-27B model?
Yes, but the ablation data suggests the gap is smaller than the headline numbers imply, and most of the real lift comes from somewhere else: skills.
In BAAI’s own breakdown, the plain Qwen3-27B model with no skills and no training scores 28.8 on MLE-Bench Light. Adding general ML-practice skills to its context pushes that to 41.2. Adding task-specific skills (built by searching around the specific problem) along with more rounds brings the untrained base model up to 68.2. Only when you swap in the trained AREX-2 model, using the same skills and the same number of rounds, does the score reach 81.8.
So the fine-tuning adds roughly 14 points on top of what good skills and enough rounds already deliver to the untrained model. That’s a real, measurable improvement, but it’s a smaller lever than the context engineering around it. For anyone building agents, that’s a familiar lesson: well-built skills and operational context often do more work than people expect, and a trained model is additive on top of that rather than a replacement for it.
On raw benchmark comparisons, AREX-2 posts 81.8 on MLE-Bench Light, ahead of GPT-5.6 Sol’s 72.7. On Frontier CS, a set of open-ended algorithmic problems, it scores 70.7, the best among open-weight models tested but about six points behind GPT-5.6 Sol. Given that AREX-2 is a 27B dense model competing against models presumed to be considerably larger, that’s a notable result either way.
Does AREX-2 keep improving over long sessions?
- Patient records✓ Granted
- Surgery schedule✓ Granted
- Billing export✕ Denied
In testing described in the source material, yes. Plotting score against a 5-hour time budget, AREX-2 reaches 54 after one hour, 66 after two hours, and 70.7 after five hours, a steady upward curve. For comparison, DeepSeek-V3.2 Pro was shown flattening out around 45 after roughly two hours and not improving meaningfully beyond that point. That sustained improvement over hours, rather than a quick plateau, is the specific behavior AREX-2 was built to produce.
A separate hands-on test compared AREX-2 against the base Qwen3-27B on a traveling salesman style problem (300 points, shortest tour, graded against a reference solver) using an identical, simplified loop for both models, stripped of extra planning prompts. The goal was to isolate how much of the “keep improving across rounds” behavior is actually baked into AREX-2’s weights versus coming from prompting or harness scaffolding.
Is this real recursive self-improvement?
Not in the fullest sense, and BAAI’s own paper acknowledges this. What AREX-2 demonstrates is self-improvement at test time: within a single task, across many rounds, the model gets measurably better. But its weights don’t change during that process. Give it a new task tomorrow, and it starts the multi-round improvement process over from scratch, the same way an intern might spend a week trying twenty approaches to a problem, present the best one, and then have no memory of any of it the following week.
True recursive self-improvement, the kind that compounds over time rather than resetting per task, would require the model’s own successful trajectories to become training data for the next generation of the model, so later versions need fewer attempts to reach the same quality. The paper explicitly names this as the intended next step rather than something already achieved.
Frequently Asked Questions
What license is AREX-2 released under?
AREX-2 is released under Apache 2.0, allowing commercial use, modification, and redistribution without the restrictions some open-weight models carry.
How much VRAM does AREX-2 need to run locally?
As a 27B dense model, full precision needs around 54GB of VRAM for weights alone. Quantized to 4-bit, expect roughly 16-18GB, fitting on a single high-end consumer GPU, though long agent sessions need extra headroom for a growing context and KV cache.
Is AREX-2 the same architecture as Qwen3?
Yes. AREX-2 is a fine-tune of Qwen3-27B, so it shares the same base architecture, and tooling built for Qwen3 (quantization formats, inference frameworks) should generally work with it.
Does AREX-2 use reinforcement learning?
No. Despite language in some launch materials suggesting reinforcement, the actual training method is supervised fine-tuning on curated agent trajectories, with loss masked to train only on steps that made genuine progress.
Why does AREX-2 do well on ML engineering and coding tasks specifically?
Those domains were chosen deliberately because feedback is unambiguous (test pass/fail, validation score up or down) and because there’s a long runway for incremental improvement, from a basic baseline to a near-optimal solution, which suits a model trained to improve over many rounds rather than produce one correct answer immediately.
