LongCat-2.0

LongCat-2.0 uses a Mixture-of-Experts architecture with 1.6 trillion total parameters, but only approximately 48 billion parameters activate per token. This means the model has a large knowledge base but maintains inference costs similar to a 48B-parameter dense model. The active parameter count varies between 33B and 56B per token depending on the routing decisions, with the 48B figure being the average.

The key architectural feature is LongCat Sparse Attention (LSA), which addresses the output discontinuity and scoring bottlenecks found in earlier sparse attention approaches like DSA. LSA introduces three improvements:

• Streaming-aware Indexing (SI): Reshapes token selection to combine hardware-aligned contiguous memory access with dynamic random selection, turning fragmented memory reads into predictable sequential access patterns. This improves HBM bandwidth utilization.
• Cross-Layer Indexing (CLI): Exploits the stability of attention saliency across adjacent layers to amortize indexing cost — a single indexing pass serves multiple consecutive layers during inference.
• Zero-computation experts: A subset of experts that require no computation for certain token types, further reducing the effective compute per token.

The native 1-million-token context window is not an afterthought. Meituan trained LongCat-2.0 on hundreds of billions of tokens of 1M-context data during post-training, making long-context retrieval and reasoning reliable rather than aspirational. For practitioners working with large codebases, full repository analysis, or long document processing, this context length is the practical differentiator.

LongCat-2.0 supports chat, code generation, reasoning, function-calling, multilingual text, and instruction-following. It is a text-only model — no vision or multimodal capabilities.

Agentic coding is the primary use case. The model integrates with harnesses like Claude Code, OpenClaw, and Hermes for automated task execution. Meituan reports 59.5 on SWE-bench Pro (software engineering benchmark), 77.3 on SWE-bench Multilingual, and 70.8 on Terminal-Bench 2.1. These are competitive scores that place it alongside frontier proprietary models for repository-level code edits and terminal-based agent workflows.

Long-context reasoning is where this model excels over most open-weight alternatives. The 1M-token context, combined with sparse attention, makes it viable for tasks like analyzing entire codebases, processing long technical documents, or maintaining conversation state across hundreds of thousands of tokens without degradation.

Multilingual support covers major languages including Chinese, English, and others typical of models trained on web-scale data. Function-calling and instruction-following are robust enough for building tool-using agents and automated pipelines.

For developers, the practical use cases are: automated code review across large repositories, bug fixing with full project context, generating documentation from codebases, building terminal-based coding assistants, and creating long-running agentic workflows that require maintaining state over extended interactions.

This is a 1600B total parameter MoE model with 48B active parameters. The local hardware requirements depend entirely on which quantization level you can tolerate.

Minimum VRAM requirements by quantization:

Realistic hardware scenarios:

• No consumer GPU can run FP8. You need dual RTX 6000 Ada (96 GB total), an A100 80GB, or an H100.
• Q4_K_M is viable on an RTX 4090 (24 GB) — barely. You will need aggressive offloading to system RAM, which drops tokens/second significantly. Expect 2-5 tok/s with 32-64 GB system RAM.
• Q3_K_M on an RTX 4090 is more practical for interactive use, yielding 5-10 tok/s with proper offloading.
• M4 Max (128 GB unified memory) can run Q4_K_M entirely in unified memory at approximately 8-15 tok/s depending on prompt length.
• Dual RTX 4090s can run Q4_K_M without offloading at 15-25 tok/s.
• Apple M3 Ultra or M4 Ultra with 192-256 GB unified memory can run FP8 entirely in memory, though you will need to check Metal backend support for MoE architectures.

Recommended setup for most practitioners: Q4_K_M quantization. It preserves most of the model's capabilities while fitting into 28 GB. If you have 24 GB VRAM, Q3_K_M is the practical ceiling for acceptable speed.

Getting started: Ollama supports LongCat-2.0. Pull it with ollama pull longcat-2.0. For custom quantization, use llama.cpp with the -b flag to set batch size and -ngl for GPU layers. Expect to experiment with layer offloading ratios — this model benefits from as many layers on GPU as your VRAM allows.

Tokens per second expectations: On a single RTX 4090 with Q4_K_M and optimal offloading, approximately 3-8 tok/s. On dual 4090s, 15-25 tok/s. On an A100 80GB with FP8, 30-50 tok/s. If you need production throughput, this model requires datacenter hardware or multi-GPU setups.

vs DeepSeek-V3 (671B total, 37B active)

DeepSeek-V3 is the closest direct competitor. It has fewer total parameters but similar active parameters. DeepSeek-V3 has stronger general reasoning benchmarks and broader community adoption. LongCat-2.0 pulls ahead on long-context tasks (1M vs 128K native) and agentic coding benchmarks. Choose LongCat-2.0 if you need the million-token context and repository-level code editing. Choose DeepSeek-V3 if you want a more mature ecosystem with more quantization tooling and community support.

vs Qwen3-235B-A22B (235B total, 22B active)

Qwen3 is a smaller MoE model that fits more easily on consumer hardware. It runs Q4_K_M on a single 24 GB GPU at usable speeds. LongCat-2.0 outperforms it on coding benchmarks, reasoning depth, and context length by a wide margin. Choose Qwen3 if you need something that runs comfortably on one GPU. Choose LongCat-2.0 if you have multi-GPU or high-VRAM hardware and need the extra capability.

The tradeoff is clear: LongCat-2.0 delivers frontier-level coding and long-context capability at the cost of demanding hardware. If you have the hardware, it is the strongest open-weight option for agentic coding workflows. If you are limited to a single consumer GPU, you will need to quantize heavily and accept slower generation.