Qué es realmente LongCat 2.0
Meituan es el gigante chino de reparto de comida y servicios locales, y LongCat es su equipo interno de modelos. LongCat 2.0 llegó el 30 de junio de 2026 como sucesor de la línea LongCat-Flash, y Meituan retiró seis modelos Flash un mes antes para hacerle sitio.
La arquitectura, según la ficha del modelo, es una mixture of experts de 1,6T parámetros con unos 48.000 millones activados por token. Incorpora 135.000 millones de parámetros de N-gram Embedding heredados de LongCat-Flash-Lite, que Meituan describe como una forma de ampliar la capacidad en dimensiones dispersas ortogonales al enrutamiento del MoE. El preentrenamiento se hizo con más de 35 billones de tokens a lo largo de "millones de días-acelerador", sin retrocesos ni picos de pérdida irrecuperables.
La pieza arquitectónica principal es LongCat Sparse Attention, que Meituan presenta como una corrección a dos problemas concretos del Lightning Indexer usado en DeepSeek V3.2: discontinuidad en la salida y un cuello de botella cuadrático en la puntuación. Tiene tres componentes. Streaming-aware Indexing reorganiza el presupuesto de selección de tokens para lecturas de memoria contiguas. Cross-Layer Indexing reutiliza un mismo paso de indexación en dos capas adyacentes. Hierarchical Indexing hace una recuperación gruesa a nivel de bloque antes de la selección fina de tokens.
Ese tercer punto merece una nota al pie. Una versión anterior de la documentación de despliegue decía que Hierarchical Indexing "no está soportado por simplicidad", y el commit 5ced4db eliminó esa línea junto con otras 41 líneas de instrucciones de lanzamiento concretas, en lugar de corregirla. La publicación de lanzamiento dice, por separado, que la función está "activada para tareas seleccionadas de contexto ultralargo", no en todas las peticiones.
Llevo varios años construyendo integraciones y conexiones de API en eesel, y mi instinto ante cualquier lanzamiento así es saltarme el anuncio e ir directo a los archivos. Cuatro afirmaciones no sobrevivieron a eso.
La ventana de contexto de 1M es 256K en la configuración
El README de Meituan promociona una ventana nativa de 1M de tokens, y el changelog repite lo mismo. El config.json publicado fija max_position_embeddings en 262.144. YaRN está previsto hasta 983.040 por encima de ese límite, así que la cifra de 1M describe con qué se entrenó el modelo, no lo que va a servir la configuración publicada.
La propia API alojada de Meituan añade un segundo límite: 128K de tokens de salida como máximo, y max_tokens cuenta contra la ventana de contexto. No es un escándalo, y 256K es una ventana grande por cualquier criterio. Simplemente no es la cifra del marketing.
El repositorio de GitHub es un README
github.com/meituan-longcat/LongCat-2.0 contiene README.md, LICENSE y una carpeta figures/ con tres imágenes. Eso es todo el repositorio, alrededor de 1 MB, sin lenguaje detectado, sin etiquetas ni releases. Los pesos viven en Hugging Face, la inferencia se hace en SGLang, y no hay ningún arnés de evaluación ni implementación de referencia en ningún sitio.
Tampoco hay ningún paper. Meituan publicó una entrada de blog de lanzamiento y nada más, y la comunidad lo notó de inmediato:
"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."
Ese hilo lleva abierto desde el 5 de julio sin respuesta de nadie de meituan-longcat. El lanzamiento hermano LongCat-Flash-Omni sí tuvo un paper real, así que esto es una decisión, no una limitación de capacidad.
No hay una ruta de Transformers que funcione
El config.json publicado no tiene la clave model_type, lo que hace que tanto AutoConfig como AutoModelForCausalLM fallen. Obtienes el tokenizador y nada más. Eso es el issue abierto #4 y seguía abierto cuando lo comprobé.
SGLang es el único motor soportado, e incluso ahí la cosa es tosca: la entrada del cookbook te dice que instales un wheel nightly porque la PR de SGLang se cerró sin fusionarse. No hay ruta de vLLM ni de TensorRT-LLM.
La historia del hardware, comprobada contra las propias palabras de Meituan
Esta es la parte del lanzamiento que más viajó, y donde la cobertura y la fuente primaria se separan más.
El número de chips es real. Meituan lo escribe con claridad en su publicación de lanzamiento:
"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."
Lo que no está en la publicación es el resto de la historia tal como se ha ido recontando. Las palabras "domestic", "China" y "Chinese" no aparecen nunca. No se nombra a ningún fabricante de chips, ni Huawei, ni Cambricon, ni Hygon, ni ningún número de pieza interno. El propio marco de Meituan es "plataformas de hardware alternativas". Nvidia aparece exactamente dos veces, ambas como punto de referencia y no como negación: una vez señalando que "comparado con el ecosistema maduro de GPU de Nvidia, la comunidad de software de soporte todavía está menos desarrollada", y otra observando que "nuestros aceleradores tienen significativamente menos memoria por dispositivo que una H800 (80 GB)".
El hardware que no es de Nvidia es la lectura natural. Sigue siendo una lectura. La identificación del Ascend 910C que sirvió de ancla al hilo de Hacker News vino de un comentarista, no de Meituan:
"This is the real news story. It looks like they may have used Huawei Ascend 910C chips"
Ese hilo llegó a 281 puntos y 88 comentarios, y el contraargumento más agudo trata sobre la escala más que sobre la autenticidad:
"1024 Huawei Ascend superpods = 50K 910C chips.
That is a tiny tiny system. OpenAI uses milions of GPUs for training"
Hay una arruga más en las propias cifras de Meituan. Una frase dice "más de 50K ASIC de IA". La sección siguiente dice "decenas de miles de superpods de ASIC de IA", mientras que la publicación define un superpod como "hasta 48 máquinas cada uno". Ambas cosas no pueden ser literales a la vez. Si vas a citar una cifra, cita la frase sobre el preentrenamiento, que es la más precisa.
Los dos meses que pasó como Owl Alpha
Antes de que se anunciara nada de esto, LongCat 2.0 llevaba tiempo sirviendo tráfico en silencio en OpenRouter como un modelo stealth gratuito llamado owl-alpha, aproximadamente desde finales de abril de 2026 hasta que lo retiraron el 30 de junio, el mismo día en que Meituan publicó la entrada de lanzamiento. Meituan nunca lo ha reconocido, y ni la ficha del modelo ni la publicación de lanzamiento mencionan a Owl Alpha en absoluto.
La comunidad lo averiguó igualmente, y las pruebas siguen en Reddit. La primera pista fue geopolítica, en el comentario más votado del hilo original sobre el modelo stealth:
I think I can confirm Chinese model, it affirmed that Taiwan is part of China.
Luego alguien probó ambos endpoints en paralelo:
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
Hay una pequeña pieza de corroboración escondida en la propia documentación de Meituan, y es mi detalle favorito de todo el conjunto de documentos. El ejemplo oficial de reasoning_content en la página de referencia de la API tiene al modelo refiriéndose a sí mismo como "OWL", un resto de un system prompt que nadie limpió.
Menciono la fase stealth porque cambia cómo hay que leer las reseñas. Buena parte de la experiencia práctica que la gente tiene con este modelo se acumuló gratis, en un arnés con el que estaban experimentando, antes de que nadie supiera qué estaba probando. Eso es inusualmente limpio como feedback de usuario, y significa que los relatos de abajo no son impresiones del día de lanzamiento.
Lo que dicen los benchmarks, y lo que no dicen
Meituan publica diez filas de benchmarks frente a seis modelos de comparación. La advertencia está en la propia ficha: salvo que estén marcadas con un asterisco, todas las puntuaciones se midieron internamente, y la mayoría de las puntuaciones de los competidores se toman directamente de los informes de esos propios proveedores. Así que esto no es una única prueba controlada.
| 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 |
Leyendo las columnas de arriba a abajo, el patrón es claro. LongCat 2.0 supera a Gemini 3.1 Pro en las tres filas de agentes de código, y le gana a GPT-5.5 en SWE-bench Pro por 0,9. También queda por detrás de Claude Opus 4.8 en todas las filas donde 4.8 tiene puntuación, por 9,7 en SWE-bench Pro y por 8,1 en Terminal-Bench 2.1. Mi lectura: es un modelo de codificación real, cercano a la frontera, que supera a la generación anterior y no supera a la actual.
Hay dos cosas de esa tabla que merece la pena señalar antes de que alguien la cite. Meituan indica que SWE-bench se ejecutó con "tareas problemáticas corregidas", y RWSearch se describe como "un benchmark objetivo interno", así que dos de las diez filas son en parte instrumento propio de Meituan. Y el conjunto de comparación no incluye ningún rival de pesos abiertos: ni DeepSeek, ni Qwen3.8 Max, ni Kimi K3, ni GLM-5.2. Esos son los modelos entre los que realmente elige un equipo que quiere pesos abiertos.
Una corrección más mientras estoy en esto, porque circula ampliamente. Anthropic no publica ninguna puntuación de SWE-bench para Claude Opus 5 ni para Sonnet 5. La cifra de 69,2 es de Opus 4.8. Si ves un 69,2 atribuido a Opus 5, es incorrecto.
Lo que dice la gente que realmente lo ha usado
Los veredictos se dividen con fuerza, y quiero ser claro en que esto es un desacuerdo real, no un consenso mayoritario con algunas quejas sueltas. El patrón general es que quienes lo usaron como agente dentro de un arnés lo valoraron bien, y quienes lo juzgaron como modelo "inteligente" lo valoraron mal, pero ese patrón no se sostiene del todo: al menos un desarrollador que lo usaba solo para código lo calificó de tener muchos bugs y aconsejó evitarlo.
El relato más sustancial de todos viene de alguien que le pasó 3.600 millones de tokens durante el periodo stealth gratuito:
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.
Alguien que compró un pack de tokens tras el lanzamiento llega a la misma conclusión:
"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."
Y la disidencia más contundente viene de alguien que lo usa en producción y que se enfrenta directamente al marco que le dio este lanzamiento:
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.
Mi lectura de todo el conjunto: "caballo de trabajo fiable" es la etiqueta honesta, y cuadra tanto con la tabla de benchmarks como con la gente que ha registrado miles de millones de tokens. Seguir instrucciones y la coherencia en contextos largos aparecen una y otra vez como puntos fuertes. El razonamiento puro no, y la calidad del código sigue en disputa, no resuelta.
Merece la pena sacar una reacción más, porque es el único sitio donde vi a alguien poner precio a lo que a mí me sigue rondando la cabeza.
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
Es un desarrollador que leyó la política, tomó una decisión y se quedó sin dos meses de acceso gratuito a un modelo decente por ello. Si esa fue la decisión correcta depende por completo de lo que planeara enviarle.
Precios: la tabla real
Meituan publica tanto un precio de lista como un descuento de lanzamiento. La columna del descuento está etiquetada como "por tiempo limitado" sin ninguna fecha de fin en ningún sitio, y la página en chino lo llama oferta de lanzamiento para el estreno inicial de la plataforma. Ambas divisas son tarifas publicadas por separado, no una conversión de tipo de cambio.
| 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 |
Hay dos detalles en esa tabla más interesantes que la cifra principal.
No hay ningún escalonado por longitud de contexto. Todos los demás modelos con ventana de 1M que revisé cobran más a partir de cierto umbral: el precio de Gemini 3.1 Pro se duplica por encima de 200K, GPT-5.6 Sol se duplica por encima de 272K, y MiniMax-M3 se duplica por encima de 512K. LongCat 2.0 es plano, lo que hace que el trabajo con contexto largo salga desproporcionadamente barato en él. Es el hecho menos reportado de la página de precios.
También vale la pena señalar lo que un precio plano no resuelve. Una tarifa barata en un modelo que necesita más tokens para llegar a la misma respuesta no es barata, y esa es la trampa de toda comparación de titulares. La misma advertencia me pilló trabajando con el precio de GPT-5.6. Se aplica igual de fuerte al precio de Gemini 3.6 Flash, y a este también.
Y las lecturas cacheadas cuestan 1/50 de la entrada sin caché, lo que suena estupendo hasta que miras el cuerpo de la respuesta. No hay campo prompt_tokens_details.cached_tokens en la ruta compatible con OpenAI ni cache_read_input_tokens en la compatible con Anthropic, y no hay ningún parámetro cache_control para dirigirlo. El caché es totalmente implícito y no puedes verificar por qué se te está cobrando realmente.
El descargo de responsabilidad de Meituan merece citarse tal cual: "Los precios están sujetos a cambios. Los precios mostrados en la plataforma de la API de LongCat y tus registros de facturación son los que tienen validez."
Cómo se compara en la práctica
Aquí es donde el precio promocional hace la mayor parte del trabajo. Introduce tus propios números.
Muévelo un rato y el panorama se vuelve obvio. Al precio promocional, LongCat 2.0 cuesta aproximadamente una veinteava parte de Opus 5 y alrededor de una quinta parte del precio de Sonnet 5, que fue la comparación que todo el mundo hizo el día del lanzamiento.
Luego sube el deslizador de caché. A partir de más o menos el 80% de tasa de aciertos, DeepSeek V4 Pro supera a LongCat 2.0 incluso al precio promocional, porque su lectura cacheada cuesta 0,003625 dólares frente a los 0,006 de LongCat. Que la entrada sin caché sea barata no es lo mismo que ser barato en producción, y el trabajo de agentes a escala de repositorio es exactamente el tipo de carga donde las tasas de acierto de caché suelen ser altas.
Al precio de lista, la imagen se invierte. 0,75 dólares de entrada y 2,95 de salida es más caro que DeepSeek V4 Pro a 0,435 y 0,87 dólares, que es el gemelo arquitectónico más cercano de LongCat 2.0: también 1,6T de parámetros totales, 49.000 millones activos, contexto de 1M, también MIT. También le gana en entrada GPT-5.6 Luna a 0,20 dólares, que es un modelo propietario alojado que se puede pagar con tarjeta de crédito. Así que la promoción es toda la historia del precio, y esa promoción no tiene fecha de fin publicada.
Hay un segundo multiplicador de coste que la etiqueta esconde. El razonamiento está activado por defecto, y los tokens de razonamiento se facturan a la tarifa de salida. En el panel de uso propio de OpenRouter, 2,03M de los 2,16M de tokens de finalización de este modelo eran tokens de razonamiento. Alrededor del 94% de lo que pagas en salida es el modelo pensando, no la respuesta que te quedas. Eso es normal en un modelo de razonamiento, y sigue siendo una cifra que quieres tener en tu previsión en lugar de descubrirla en una factura. Si has pasado por este ejercicio con Opus 5 frente a Sonnet 5 ya sabes cuánto mueve esto el coste por tarea.
La parte que realmente te va a frenar
Meituan documenta exactamente dos canales de pago, y ambos aparecen solo dentro de las normas de reembolso: WeChat y Alipay. Sin tarjeta, sin PayPal, sin transferencia. La facturación de autoservicio está disponible "solo para usuarios en China continental", y todos los demás tienen que escribir por correo al equipo.
El registro en sí está abierto: los usuarios fuera de China continental pueden darse de alta con un correo electrónico. Financiar la cuenta es otra cuestión, y la API rechaza las peticiones en cuanto el saldo llega a cero. Los Token Packs, la alternativa de prepago, se venden en lanzamientos flash con horario fijo a las 10:00, 16:00, 21:00 y 23:00 hora de Pekín, con existencias limitadas, y caducan a los 30 días naturales.
La respuesta práctica para la mayoría de los equipos fuera de China es, por tanto, OpenRouter, lo que explica en parte que el tráfico público del modelo pase más por arneses de codificación que por la propia plataforma de Meituan. Vuelvo a esa contrapartida en un momento.
La API: siete parámetros y ninguna herramienta
Leí la documentación de la API de la misma manera en que la leería antes de conectar algo a producción, y esta es la sección donde una opinión con forma de benchmark se convierte en una opinión de ingeniería.
Hay dos superficies disponibles: una ruta compatible con OpenAI y una ruta compatible con Anthropic Messages, ambas en api.longcat.chat, ambas aceptando la misma clave bearer. Cambiar la URL base de cualquiera de los dos SDK es un cambio de una sola línea, que es lo más agradable de la plataforma. Si has comparado las APIs de OpenAI, Anthropic y Gemini sabes lo raro que es esto.
A partir de ahí, la cosa se adelgaza. Solo se soportan siete parámetros en total: max_tokens, temperature, top_p, stream, tools, tool_choice y thinking. Sin secuencias stop. Sin seed. Sin response_format ni modo JSON. Sin logprobs, sin n, sin penalizaciones, sin top_k. temperature va de 0 a 1 en lugar del 0 a 2 de OpenAI, así que una configuración migrada directamente puede quedar fuera de rango sin avisar. thinking es binario, activado o desactivado, sin presupuesto ni nivel de esfuerzo.
tools y tool_choice aparecen en la lista de parámetros y no están documentados en ningún sitio. Sin esquema, sin forma de la respuesta de llamada a herramienta, sin ejemplo, a pesar de que el changelog anuncia llamadas a herramientas nativas. El día del lanzamiento, ese hueco se hizo notar exactamente donde cabría esperar:
"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"
La ficha del modelo confirma una rotura relacionada: LongCat espera los arguments de la llamada a herramienta como un diccionario en lugar de la cadena JSON que especifica el esquema de OpenAI. Cualquier cosa escrita contra la forma estándar necesita un adaptador.
Ambas capas de compatibilidad también tienen una forma sutilmente incorrecta que rompe parsers estrictos. El razonamiento llega como message.reasoning_content en la ruta de OpenAI, que es un campo de DeepSeek y no de OpenAI. En la ruta de Anthropic llega como una clave thinking dentro de un bloque de contenido de texto en lugar de como un bloque de pensamiento propiamente dicho, y el stream SSE documentado omite content_block_start, content_block_stop y ping.
No hay herramientas alojadas de ningún tipo. Sin búsqueda web, sin intérprete de código, sin almacén de recuperación, sin endpoints de archivos, sin embeddings, sin API de lotes. MCP no se menciona ni una vez, y no hay ningún bucle de agente del lado del servidor, así que el comportamiento agéntico es enteramente una afirmación sobre el modelo, y hacerlo funcionar es enteramente trabajo de tu arnés.
Lo que Meituan sí documenta son las integraciones de cliente: doce en total, incluyendo Claude Code, Codex, Cline, Kilo Code, OpenCode y Cherry Studio, cada una con el cambio exacto de URL base. Cursor y Roo no están en esa lista. Si ya vives dentro de un CLI de codificación agéntica, ese es el camino de menor resistencia, y es hacia donde va el tráfico real del modelo.
Existen límites de tasa y no se publican cifras para ellos. La única cifra concreta en todo el conjunto es retry_after: 60 en el cuerpo de la respuesta 429. Las peticiones fallidas no se facturan, un detalle amable, y el saldo de pago por uso nunca caduca.
Mi detalle favorito de todo el conjunto de documentos es pequeño: el ejemplo oficial de reasoning_content tiene al modelo refiriéndose a sí mismo como "OWL", un resto de un system prompt distinto. La documentación la escriben humanos con prisa, y se nota.
El autoalojamiento: el muro
Tener pesos MIT en un modelo a escala de frontera es un regalo real, y viene con una factura de hardware que decide para quién es ese regalo.
La versión BF16, según la API de blobs de Hugging Face, ocupa 3,55 TB repartidos en 194 shards de safetensors. La versión FP8 ocupa 2,05 TB repartidos en 141. Todas las recetas de SGLang cargan FP8, así que el maestro de 3,55 TB es una fuente de cuantización, no un objetivo de servicio, y BF16 no tiene ninguna topología publicada en absoluto.
| 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 |
La fila de 8x B300 es la única que SGLang marca como verificada, y las cuentas explican por qué el B200 de 192 GB sigue necesitando dos nodos: 2,05 TB de pesos FP8 no entran en 8 x 192 GB. La receta de H20 es más extraña, porque 16 x 96 GB son 1.536 GB frente a 2.051 GB de pesos, lo que solo funciona si las tablas de N-gram y los módulos MTP se quedan fuera de la HBM, y ningún documento dice que sea así.
Luego está la caché de KV. Con 43.776 bytes por token y --mem-fraction-static 0.92 en 8x B300, te quedan aproximadamente 69 GB de margen para KV después de cargar los pesos. Eso equivale a unas seis secuencias simultáneas con la ventana completa de 256K, o a 64 slots con un promedio de 24K tokens cada uno. La ventana de contexto y la concurrencia compiten por la misma memoria, y con un contexto de 1M, 64 slots necesitarían 2.802 GB solo de KV, más que todo el pool de 2.304 GB.
Los runtimes para consumidor son un no rotundo. llama.cpp no tiene soporte fusionado para LongCat y no existe ningún GGUF para ninguna variante, así que Ollama y LM Studio no pueden cargarlo. Las cuantizaciones comunitarias que sí existen son solo para MLX, necesitan una PR de mlx-lm que aún no se ha fusionado, y la versión más pequeña con todos los expertos pesa 512 GB, lo que supera a un Mac de 512 GB. La pestaña de discusión de Hugging Face es básicamente una larga petición continua:
"GGUF Version please!!!"
r/LocalLLaMA llegó antes, y el comentario más votado del hilo de publicación de pesos lo resume mejor que nadie:
Damn, that's a really long Cat!
3.55 TB in all its BF16 glory. 2.05 TB in FP8.
La versión más sobria del mismo punto, del mismo hilo: pesos abiertos y acceso abierto no son lo mismo. Para cualquiera con una 4090, una 5090 o incluso una RTX PRO 6000 de 96 GB, este lanzamiento es algo para leer, no para ejecutar. Lo que sí habilita es el trabajo de ecosistema: inspección, destilación, cuantizaciones comunitarias, y con el tiempo una versión Lite o destilada que el hardware corriente pueda cargar de verdad.
Las descargas cuentan la misma historia: 3.240 en el último mes, con cero proveedores de inferencia listados en Hugging Face y 24 personas que han pulsado "Ask for provider support". Para un modelo que dominó la conversación sobre modelos de codificación durante un mes, es una cifra pequeña, y es la cifra que cabría esperar cuando la entrada mínima es un nodo de 8x B300. Que los pesos sean gratis no hace gratis la inferencia, y el precio de Hugging Face es una comprobación de realidad útil sobre dónde acaba cayendo la factura de verdad.
A dónde van tus datos, que es la decisión de verdad
Esta es la sección que leería primero si dirigiera soporte en lugar de un repositorio, y es la más corta porque hay muy poco que contar.
Las FAQ de la plataforma de Meituan no hablan de retención de datos. No hablan de si los prompts o las finalizaciones se usan para entrenar. La palabra "training" no aparece en la página. No se nombra ningún país de servidores, y la única línea relacionada con geografía es "carga del servidor y ubicación geográfica", bajo un epígrafe sobre latencia. No hay SLA, ni cifra de uptime, ni crédito de servicio, ni ninguna vía de despliegue empresarial o privado más allá de una dirección de correo.
Nada de esto significa que esté pasando algo malo. Significa que las preguntas siguen sin respuesta, y en una revisión de seguridad, no tener respuesta ya es una respuesta en sí misma.
Pasar por OpenRouter tampoco lo resuelve del todo. Exactamente un proveedor sirve este modelo, AtlasCloud, y lleva una insignia de "No training" pero ninguna de retención cero de datos, mientras que NovitaAI, Tencent Cloud y Fireworks sí llevan ZDR en la misma página del directorio. La política propia de AtlasCloud retiene el contenido del cliente, definido para incluir prompts, resultados generados y payloads de la API, durante hasta siete días, con ZDR reservado a un anexo empresarial separado. Con un único proveedor, una petición filtrada por ZDR no tiene adónde ir.
No tengo que especular sobre si esto importa comercialmente, porque lo veo cada semana en las llamadas de ventas de eesel. Un comprador danés de telemática B2B, frenado por una revisión de seguridad interna estricta, no quería empezar una prueba hasta tener la garantía de que los datos de tickets con números de tarjeta y contraseñas se quedaban dentro de su propio entorno. Una empresa de medios que procesa alrededor de 1.000 tickets a la semana convirtió la redacción de tarjetas de crédito y PII en la objeción principal de toda la evaluación, por delante de la precisión y por delante del precio. La respuesta que doy en esas salas es concreta: ningún dato de cliente se usa para entrenar modelos, los proveedores de modelo subyacentes retienen los datos como máximo 30 días para vigilancia contra abusos, y los datos están aislados por cuenta. No puedes dar esa respuesta sobre una página que nunca menciona el entrenamiento.
Eso no es un golpe contra LongCat 2.0 como modelo de codificación. Es la diferencia entre un modelo que apuntas a tu propio repositorio y un modelo que apuntas a los datos personales de otra persona. La misma barrera aparece en todas las evaluaciones de IA para helpdesk que he visto, y una respuesta equivocada con el número de tarjeta de un cliente en el prompt es un tipo peor de alucinación que una respuesta equivocada sobre una ruta de código.
Quién debería usarlo de verdad
Recurre a LongCat 2.0 si haces trabajo de codificación de alto volumen y contexto largo dentro de un arnés que controlas, puedes pagar a través de OpenRouter, y el código que le das no es sensible. El precio plano hasta 1M de entrada es una ventaja real para prompts a escala de repositorio, la licencia MIT no tiene cláusula de uso aceptable ni umbral de usuarios, y "caballo de trabajo fiable" es una descripción justa de lo que reporta la gente.
Sáltatelo si necesitas modo JSON, secuencias stop o un contrato documentado de llamadas a herramientas, si pensabas autoalojarlo en algo por debajo de un nodo de 8x B300, o si un cuestionario de tratamiento de datos forma parte de tu proceso de compra. Si quieres pesos abiertos específicamente, DeepSeek V4 Pro es la comparación más cercana a un precio de lista más bajo, y GLM-5.2 también es MIT. Si quieres tokens baratos específicamente y no te importan los pesos abiertos, GPT-5.6 Luna es más barato en entrada y se paga con tarjeta de crédito. Merece la pena leer cómo se comparan DeepSeek Flash y K3 en coste por tarea terminada antes de comprometerte, porque las tarifas de titular y las facturas reales se separan mucho en este segmento.
Y si estás elegiendo un modelo porque quieres que la IA responda a los tickets de tus clientes, yo diría que estás comprando en la capa equivocada. Eso merece su propia sección.
Try eesel
Si has llegado hasta aquí comparando precios de tokens porque quieres que la IA gestione tu cola de soporte, lo que te diría es que elegir el modelo es la parte fácil, el 5% de ese proyecto. La parte difícil es saber qué le va a decir la IA a tus clientes antes de que lo diga, y poder responder después ante tu propio equipo de seguridad.
eesel es un compañero de equipo con IA que conectas al helpdesk que ya usas, Zendesk, Freshdesk, Gorgias, Front, Help Scout o Salesforce, y aprende de tus tickets y tu centro de ayuda existentes en lugar de necesitar una base de conocimiento nueva. Nosotros nos encargamos de la capa del modelo, así que no tienes que replantear el precio de tu stack de soporte cada vez que una publicación de lanzamiento promete un 60% de descuento sin fecha de fin. Antes de que nada se ponga en marcha puedes simular al agente contra tus tickets históricos reales y ver las respuestas que habría enviado, un paso que construimos después de ver a bots de aspecto seguro equivocarse en silencio. Y en las preguntas que la FAQ de LongCat deja abiertas, nosotros tenemos respuestas concretas: tus datos no se usan para entrenar modelos, y están aislados por cuenta.
Puedes conectar un helpdesk y ver cómo redacta su primera respuesta en pocos minutos, con un plan de autoservicio con precios de eesel por tarea y sin cuotas por asiento. Si quieres ver cómo encajan las piezas antes de eso, nuestro análisis sobre el mejor LLM para soporte cubre las contrapartidas, y el desglose de construir frente a comprar pone números reales a lo que cuesta operar tu propio stack una vez que incluyes las GPU. Prueba eesel gratis, o reserva una demo y trae tu ticket más difícil.
Preguntas frecuentes
¿Qué es LongCat 2.0?
¿Cuánto cuesta LongCat 2.0 por millón de tokens?
¿Es LongCat 2.0 realmente un modelo con 1M de contexto?
config.json publicado limita max_position_embeddings a 262.144. Así que la ventana de contexto real que se sirve es de 256K a menos que configures la extensión tú mismo, una diferencia menor de lo que parece frente a la ventana de contexto de Claude Code, pero sigue sin ser la cifra que se anuncia.¿Puedo alojar LongCat 2.0 yo mismo?
¿Debería usar LongCat 2.0 para atención al cliente?
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.
