La API de DeepSeek consta de dos endpoints y dos nombres de modelo — esto es lo que acepta cada uno

La API de DeepSeek parece más simple de lo que es. Hay dos URL base, dos identificadores de modelo y una matriz de características en la que las dos columnas son casi idénticas — excepto por la única línea que decide si tu carga de trabajo es posible en absoluto. Si migras desde un SDK de OpenAI, necesitas una de ellas; si migras desde un harness con forma de Anthropic, necesitas la otra; y si envías capturas de pantalla, solo uno de los dos modelos las aceptará.

Las dos bases

• Formato OpenAI — code>https://api.deepseek.com/code>. Completaciones de chat con el formato de OpenAI, incluida la API Responses, salida JSON, llamadas a herramientas y completación de prefijo en beta.

• Formato Anthropic — code>https://api.deepseek.com/anthropic/code>. Los mismos dos modelos detrás de una superficie con forma de Anthropic, que es justo lo que necesita un arnés de programación que habla ese protocolo.

Ambas bases sirven a ambos modelos. La elección de la base tiene que ver con tu biblioteca de cliente, no con la capacidad.

Los dos nombres, y lo que hay detrás de cada uno.

• deepseek-flash — actualmente servido por DeepSeek-V4.1-Flash-1017, el checkpoint de octubre. Multimodal: texto e imágenes de entrada, texto de salida. Contexto de 1M, salida máxima de 384K, 2.500 solicitudes concurrentes.

• deepseek-v4-pro — servido por DeepSeek-V4-Pro-0813. Solo texto. Misma ventana de contexto de 1M y salida de 384K, 500 solicitudes simultáneas.

Todavía se aceptan dos identificadores heredados — code>deepseek-v4-flash/code> y code>deepseek-v4-flash-vision-exp/code> — pero la documentación de DeepSeek es explícita en que los modelos correspondientes se han retirado, que las solicitudes se atienden con V4.1-Flash-1017 y que se facturan al precio de Flash. En la práctica, eso significa que una integración antigua sigue funcionando y, sin aviso, empieza a devolver respuestas de otro modelo, lo que conviene comprobar antes de atribuir a cualquier otra cosa un cambio en la salida.

La matriz de características, fila por fila

Casi todo es compartido. Las excepciones son la razón misma por la que existe esta guía.

• Modo de pensamiento — ambos modelos admiten los modos sin pensamiento y con pensamiento, y el pensamiento es el predeterminado. Los niveles de esfuerzo son bajo, alto y máximo; la recomendación de DeepSeek es bajo para tareas simples, alto para el trabajo diario de agentes y máximo para escenarios más difíciles.

• Salida JSON, llamadas a herramientas, finalización de prefijos — compatibles de forma idéntica en ambas. La finalización de prefijos está en beta.

• Responses API y API de Anthropic — ambas compatibles con ambos modelos, lo cual es poco habitual y conviene saberlo: puedes manejar cualquiera de los dos modelos desde cualquiera de las dos formas de cliente sin necesidad de una capa de traducción.

• Completado FIM —beta en ambos, y modo sin pensamiento solo en ambos. Si su caso de uso es relleno de código, esa restricción también se aplica al modelo insignia.

• Visión — una marca de verificación para code>deepseek-flash/code>, «No compatible» para code>deepseek-v4-pro/code>. Esta es la única bifurcación en la matriz, y no es algo que un cambio de prompt pueda solucionar.

Lo que los identificadores implican sobre el costo

Los nombres conllevan la estructura de precios. Flash cuesta $0,15 de entrada y $0,60 de salida por millón de tokens, con un acierto de caché a $0,003; V4 Pro cuesta $0,66 y $1,98, con un acierto de caché a $0,022. Ambos se duplican durante 01:00–04:00 y 06:00–10:00 UTC, de lunes a viernes. Así, el nombre del modelo que elijas determina tanto la capacidad como la factura, y los nombres heredados anteriores fijan la factura a la tarifa de Flash independientemente de qué checkpoint responda.

Una consecuencia práctica: dado que code>deepseek-flash/code> ahora apunta a un checkpoint publicado en octubre, un modelo de costos o una línea base de calidad que se escribió con respecto al modelo de septiembre está describiendo algo que ya no recibes con ese identificador. No fijes nada a un nombre que no hayas vuelto a medir este mes.

Cómo se compara esto con una capa de enrutamiento

La propia superficie de DeepSeek consiste en dos modelos detrás de dos protocolos. Si tu aplicación solo necesita el modelo DeepSeek más potente, con eso basta. Los casos en los que no basta son aquellos que esta forma no puede expresar: elegir un respaldo para una caída de proveedor, combinar DeepSeek con el modelo de otro proveedor en un mismo flujo de trabajo, o hacer pruebas A/B de Flash frente a Pro sobre tráfico real sin dos integraciones.

Para eso sirve el endpoint compatible con OpenAI de OrcaRouter, con 224 modelos, y DeepSeek V4 Pro y V4.1 Flash están disponibles en él con las tarifas publicadas por DeepSeek, sin recargo — incluida la fila de aciertos de caché y la duplicación en hora pico, porque se traslada tal cual el precio del proveedor. Los endpoints anteriores siguen funcionando exactamente como DeepSeek los documenta; un router no sustituye la API del proveedor, sino que te ofrece un único lugar para cambiar entre varios de ellos.

La lista de verificación de migración, en orden.

• Elige la base según la forma de tu cliente, no según el modelo que quieres.

• Elige el modelo según lo que envíes: imágenes significa Flash, el trabajo solo de texto lo decide el precio.

• Establezca explícitamente el esfuerzo de pensamiento en lugar de heredar el valor predeterminado, porque el valor predeterminado tiene el pensamiento activado.

• Comprueba si tu antiguo identificador ha sido retirado bajo tu responsabilidad — los dos nombres heredados se aceptan, se facturan de nuevo y se sirven de nuevo.

Mide la proporción de aciertos de caché antes de estimar la factura mensual, ya que un prefijo estable supone un descuento de 30× y uno inestable no aporta nada.