IQuest-Q1 Reports 83.2 on Terminal-Bench, Plus 30 Vulnerability Reports

The newly released IQuest-Q1 is a 320B-parameter sparse mixture-of-experts model targeting agentic CLI work, with a reported 83.2 on Terminal-Bench 2.1. The architecture has 15B parameters active per token and a 512K context window, according to the supplied release coverage in AI Weekly.

The same account says security experts produced 30 vulnerability reports during a three-day live deployment. That is a separate evidence track from benchmark performance. It does not establish how many reports were confirmed, what their severity was or which issues were fixed.

Builders evaluating a command-line agent need both kinds of evidence without blending them into a single score. A benchmark result can support a decision to test a candidate. Live vulnerability reporting can identify questions for an operational review. Neither automatically resolves the other, and neither supplies a complete deployment decision.

The score needs its version and its task

The reported 83.2 result belongs to Terminal-Bench 2.1. Keep the version in every comparison rather than treating Terminal-Bench as an undifferentiated label. The supplied facts do not establish a score on another version, so an apparently higher number elsewhere cannot be used to construct a defensible ranking without checking evaluation compatibility.

Other reported results are 57.5 on SWE-Bench Pro and 64.6 on DeepSWE v1.1. IQuest also reports 93.3 on GPQA Diamond, 85.5 on BrowseComp and 84.5 on CyberGym. Each score belongs to a named evaluation. The list is evidence of reported breadth, not a supplied conversion into expected success on your company's tasks.

For a CLI buyer, this leaves a concrete next step: define the commands and repository work the agent would actually perform, then evaluate those tasks under the permissions you intend to grant. The supplied scores do not establish reliability in that environment. They justify placing the model on an evaluation shortlist without making the shortlist equivalent to approval.

Sparse activation does not provide a hosting quote

IQuest describes Q1 as having 320B total parameters with 15B active per token, across 88 layers and 256 experts, of which 8 are routed. Those are architecture details. They distinguish total model size from active computation, but the supplied facts do not translate them into a hardware configuration or operating bill.

The model paper's claim of 1.93x higher scaling efficiency over Qwen3-MoE baselines also needs its original boundary. It is a reported comparison against those baselines, not an inference-price promise. Substituting that ratio for a customer cost reduction would add a commercial conclusion that the supplied evidence does not contain.

The 512K context window is another capacity specification rather than a complete workflow guarantee. The fact sheet does not supply latency, pricing or a measurement of task performance across that entire context. Buyers should request those missing details if they affect the application. A larger stated context can be relevant without answering every question about how an agent behaves during extended work.

The trade-off is live exposure without a supplied resolution record

The three-day deployment yielded 30 vulnerability reports from security experts. That tells readers a reporting process produced findings during actual deployment. It does not supply a severity distribution or establish that every report describes a distinct confirmed vulnerability. Keeping the noun reports matters because confirmation and remediation are separate stages of evidence.

The provided account also does not describe the affected components or whether the reports concern the model, its surrounding service or another part of the deployed system. Assigning all reports to the weights would be unsupported. Dismissing them as unrelated to a deployment decision would also skip questions the available facts leave open.

For builders, the trade-off is proceeding with an operational trial while the public summary does not close the security review. A good benchmark score cannot establish that tool access is safe, and an unexplained report count cannot establish that deployment is impossible. The appropriate response is to request the disposition of the reports and keep permissions bounded while evaluating the intended workflow.

What To Do About It

• Normalize the comparison: Have your evaluation owner annotate every candidate result with the benchmark version and avoid ranking incompatible entries together. Preserve the supplied score exactly in your decision notes; IQuest-Q1's reported result is 83.2 on Terminal-Bench 2.1.
• Request report disposition: Ask the supplier what was confirmed, what remains open and which deployment components were affected. Record missing answers rather than treating a count as either a clean bill of health or a confirmed incident inventory; the supplied account lists 30 vulnerability reports.
• Price the actual deployment: Ask for the requirements and costs of the specific serving arrangement you are considering before accepting an efficiency argument. Do not enter the paper's baseline comparison as an invoice reduction; the reported scaling-efficiency claim is 1.93x.
• Bound the CLI trial: Review the commands and permissions your agent would receive, and require approval for actions outside the test's intended scope. Evaluate the tasks you actually need rather than assuming the full stated context establishes reliability; the advertised context window is 512K.

The Bottom Line

IQuest-Q1's reported 83.2 on Terminal-Bench 2.1 is a reason to investigate its suitability for CLI work, not a production approval. The 30 vulnerability reports introduce operational questions that the supplied summary does not resolve. Keep architecture, benchmark results and report disposition in separate parts of the decision. Buy only after the evidence covers the workflow and permissions you intend to deploy.