Was LongCat 2.0 tatsächlich ist
Meituan ist der chinesische Riese für Essenslieferungen und lokale Dienstleistungen, und LongCat ist sein internes Modell-Team. LongCat 2.0 kam am 30. Juni 2026 als Nachfolger der LongCat-Flash-Reihe heraus, und Meituan hatte einen Monat zuvor sechs Flash-Modelle abgeschaltet, um Platz zu machen.
Die Architektur ist laut Model Card eine Mixture of Experts mit 1,6T Parametern, von denen etwa 48B pro Token aktiviert werden. Sie trägt 135B von LongCat-Flash-Lite übernommene N-Gram-Embedding-Parameter, die Meituan als Kapazitätserweiterung entlang sparsamer Dimensionen beschreibt, die orthogonal zum MoE-Routing stehen. Das Pretraining lief über mehr als 35 Billionen Tokens hinweg über "Millionen von Beschleuniger-Tagen", ohne Rollbacks oder nicht wiederherstellbare Verlustspitzen.
Das architektonische Highlight ist LongCat Sparse Attention, das Meituan als Lösung für zwei benannte Probleme im Lightning Indexer präsentiert, der bei DeepSeek V3.2 zum Einsatz kommt: Ausgabediskontinuität und ein quadratischer Bottleneck beim Scoring. Es besteht aus drei Teilen. Streaming-aware Indexing formt das Budget für die Token-Auswahl so um, dass zusammenhängende Speicherzugriffe möglich sind. Cross-Layer Indexing nutzt einen Indexierungsdurchgang für zwei benachbarte Layer wiederholt. Hierarchical Indexing führt eine grobe blockweise Wiederauffindung durch, bevor die feine Token-Auswahl erfolgt.
Der dritte Punkt verdient eine Fußnote. Eine frühere Version der Deployment-Dokumentation besagte, Hierarchical Indexing werde "aus Gründen der Einfachheit nicht unterstützt", und Commit 5ced4db entfernte diese Zeile zusammen mit 41 weiteren Zeilen konkreter Launch-Anleitungen, statt sie zu korrigieren. Der Launch-Post besagt separat, das Feature sei "für ausgewählte Ultra-Long-Context-Aufgaben aktiviert", nicht bei jeder Anfrage.
Ich baue seit einigen Jahren bei eesel Integrationen und API-Anbindungen, und mein Reflex bei jedem solchen Launch ist, die Ankündigung zu überspringen und direkt zu den Dateien zu gehen. Vier Behauptungen haben das nicht überlebt.
Das 1M-Kontextfenster ist in der Konfiguration 256K
Meituans README wirbt mit einem nativen 1M-Token-Fenster, und das Changelog wiederholt das. Die ausgelieferte config.json setzt max_position_embeddings auf 262.144. YaRN ist bis zu 983.040 über diese Grenze hinaus vorgesehen, sodass die 1M-Zahl eher beschreibt, worauf das Modell trainiert wurde, als das, was die veröffentlichte Konfiguration tatsächlich liefert.
Meituans eigene gehostete API setzt eine zweite Obergrenze: maximal 128K Output-Tokens, wobei max_tokens gegen das Kontextfenster angerechnet wird. Das ist kein Skandal, und 256K ist nach jedem Maßstab ein großes Fenster. Es ist nur nicht die Zahl aus dem Marketing.
Das GitHub-Repo ist ein README
github.com/meituan-longcat/LongCat-2.0 enthält README.md, LICENSE und einen figures/-Ordner mit drei Bildern. Das ist das gesamte Repo, etwa 1 MB groß, keine erkannte Sprache, keine Tags oder Releases. Die Gewichte liegen auf Hugging Face, die Inferenz läuft über SGLang, und nirgendwo gibt es ein Eval-Harness oder eine Referenzimplementierung.
Es gibt auch kein Paper. Meituan hat einen Launch-Blogbeitrag veröffentlicht und sonst nichts, was der Community sofort auffiel:
"The description of LSA and N-Gram in that blog is imo quite surface-level. Thats why i was asking whether there is/will be a full paper."
Dieser Thread ist seit dem 5. Juli offen, ohne Antwort von jemandem bei meituan-longcat. Das Schwester-Release LongCat-Flash-Omni bekam tatsächlich ein richtiges Paper, das hier ist also eine bewusste Entscheidung und keine Fähigkeitslücke.
Es gibt keinen funktionierenden Transformers-Pfad
Der ausgelieferten config.json fehlt der Schlüssel model_type, wodurch sowohl AutoConfig als auch AutoModelForCausalLM fehlschlagen. Man bekommt den Tokenizer und sonst nichts. Das ist offenes Issue #4 und war zum Zeitpunkt meiner Prüfung noch offen.
SGLang ist die einzige unterstützte Engine, und selbst das ist grobschlächtig: Der Cookbook-Eintrag verlangt die Installation eines Nightly-Wheels, weil die SGLang-PR geschlossen wurde, ohne gemergt zu werden. Es gibt keinen vLLM-Pfad und keinen TensorRT-LLM-Pfad.
Die Hardware-Geschichte, abgeglichen mit Meituans eigenen Worten
Das ist der Teil des Launches, der sich am weitesten verbreitet hat, und der Teil, in dem Berichterstattung und Quelle am stärksten voneinander abweichen.
Die Chip-Anzahl ist echt. Meituan schreibt es klar im Launch-Post:
"LongCat-2.0 is pre-trained on over 50K AI ASICs, introducing significant system-level challenges due to both model and cluster scale. We address these challenges through systematic optimizations, achieving over 35% training throughput improvement while also enhancing reliability compared to a naive implementation."
Was nicht im Post steht, ist der Rest der Geschichte, wie sie weitererzählt wurde. Die Wörter "domestic", "China" und "Chinese" tauchen nirgends auf. Kein Chip-Hersteller wird genannt, weder Huawei, noch Cambricon, noch Hygon, und auch keine hausinterne Teilenummer. Meituans eigener Rahmen ist "alternative Hardwareplattformen". Nvidia taucht genau zweimal auf, beide Male als Referenzpunkt und nicht als Dementi: einmal mit der Bemerkung, dass "im Vergleich zum ausgereiften Nvidia-GPU-Ökosystem die unterstützende Software-Community noch weniger entwickelt ist", und einmal mit der Feststellung, dass "unsere Beschleuniger deutlich weniger Speicher pro Gerät haben als ein H800 (80 GB)".
Nicht-Nvidia-Hardware ist die naheliegende Lesart. Sie bleibt trotzdem eine Lesart. Die Identifizierung des Ascend 910C, die den Hacker-News-Thread verankert hat, stammt von einem Kommentator, nicht von Meituan:
"This is the real news story. It looks like they may have used Huawei Ascend 910C chips"
Dieser Thread kam auf 281 Punkte und 88 Kommentare, und das schärfste Gegenargument darin betrifft die Größenordnung, nicht die Echtheit:
"1024 Huawei Ascend superpods = 50K 910C chips.
That is a tiny tiny system. OpenAI uses milions of GPUs for training"
Es gibt noch eine Unstimmigkeit in Meituans eigenen Zahlen. Ein Satz spricht von "über 50K AI-ASICs". Der nächste Abschnitt spricht von "zehntausenden AI-ASIC-Superpods", während der Post einen Superpod als "bis zu 48 Maschinen jeweils" definiert. Beides kann nicht gleichzeitig wörtlich gemeint sein. Wer eine Zahl zitiert, sollte den Satz zum Pretraining zitieren, denn der ist der präzisere.
Die zwei Monate als Owl Alpha
Bevor irgendetwas davon angekündigt wurde, lief LongCat 2.0 still und leise auf OpenRouter als kostenloses Stealth-Modell namens owl-alpha, ungefähr von Ende April 2026 an, bis es am 30. Juni zurückgezogen wurde, dem Tag, an dem Meituan den Launch-Post veröffentlichte. Meituan hat das nie eingeräumt, und weder die Model Card noch der Launch-Post erwähnen Owl Alpha überhaupt.
Die Community hat es trotzdem herausgefunden, und die Belege stehen noch auf Reddit. Der erste Hinweis war geopolitisch, im meistbewerteten Kommentar im ursprünglichen Stealth-Modell-Thread:
I think I can confirm Chinese model, it affirmed that Taiwan is part of China.
Dann testete jemand beide Endpunkte nebeneinander:
I am ABSOLUTELY certain it's Longcat. I tried both the Longcat 2.0 preview via the Longcat API and the Owl Alfa via Openrouter.
It has the same 10-second response time, the same dialogue, and both has 1M of context
In Meituans eigener Dokumentation versteckt sich ein kleines Bestätigungsdetail, das mein Lieblingsdetail im ganzen Dokumentensatz ist. Das offizielle reasoning_content-Beispiel auf der API-Referenzseite zeigt, wie sich das Modell selbst als "OWL" bezeichnet, ein Überbleibsel eines System-Prompts, das niemand aufgeräumt hat.
Ich erwähne den Stealth-Lauf, weil er verändert, wie man die Reviews lesen sollte. Ein großer Teil der praktischen Erfahrung, die Leute mit diesem Modell gemacht haben, wurde kostenlos gesammelt, in einem Harness, mit dem sie experimentierten, bevor überhaupt jemand wusste, was er da testete. Das ist als Nutzerfeedback ungewöhnlich unverzerrt, und es bedeutet, dass die folgenden Berichte keine Eindrücke vom Launch-Tag sind.
Was die Benchmarks sagen, und was sie nicht sagen
Meituan veröffentlicht zehn Benchmark-Zeilen gegenüber sechs Vergleichsmodellen. Der Vorbehalt steht auf der Karte selbst: Sofern nicht mit einem Sternchen markiert, sind alle Werte intern gemessen, und die meisten Konkurrenzwerte sind direkt aus den eigenen Berichten dieser Anbieter übernommen. Das ist also kein einzelner kontrollierter Testlauf.
| Benchmark | LongCat 2.0 | Gemini 3.1 Pro | GPT-5.5 | Claude Opus 4.7 | Claude Opus 4.8 |
|---|---|---|---|---|---|
| Terminal-Bench 2.1 | 70.8 | 70.7 | 73.8 | 71.7 | 78.9 |
| SWE-bench Pro | 59.5 | 54.2 | 58.6 | 64.3 | 69.2 |
| SWE-bench Multilingual | 77.3 | 76.9 | - | 80.5 | 84.8 |
| FORTE | 73.2 | 70.3 | 77.8 | 77.6 | 77.2 |
| BrowseComp | 79.9 | 85.9 | 84.4 | 79.3 | 84.3 |
| RWSearch | 78.8 | 76.3 | 85.3 | 79.3 | 77.3 |
| IFEval | 90.0 | 96.1 | 95.0 | 88.7 | 86.0 |
| Writing Bench | 83.8 | 83.7 | 84.7 | 85.3 | 85.2 |
| IMO-AnswerBench | 81.8 | 90.0 | 79.5 | 81.8 | 75.3 |
| GPQA-diamond | 88.9 | 94.3 | 93.6 | 94.2 | 92.4 |
Liest man die Spalten von oben nach unten, ist die Struktur klar. LongCat 2.0 liegt bei allen drei Code-Agent-Zeilen vor Gemini 3.1 Pro und setzt sich bei SWE-bench Pro um 0,9 Punkte knapp vor GPT-5.5. Es liegt aber auch bei jeder einzelnen Zeile hinter Claude Opus 4.8, wo 4.8 einen Wert hat, um 9,7 Punkte bei SWE-bench Pro und um 8,1 Punkte bei Terminal-Bench 2.1. Meine Einschätzung: Das ist ein echtes, frontnahes Coding-Modell, das die vorherige Generation schlägt und die aktuelle nicht schlägt.
Zwei Dinge an dieser Tabelle sollte man kennzeichnen, bevor sie jemand zitiert. Meituan vermerkt, dass SWE-bench mit "korrigierten problematischen Aufgaben" gelaufen ist, und RWSearch wird als "hausinterner, objektiver Benchmark" beschrieben, sodass zwei der zehn Zeilen teilweise Meituans eigenes Messinstrument sind. Und im Vergleichsfeld fehlt jeder Open-Weight-Rivale komplett: kein DeepSeek, kein Qwen3.8 Max, kein Kimi K3, kein GLM-5.2. Genau zwischen diesen Modellen entscheidet sich ein Team, das Open Weights wählt, tatsächlich.
Noch eine Korrektur, solange ich dabei bin, weil sie breit kursiert. Anthropic veröffentlicht keinen SWE-bench-Wert für Claude Opus 5 oder Sonnet 5. Die 69,2 ist die Zahl von Opus 4.8. Wenn irgendwo 69,2 als Opus-5-Wert auftaucht, ist das falsch.
Was die Leute sagen, die es tatsächlich ausprobiert haben
Die Urteile gehen stark auseinander, und ich möchte klar sagen, dass das ein echter Dissens ist und kein Konsens-Erfolg mit ein paar Nörgeleien am Rand. Das grobe Muster ist, dass Leute, die es als Agenten in einem Harness betrieben haben, es gut bewerten, und Leute, die es als "kluges" Modell beurteilt haben, es schlecht bewerten, aber dieses Muster geht nicht restlos auf: Mindestens ein Entwickler, der es rein für Code nutzte, nannte es fehleranfällig und riet davon ab.
Der substanziellste Bericht überhaupt kommt von jemandem, der während der kostenlosen Stealth-Phase 3,6 Milliarden Tokens durch das Modell laufen ließ:
I used this for over 3.6 billion tokens when it was owl-alpha on Openrouter (with Hermes Agent). It was a very good experience.
It's not as 'smart' as other frontier models when it comes to benchmark style tests (one shots, riddles, etc) but it was very good at (1) following instructions, (2) making a plan, (3) following that plan, and (4) staying coherent at very high contexts. I built a number of apps from start to finish and it performed very well.
Jemand, der nach dem Launch ein Token-Paket kaufte, landet an derselben Stelle:
"Not free, but it's so cheap they're basically giving it away. Very impressed too... Not frontier-level intelligence, but a dependable workhorse that can navigate a codebase well and can reliably execute what you tell it to do."
Und der schärfste Widerspruch kommt von jemandem, der es im Produktivbetrieb einsetzt und sich direkt gegen den Rahmen stellt, den dieser Launch bekommen hat:
I was using Owl Alpha a lot for my project. Thats not gpt 5.5 level model. it not even close to flash 2.5 model - its not gollowing promts.
Meine Einschätzung über alles hinweg: "Verlässliches Arbeitstier" ist die ehrliche Bezeichnung, und sie passt sowohl zur Benchmark-Tabelle als auch zu den Leuten, die Milliarden Tokens protokolliert haben. Instruction-Following und Kohärenz über lange Kontexte hinweg tauchen wiederholt als Stärken auf. Reines Reasoning nicht, und die Codequalität bleibt umstritten statt geklärt.
Eine weitere Reaktion lohnt sich herauszuheben, weil sie die einzige Stelle ist, an der jemand genau das eingepreist hat, worauf ich immer wieder zurückkomme.
Wait, this is Owl Alpha? Now I wish I had tried it when it was available. I stayed away from it back then because of their privacy policy
Das ist ein Entwickler, der die Richtlinie gelesen, eine Entscheidung getroffen und dadurch zwei Monate freien Zugang zu einem brauchbaren Modell verloren hat. Ob das der richtige Trade war, hängt vollständig davon ab, was er damals damit vorhatte.
Preise: die echte Tabelle
Meituan veröffentlicht sowohl einen Listenpreis als auch einen Launch-Rabatt. Die Rabattspalte ist als "zeitlich begrenzt" gekennzeichnet, ohne dass irgendwo ein Enddatum steht, und die chinesischsprachige Seite bezeichnet es als Launch-Angebot zum ersten Release der Plattform. Beide Währungen sind separat festgelegte Kurse, keine FX-Umrechnung.
| Item | List USD / 1M | Promo USD / 1M | List CNY / 1M | Promo CNY / 1M |
|---|---|---|---|---|
| Uncached input | $0.75 | $0.30 | ¥5 | ¥2 |
| Cached input (read) | $0.015 | $0.006 | ¥0.10 | ¥0.04 |
| Output | $2.95 | $1.20 | ¥20 | ¥8 |
| Cache write | not published | not published | not published | not published |
| Context tiering | none, flat rate to 1M input | none | none | none |
Zwei Details in dieser Tabelle sind interessanter als die Schlagzeilenzahl.
Es gibt überhaupt keine Staffelung nach Kontextlänge. Jedes andere 1M-Fenster-Modell, das ich geprüft habe, verlangt oberhalb eines Schwellenwerts mehr: Der Preis von Gemini 3.1 Pro verdoppelt sich oberhalb von 200K, GPT-5.6 Sol verdoppelt sich oberhalb von 272K, und MiniMax-M3 verdoppelt sich oberhalb von 512K. LongCat 2.0 ist flach, was Arbeit mit langem Kontext dort unverhältnismäßig günstig macht. Das ist die am wenigsten berichtete Tatsache auf der Preisseite.
Es lohnt sich auch zu sehen, was ein flacher Preis nicht behebt. Ein günstiger Satz bei einem Modell, das mehr Tokens braucht, um dieselbe Antwort zu erreichen, ist nicht günstig, und das ist die Falle in jedem Schlagzeilenvergleich. Genau dieselbe Warnung hat mich bei der Beschäftigung mit dem Preis von GPT-5.6 erwischt. Sie gilt ebenso stark für den Preis von Gemini 3.6 Flash wie für dieses Modell hier.
Und gecachte Reads kosten 1/50 des ungecachten Inputs, was großartig klingt, bis man in den Response-Body schaut. Es gibt kein Feld prompt_tokens_details.cached_tokens im OpenAI-kompatiblen Pfad und kein cache_read_input_tokens im Anthropic-kompatiblen Pfad, und es gibt keinen cache_control-Parameter, um es zu steuern. Caching läuft vollständig implizit, und man kann nicht überprüfen, wofür man tatsächlich bezahlt wurde.
Meituans Disclaimer ist es wert, wortgetreu zitiert zu werden: "Prices are subject to change. The prices shown on the LongCat API Platform and your billing records are authoritative."
Wie es sich in der Praxis vergleicht
Hier leistet der Promo-Preis den größten Teil der Arbeit. Setz deine eigenen Zahlen ein.
Bewegt man die Zahlen eine Weile, wird das Bild schnell klar. Zum Promo-Preis kostet LongCat 2.0 etwa ein Zwanzigstel von Opus 5 und etwa ein Fünftel des Preises von Sonnet 5, was der Vergleich war, den am Launch-Tag jeder gezogen hat.
Dann zieh den Cache-Regler nach oben. Ab etwa 80 % Cache-Trefferquote überholt DeepSeek V4 Pro LongCat 2.0 sogar zum Promo-Preis, weil dessen gecachter Read mit 0,003625 US-Dollar günstiger ist als LongCats 0,006 US-Dollar. Günstiger ungecachter Input ist nicht dasselbe wie günstig im Produktivbetrieb, und Agentenarbeit auf Repository-Ebene ist genau die Art von Workload, bei der die Cache-Trefferquote hoch ausfällt.
Zum Listenpreis dreht sich das Bild um. 0,75 US-Dollar Input und 2,95 US-Dollar Output ist teurer als DeepSeek V4 Pro mit 0,435 und 0,87 US-Dollar, das architektonisch der engste Zwilling von LongCat 2.0 ist: ebenfalls 1,6T Parameter insgesamt, 49B aktiv, 1M Kontext, ebenfalls MIT. Beim Input wird es sogar von GPT-5.6 Luna mit 0,20 US-Dollar unterboten, einem gehosteten, proprietären Modell, das man mit Kreditkarte bezahlen kann. Also ist die Promo die gesamte Preisgeschichte, und diese Promo hat kein veröffentlichtes Enddatum.
Es gibt einen zweiten Kostenmultiplikator, den der Aufkleber verbirgt. Reasoning ist standardmäßig aktiviert, und Reasoning-Tokens werden zum Output-Satz abgerechnet. Im eigenen Nutzungspanel von OpenRouter waren 2,03M von 2,16M Completion-Tokens für dieses Modell Reasoning-Tokens. Rund 94 % dessen, was man beim Output bezahlt, ist das Nachdenken des Modells und nicht die Antwort, die man tatsächlich behält. Das ist bei einem Reasoning-Modell normal, und trotzdem eine Zahl, die man lieber in seiner Prognose hat als in einer Rechnung entdeckt. Wer diese Übung schon einmal mit Opus 5 gegenüber Sonnet 5 durchgemacht hat, weiß bereits, wie stark das die Kosten pro Aufgabe verschiebt.
Der Teil, der dich tatsächlich ausbremsen wird
Meituan dokumentiert genau zwei Zahlungskanäle, und beide erscheinen nur innerhalb der Rückerstattungsregeln: WeChat und Alipay. Keine Karte, kein PayPal, keine Überweisung. Self-Service-Rechnungsstellung steht "nur Nutzern in Festlandchina" zur Verfügung, und alle anderen müssen dem Team eine E-Mail schreiben.
Die Registrierung selbst ist offen: Nutzer außerhalb Festlandchinas können sich mit einer E-Mail-Adresse anmelden. Das Konto aufzuladen ist eine andere Frage, und die API lehnt Anfragen ab, sobald der Kontostand null erreicht. Token Packs, die Prepaid-Alternative, werden als zeitlich befristete Flash-Drops um 10:00, 16:00, 21:00 und 23:00 Uhr Pekinger Zeit mit begrenztem Bestand verkauft und verfallen nach 30 Kalendertagen.
Die praktische Antwort für die meisten Teams außerhalb Chinas ist deshalb OpenRouter, was ein Grund dafür ist, warum der öffentliche Traffic des Modells eher über Coding-Harnesses läuft als über Meituans eigene Plattform. Mehr zu dieser Abwägung gleich noch.
Die API: sieben Parameter und keine Tools
Ich habe die API-Dokumentation so gelesen, wie ich sie lesen würde, bevor ich irgendetwas in die Produktion einbinde, und das ist der Abschnitt, in dem sich eine benchmarkförmige Meinung in eine ingenieurstechnische verwandelt.
Es gibt zwei Oberflächen: einen OpenAI-kompatiblen Pfad und einen Anthropic-Messages-kompatiblen Pfad, beide unter api.longcat.chat, beide akzeptieren denselben Bearer-Key. Die Base-URL eines der beiden SDKs zu tauschen ist eine Änderung mit einer Zeile, was das Schönste an der Plattform ist. Wer schon einmal OpenAI-, Anthropic- und Gemini-APIs verglichen hat, weiß, wie selten das ist.
Danach wird es dünn. Insgesamt werden nur sieben Parameter unterstützt: max_tokens, temperature, top_p, stream, tools, tool_choice und thinking. Keine stop-Sequenzen. Kein seed. Kein response_format oder JSON-Modus. Kein logprobs, kein n, keine Penalties, kein top_k. temperature läuft von 0 bis 1 statt der 0 bis 2 von OpenAI, sodass eine direkt übernommene Konfiguration unbemerkt außerhalb des gültigen Bereichs landen kann. thinking ist binär, an oder aus, ohne Budget und ohne Effort-Level.
tools und tool_choice stehen in der Parameterliste und sind nirgendwo dokumentiert. Kein Schema, keine Form der Tool-Call-Antwort, kein Beispiel, obwohl das Changelog natives Tool-Calling anpreist. Am Launch-Tag zeigte sich diese Lücke genau dort, wo man es erwarten würde:
"I can't get any tool calls working. Seems to use a
<longcat_tool_call>wrapper which the current harnesses I'm using don't support"
Die Model Card bestätigt einen verwandten Bruch: LongCat erwartet die arguments eines Tool-Calls als Dict statt als den JSON-String, den das OpenAI-Schema vorschreibt. Alles, was gegen die Standardform geschrieben wurde, braucht einen Adapter.
Auch beide Kompatibilitätsschichten sind auf subtile Weise falsch geformt, und zwar so, dass strikte Parser daran zerbrechen. Reasoning kommt auf dem OpenAI-Pfad als message.reasoning_content an, ein Feld von DeepSeek und nicht von OpenAI. Auf dem Anthropic-Pfad kommt es als thinking-Schlüssel innerhalb eines Textinhaltsblocks an statt als richtiger Thinking-Block, und der dokumentierte SSE-Stream lässt content_block_start, content_block_stop und ping aus.
Es gibt keine gehosteten Tools jeglicher Art. Keine Websuche, keinen Code-Interpreter, keinen Retrieval-Speicher, keine File-Endpoints, keine Embeddings, keine Batch-API. MCP wird kein einziges Mal erwähnt, und es gibt keine serverseitige Agentenschleife, sodass agentisches Verhalten allein eine Behauptung über das Modell ist und vollständig deinem Harness überlassen bleibt.
Was Meituan dokumentiert, sind Client-Integrationen: zwölf Stück, darunter Claude Code, Codex, Cline, Kilo Code, OpenCode und Cherry Studio, jeweils mit dem exakten Base-URL-Tausch. Cursor und Roo stehen nicht auf dieser Liste. Wer bereits in einer agentischen Coding-CLI lebt, findet dort den Weg des geringsten Widerstands, und genau dort läuft auch der eigentliche Traffic des Modells.
Rate Limits existieren, es werden aber keine Zahlen dazu veröffentlicht. Die einzige konkrete Zahl im gesamten Set ist retry_after: 60 im 429-Response-Body. Fehlgeschlagene Anfragen werden nicht abgerechnet, was ein netter Zug ist, und das Pay-as-you-go-Guthaben verfällt nie.
Mein Lieblingsdetail im gesamten Dokumentensatz ist klein: Das offizielle reasoning_content-Beispiel zeigt das Modell, wie es sich selbst als "OWL" bezeichnet, ein Überbleibsel eines anderen System-Prompts. Dokumentation wird von Menschen in Eile geschrieben, und man sieht es.
Self-Hosting: die Wand
MIT-Gewichte für ein Modell im Frontier-Maßstab sind ein echtes Geschenk, und es kommt mit einer Hardware-Rechnung, die darüber entscheidet, für wen dieses Geschenk eigentlich gedacht ist.
Das BF16-Release ist laut Hugging-Face-Blob-API 3,55 TB groß, verteilt über 194 Safetensors-Shards. Der FP8-Build kommt auf 2,05 TB über 141 Shards. Jedes SGLang-Rezept lädt FP8, sodass der 3,55-TB-Master eher eine Quantisierungsquelle als ein Serving-Ziel ist, und für BF16 gibt es überhaupt keine veröffentlichte Topologie.
| Hardware | HBM per GPU | GPUs | Nodes | Parallelism |
|---|---|---|---|---|
| NVIDIA B300 | 288 GB | 8 | 1 | TP=8, EP=8 |
| NVIDIA B200 | 192 GB | 16 | 2 | TP=16, EP=16 |
| NVIDIA H200 | 141 GB | 16 | 2 | TP=16, EP=16 |
| NVIDIA H20 | 96 GB | 16 | 2 | TP=16, EP=16 |
| Ascend Atlas A2 | not published | 192 | 12 | 64 prefill, 128 decode |
Die 8x-B300-Zeile ist die einzige, die SGLang als verifiziert markiert, und die Rechnung erklärt, warum das 192-GB-B200 trotzdem zwei Knoten braucht: 2,05 TB an FP8-Gewichten passen nicht in 8 x 192 GB. Das H20-Rezept ist noch seltsamer, denn 16 x 96 GB sind 1.536 GB gegenüber 2.051 GB an Gewichten, was nur funktioniert, wenn die N-Gram-Tabellen und MTP-Module außerhalb des HBM bleiben, und kein Dokument sagt, dass das der Fall ist.
Dann kommt der KV-Cache. Bei 43.776 Byte pro Token und --mem-fraction-static 0.92 auf 8x B300 bleiben nach den Gewichten rund 69 GB KV-Spielraum übrig. Das entspricht etwa sechs gleichzeitigen Sequenzen im vollen 256K-Fenster oder 64 Slots mit durchschnittlich 24K Tokens jeweils. Kontextfenster und Nebenläufigkeit konkurrieren um denselben Speicher, und bei 1M Kontext würden 64 Slots allein 2.802 GB an KV benötigen, mehr als der gesamte 2.304-GB-Pool.
Consumer-Runtimes sind ein klares Nein. llama.cpp hat null gemergte LongCat-Unterstützung, und für keine Variante existiert ein GGUF, sodass Ollama und LM Studio das Modell nicht laden können. Die Community-Quants, die existieren, sind nur für MLX gedacht, benötigen eine noch nicht gemergte mlx-lm-PR, und der kleinste Build mit allen Experten liegt bei 512 GB, was einen 512-GB-Mac übersteigt. Der Diskussionstab auf Hugging Face ist im Grunde eine einzige lange Bitte:
"GGUF Version please!!!"
r/LocalLLaMA war schneller dabei, und der meistbewertete Kommentar im Thread zur Veröffentlichung der Gewichte bringt es am besten auf den Punkt:
Damn, that's a really long Cat!
3.55 TB in all its BF16 glory. 2.05 TB in FP8.
Die nüchterne Version desselben Punkts, aus demselben Thread: offene Gewichte und offener Zugang sind nicht dasselbe. Für jeden mit einer 4090, einer 5090 oder sogar einer 96-GB-RTX-PRO-6000 ist dieses Release eher etwas zum Lesen als zum Betreiben. Was es aber ermöglicht, ist die Arbeit im Ökosystem: Inspektion, Distillation, Community-Quants und irgendwann eine Lite- oder distillierte Variante, die gewöhnliche Hardware tatsächlich laden kann.
Die Download-Zahlen erzählen dieselbe Geschichte: 3.240 im letzten Monat, mit null gelisteten Inference-Anbietern auf Hugging Face und 24 Personen, die auf "Ask for provider support" geklickt haben. Für ein Modell, das einen Monat lang die Coding-Modell-Konversation angeführt hat, ist das eine kleine Zahl, und genau die Zahl, die man erwarten würde, wenn das Eintrittsticket ein 8x-B300-Knoten ist. Kostenlose Gewichte machen die Inferenz nicht kostenlos, und der Preis von Hugging Face ist ein nützlicher Realitätscheck dafür, wo die Rechnung am Ende tatsächlich landet.
Wohin deine Daten gehen, die eigentlich entscheidende Frage
Das ist der Abschnitt, den ich als Erstes lesen würde, wenn ich Support statt ein Repository verantworten würde, und es ist der kürzeste, weil es so wenig zu berichten gibt.
Meituans Plattform-FAQ geht nicht auf Datenaufbewahrung ein. Sie geht nicht darauf ein, ob Prompts oder Completions zum Training verwendet werden. Das Wort "training" taucht auf der Seite kein einziges Mal auf. Es wird kein Serverland genannt, und die einzige geografieähnliche Zeile darauf ist "Serverlast und geografische Lage" unter einer Überschrift zur Latenz. Es gibt kein SLA, keine Uptime-Zahl, keinen Service-Credit und keinen Weg zu Enterprise- oder privatem Deployment außer einer E-Mail-Adresse.
Nichts davon bedeutet, dass etwas Schlechtes passiert. Es bedeutet, dass die Fragen unbeantwortet sind, und unbeantwortet ist bei einer Sicherheitsprüfung selbst schon eine Antwort.
Auch der Weg über OpenRouter löst das nicht vollständig. Genau ein Anbieter serviert dieses Modell, AtlasCloud, und der trägt ein "No training"-Badge, aber kein Zero-Data-Retention-Badge, während NovitaAI, Tencent Cloud und Fireworks auf derselben Verzeichnisseite alle ZDR tragen. AtlasClouds eigene Richtlinie speichert Kundendaten, definiert als Prompts, generierte Outputs und API-Payloads, für bis zu sieben Tage, mit ZDR hinter einem separaten Enterprise-Zusatz. Mit nur einem Anbieter hat eine nach ZDR gefilterte Anfrage nirgendwohin, wohin sie geleitet werden könnte.
Ich muss nicht spekulieren, ob das kommerziell eine Rolle spielt, denn ich sehe es jede Woche in den Sales-Calls von eesel. Ein dänischer B2B-Telematik-Kunde, blockiert durch eine strenge interne Sicherheitsprüfung, wollte keinen Test starten, bevor er die Zusicherung hatte, dass Ticket-Daten mit Kartennummern und Passwörtern innerhalb der eigenen Umgebung blieben. Ein Medienunternehmen mit rund 1.000 Tickets pro Woche machte die Schwärzung von Kreditkarten- und PII-Daten zum wichtigsten Einwand der gesamten Evaluierung, noch vor Genauigkeit und noch vor Preis. Die Antwort, die ich in solchen Gesprächen gebe, ist konkret: Keine Kundendaten werden zum Trainieren von Modellen verwendet, die zugrunde liegenden Modellanbieter speichern Daten maximal 30 Tage zur Missbrauchsüberwachung, und die Daten sind pro Konto isoliert. Diese Antwort kann man über eine Seite, die Training nie erwähnt, nicht geben.
Das ist kein Seitenhieb gegen LongCat 2.0 als Coding-Modell. Es ist der Unterschied zwischen einem Modell, das man auf das eigene Repository ansetzt, und einem Modell, das man auf die persönlichen Daten von jemand anderem ansetzt. Dieselbe Hürde taucht in jeder Helpdesk-KI-Evaluierung auf, die ich gesehen habe, und eine falsche Antwort mit der Kartennummer eines Kunden im Prompt ist eine schlimmere Art von Halluzination als eine falsche Antwort über einen Codepfad.
Wer es tatsächlich einsetzen sollte
Greife zu LongCat 2.0, wenn du hochvolumige, langkontextige Coding-Arbeit innerhalb eines von dir kontrollierten Harness betreibst, über OpenRouter bezahlen kannst und der Code, den du hineinfütterst, nicht sensibel ist. Die flache Preisgestaltung bis 1M Input ist ein echter Vorteil für Prompts im Repository-Maßstab, die MIT-Lizenz hat keine Acceptable-Use-Klausel und keine Nutzerschwelle, und "verlässliches Arbeitstier" ist eine faire Beschreibung dessen, was Nutzer berichten.
Verzichte darauf, wenn du JSON-Modus, stop-Sequenzen oder einen dokumentierten Tool-Calling-Vertrag brauchst, wenn du vorhattest, es auf weniger als einem 8x-B300-Knoten selbst zu hosten, oder wenn ein Fragebogen zur Datenverarbeitung Teil deines Einkaufsprozesses ist. Wer speziell Open Weights will, findet in DeepSeek V4 Pro den engeren Vergleich bei niedrigerem Listenpreis, und auch GLM-5.2 ist MIT-lizenziert. Wer speziell billige Tokens will und sich nicht um Open Weights schert, ist mit GPT-5.6 Luna beim Input günstiger dran und kann per Kreditkarte an der Kasse zahlen. Es lohnt sich, vor der Entscheidung zu lesen, wie DeepSeek Flash gegenüber K3 bei den Kosten pro erledigter Aufgabe abschneiden, denn Schlagzeilentarife und echte Rechnungen weichen in diesem Segment stark voneinander ab.
Und wenn du ein Modell auswählst, weil du willst, dass KI Kundentickets beantwortet, würde ich sagen, dass du auf der falschen Ebene einkaufst. Das ist einen eigenen Abschnitt wert.
Try eesel
Wenn du hier gelandet bist, weil du Token-Preise vergleichst und willst, dass KI deine Support-Warteschlange übernimmt: Was ich dir sagen würde, ist, dass die Modellwahl der leichte Teil ist, die 5 % dieses Projekts. Der schwierige Teil ist zu wissen, was die KI deinen Kunden sagen wird, bevor sie es sagt, und danach dein eigenes Security-Team beantworten zu können.
eesel ist ein KI-Teammitglied, das du an das Helpdesk anschließt, das du schon betreibst, Zendesk, Freshdesk, Gorgias, Front, Help Scout oder Salesforce, und es lernt aus deinen bestehenden Tickets und deinem Helpcenter, statt eine neue Wissensdatenbank zu brauchen. Wir übernehmen die Modell-Schicht, damit du deinen Support-Stack nicht jedes Mal neu bepreisen musst, wenn ein Launch-Post 60 % Rabatt ohne Enddatum verspricht. Bevor irgendetwas live geht, kannst du den Agenten an deinen echten historischen Tickets simulieren und sehen, welche Antworten er gesendet hätte, ein Schritt, den wir eingeführt haben, nachdem wir gesehen haben, wie selbstbewusst wirkende Bots still und leise Fehler machen. Und bei den Fragen, die die LongCat-FAQ offenlassen, haben wir konkrete Antworten: Deine Daten werden nicht zum Trainieren von Modellen genutzt und sind pro Konto isoliert.
Du kannst ein Helpdesk verbinden und in wenigen Minuten zusehen, wie die erste Antwort entworfen wird, auf einem Self-Serve-Plan mit nutzungsbasiertem eesel-Preis und ohne Sitzplatzgebühren. Wenn du vorher sehen willst, wie die Teile zusammenpassen, geht unser Beitrag zum besten LLM für Support auf die Kompromisse ein, und die Aufschlüsselung Selbstbau versus Kauf legt echte Zahlen darauf, was der Betrieb eines eigenen Stacks kostet, wenn man die GPUs einrechnet. Probier eesel kostenlos aus oder buche eine Demo und bring dein schwierigstes Ticket mit.
Häufig gestellte Fragen
Was ist LongCat 2.0?
Wie viel kostet LongCat 2.0 pro Million Tokens?
Ist LongCat 2.0 wirklich ein Modell mit 1M Kontext?
config.json begrenzt max_position_embeddings auf 262.144. Das tatsächlich servierte Kontextfenster liegt also bei 256K, sofern man die Erweiterung nicht selbst konfiguriert, was neben dem Kontextfenster von Claude Code kleiner wirkt als es klingt, aber trotzdem nicht die beworbene Zahl ist.Kann ich LongCat 2.0 selbst hosten?
Sollte ich LongCat 2.0 im Kundensupport einsetzen?
Article by
Rama Adi Nugraha
Rama is a software engineer at eesel AI with two years of experience writing about B2B SaaS, AI tools, and customer support technology. Based in Bali, Indonesia, he brings a developer's perspective to product comparisons — cutting through marketing copy to what the integrations and APIs actually do.
