SubQ 1M-Preview

What You'll Learn

• What SubQ announced on May 5, 2026 and how its sparse-attention design is described.
• Which benchmark numbers belong to SubQ 1M-Preview and which belong to the newer SubQ 1.1 Small model.
• Why a 12 million-token context window does not by itself prove reliable reasoning or universal speed.
• How to evaluate early-access API access, pricing, long-context quality, and production risk before adoption.

Subquadratic's official launch post dated May 5, 2026 introduces SubQ 1M-Preview as an LLM built on a fully subquadratic architecture. The company says compute grows linearly with context length and that the design is intended for multi-million-token reasoning. Its product site presents an API, SubQ Code, and SubQ Search through private beta early access. That is an important starting point because the model is a product announcement and a research claim, not a universally available replacement for every transformer model.

The original article used phrases such as first commercial non-transformer model, 52x faster, 5x cheaper, and historic breakthrough as if each statement were an independently established fact. A better reading is narrower. Subquadratic has published a technical direction, benchmark figures, and product descriptions. Some results were evaluated by Appen or reported by the company. Independent readers still need to check the evaluation scope, model version, input length, hardware, and whether a number describes an attention kernel or an end-to-end application.

For a wider explanation of why long-context model design affects agent workflows, see our agentic AI guide. The SubQ announcement belongs in that broader discussion, but its own evidence should remain separate from general claims about the AI market.

What Is SubQ 1M-Preview

SubQ 1M-Preview is the first model that Subquadratic publicly introduced. The company describes it as a fully subquadratic LLM rather than a conventional dense-attention transformer. In plain language, the design tries to avoid computing every possible relationship between every token in a long input. It uses a learned sparse-attention mechanism to focus computation on relationships that the model considers relevant.

The name can cause confusion. The official launch post discusses a research result at 12 million tokens, while the model name includes 1M-Preview because the published benchmark package focuses on a one-million-token evaluation version. The correct interpretation is not that the name itself proves a one-million-token product limit. It is that Subquadratic used the preview model name while describing a much larger research context capability.

The product site positions SubQ for full repositories, long histories, persistent agent state, and other artifacts that are difficult to fit into a conventional context window. It shows examples such as the Python standard library and months of React pull requests. Those examples describe intended use cases. They do not guarantee that every codebase or document collection will be processed accurately in one pass.

Why Subquadratic Attention Matters

Dense self-attention is commonly described as O(n²) with respect to sequence length. If the number of tokens increases, the number of possible token-to-token interactions grows sharply. The exact cost of a production system also depends on hardware, implementation, batching, memory movement, and other parts of inference. The important idea is that attention cost becomes a major constraint as the context grows.

Subquadratic Sparse Attention, or SSA, is designed to reduce that burden by selecting a smaller set of relationships based on content or learned routing. A sparse design can lower compute and memory requirements, but it introduces a quality question. If the model skips a relationship that later proves important, the output can lose information even when the context window is large. Sparse attention therefore needs retrieval and reasoning evaluations rather than a context-size claim alone.

Subquadratic's official pages say its architecture scales linearly with context length and that attention compute is reduced by almost 1,000x at 12 million tokens compared with other frontier models. This is a company-reported architectural claim. It should not be restated as 1,000x faster application performance because attention compute is only one part of total inference time.

The distinction matters for engineering budgets. A model may use fewer floating-point operations yet still be limited by input transfer, tokenization, output generation, storage, network delay, or model orchestration. A fair deployment test measures time to first token, total latency, throughput, error rate, memory use, and cost for the actual workload.

What the Official Launch Claim Includes

The official launch post makes several related claims. It describes SubQ 1M-Preview as the first LLM built on a fully subquadratic architecture. It says the model supports significantly larger context windows, reports a research result at 12 million tokens, and says attention compute can be reduced by almost 1,000x at that scale. It also describes API, coding-agent, and search products that were available through private beta.

These claims are useful because they define what the company is trying to solve. Long-context applications often rely on chunking, retrieval, summarization, and multiple agent steps because a model cannot hold or reliably use a full artifact. A model that can reason across more of the artifact could simplify some workflows. It would not remove the need for permissions, data freshness, audit trails, evaluation, or human review.

The official site says the API supports streaming, tool use, and OpenAI-compatible endpoints. That can reduce integration effort for teams that already use OpenAI-style request formats. It does not establish that the API has identical semantics, limits, safety behavior, rate limits, or pricing. Developers should test tool calls, structured outputs, failures, retries, and context truncation on the actual account before changing a production route.

Benchmark Results and Their Scope

Subquadratic's launch post reports a RULER 128K result of 95.6% for SubQ 1M-Preview compared with 94.8% for Claude Opus 4.6. It also reports an architecture-level comparison in which SubQ Sparse Attention was 52x faster than FlashAttention and required 63% less compute. The figures are meaningful only with the test setup. The RULER score measures a defined long-context task. The speed number compares an attention mechanism, not a complete user request.

The launch post also reports an MRCR v2 research result of 83 and a production model score of 65.9 described as third-party verified. It lists scores of 74 for GPT 5.5, 32.2 for Claude Opus 4.7, and 26.3 for Gemini 3.1 Pro. It reports SWE-Bench Verified at 81.8 for SubQ, compared with 80.8 for Opus 4.6 and 80.0 for Deepseek 4.0 Pro. The comparison is useful for locating the model's intended strengths, but it is not a complete evaluation of general reasoning, safety, multilingual performance, or short-context chat.

DataCamp's independent review makes the limitation explicit. It notes that SubQ's public evaluations focus on long-context retrieval and coding, and that broader evaluations and transparent public per-token pricing were not available at the time of its review. That caution should stay in the article because a narrow benchmark can show that a model is good at its chosen test without proving universal superiority.

Context Window Versus Context Quality

A 12 million-token context window is a capacity statement. It tells you how much input the API may accept or how much the architecture was designed to handle. It does not tell you whether the model will retrieve every relevant fact, preserve every relationship, follow instructions consistently, or produce a correct answer when the context is noisy.

Long-context evaluation should vary the depth and distribution of the evidence. A single needle-in-a-haystack test can show retrieval at a selected location. A multi-task test can examine several facts or transformations. A real application test should add repeated names, conflicting versions, permissions, tables, code dependencies, and irrelevant material. It should also check whether the model cites the right source or simply produces a confident answer.

The model-card and product version matter. The official company site now presents SubQ 1.1 Small with newer numbers such as 99.12% on RULER 128K, 100% single-fact retrieval at 1M and 2M, and 98% at 6M and 12M. It reports 64.5x less compute than dense attention and 56x faster than FlashAttention-2 at 1M context. These figures belong to SubQ 1.1 Small and should not be copied into an article about the original SubQ 1M-Preview as if the models were identical.

Appen's June 16, 2026 brief has the same version boundary. It evaluates SubQ 1.1 Small Preview and reports long-context retrieval and LiveCodeBench results for that newer preview family. A third-party report can strengthen the evidence for the company's broader approach, but it cannot silently change which model a benchmark describes.

API and Product Availability

The official launch post says SubQ 1M-Preview became available through private beta early access in three product forms. The API is intended for developers and enterprise teams. SubQ Code is a coding agent that can load repository context. SubQ Search is described as a long-context search and research tool. The current product site still presents an early-access request rather than a normal public sign-up with transparent usage terms.

This availability status changes the practical evaluation plan. A team cannot assume that a public benchmark page means a production account is available. It should request access, confirm the model name and version, read the current acceptable-use and privacy terms, and ask for limits on context, concurrency, tool use, data retention, and support. A private beta may also change behavior or pricing during the preview period.

The OpenAI-compatible description is helpful for a prototype, but compatibility is not equivalence. An integration test should check authentication, streaming, error codes, tool-call arguments, structured responses, maximum input size, output limits, and retry behavior. It should also test whether the service exposes enough usage data for cost monitoring.

Why Public Pricing Needs Verification

The original article described SubQ as 5x cheaper and gave an implied one-fifth price of frontier models. The official launch materials describe lower cost as a product goal and report lower attention compute. DataCamp's review says public per-token pricing was not transparent. Without a public pricing table or a reproducible invoice, the article should not present a universal price multiplier as a fact.

Cost depends on more than a model's attention mechanism. A long prompt may reduce the number of retrieval steps while increasing input tokens. A request may add tool calls, retries, output tokens, storage, or network charges. A vendor may price early access differently from a later general product. A production decision therefore needs an account-specific quote or billing record and a controlled workload comparison.

The right cost experiment holds the task constant. Send the same artifact to the same model version, record input and output tokens, measure latency, count failures and retries, and compare the result with the baseline system. Run short, medium, and long contexts. Include the cost of retrieval and orchestration when the baseline uses RAG or multiple agents. The resulting figure is a workload cost, not a permanent claim about all SubQ usage.

Where Long Context Can Help

Long context can be useful when the relationships across an artifact matter. A coding agent may need to inspect definitions spread across many files. A legal workflow may need to compare a term with exceptions in another section. A financial review may need to connect a filing, an earnings report, and supporting tables. A research system may need to hold a long history while tracking references.

The benefit is not that retrieval becomes useless. Retrieval can enforce permissions, select the current document, reduce unnecessary tokens, produce citations, and make an answer auditable. A 12 million-token window can become another layer in the system rather than a reason to remove every data-control layer. It may support a larger working set while a retrieval system still decides what a user is allowed to see.

For AI search workflows, compare the long-context idea with our AI search engines guide. For coding workflows, see our coverage of AI browsers and tool-using systems. Those related articles provide context, while the SubQ launch page remains the authority for the product's own claims.

What Developers Should Test

A serious SubQ evaluation should start with a representative artifact and a fixed answer key. For an agent-focused test plan, see our agentic AI guide. If the test is code, define the repository, build command, security policy, and expected patches. If the test is a document set, define the questions, source locations, conflict rules, and citation standard. If the test is an agent, define the tool permissions and which actions require approval.

1. Confirm the account, model version, context limit, and current private-beta terms.
2. Measure retrieval accuracy at several context lengths and evidence depths.
3. Test conflicting facts, duplicated entities, tables, code references, and irrelevant material.
4. Record time to first token, total latency, throughput, input tokens, output tokens, and failures.
5. Test tool calls, structured outputs, retries, cancellation, and partial responses.
6. Check permissions, retention, encryption, logging, and deletion options for sensitive data.
7. Compare the full workload cost with the current RAG or multi-agent baseline.

Keep the evidence versioned. A preview model can change between tests, and a benchmark score can change when the prompt format, harness, sampling parameters, or comparison model changes. Save the request configuration and response metadata so that another engineer can reproduce the result.

How SubQ 1.1 Small Changes the Comparison

SubQ 1.1 Small is a newer model family described in the company's June 16, 2026 technical report. The report says it is being deployed with select design partners and that a broader lineup ranging from 2M to 12M tokens is planned later in the year. It describes long-context retrieval, general knowledge, coding, and agentic workflow evaluations.

The report also says SubQ 1.1 Small started from an existing open-weight frontier model, replaced dense attention with SSA, and used staged context extension. That detail is important because the innovation is not necessarily a completely new model trained from scratch. It may be a combination of a base model, a changed attention mechanism, long-context training, serving infrastructure, and product design.

The technical report lists GPQA Diamond at 85.4, LiveCodeBench at 89.7 pass@4, and AutomationBench Finance at 13% for SubQ 1.1 Small. It compares those figures with newer model versions such as GPT-5.5, Opus 4.8, Sonnet 4.6, GPT-5.4-mini, GPT-5.4-nano, and Haiku 4.5. Because these figures belong to a later model, they are useful for tracking the company's progress but should not be used to rewrite the original 1M-Preview benchmark table.

How to Read the SubQ Announcement

The safest reading is that Subquadratic has proposed a credible and interesting architecture direction with early evidence on the tasks it chose to measure. For comparison with another long-context research workflow, see our Gemini and Perplexity guide. a credible and interesting architecture direction with early evidence on the tasks it chose to measure. The official materials provide enough detail to understand the intended value: use sparse attention to make larger context practical, reduce compute, and support repository-scale or artifact-scale workflows.

The cautious reading is that a preview launch is not the same as mature production adoption. The benchmark set is narrow. Public pricing is not transparent. Access is private beta. Some comparison scores are vendor reported or commissioned by the vendor. Newer product pages describe newer model versions. These are not reasons to dismiss the work. They are reasons to keep the claim precise.

When a source says “first,” ask whether it means first announced, first commercially offered, first based on a particular architecture, or first independently evaluated. When it says “faster,” ask whether the test measures an attention kernel, prefill, end-to-end latency, or total workflow time. When it says “cheaper,” ask for the price table, token accounting, and baseline assumptions. These questions make the article more useful to developers than a stronger but less defensible headline.

Conclusion: Evaluate the Model Before You Adopt It

SubQ 1M-Preview is a serious architecture and product announcement, but the available evidence supports a careful conclusion rather than a universal victory claim. Subquadratic describes a sparse-attention system designed for multi-million-token context. Its launch materials report long-context retrieval, coding results, lower attention compute, and private-beta products for API, code, and search use.

The most important technical distinction is between capacity and reliability. A 12 million-token window can make a new class of workflows possible, but developers still need to measure retrieval, reasoning, citations, tools, privacy, latency, and cost. The most important editorial distinction is between the original 1M-Preview and the newer 1.1 Small model. Their benchmark figures and availability should not be mixed.

For teams considering access, the next step is a controlled evaluation with fixed artifacts, a clear baseline, and a reproducible cost record. For readers, the useful takeaway is not that transformers are already finished. It is that attention architecture is an active area of competition, and SubQ is an early example whose claims should be tested against real workloads before they become production assumptions.