Poolside setzt diesmal nicht auf die Schlagzeile eines Billionen-Parameter-Modells. Laguna S 2.1 ist ein MoE-Coding-Modell mit 118B Gesamtparametern und 8B aktiven Parametern. Die Gewichte liegen auf Hugging Face, und laut Poolside kann das Modell auf einer einzelnen NVIDIA DGX Spark laufen.
Der Kern der Meldung: Ein westliches Unternehmen liefert ein Open-Weight-Coding-Modell, das sich selbst hosten lässt. Poolside behauptet dabei nicht, GPT oder Claude geschlagen zu haben. In den eigenen Zahlen erreicht Laguna S 2.1 auf Terminal-Bench 2.1 70,2 Prozent und liegt damit weiter hinter der geschlossenen Spitze. Die Wette lautet, dass Unternehmen diesen Abstand akzeptieren, wenn Code, Logs und interne Daten im eigenen Umfeld bleiben.
Zuerst auf eine deploybare Größe gebracht
Poolside beschreibt Laguna S 2.1 als Mixture-of-Experts-Modell mit 118B totalen und 8B aktiven Parametern, Unterstützung für bis zu 1 Million Token Kontext und weniger als neun Wochen zwischen Trainingsstart und Veröffentlichung.
Das Modell ist vor allem für agentic coding gedacht. Poolside nennt 70,2% auf Terminal-Bench 2.1, 78,5% auf SWE-Bench Multilingual, 59,4% auf dem öffentlichen SWE-Bench Pro und 40,4% auf DeepSWE. The Next Web ordnet ähnlich ein: Bei Terminal-Bench und SWE-Bench Pro kommt Laguna S 2.1 mehreren größeren offenen Modellen nahe oder liegt vor ihnen, während geschlossene Modelle noch etwa 10 bis 15 Punkte führen.
Diese Werte sind keine saubere Gesamtrangliste. Die 70,2 Prozent stammen aus Poolsides eigenem Agent-Harness für Terminal-Bench 2.1. Die 40,4 Prozent bei DeepSWE beziehen sich auf thinking mode; ohne Thinking sind es im selben Maßstab nur 16,5 Prozent. Poolside weist zudem darauf hin, dass manche Vergleiche Herstellerangaben, Leaderboards oder Bestwerte Dritter nutzen. Die Zahlen zeigen also eher die Position als ein exaktes Kopf-an-Kopf-Rennen.
Die Aussage dreht sich um Arbeitsgewohnheiten
Poolside erklärt das Update nicht als reines Parameter-Upgrade. Das Modell soll mehr prüfen, weniger voraussetzen, nicht zu früh Erfolg melden und länger an Aufgaben dranbleiben.
"What we've done in this model is not necessarily add more intelligence, but improve the behaviors that lead to a more capable model: more verification, less taking things for granted, not declaring victory early, and being more persistent."
Pengming Wang, Co-Leiter Applied Research bei Poolside, beschreibt damit weniger zusätzliche Intelligenz als bessere Engineering-Disziplin: mehr Verifikation, weniger Annahmen, kein Abbruch bevor Tests wirklich durch sind.
Die Beispiele passen dazu. Laguna S 2.1 soll in einer 50-minütigen Sitzung mit 181 Schritten aus einem leeren Ordner eine einfache HTML/CSS-Rendering-Engine gebaut haben. In einer internen Harness-Optimierung habe das Modell die Geschwindigkeit um 5,2% erhöht und Speicherallokationen um rund 70% gesenkt. Das beweist keine Kundenleistung, zeigt aber, dass Poolside lange Softwareaufgaben und Selbstprüfung verkauft, nicht nur Chat.
Eine Lücke bei offenen Gewichten
Im vergangenen Jahr kamen viele laute Open-Weight-Coding-Modelle aus China: Kimi K3, Qwen, DeepSeek und MiniMax konkurrierten bei Größe, Lizenz, günstigen APIs und lokaler Ausführung. Westliche Anbieter verkauften häufiger geschlossene APIs, während offene Modelle bei Größe und Coding-Leistung weniger auffielen.
Laguna S 2.1s 118B-A8B-Format wirkt wie ein Kompromiss: stärker für lange Aufgaben als ein 30B-Modell, aber leichter auszurollen als ein Billionen-Parameter-System. Die Hugging-Face-Modellkarte bestätigt für die NVFP4-Version die OpenMDW-1.1-Lizenz. vLLM Recipes weist darauf hin, dass BF16-Gewichte etwa 235GB benötigen; quantisierte Versionen sind für Desktop- und Multi-GPU-Setups realistischer.
Für regulierte Unternehmen ist das ein handfester Unterschied. Code, Sicherheitslücken, Kundendaten und interne Logs dürfen oft nicht in ausländische geschlossene APIs. Lokale Ausführung, auditierbare Gewichte und Lizenzen sowie Anschluss an vLLM, SGLang, Ollama, OpenRouter und Vercel AI Gateway können im Einkauf wichtiger sein als ein paar Benchmark-Punkte.
Die Grenzen stehen mit im Angebot
Poolside nennt auch Schwächen. In fremden Agent-Harnesses kann das Modell zu stark auf Poolsides eigene Toolformate geprägt sein und ähnliche, aber andere Schemas falsch verwenden. Verschachtelte Toolaufrufe können JSON mit falschem Escaping erzeugen. Thinking mode kann zu lange nachdenken, besonders bei Wettbewerbs-Mathematik.
Alle drei Punkte zeigen dasselbe Risiko: Coding-Agenten scheitern nicht nur, weil sie keinen Code schreiben können. Toolprotokolle, Kontextbudget und der richtige Zeitpunkt zum Stoppen sind oft kritischer. Sobald ein Modell an CI, Repositories, Tickets und Berechtigungssysteme angeschlossen ist, kann ein falscher Toolaufruf teurer sein als eine falsche Antwort.
Auch die Kosten sind benannt. Der kostenlose OpenRouter-Endpunkt bietet 256K Kontext; ein dedizierter kostenpflichtiger Endpunkt liefert den vollen 1M-Kontext für 0,10 US-Dollar pro Million Input-Token, 0,20 US-Dollar pro Million Output-Token und 0,01 US-Dollar pro Million Cache-Read-Token. Das ist deutlich günstiger als geschlossene Frontier-Modelle, aber lange Agent-Sitzungen können Hunderttausende Output-Token verbrauchen.
Die Prüfung findet im Repository statt
Laguna S 2.1 ist klar positioniert: nicht als Sieger über die geschlossene Spitze, sondern als herunterladbare, selbst hostbare Grundlage für Coding-Agenten in bestehenden Inferenz-Stacks.
Entscheidend werden nun praktische Signale: ob Hugging-Face-Downloads und Community-Reproduktionen halten, ob vLLM, Ollama und SGLang in realen Repositories stabil laufen, ob die nächste größere Laguna-Generation den Terminal-Bench-Abstand verringert und ob OpenMDW in kommerziellen Compliance-Prüfungen gut handhabbar ist.
Wenn das gelingt, liegt der Wert von Laguna S 2.1 nicht im Etikett eines westlichen DeepSeek. Die nüchterne Einkaufslogik reicht: Code bleibt lokal, das Modell kann lange Repository-Aufgaben bearbeiten, die Rechnung ist kalkulierbar, und der Abstand zur Spitze ist klein genug für Tests in echten Projekten.
Quellen: offizieller Poolside-Blog, Hugging-Face-Modellkarte, vLLM Recipes, CocoLoop, The Next Web; geprüft wurden Modellparameter, aktive Parameter, Kontextfenster, Benchmark-Methodik, Trainingshardware, Lizenz, Inferenz-Deployment und veröffentlichte Einschränkungen.