MiroThinker: A Deep Research Agent That Runs Up to 300 Tool Calls per Task

The problem MiroThinker targets: research questions that outlast a single retrieval step

Most retrieval-augmented systems answer a question in one pass: embed the query, pull the top-k chunks, generate. That works for factoid lookups. It breaks on questions whose answer depends on a chain of intermediate findings, where step three only becomes visible after step two returns something unexpected. MiroThinker is built for that second category. The README describes it as a deep research agent optimized for complex research and prediction tasks, and the feature list is explicit about the shape of the workload: long-horizon reasoning, deep multi-step analysis, and up to 300 tool interactions per task. The target user is not someone building a customer support bot. It is a team that needs an agent to work a research or forecasting problem over many tool calls, and that is willing to serve a large open-weight model to get there. The MiroVerse-v0.1 dataset link in the README suggests the project also cares about training or fine-tuning on research traces, not just inference.

How the agent is structured: model scale, context budget, and a tool-call ceiling

The architecture visible in the README is a model plus a tool loop, with two hard numbers defining the envelope. First, context: both MiroThinker-1.7-mini and MiroThinker-1.7 support a 256K context window. Second, interaction depth: both allow up to 300 tool calls per task. The two variants differ only in parameter count, 30B for the mini model and 235B for the full one, and the README says they ship with a suite of tools and workflows intended to flex across research settings and compute budgets. That framing matters. The project is not presenting a single fixed pipeline. It is presenting a base model plus scaffolding, where the number of tool calls you permit is a dial you can turn against your compute budget. The README also mentions interactive scaling as a third dimension of performance improvement, introduced with v1.0, alongside the usual parameter and context scaling axes. The README does not document the tool interface itself in the material provided, so the exact schema for registering a search tool or a document reader cannot be confirmed from what is here. That is a gap worth noting before you plan an integration.

Reported benchmark results, and why the version history complicates them

The README states that MiroThinker-1.7 achieves 74.0 on BrowseComp, 75.3 on BrowseComp-ZH, 82.7 on GAIA-Val-165, and 42.9 on HLE-Text, and claims state-of-the-art performance on BrowseComp-ZH among open-source models. Those are the numbers to hold onto, and they come from the project's own materials, not from an independent evaluation. The complication is the release history. MiroThinker-v1.5-235B is listed at 69.8 on BrowseComp and 71.5 on BrowseComp-ZH. MiroThinker-v1.0 is listed at 47.1 on BrowseComp and 55.6 on BrowseComp-ZH. MiroThinker-v0.2 is listed at 17.2 and 29.4 on those same two benchmarks. Four generations, four different result sets, all on the same benchmark names. If you are comparing MiroThinker against another agent, pin the version. Quoting a v1.0 figure as if it were the current model understates it by a wide margin, and the reverse mistake is just as easy to make. The README also notes that MiroThinker-1.7-mini reaches 72.3 on BrowseComp-ZH with 30B parameters, which is the more interesting claim for anyone without a large GPU allocation.

Getting it running: what the README actually gives you

The README's Quick Start section is the entry point, and the repository also ships a Gradio demo under apps/gradio-demo, referenced in the 2025-08-22 update as a deployment option with optimized resource usage and faster startup. Beyond that, the material provided does not include the install commands, the Python entry point, or the configuration keys. I cannot list a pip install line or a YAML key here without inventing it, so I will not. What can be said is the shape of the setup work: you pull a model from the Hugging Face collection linked in the README, you run the agent code from the repository, and you supply whatever tools the loop is meant to call. The 30B mini model is the realistic starting point for a single-machine evaluation. The 235B model implies a multi-GPU serving setup, and the README gives no VRAM figures, no quantization guidance, and no throughput numbers. Budget for that discovery phase. The FAQ and Troubleshooting section exists in the table of contents, which suggests the project expects setup friction, but its contents are not in the material I have.

Where MiroThinker is the wrong tool

The 300 tool call ceiling is generous, and that is exactly the problem for simple workloads. An agent permitted to make hundreds of calls will make them if the prompt does not discourage it, and each call costs latency and, if your tools hit paid APIs, money. For a question that a single search plus a summarization pass would answer, MiroThinker adds a long tail of orchestration overhead with no accuracy benefit you can measure. The second limitation is deployment weight. There is no hosted API from MiroMindAI documented in this repository, only a web demo at dr.miromind.ai and the open weights. If your constraint is that you cannot run a 30B model yourself, this project does not solve your problem; it hands you a model card and a codebase. Third, the benchmark suite the project optimizes against (BrowseComp, BrowseComp-ZH, GAIA, HLE, XBench-DeepSearch, FutureX) is dominated by web-research tasks. If your domain is internal document retrieval over a private corpus, the reported numbers tell you very little about your workload, and you would be adopting the scaffolding while replacing the evaluation entirely.

The alternative: single-pass RAG and what changes when you switch

The obvious alternative is a conventional retrieval-augmented pipeline built on a general-purpose instruction model, where you embed the query, retrieve once, and generate. The difference is not quality on hard questions. It is where the control lives. In a single-pass pipeline, the retrieval step is fixed before generation starts, so the system cannot decide that its first search was insufficient and try a different query. MiroThinker's tool loop inverts that: the model chooses the next call based on what the previous call returned, which is what makes multi-step research possible and also what makes cost unpredictable. A second alternative is a hosted deep research product, which trades the deployment burden for a per-query price and no visibility into the loop. The practical decision is whether you want to own the inference stack. If you do, MiroThinker's Apache-2.0 licence gives you the weights and the code with no per-query fee. If you do not, the open weights are not a substitute for a service.

Maintenance, version churn, and licence terms

The release cadence is the maintenance story. The README documents v0.1 in August 2025, v0.2 in September 2025, v1.0 in November 2025, v1.5 in January 2026, and 1.7 in March 2026. That is roughly a major version every two months, and each one changes the benchmark numbers, which means each one changes the model you are serving. Pinning a checkpoint is not optional if you care about reproducibility across a quarter. The last push to the repository is dated 2026-07-06, so the project is active. On licensing: the repository is Apache-2.0, which permits commercial use and modification, but the model weights live on Hugging Face under their own terms, and the README links to a Hugging Face collection rather than restating a model licence. Check the model card for the specific checkpoint before you ship anything. The README also links a dataset, MiroVerse-v0.1, on Hugging Face, which will carry its own terms separate from the code licence. This is a description of what the repository states, not legal advice; read the actual licence files for the code, the weights, and the dataset before commercial deployment.

Editorial conclusion

MiroThinker is worth a serious look if you need an open-weight agent that can hold a 256K context and chain up to 300 tool calls on a single research question, and if you have the GPU budget to serve a 30B or 235B model. It is the wrong choice if you want a hosted API with a published rate card, or if your tasks resolve in one or two retrieval steps. Before committing, verify three things: that the tool-calling loop in the 1.7 code path actually matches the 300-call ceiling the README advertises, that your inference stack can serve the 235B variant at acceptable latency, and that the BrowseComp and BrowseComp-ZH figures you care about come from the 1.7 checkpoint rather than the older v1.0 or v1.5 releases, which report different numbers on the same benchmarks.

Official sources

1. Issues
2. License: Apache-2.0
3. MiroMindAI/MiroThinker on GitHub
4. Project website
5. README