SubQ AI uitgelegd: hoe goed is de LLM met een contextvenster van 12M?

Op 5 mei 2026 bracht een kleine startup uit Miami, Subquadratic, een model uit genaamd SubQ. Het team is klein, maar ze hebben $29M aan seed-financiering opgehaald en claimen dat het model tot 12 miljoen tokens kan verwerken in één enkele pass.

Ze hebben ook andere bizar klinkende claims gedaan, zoals dat hun model tot 52 keer efficiënter is dan FlashAttention bij 1M tokens en een codeerprestatie behaalt die vergelijkbaar is met Claude Opus voor ongeveer 1/20e van de kosten.

Dit zijn grote uitspraken, dus het is logisch om dit op te splitsen en te kijken wat er daadwerkelijk aan de hand is. In dit stuk loop ik door wat SubQ is, hoe de architectuur werkt en wat de vroege details en ontwikkelaarscommunities suggereren over deze claims.

Wat is SubQ?

SubQ is de LLM van Subquadratic, uitgebracht op 5 mei 2026 en gebouwd rond één opvallende feature: een contextvenster van 12 miljoen tokens. Het is het eerste model dat het bedrijf heeft geleverd, en het komt met een reeks gedurfde claims rond efficiëntie en kosten die al tot flink debat hebben geleid. 

Het model is nog niet openbaar beschikbaar; toegang tot de API, SubQ Code en SubQ Search is momenteel beperkt tot vroege toegang via een wachtlijst.

Het is gebouwd op iets dat SSA heet, kort voor Subquadratic Sparse Attention.

In plaats van elke token met elke andere token te vergelijken, zoals bij standaard dichte attention, kiest SSA een selectieve aanpak. Voor elke token kiest het model de meest relevante tokens en berekent het alleen relaties binnen die subset.

Dit heeft twee duidelijke effecten.

• Ten eerste vermindert het het aantal berekeningen, wat de efficiëntie direct verbetert en de kosten verlaagt. 
• Ten tweede is de selectie inhoudsafhankelijk. Dat betekent dat het model niet alleen naar nabijgelegen tokens kijkt. Het kan relevante tokens overal uit de sequentie ophalen, zelfs als ze ver uit elkaar liggen.

Wat is er bijzonder aan SubQ?

In de praktijk betekent de SSA-architectuur dat het model zich richt op wat echt telt, in plaats van alles gelijk te verwerken. Het beoogde resultaat is een vergelijkbare nauwkeurigheid als full attention, maar met aanzienlijk lagere reken- en geheugeneisen.

Laten we eerst dichter kijken naar dichte attention en vervolgens beide benaderingen vergelijken.

Het kwadratische schaalprobleem in transformers

Modellen van vandaag zoals GPT, Claude en Gemini vertrouwen op dichte attention. Op hoofdlijnen betekent dit dat elke token wordt vergeleken met elke andere token in de input. Naarmate de input groeit, groeit het aantal vergelijkingen kwadratisch.

Neem een lang document en stel je voor dat het model het laatste woord moet genereren. Het kijkt terug naar elke token in dat document, bouwt relaties op en beslist dan wat erna komt. Daarom werkt dichte attention goed. Het houdt overal rekening mee.

Maar die kracht heeft een prijs. Naarmate de inputgrootte toeneemt, stijgen de reken- en geheugeneisen scherp, wat contextvenster-limieten creëert. Simpel gezegd schaalt het als O(n²), waarbij n het aantal tokens is.

Dit is waarom de meeste modellen binnen praktische grenzen blijven. In standaardmodellen is 128k tokens de norm, en de meeste krachtige modellen zoals Claude Opus halen maximaal 1M contextvenster.

Om dit te omzeilen, vermijden de meeste AI-gestuurde systemen om volledige datasets aan het model te voeren. In plaats daarvan vertrouwen ze op technieken zoals:

• RAG (Retrieval-Augmented Generation): Sla data extern op, haal alleen relevante stukken op en voer die in het model.
• Chunking: Breek grote tekst op in kleinere stukken en stuur alleen relevante delen naar het model.
• Samenvattingsstrategieën: Comprimeer lange content en voer samenvattingen in het model in, in plaats van de volledige tekst.

Als je dieper wilt begrijpen hoe attention-mechanismen werken, bekijk dan deze tutorial over het attention-mechanisme in LLMs. Voor hands-on ervaring met de bouwstenen van moderne LLMs raad ik onze cursus Transformer Models with PyTorch aan.

Hoe SubQ zich anders positioneert

Dichte attention groeit kwadratisch met de inputgrootte, terwijl SSA is ontworpen om sub-kwadratisch te schalen, dichter bij O(n·k) in plaats van O(n²), waarbij k het aantal geselecteerde tokens per stap is. Wanneer k klein wordt gehouden ten opzichte van n, is dit aanzienlijk efficiënter dan full attention.

Diagram van kwadratische versus lineaire attention met dichte alles-met-alles-verbindingen versus spaarzame selectieve verbindingen.

De voor de hand liggende zorg is hier nauwkeurigheid. Als het model maar naar een deel van de input kijkt, kan het belangrijke relaties missen. Die trade-off is meestal de reden dat dichte attention überhaupt bestaat.

De claim van SubQ is dat die trade-off zich in de praktijk niet voordoet. Ze zeggen dat het model alle noodzakelijke tokens bekijkt, zelfs als die ver van de huidige token afstaan, en een vergelijkbare nauwkeurigheid behoudt als topmodellen.

Hoe werkt Subquadratic Sparse Attention?

We weten inmiddels dat SSA, in plaats van elke token met elke andere te vergelijken, alleen de tokens selecteert die ertoe doen in de sequentie en daarover attention berekent. Laten we kijken hoe die selectie wordt gemaakt.

Hoe SSA relevante relaties selecteert

SSA gebruikt content-afhankelijke routing. Simpel gezegd kiest het tokens op basis van hoe relevant ze zijn voor de huidige token. Het berekent een similariteitsscore tussen tokens, iets als similarity(query_i, key_j), en behoudt alleen de top-k tokens met de hoogste scores voor attention.

Na verloop van tijd leert het model betekenisvolle tokens te prioriteren en ruis te negeren. Dat omvat trefwoorden, belangrijke entiteiten en tokens met sterke contextuele signalen.

Het hangt niet alleen af van de inhoud; SSA bewaart ook structurele relaties in de sequentie. Zo krijgen nabijgelegen tokens altijd aandacht via lokale attention-patronen, terwijl bepaalde globale tokens zijn ontworpen om over de hele sequentie aandacht te krijgen.

SSA omvat ook hiërarchische en clustergestuurde attention-technieken. Het clustert bijvoorbeeld vergelijkbare tokens en berekent de attention met de meest relevante clusters. Dit betekent dat het model niet elke token individueel hoeft te evalueren, maar eerst op groepsniveau kan redeneren en vervolgens, indien nodig, inzoomen op de tokens binnen die clusters.

Training voor long-context retrieval

Een groot contextvenster op zich doet geen magie. Zelfs als je het model 12M tokens geeft, moet het nog steeds weten hoe het die context effectief benut. SSA is hiervoor getraind:

• Pretraining: Het basismodel is getraind op massieve, diverse datasets met long-contextrepresentaties. 
• Supervised fine-tuning: Vervolgens is het model getraind op gestructureerde taken, waaronder redeneren en codegeneratie. 
• Reinforcement learning: In plaats van het model te beperken tot nabijgelegen tokens (lokale attention), is deze stap bedoeld om relevante tokens uit de volledige tekst (globale attention) te laten gebruiken.

De reinforcement learning-fase is vooral belangrijk voor enterprise-codingusecases. Het stelt het model in staat om in één keer een bredere context te overzien—hier de hele codebase—terwijl het de output genereert.

SubQ-benchmarks en prestaties

Let op: "SubQ 1M-Preview" verwijst naar de versie die is gebenchmarkt op 1M tokens. Het volledige contextvenster van 12M is toegankelijk via de API.

Op de drie benchmarks die Subquadratic heeft vrijgegeven, neemt SubQ 1M-Preview het op tegen Claude Opus 4.7, GPT-5.5 en Gemini 3.1 Pro. 

Maar de benchmarkselectie is smal; exact drie tests, allemaal gericht op long-context retrieval en coderen, de twee dingen waarvoor SubQ expliciet is ontworpen. Brede evaluaties over algemeen redeneren, wiskunde, meertalige prestaties en veiligheid zijn niet gepubliceerd.

De volledige modelkaart staat als "binnenkort" op de website, dus we kunnen meer benchmarks verwachten over algemene usecases.

Voor nu zijn dit de resultaten voor long-context retrieval en coding-usecases:

Wat de cijfers laten zien

RULER 128K: SubQ scoort 95% tegen Opus 4.7 met 94,8%. Hoewel het nauwkeurigheidsverschil verwaarloosbaar is, is hier de kostprijs doorslaggevend: Subquadratic claimt dat deze evaluatie op SubQ circa $8 kostte, tegenover ongeveer $2.600 op Opus bij dezelfde contextlengte.

MRCR v2 (8-needle, 1M): Deze benchmark test of het model 8 afzonderlijke feiten, verspreid over een context van 1M tokens, correct ophaalt en bijhoudt. SubQ toont een onderzoeksresultaat van 83%, maar de productie-score daalt naar 65,9%. Deze kloof van ~17 punten tussen lab- en productieprestaties is opmerkelijk en niet volledig verklaard. Toch blijft het competitief met GPT-5.5 (74,0%) en aanzienlijk voor op Claude Opus 4.7 (32,2%) en Gemini 3.1 Pro (26,3%).

SWE-Bench Verified: SubQ scoort 81,8%, vóór Opus 4.6 met 80,8% maar achter Opus 4.7 met 87,6%. De marges ten opzichte van Opus 4.6 zijn klein en gevoelig voor de testopzet. Tegenover Opus 4.7 en GPT-5.5 ligt SubQ duidelijk achter.

Bij 12 miljoen tokens: Er is gerapporteerd dat SubQ meer dan 90% scoort op needle-in-a-haystack-taken bij 12M context, al is dit cijfer niet geverifieerd in officiële benchmarks. Geen enkel ander frontier-model is op deze lengte getest, dus er is niets om direct mee te vergelijken. Het is het meest architectonisch interessante resultaat van de lancering en ook het resultaat dat onafhankelijke reproductie nodig heeft voordat we conclusies trekken.

Wat SubQ betekent voor RAG, coding-agents en AI-kosten

Als de architectuur van SubQ op schaal standhoudt, verandert dat hoe LLM-systemen worden gebouwd. Langere context wordt praktisch, waardoor de behoefte aan agressief chunking, retrieval en tokenoptimalisatie afneemt. Laten we deze veranderingen nader bekijken.

Wanneer RAG optioneel wordt

De afgelopen twee jaar is Retrieval-Augmented Generation (RAG) het standaardantwoord geweest op een fundamentele beperking in LLMs: modellen kunnen niet alles in één keer lezen. Als je knowledge base groter is dan het contextvenster, verdeel je documenten in stukken, embed je ze, sla je ze op in een vectordatabase, haal je de meest relevante stukken op en geef je alleen die fragmenten aan het model mee met de prompt.

Dat hele ecosysteem bestaat omdat context schaars is.

Wanneer een model betrouwbaar miljoenen tokens in één pass kan verwerken, worden veel van de engineeringslagen rond retrieval voor bepaalde workflows minder noodzakelijk. In plaats van tijd te besteden aan beslissen welke stukken je ophaalt, kan het systeem het ruwe materiaal direct inlezen en er end-to-end over redeneren.

Toch blijft RAG, los van het contextvenster, belangrijk voor deze mogelijkheden:

• Cross-sessie-geheugen: LLMs onthouden niets zodra een sessie eindigt. Als een gebruiker later terugkomt, begint het model opnieuw. Retrievalsystemen (of databases) slaan belangrijke informatie op zoals eerdere beslissingen, documenten of gebruikersdata, zodat het model die in toekomstige interacties kan gebruiken.
• Toegangsrechten en autorisatie: Retrievalsystemen kunnen regels afdwingen zoals “deze gebruiker heeft alleen toegang tot data van zijn/haar team.” Zo ontvangt het model alleen documenten die de gebruiker mag zien, wat onbedoelde datalekken voorkomt.
• Auditability: In enterprise-omgevingen is een antwoord niet genoeg; je moet laten zien waarom het klopt. Retrievalsystemen kunnen wijzen op de exacte documenten of bronnen die zijn gebruikt, zodat teams resultaten kunnen verifiëren en problemen kunnen debuggen als er iets misgaat.
• Gestructureerd kennisbeheer: Bedrijven voegen voortdurend documenten toe, werken ze bij en verwijderen ze. Retrievalsystemen gebruiken embeddings en indexing om deze data te organiseren, zodat het model snel de nieuwste en meest relevante informatie vindt zonder elke keer alles opnieuw te verwerken.

Voor een nieuwe, interessante aanpak om persistente geheugenlaag aan AI-agenten toe te voegen, lees onze Supermemory-tutorial, waarin je leert hoe je een oefentrainer bouwt met kort- en langetermijngeheugen.

Long-context coding-workflows

Op dit moment kunnen de meeste codingmodellen niet de hele codebase overzien. Dus voegen we lagen erbovenop toe—bestandszoekfunctie, chunking, ranking en meerstapsplanning—alleen om de juiste context in het venster te houden en relaties over bestanden heen te bouwen.

Maar met het SubQ-contextvenster van 12M wordt de hele codebase in één keer in het model geladen. Dit vereenvoudigt het agentontwerp op een betekenisvolle manier.

• Planning wordt globaal: Het model kan redeneren over architectuur, dependencies en interacties tussen bestanden zonder context te missen.
• Uitvoering is consistenter: Wijzigingen over meerdere bestanden kunnen in één pass worden gecoördineerd, in plaats van via incrementele updates.
• Review is betrouwbaarder: Het model kan zijn eigen wijzigingen verifiëren tegen de hele codebase, wat inconsistenties vermindert.

Kosteneconomie

In standaard transformer-modellen schaalt attention kwadratisch met de sequentielengte. Als je de context verdubbelt, verdubbelen de kosten niet alleen; het kan vier keer zo duur worden.

SubQ claimt die trade-off te doorbreken.

• Het meldt ~1/20e van de kosten van vergelijkbare frontier-modellen (Claude Opus)
• En tot ~1.000× reductie in compute bij een context van 12M tokens

Als dit in productie standhoudt, houdt long-contextverwerking op een dure randcase te zijn en wordt het iets dat je vaker kunt inzetten.

Echter, naast een goedkoop contextvenster moet het model de informatie die we in zijn context laden ook efficiënt kunnen gebruiken. Op basis van de benchmarks claimt SubQ vergelijkbare nauwkeurigheid tegen veel lagere kosten, maar het is nog te vroeg voor een definitief oordeel.

Hoe krijg ik toegang tot SubQ?

SubQ is nog niet openbaar beschikbaar. Alle drie de producten—de core API, SubQ Code en SubQ Search—zijn momenteel in private bèta, en toegang vereist een early-access-aanvraag via de SubQ-website.

Vanuit ontwikkelaarsperspectief is de API ontworpen om gemakkelijk te integreren. Deze ondersteunt:

• streaming responses
• tool/function calling
• OpenAI-compatibele endpoints

Dat betekent dat je doorgaans je integratie niet hoeft te herschrijven als je stack al met OpenAI-achtige APIs werkt.

SubQ Code wordt gepositioneerd als een commandline coding-agent, terwijl SubQ Search zich richt op long-context-zoekopdrachten voor diepgaandere onderzoeksworkflows. Zie ze als de SubQ-versies van Claude Code en Perplexity. 

De prijzen voor deze tools zijn ook nog niet transparant. Er zijn geen publiek beschikbare per-token-tarieven, wat het lastig maakt om de kostenclaims van het bedrijf onafhankelijk te valideren.

Scepsis en open vragen

Binnen uren na de lancering is er al veel scepsis en gemengde reacties op sociale platforms en forums zoals Hacker News. De discussie is verdeeld: sommigen zien het als een echte doorbraak, terwijl anderen het vergelijken met een “AI Theranos” (een verwijzing naar de mislukte bloedtest-startup die frauduleuze technologische claims deed).

De meeste twijfels richten zich op: 

• Ze claimen een contextvenster van 12M, maar de gedeelde benchmarks zijn allemaal op 1M.
• Ze noemden het bedrijf Subquadratic, maar op sommige plekken noemen ze O(1)-achtige schaling. Bij O(1) zou je veel meer dan een contextvenster van 12M tokens verwachten. Zelfs O(log n) zou grotere limieten toelaten.

Een vergelijkbaar verhaal dook op bij Magic.dev in 2024. Zij deden sterke claims over extreem grote contextvensters, tot 100M tokens, en grote efficiëntiewinsten, vooral voor coding-workflows. 

De pitch was bijna identiek: hele codebases laden, retrievalcomplexiteit verminderen en het ontwerp van agents vereenvoudigen. Maar het publieke resultaat is vooralsnog gematigder. Ondanks het ophalen van circa $500M is er nog steeds beperkte zichtbaarheid of adoptie in de echte wereld, begin 2026.

Wat wel is geverifieerd

De claims van SubQ zijn niet puur theoretisch. Subquadratic meldt dat benchmarks op RULER, MRCR v2 en SWE-Bench Verified door een externe testdienst zijn uitgevoerd, met sterke prestaties op long-context retrieval en competitieve resultaten op codetaken. 

Toch zijn deze resultaten nog niet onafhankelijk gereproduceerd door externe onderzoekers, en de reikwijdte van de evaluatie is smal. Alle drie benchmarks benadrukken precies de gebieden waarvoor SubQ is gebouwd (het ophalen van signalen uit grote context en opereren over code).

Een ander belangrijk detail is de architectuur. De CTO heeft bevestigd dat SubQ geen modellen from scratch traint, maar voortbouwt op open-source basismodellen (waarschijnlijk uit families zoals DeepSeek of Kimi). Dit is een praktische keuze voor een klein team. Het versnelt iteratie en vermindert trainingskosten. Dat betekent ook dat de kerninnovatie niet zit in het basismodel zelf, maar in het attention-mechanisme en het systeemontwerp eromheen.

Slotgedachten

SubQ is er, en de claims zijn behoorlijk gedurfd. De richting is duidelijk: verwijder de beperking van het contextvenster en laat modellen veel grotere inputs aan. Ze positioneren het als gelijkwaardig aan of beter dan frontier-modellen op coderen en long-context retrieval, tegen veel lagere kosten.

Dat gezegd hebbende: het is nog vroeg. We wachten nog op de volledige modelkaart voor meer zicht op bredere capaciteiten en tests. De producten die erop zijn gebouwd, SubQ Code en de API, zijn ook nog niet openbaar beschikbaar. Ik kijk ernaar uit om met deze tools aan de slag te gaan en te zien hoe de claims standhouden in productie.