Dots3-Note Preview: 512K Open-Weight AI Agent Guide
> Dots3-Note Preview is a 280B MoE model with 16B active parameters, 512K context, multimodal inputs, Apache 2.0 weights, and eight-GPU serving guidance.
🎧 Listen — ~8 min
Ready · Dots3-Note Preview: 512K Open-We
Dots3-Note Preview is the first open-weight model in Dots Studio’s dots3 family, and it is an unusually ambitious release for a “lightweight” family member. The model combines a 280B-parameter Mixture-of-Experts architecture with only 16B activated parameters, a 512K-token context window, and native input support for text, images, video, and audio.
For developers, the important story is not only the parameter count. Dots3-Note Preview is designed for long-horizon agent work: tool use, code generation, repository-scale reasoning, multimodal document analysis, and tasks that require exploration, memory updates, and adaptation. It is released under Apache 2.0, but running it locally still requires serious multi-GPU infrastructure.
What Dots3-Note Preview is
Dots3-Note Preview comes from Dots Studio, the model lab associated with Xiaohongshu, also known as RedNote. The official model card describes it as a multimodal MoE model with 280B total parameters and 16B active parameters. It accepts text, image, video, and audio inputs, while producing text outputs.
The model is the smallest planned member of the dots3 family. Dots Studio says the wider family will explore different trade-offs among capability, latency, and inference cost. That positioning matters: “lightweight” here means lighter activation and a more manageable serving profile than a dense 280B model—not that it can run comfortably on a consumer laptop.
The headline specifications are:
- 280B total parameters and 16B activated parameters
- 512K-token maximum context length
- 256 routed experts plus one shared expert, with top-8 routing
- 13 DSA attention layers and 33 sliding-window attention layers
- 7B total-parameter MoE vision encoder, with 1.2B active parameters
- 800M dense audio encoder
- BF16 and FP8 support
- Text, image, video, and audio input
- Apache License 2.0 for the model weights and repository assets
This combination is aimed at applications where the model must keep a large amount of context in working memory while operating across multiple data types.
Why the 512K context window matters
A 512K context window is useful when the task is larger than a chat prompt: a monorepo, a long incident timeline, a collection of design documents, a video transcript with supporting files, or a multi-step investigation.
Context length alone does not guarantee good long-horizon behavior. The application still needs retrieval, summarization, tool permissions, state management, and a way to prevent irrelevant material from consuming the entire window. The practical advantage is that developers can defer aggressive chunking and expose more of the task state to the model during complex workflows.
A sensible architecture looks like this:
The model should not receive unrestricted access to production systems. Use a sandbox, narrow tool schemas, read-only defaults, and explicit approval for writes.
Reported evaluation results
The Hugging Face model card reports results across coding, agent, reasoning, and multimodal evaluations. The published figures include 78.4 on SWE-bench Verified, 61 on SWE-bench Pro, 75.7 on SWE-bench Multilingual, and 61.7 on WildClawBench. It also reports 73.4 on Claw-Eval, 30.8 on Apex Agents, 79.1 on MMMU-Pro, 52.6 on Humanity’s Last Exam with tools, 39.3 on Video-MME v2, and 52.8 on SkillsBench with skills enabled.
These should be treated as model-card claims rather than independently verified rankings. Evaluation harnesses differ in prompts, tools, graders, budgets, and input modalities. For example, the model card notes that the Humanity’s Last Exam result used tool or browsing access, while Apex Agents was evaluated through a multimodal harness and judged by another model.
The result pattern is still useful. Dots3-Note Preview is not marketed as a narrow coding model. Its appeal is the combination of software engineering, multimodal understanding, tool use, and long-context processing. Teams should reproduce the evaluations that resemble their workload instead of selecting it from one headline score.
Local deployment requirements
The official repository recommends serving the FP8 checkpoint on one eight-GPU node with SGLang or vLLM. The reference examples target high-memory NVIDIA systems, and BF16 requires more memory than FP8. Actual requirements depend on context length, concurrency, batch size, image/video/audio inputs, and whether speculative decoding is enabled.
The repository provides an OpenAI-compatible endpoint pattern. Once a server is running, a client can use the standard OpenAI Python package against the local base URL:
1from openai import OpenAI
2
3client = OpenAI(
4 base_url="http://127.0.0.1:8000/v1",
5 api_key="EMPTY",
6)
7
8response = client.chat.completions.create(
9 model="dots3-note-prev",
10 messages=[
11 {"role": "user", "content": "Explain this repository's test strategy."}
12 ],
13 temperature=1.0,
14 top_p=0.95,
15 max_tokens=256,
16 extra_body={
17 "chat_template_kwargs": {"enable_thinking": False}
18 },
19)
20
21print(response.choices[0].message.content)For a first evaluation, disable thinking and use a short output budget. Then compare direct answers with reasoning-enabled runs on a fixed test set. Do not assume that a larger token budget automatically improves correctness.
The official deployment guidance includes SGLang and vLLM recipes, with tensor parallelism and expert parallelism across eight GPUs. Dots3-Note Preview support is moving quickly in both projects, so production teams should pin a known-good nightly or release rather than relying on an unpinned main branch.
Multimodal and agent workflows
The model card includes examples for image, audio, and video messages. Video inputs can include their audio track when available, which makes the model relevant to meeting analysis, technical walkthroughs, product demos, and incident recordings.
Useful applications include:
- Reviewing a large codebase while consulting screenshots and architecture diagrams
- Extracting structured findings from long technical videos
- Comparing a design document with an implementation and its test output
- Building research agents that maintain state across multiple tool calls
- Generating patches after inspecting logs, charts, and source files together
- Summarizing multimodal customer-support evidence for human review
The main engineering challenge is observability. Log the prompt context selected by the orchestrator, tools called, files changed, model latency, token usage, and validation results. A multimodal agent that appears impressive in a demo can still fail silently when an image is low quality, an audio track is missing, or a long context buries the relevant instruction.
Dots3-Note Preview compared with a typical coding model
| Capability | Dots3-Note Preview | Typical coding-focused model |
|---|---|---|
| Architecture | 280B MoE, 16B active | Often smaller dense or coding-specialized model |
| Context | Up to 512K tokens | Commonly much smaller |
| Inputs | Text, image, video, audio | Usually text, sometimes images |
| License | Apache 2.0 | Depends on provider or checkpoint |
| Local serving | Eight-GPU class deployment | Often easier and cheaper |
| Best fit | Long, multimodal agent workflows | Fast code generation and repair |
The trade-off is straightforward: Dots3-Note Preview offers broader inputs and a very large working context, while a smaller coding model may deliver lower latency and lower infrastructure cost for ordinary pull-request work.
Security, cost, and operational limits
Apache 2.0 simplifies commercial use, but it does not remove operational risk. Treat generated patches as untrusted until tests, static analysis, dependency checks, and human review pass. For tool-enabled deployments, restrict filesystem access and network egress. Never expose a local inference endpoint directly to the public internet without authentication and request controls.
The eight-GPU recommendation also changes the economics. The model may be attractive when a team needs one system for long documents, multimodal inputs, and agentic coding, but excessive context and high concurrency can make serving expensive. Benchmark end-to-end cost per completed task, not just tokens per second.
Should developers try it?
Try Dots3-Note Preview if you need open weights, Apache 2.0 licensing, long context, and multimodal agent behavior—and you have access to an appropriate multi-GPU environment. Start with offline evaluations: repository repair, document-plus-code analysis, video understanding, and tool-call reliability.
Do not choose it solely because of a perfect or near-perfect headline benchmark. The official results are promising, but the model is new, the serving integrations are evolving, and real-world performance depends heavily on orchestration and hardware.
FAQ
Is Dots3-Note Preview open source?
The weights and repository are released under Apache 2.0. “Open-weight” is the more precise description for the model release; the full surrounding training data and training process are not necessarily public.
Can it run on a laptop?
Not realistically in its full form. The official deployment guidance targets an eight-GPU node, with FP8 recommended for the reference setup.
Does it accept video and audio?
Yes. The official model card lists text, image, video, and audio as supported inputs and provides examples for multimodal requests.
Is the 512K context window automatically available in production?
No. The server must be configured for the desired context length, and memory, concurrency, modality, and batching settings determine whether that limit is practical.
Which serving frameworks support it?
The official repository documents Transformers, SGLang, and vLLM. Support is evolving, so pin versions and test the exact checkpoint and flags before deployment.
Bottom line
Dots3-Note Preview is a serious open-weight attempt to combine long-context reasoning, coding, multimodal understanding, and agent workflows in one model. Its 16B active-parameter MoE design makes the 280B total size more practical than a dense equivalent, but local deployment remains an enterprise-scale task.
For developers, the best way to evaluate it is not a casual chat. Build a fixed, observable workload that combines the capabilities you actually need, run it through the official serving stack, and measure correctness, latency, memory, tool-call reliability, and cost. That is where Dots3-Note Preview’s broad design will either become a genuine advantage—or prove more infrastructure-heavy than the problem justifies.
Sources
- Dots3-Note Preview model card on Hugging Face
- Official Dots3-Note Preview repository and deployment guide
- Dots3-Note Preview on OpenRouter
Visual: Model execution pipeline
This original flow explains the runtime path behind the model or agent discussed here. It separates context preparation, inference, tools, and output verification.
Visual reading: the model is one stage in the system, not the whole system. Tool calls and generated artifacts need an explicit verification boundary before they are trusted.
| Stage | Main question | Useful signal |
|---|---|---|
| Context | Is the input relevant and complete? | Grounding and prompt size |
| Inference | Is the model meeting the task? | Quality, latency, token use |
| Tools | Are actions permitted? | Success and permission errors |
| Output | Can the result be used safely? | Tests, review, provenance |
Keep reading
Related reading
⚡ Daily AI Model Drop — Get Kimi K3 benchmarks before Twitter
Join 2,400+ AI engineers. 1 email/day, no spam, unsubscribe anytime