Agnes-3.0-Flash: Preview vs Production, What Actually Differs
Agnes-3.0-Flash Preview's open-weight 33B checkpoint differs from the production API model. Here's what changed, what stayed, and why it matters.
What’s the difference between Agnes-3.0-Flash Preview and the production model?
Agnes-3.0-Flash Preview is a 33B-parameter open-weight checkpoint with a 262,144-token context window, released under Apache 2.0. The production/API version of Agnes 3.0 Flash, listed separately on Artificial Analysis, runs a different checkpoint and configuration with a 1-million-token context window. They share a name and a lineage, but they are not the same model, and benchmark scores from one should not be read onto the other.
TL;DR
- Two distinct checkpoints share one name. The open-weight repository holds a Preview build (33B parameters, 262K context), while the production/API model on Artificial Analysis uses a separate checkpoint with a 1M-token context window.
- The model card was updated for clarity. The repository originally shipped as “Agnes-3.0-Flash” without the Preview label, and the maintainers later added the suffix explicitly to stop people from conflating the two releases.
- Benchmark numbers belong only to the Preview weights. Every score in the model’s published benchmark table (IFBench, SciCode, GPQA Diamond, AA-LCR, AA-Omniscience) was measured on the open-weight Preview checkpoint, not the production API.
- The architecture is a hybrid-attention design. Of 72 decoder layers, 54 use a recurrent gated delta rule and only 18 use standard global attention, which means just a quarter of layers carry a KV cache that grows with sequence length.
- Running it locally requires real infrastructure. The bf16 checkpoint is roughly 66GB on disk and the model card recommends a single H200 (141GB) or H100 (80GB) GPU, with tensor parallelism available for larger context or concurrency needs.
- It’s multimodal out of the box. Preview handles text, image, and video input through a bundled processor, plus adjustable reasoning effort and native tool calling via the chat template.
Why does an open-weight release need a “Preview” label at all?
Model naming gets messy when a lab ships an open-weight checkpoint early and later stands up a separate, more capable production system under the same product name. That’s what happened here. The repository was first published simply as Agnes-3.0-Flash. Once a production/API version went live and started appearing in third-party trackers like Artificial Analysis, the maintainers went back and added the explicit “Preview” suffix to the model card, along with a clarification section spelling out that the two are different checkpoints with different configurations.
This matters because benchmark aggregators and leaderboards often key off model names, not internal checkpoint IDs. Without the clarification, someone could see “Agnes 3.0 Flash” scoring well on a third-party benchmark site and assume the open weights they download will perform identically. The model card is explicit that this isn’t the case: the production model’s benchmark results “should not be attributed to the Preview weights released here.”
What are the actual spec differences?
The clearest, most concrete difference is context window size. The Preview checkpoint supports 262,144 tokens. The production/API model supports 1,048,576 tokens (1M), a roughly 4x jump. That’s a meaningful gap for anyone building long-document retrieval, large codebase analysis, or extended multi-turn agents, since context length often becomes the binding constraint before raw reasoning quality does.
Parameter count is documented for the Preview checkpoint at 33B. The production model’s parameter count, architecture, and training configuration are not disclosed in the open-weight model card, which explicitly says it “uses a different checkpoint and configuration.” That’s a meaningful gap in transparency: you can inspect and run the Preview weights yourself, but the production model is API-only and effectively a black box in terms of internal specs.
How does the Preview checkpoint’s architecture actually work?
Agnes-3.0-Flash Preview uses what its documentation calls a hybrid-attention decoder. Out of 72 total decoder layers, the pattern alternates 3:1: three layers run a gated delta rule (a recurrent mechanism with per-layer state that doesn’t grow with sequence length), and every fourth layer runs standard global attention. That works out to 54 recurrent layers and 18 global-attention layers.
The practical consequence is memory efficiency. Only the 18 global-attention layers maintain a KV cache that scales with context length. The other 54 layers keep a fixed-size recurrent state regardless of how long the input gets. This is the architectural mechanism that lets a 33B model handle a 262K-token context without the KV-cache memory blowup you’d get from a pure transformer at that scale.
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
Other specifics from the model card: hidden size of 5120, global attention layers using 24 query heads and 4 KV heads (a 6:1 grouped-query attention ratio) with head dimension 256, delta-rule layers using 16 key heads and 48 value heads at head dimension 128, and a SwiGLU feed-forward block with intermediate size 17408 plus a smaller parallel SwiGLU branch in every layer. Position encoding uses a 3-axis rotary scheme (separate axes for text, height, and width) to support the vision inputs. The vocabulary sits at 248,320 tokens, and a 27-layer vision tower with 2x2 spatial merging feeds into the same 5120 hidden size as the text decoder.
How does Preview compare to other open models on benchmarks?
The model card publishes reference numbers across five benchmarks: IFBench (instruction following), SciCode (scientific coding), GPQA Diamond (graduate-level QA), AA-LCR (long-context reasoning), and AA-Omniscience Accuracy. Preview scores 74.20 on IFBench, 38.08 on SciCode, 85.05 on GPQA Diamond, 68.33 on AA-LCR, and 23.00 on AA-Omniscience Accuracy.
Comparing across the published table, Preview lands competitively against similarly-sized open models like Qwen3.5 (27B) and Muse Glimmer (30B) on GPQA Diamond and IFBench, while larger mixture-of-experts models like MiniMax M3 (428B total, 23B active) and Qwen3.8 Flash Next (125B total, 6B active) generally post higher scores on SciCode and AA-Omniscience. The model card itself flags that these figures come from different sources, harnesses, and snapshot dates, so they’re reference points rather than a controlled head-to-head test. Worth noting: none of these numbers say anything about the separate production/API model’s performance.
Is the Preview checkpoint practical to run yourself?
For self-hosting, the requirements are real but not exotic by current standards. The bf16 checkpoint takes about 66GB of disk space. The model card recommends one NVIDIA H200 (141GB) or H100 (80GB) GPU, or equivalent, with 128GB or more of host memory. Tensor parallelism of 2 (--tp 2) is suggested if you want maximum context length or concurrency rather than the default single-GPU setup.
The model requires trust_remote_code=True since it ships its own implementation rather than relying on a stock architecture in the transformers library, and needs transformers>=5.12 along with torchvision for image and video processing. Deployment options include the standard Hugging Face transformers pipeline for single requests, or an SGLang-based server (via a documented Docker image and patch) for OpenAI-API-compatible serving with streaming, tool calls, and configurable reasoning effort.
The chat template supports three reasoning effort levels (high by default, medium, low) plus a full thinking-off switch, and renders tool definitions natively so the model can emit structured tool calls that a calling application executes and feeds back as results.
Which one should developers actually use?
If the goal is inspecting, fine-tuning, or self-hosting under an open license, the Preview checkpoint is the only option, since it’s the one with published weights. If the goal is maximum context length or the best available performance under the Agnes 3.0 Flash name, the production/API model is the one to reach for, keeping in mind that its internal architecture and exact benchmark methodology aren’t part of the open documentation. Treating them as interchangeable, especially when quoting benchmark scores, is the exact confusion the updated model card was written to prevent.
Frequently Asked Questions
Is Agnes-3.0-Flash Preview the same model as the production Agnes 3.0 Flash API?
No. They share a name but use different checkpoints and configurations. The Preview is a 33B open-weight model with a 262K-token context window; the production/API model has a 1M-token context window and undisclosed internals.
Can I reproduce the production model’s benchmark scores with the open weights?
Other agents ship a demo. Remy ships an app.
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
No. The model card explicitly states that benchmark results for the production/API model should not be attributed to the Preview checkpoint. All published benchmark figures on the model card belong only to the Preview weights.
What license is Agnes-3.0-Flash Preview released under?
Apache 2.0, according to the model repository’s badges.
What hardware do I need to run Agnes-3.0-Flash Preview locally?
The model card recommends one NVIDIA H200 (141GB) or H100 (80GB) GPU at bf16, with roughly 66GB of disk space for weights and 128GB or more of host memory recommended.
Does Agnes-3.0-Flash Preview support images and video?
Yes. It handles text, image, and video understanding through a bundled processor that requires torchvision, in addition to adjustable reasoning effort and native tool calling.
