DeepSeek V4 Pro ya se puede invocar en la API oficial con el ID estable deepseek-v4-pro. A 13 de agosto de 2026, ese ID sirve la versión DeepSeek-V4-Pro-0813. Pro no es una suscripción ni otro nombre para V4 Flash: es un modelo con tarifa y límite de concurrencia propios.
Para la primera petición basta con adaptar el cliente de OpenAI. Para decidir una implantación hay tres condiciones más importantes: thinking viene activado, un acierto y un fallo de caché tienen precios radicalmente distintos y DeepSeek ha anunciado una subida significativa del precio global de sus API.
Identifica el modelo antes de copiar código o precios
La tabla oficial vigente describe este contrato:
| Campo | Valor actual |
|---|---|
| ID de modelo para la API | deepseek-v4-pro |
| Versión servida | DeepSeek-V4-Pro-0813 |
| Base URL, formato OpenAI | https://api.deepseek.com |
| Base URL, formato Anthropic | https://api.deepseek.com/anthropic |
| Contexto | 1 millón de tokens |
| Salida máxima | 384K tokens |
| Thinking | activado por defecto; se puede desactivar |
| Concurrencia indicada | 500 |
Usa el ID estable en la configuración y guarda la versión servida en evaluaciones e incidencias. Así DeepSeek puede actualizar la versión detrás del ID sin obligarte a inventar un nombre fechado, mientras tus resultados conservan contexto temporal.
No sustituyas Pro por deepseek-chat o deepseek-reasoner. El registro de cambios explica que esos alias antiguos se vincularon durante la transición a los modos non-thinking y thinking de V4 Flash, no a Pro.
También conviene separar disponibilidad y ciclo de vida. El anuncio de abril llamó preview a V4 y la actualización del 31 de julio indicó que el official release de Pro llegaría después. El quick start actual ya muestra la versión 0813, pero las páginas oficiales comprobadas no incluyen un aviso independiente que llame GA a Pro. “La API está disponible ahora” está respaldado; añadir GA sin matiz no hace falta.
Calcula un trabajo completo con la tarifa actual
Los precios directos de Pro por un millón de tokens son:
- entrada con acierto de caché: $0,003625;
- entrada sin acierto: $0,435;
- salida: $0,87.
Supón un análisis de repositorio con 600.000 tokens de entrada cacheados, 200.000 nuevos y 30.000 de salida:
0,6 × $0,003625 + 0,2 × $0,435 + 0,03 × $0,87 = $0,115275
Es una operación reproducible sobre la tarifa del 13 de agosto de 2026, no un presupuesto cerrado. Faltan impuestos, herramientas externas, reintentos, corrección humana y margen de un router. DeepSeek además advierte en la misma página que espera aumentar notablemente el precio general de la API, pero aún no muestra la tarifa definitiva de sustitución. Revisa la página antes de comprometer gasto mensual o anual.

El precio bajo de caché tampoco significa que toda entrada larga se facture como acierto. Mantén estables el prompt de sistema, el mapa del repositorio y los documentos comunes; separa instrucciones nuevas, resultados de herramientas e historial variable. Solo los cached tokens devueltos en usage demuestran el ahorro.
Para una decisión de negocio añade los fallos:
coste por tarea aceptada = coste de todos los intentos / tareas que superan la aceptación
Pro puede salir más barato que un modelo de menor tarifa si reduce de forma medible reintentos e intervención. También puede ser un gasto innecesario cuando Flash ya supera el mismo validator.
Primera llamada con el SDK de OpenAI
El quick start oficial usa el cliente de OpenAI. Guarda la clave en una variable de entorno:
pythonimport os from openai import OpenAI client = OpenAI( api_key=os.environ["DEEPSEEK_API_KEY"], base_url="https://api.deepseek.com", ) response = client.chat.completions.create( model="deepseek-v4-pro", messages=[ {"role": "system", "content": "Revisa los cambios de código de forma conservadora."}, {"role": "user", "content": "Detecta riesgos de rollback en este plan de migración."}, ], reasoning_effort="high", extra_body={"thinking": {"type": "enabled"}}, stream=False, ) print(response.choices[0].message.content)
Para clasificación, extracción o transformaciones sencillas, prueba non-thinking y compara la aceptación:
pythonextra_body={"thinking": {"type": "disabled"}}
Un smoke test correcto no termina en HTTP 200. Verifica content no vacío, model y usage registrados, manejo de timeout y errores, y que ni la clave ni prompts sensibles lleguen al log habitual.
Thinking cambia parámetros y continuidad de mensajes
La guía oficial de thinking establece que el modo viene activo con esfuerzo high. Los niveles efectivos son low, high y max; medium y xhigh se mapean a high.
En thinking no tienen efecto temperature, top_p, presence_penalty ni frequency_penalty. El servidor puede aceptarlos sin error por compatibilidad, así que una configuración antigua puede parecer afinada aunque no cambie nada. Desactiva thinking para la tarea simple o ajusta el effort para la compleja.
Los agentes con herramientas tienen una regla más delicada. Si la respuesta incluye reasoning_content, content y tool_calls, después de ejecutar la herramienta conserva el mensaje assistant completo y añade el resultado con role: tool. Perder reasoning_content al continuar el bucle puede provocar HTTP 400.
La opción segura es añadir directamente a la conversación el objeto message del SDK. La guía de tool calls trata strict mode por separado: requiere la base /beta y un subconjunto limitado de JSON Schema. Sigue siendo Beta y no valida cualquier esquema imaginable.
Un contexto de 1M no es un objetivo de entrada
El millón de tokens es el techo de la ventana de trabajo; 384K es el máximo de salida indicado. Son límites distintos. Ninguno recomienda enviar un monorepo entero en cada petición.
Una entrada enorme sin caché aumenta coste y prefill, y los archivos irrelevantes pueden empeorar la precisión. Recupera primero el código y las pruebas necesarias. Amplía solo si la aceptación demuestra que faltaba información concreta. Mide tiempo hasta resultado aceptable, no solo tiempo hasta el primer token.
Cuándo merece Pro la prima frente a Flash
En la tarifa comprobada, la entrada sin caché y la salida de Pro cuestan algo más de tres veces las de Flash. Deja que el coste del fallo decida el primer candidato:
| Carga | Primer candidato | Evidencia que justifica Pro |
|---|---|---|
| Chat breve, extracción, transformación | V4 Flash | Menos errores importantes de formato o hechos |
| Planificación entre varios archivos | V4 Pro | Menos omisiones, reintentos e intervención |
| Cadenas largas con herramientas caras | Prueba controlada de Pro | Mayor tasa de aceptación y menor coste total |
| Alto volumen con validator claro | V4 Flash | Pro solo si baja el coste por tarea aceptada |
No uses un benchmark de Pro para describir Flash. Si la lista incluye más modelos, la guía en español DeepSeek V4 Flash vs Kimi K3 vs GLM-5.2 resuelve esa comparación más amplia.
Prueba 10–30 tareas reales con los mismos archivos, permisos, timeout, presupuesto de reintentos y aceptación. Registra entrada cacheada y nueva, salida, tiempo total e intervención humana. Una demo vistosa descubre una posibilidad; el coste por resultado aceptado decide si es producción.

Antes de integrar, vuelve a consultar la tarifa oficial y el registro de cambios. El ID estable mantiene el código, pero no congela la versión, el precio ni el estado del producto que hay detrás.



