
What LongCat 2.0 actually is
Meituan is the Chinese food-delivery and local-services giant, and LongCat is its in-house model team. LongCat 2.0 landed on 30 June 2026 as the successor to the LongCat-Flash line, and Meituan retired six Flash models a month earlier to make room for it.
The architecture, per the model card, is a 1.6T-parameter mixture of experts with about 48B parameters activated per token. It carries 135B of N-gram Embedding parameters inherited from LongCat-Flash-Lite, which Meituan describes as expanding capacity along sparse dimensions orthogonal to the MoE routing. Pretraining ran over more than 35 trillion tokens across "millions of accelerator-days," with no rollbacks or irrecoverable loss spikes.
The headline architectural piece is LongCat Sparse Attention, which Meituan frames as a fix for two named problems in the Lightning Indexer used by DeepSeek V3.2: output discontinuity and a quadratic scoring bottleneck. It has three parts. Streaming-aware Indexing reshapes the token-selection budget for contiguous memory reads. Cross-Layer Indexing reuses one indexing pass across two adjacent layers. Hierarchical Indexing does coarse block-level recall before fine token selection.
That third one is worth a footnote. An earlier version of the deployment docs said Hierarchical Indexing "is not supported for simplicity," and commit 5ced4db removed that line along with 41 other lines of concrete launch instructions rather than fixing it. The launch post separately says the feature is "enabled for selected ultra-long-context tasks," not on every request.

I have spent the last few years shipping integrations and API glue at eesel, and my instinct with any launch like this is to skip the announcement and go straight to the files. Four claims did not survive that.
The 1M context window is 256K in the config
Meituan's README markets a native 1M-token window, and the changelog repeats it. The shipped config.json sets max_position_embeddings to 262,144. YaRN is provisioned up to 983,040 behind that cap, so the 1M figure describes what the model was trained on rather than what the released config will serve.
Meituan's own hosted API adds a second ceiling: 128K maximum output tokens, and max_tokens counts against the context window. This is not a scandal, and 256K is a big window by any measure. It is just not the number in the marketing.
The GitHub repo is a README
github.com/meituan-longcat/LongCat-2.0 contains README.md, LICENSE and a figures/ folder with three images. That is the whole repo, about 1 MB, no language detected, zero tags or releases. The weights live on Hugging Face, inference lives in SGLang, and there is no eval harness or reference implementation anywhere.
There is also no paper. Meituan published a launch blog post and nothing else, which the community noticed immediately:
"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."
That thread has been open since 5 July with no reply from anyone at meituan-longcat. The sibling LongCat-Flash-Omni release did get a real paper, so this is a choice rather than a capability gap.
There is no working Transformers path
The shipped config.json has no model_type key, which means AutoConfig and AutoModelForCausalLM both fail. You get the tokenizer and nothing else. That is open issue #4 and it was still open when I checked.
SGLang is the only supported engine, and even that is rough: the cookbook entry tells you to install a nightly wheel because the SGLang PR was closed without being merged. There is no vLLM path and no TensorRT-LLM path.
The hardware story, checked against Meituan's own words
This is the part of the launch that travelled furthest, and the part where the reporting and the source diverge most.
The card count is real. Meituan writes it plainly in the 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."
What is not in the post is the rest of the story as it got retold. The words "domestic," "China" and "Chinese" never appear. No chip vendor is named, not Huawei, not Cambricon, not Hygon, and no in-house part number. Meituan's own framing is "alternative hardware platforms." Nvidia appears exactly twice, both times as a reference point rather than a denial: once noting that "compared to the mature Nvidia GPU ecosystem, the supporting software community is still less developed," and once observing that "our accelerators have significantly less per-device memory than an H800 (80 GB)."
Non-Nvidia hardware is the natural reading. It is still a reading. The Ascend 910C identification that anchored the Hacker News thread came from a commenter, not from Meituan:
"This is the real news story. It looks like they may have used Huawei Ascend 910C chips"
That thread ran to 281 points and 88 comments, and the sharpest counter-argument in it is about scale rather than authenticity:
"1024 Huawei Ascend superpods = 50K 910C chips.
That is a tiny tiny system. OpenAI uses milions of GPUs for training"
There is one more wrinkle in Meituan's own numbers. One sentence says "over 50K AI ASICs." The next section says "tens of thousands of AI ASIC superpods," while the post defines a superpod as "up to 48 machines each." Those cannot both be literal. If you cite a figure, cite the pretraining sentence, which is the precise one.
The two months it spent as Owl Alpha
Before any of this was announced, LongCat 2.0 was quietly serving traffic on OpenRouter as a free stealth model called owl-alpha, from roughly late April 2026 until it was pulled on 30 June, the day Meituan published the launch post. Meituan has never acknowledged it, and neither the model card nor the launch post mentions Owl Alpha at all.
The community worked it out anyway, and the receipts are still on Reddit. The first tell was geopolitical, in the top comment on the original stealth-model thread:
I think I can confirm Chinese model, it affirmed that Taiwan is part of China.
Then someone ran both endpoints side by side:
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
There is one small piece of corroboration hiding in Meituan's own documentation, which is my favourite detail in the whole doc set. The official reasoning_content example on the API reference page has the model referring to itself as "OWL", left over from a system prompt nobody cleaned up.
I mention the stealth run because it changes how you read the reviews. A lot of the hands-on experience people have with this model was accumulated for free, on a harness they were experimenting with, before anyone knew what they were testing. That is unusually clean as user feedback goes, and it means the accounts below are not launch-day impressions.
What the benchmarks say, and what they do not
Meituan publishes ten benchmark rows against six comparison models. The caveat is stated on the card itself: unless marked with an asterisk, all scores are measured in-house, and most competitor scores are lifted from those vendors' own reports. So this is not one controlled run.

| 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 |
Read down the columns and the shape is clear. LongCat 2.0 leads Gemini 3.1 Pro on all three code-agent rows, and it edges GPT-5.5 on SWE-bench Pro by 0.9. It also trails Claude Opus 4.8 on every single row where 4.8 has a score, by 9.7 on SWE-bench Pro and 8.1 on Terminal-Bench 2.1. My read: this is a real frontier-adjacent coding model that beats the previous generation and does not beat the current one.
Two things about that table deserve flagging before anyone quotes it. Meituan notes that SWE-bench was run with "problematic tasks corrected," and RWSearch is described as "an in-house objective benchmark," so two of the ten rows are partly Meituan's own instrument. And the comparison set contains no open-weight rival at all: no DeepSeek, no Qwen3.8 Max, no Kimi K3, no GLM-5.2. Those are the models a team choosing open weights is actually deciding between.
One more correction while I am here, because it is circulating widely. Anthropic publishes no SWE-bench score for Claude Opus 5 or Sonnet 5. The 69.2 figure is Opus 4.8. If you see 69.2 attributed to Opus 5, it is wrong.
What people who actually ran it say
The verdicts split hard, and I want to be straight that this is real disagreement rather than a consensus win with a few grumbles. The rough pattern is that people running it as an agent inside a harness rated it well, and people judging it as a smart model rated it poorly, but that pattern does not hold cleanly: at least one developer using it purely for code called it buggy and told people to stay away.
The most substantial account anywhere comes from someone who put 3.6 billion tokens through it during the free stealth period:
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.
Someone who bought a token pack after launch landed in the same place:
"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."
And the sharpest dissent comes from someone running it in production, pushing directly on the framing this launch got:
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.
My read across all of it: "dependable workhorse" is the honest label, and it fits both the benchmark table and the people who logged billions of tokens. Instruction-following and long-context coherence come up repeatedly as the strengths. Raw reasoning does not, and code quality is contested rather than settled.
One more reaction is worth pulling out, because it is the only place I saw someone price in the thing I keep coming back to:
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
That is a developer who read the policy, made a call, and lost two months of free access to a decent model because of it. Whether that was the right trade depends entirely on what you were planning to send it.
Pricing: the real table
Meituan publishes both a list price and a launch discount. The discount column is labelled "limited-time" with no end date anywhere, and the Chinese-language page calls it a launch offer for the platform's initial release. Both currencies are separately posted rates rather than an FX conversion.
| 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 |
Two details in that table are more interesting than the headline number.
There is no context-length tiering at all. Every other 1M-window model I checked charges more above some threshold: Gemini 3.1 Pro pricing doubles above 200K, GPT-5.6 Sol doubles above 272K, and MiniMax-M3 doubles above 512K. LongCat 2.0 is flat, which makes long-context work disproportionately cheap on it. That is the most under-reported fact on the pricing page.
It is also worth noting what flat pricing does not fix. A cheap rate on a model that needs more tokens to reach the same answer is not cheap, which is the trap in every headline comparison. The same caveat bit me working through GPT-5.6 pricing. It applies just as hard to Gemini 3.6 Flash pricing, and to this one.
And cached reads cost 1/50th of uncached input, which sounds great until you look at the response body. There is no prompt_tokens_details.cached_tokens field on the OpenAI-compatible path and no cache_read_input_tokens on the Anthropic-compatible one, and there is no cache_control parameter to steer it. Caching is fully implicit and you cannot verify what you were billed for.
Meituan's disclaimer is worth quoting exactly: "Prices are subject to change. The prices shown on the LongCat API Platform and your billing records are authoritative."
How it actually compares
Here is where the promo price does most of the work. Plug in your own numbers.
Push the numbers around for a minute and the shape of it becomes obvious. At the promo rate LongCat 2.0 is roughly a twentieth of Opus 5 and about a fifth of Sonnet 5 pricing, which is the comparison everybody made on launch day.
Then drag the cache slider up. Past about 80% cache hit rate DeepSeek V4 Pro overtakes LongCat 2.0 even at the promo rate, because its cache read is $0.003625 against LongCat's $0.006. Cheap uncached input is not the same as cheap in production, and repository-scale agent work is exactly the workload where cache hit rates run high.
At the list rate the picture inverts. $0.75 in and $2.95 out is more expensive than DeepSeek V4 Pro at $0.435 and $0.87, which is LongCat 2.0's closest architectural twin: also 1.6T total, 49B active, 1M context, also MIT. It is also beaten on input by GPT-5.6 Luna at $0.20, which is a hosted proprietary model you can pay for with a credit card. So the promo is the entire price story, and the promo has no published end date.
There is a second cost multiplier that the sticker hides. Reasoning is on by default, and reasoning tokens bill at the output rate. On OpenRouter's own usage panel, 2.03M of 2.16M completion tokens on this model were reasoning tokens. Roughly 94% of what you pay on output is the model thinking rather than the answer you keep. That is normal for a reasoning model, and it is still a number you want in your forecast rather than discovered in a bill. If you have been through this exercise with Opus 5 versus Sonnet 5 you already know how much it moves cost per task.
The part that will actually stop you
Meituan documents exactly two payment channels, and both of them appear only inside the refund rules: WeChat and Alipay. No card, no PayPal, no wire. Self-service invoicing is available "for users in mainland China only," and everyone else has to email the team.
Registration itself is open: users outside mainland China can sign up with an email address. Funding the account is a different question, and the API rejects requests once your balance hits zero. Token Packs, the prepaid alternative, are sold as timed flash drops at 10:00, 16:00, 21:00 and 23:00 Beijing time with limited stock, and they expire after 30 calendar days.
The practical answer for most teams outside China is therefore OpenRouter, which is one reason the model's public traffic runs through coding harnesses rather than Meituan's own platform. More on the tradeoff there in a moment.
The API: seven parameters and no tools
I read the API docs the way I would read them before wiring anything into production, and this is the section where a benchmark-shaped opinion turns into an engineering one.
You get two surfaces: an OpenAI-compatible path and an Anthropic Messages-compatible path, both on api.longcat.chat, both accepting the same bearer key. Swapping either SDK's base URL is a one-line change, which is the nicest thing about the platform. If you have compared OpenAI, Anthropic and Gemini APIs you know how rare that is.
Then it gets thin. Seven parameters are supported, total: max_tokens, temperature, top_p, stream, tools, tool_choice and thinking. No stop sequences. No seed. No response_format or JSON mode. No logprobs, no n, no penalties, no top_k. temperature runs 0 to 1 rather than OpenAI's 0 to 2, so a config ported straight across can be silently out of range. thinking is binary, enabled or disabled, with no budget and no effort level.
tools and tool_choice appear in the parameter list and are documented nowhere. No schema, no tool-call response shape, no example, despite the changelog marketing native tool calling. On launch day that gap showed up exactly where you would expect:
"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"
The model card confirms a related break: LongCat expects tool-call arguments as a dict rather than the JSON string the OpenAI schema specifies. Anything written against the standard shape needs a shim.
Both compatibility layers are also subtly shape-wrong in ways that break strict parsers. Reasoning arrives as message.reasoning_content on the OpenAI path, which is a DeepSeek field rather than an OpenAI one. On the Anthropic path it arrives as a thinking key inside a text content block rather than as a proper thinking block, and the documented SSE stream omits content_block_start, content_block_stop and ping.
There are no hosted tools of any kind. No web search, no code interpreter, no retrieval store, no file endpoints, no embeddings, no batch API. MCP is not mentioned once, and there is no server-side agent loop, so agentic behaviour is entirely a claim about the model and entirely your harness's job to drive.
What Meituan does document is client integrations: twelve of them, including Claude Code, Codex, Cline, Kilo Code, OpenCode and Cherry Studio, each with the exact base-URL swap. Cursor and Roo are not on that list. If you already live in an agentic coding CLI, that is the path of least resistance, and it is where the model's real traffic goes.
Rate limits exist and no numbers are published for them. The only concrete figure anywhere is retry_after: 60 in the 429 body. Failed requests are not billed, which is a nice touch, and the pay-as-you-go balance never expires.
My favourite detail in the whole doc set is small: the official reasoning_content example has the model referring to itself as "OWL," which is a leftover from a different system prompt. Docs are written by humans in a hurry, and it shows.
Self-hosting: the wall
MIT weights on a frontier-scale model is a real gift, and it comes with a hardware bill that decides who the gift is for.

The BF16 release is 3.55 TB across 194 safetensors shards, per the Hugging Face blob API. The FP8 build is 2.05 TB across 141. Every SGLang recipe loads FP8, so the 3.55 TB master is a quantization source rather than a serving target, and BF16 has no published topology at all.
| 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 |
The 8x B300 row is the only one SGLang marks verified, and the arithmetic explains why the 192 GB B200 still needs two nodes: 2.05 TB of FP8 weights does not fit in 8 x 192 GB. The H20 recipe is stranger, because 16 x 96 GB is 1,536 GB against 2,051 GB of weights, which only works if the N-gram tables and MTP modules stay off-HBM, and no document says they do.
Then there is the KV cache. At 43,776 bytes per token and --mem-fraction-static 0.92 on 8x B300, you have roughly 69 GB of KV headroom after weights. That is about six concurrent sequences at the full 256K window, or 64 slots averaging 24K tokens each. The context window and the concurrency are competing for the same memory, and at 1M context 64 slots would need 2,802 GB of KV alone, more than the entire 2,304 GB pool.
Consumer runtimes are a hard no. llama.cpp has zero merged LongCat support and no GGUF exists for any variant, so Ollama and LM Studio cannot load it. The community quants that do exist are MLX-only, need an unmerged mlx-lm PR, and the smallest full-expert build is 512 GB, which exceeds a 512 GB Mac. The Hugging Face discussion tab is basically one long request:
"GGUF Version please!!!"
r/LocalLLaMA got there faster, and the top comment on the weights-release thread put it best:
Damn, that's a really long Cat!
3.55 TB in all its BF16 glory. 2.05 TB in FP8.
The sober version of the same point, from the same thread: open weights and open access are not the same thing. For anyone with a 4090, a 5090 or even a 96 GB RTX PRO 6000, this release is something to read about rather than run. What it does enable is the ecosystem work: inspection, distillation, community quants, and eventually a Lite or distilled derivative that ordinary hardware can actually load.
Downloads tell the same story: 3,240 in the last month, with zero inference providers listed on Hugging Face and 24 people having clicked "Ask for provider support." For a model that led coding-model conversation for a month, that is a small number, and it is the number you would expect when the entry ticket is an 8x B300 node. Weights being free does not make inference free, and Hugging Face pricing is a useful reality check on where the bill actually lands.
Where your data goes, which is the real decision
This is the section I would read first if I ran support rather than a repo, and it is the shortest one because there is so little to report.
Meituan's platform FAQ does not address data retention. It does not address whether prompts or completions are used for training. The word "training" does not appear on the page. It does not name a server country, and the only geography-adjacent line on it is "server load and geographic location," under a latency heading. There is no SLA, no uptime figure, no service credit and no enterprise or private-deployment path beyond an email address.
None of that means anything bad is happening. It means the questions are unanswered, and unanswered is its own answer during a security review.
Going through OpenRouter does not fully solve it either. Exactly one provider serves this model, AtlasCloud, and it carries a "No training" badge and no zero-data-retention badge, while NovitaAI, Tencent Cloud and Fireworks all carry ZDR on the same directory page. AtlasCloud's own policy retains customer content, defined to include prompts, generated outputs and API payloads, for up to seven days, with ZDR behind a separate enterprise addendum. With one provider, a ZDR-filtered request has nowhere to route.
I do not have to speculate about whether that matters commercially, because I see it in eesel's sales calls every week. A Danish B2B telematics buyer gated by a hard internal security review would not start a trial until they had assurance that ticket data containing card numbers and passwords stayed inside their environment. A media company running about 1,000 tickets a week made credit-card and PII redaction the top objection of the entire evaluation, ahead of accuracy and ahead of price. The answer I give in those rooms is specific: no customer data is used for model training, the underlying model providers retain data for a maximum of 30 days for abuse monitoring, and data is siloed per account. You cannot give that answer about a page that never mentions training.
That is not a knock on LongCat 2.0 as a coding model. It is the difference between a model you point at your own repo and a model you point at somebody else's personal data. The same gate shows up in every helpdesk AI evaluation I have seen, and a wrong answer with a customer's card number in the prompt is a worse kind of hallucination than a wrong answer about a code path.
Who should actually use it
Reach for LongCat 2.0 if you are doing high-volume, long-context coding work inside a harness you control, you can pay through OpenRouter, and the code you are feeding it is not sensitive. The flat pricing to 1M input is a real edge for repository-scale prompts, the MIT licence has no acceptable-use rider or user threshold, and "dependable workhorse" is a fair description of what people report.
Skip it if you need JSON mode, stop sequences or a documented tool-calling contract, if you were planning to self-host on anything less than an 8x B300 node, or if a data-processing questionnaire is part of your buying process. If you want open weights specifically, DeepSeek V4 Pro is the closer comparison at a lower list price, and GLM-5.2 is also MIT. If you want cheap tokens specifically and do not care about open weights, GPT-5.6 Luna is cheaper on input with a credit-card checkout. It is worth reading how DeepSeek Flash vs K3 shake out on cost per finished task before you commit, because headline rates and real bills diverge a lot in this bracket.
And if you are choosing a model because you want AI answering customer tickets, I would argue the model is the wrong layer to be shopping at. That is worth its own section.
Try eesel
If you landed here comparing token prices because you want AI handling your support queue, the thing I would tell you is that picking the model is the easy 5% of that project. The hard part is knowing what the AI will say to your customers before it says it, and being able to answer your own security team afterwards.
eesel is an AI teammate you plug into the helpdesk you already run, Zendesk, Freshdesk, Gorgias, Front, Help Scout or Salesforce, and it learns from your existing tickets and help centre instead of needing a fresh knowledge base. We handle the model layer, so you are not repricing your support stack every time a launch post promises a 60% discount with no end date. Before anything goes live you can simulate the agent against your real historical tickets and see the answers it would have sent, which is the step we built after watching confident-sounding bots quietly get things wrong. And on the questions that the LongCat FAQ leaves open, we have specific answers: your data is not used to train models, and it is siloed per account.

You can connect a helpdesk and watch it draft its first reply in a few minutes, on a self-serve plan with per-task eesel pricing and no seat fees. If you want to see how the pieces fit before that, our take on best LLM for support covers the tradeoffs, and the build versus buy breakdown puts real numbers on what running your own stack costs once you include the GPUs. Try eesel free, or book a demo and bring your hardest ticket.
Frequently Asked Questions
What is LongCat 2.0?
How much does LongCat 2.0 cost per million tokens?
Is LongCat 2.0 really a 1M context model?
config.json caps max_position_embeddings at 262,144. So the real serving context window is 256K unless you configure the extension yourself, which is a smaller gap than it sounds next to Claude Code's context window but still not the marketed figure.Can I self-host LongCat 2.0?
Should I use LongCat 2.0 for customer support?

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.








