DeepSeek V4.1 / V4

Autentíquese con una clave Bearer y tome el ID de modelo exacto de GET /v1/models. En /v1/messages también funciona la cabecera x-api-key.

curl https://api.hop-base.com/v1/chat/completions \
  -H "Authorization: Bearer sk-your-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-pro-202606",
    "messages": [{
      "role": "user",
      "content": "Resuma los riesgos de este trimestre en cinco puntos."
    }]
  }'

Modelos

V4.1 Flash devuelve el razonamiento en reasoning_content. Se factura sobre el precio oficial de DeepSeek y sigue el horario oficial de hora punta/valle; vea Precios en hora punta y hora valle.

Los tres modelos están en el grupo DeepSeek, así que una sola clave llega a todos.

Estos nombres cortos devuelven el mismo 404 model_not_found y no indican ningún ID de reemplazo: deepseek-v4-flash, deepseek-v4-pro, deepseek-chat, deepseek-reasoner y deepseek-flash (el nombre corto de DeepSeek para V4.1 Flash). El mensaje sigue el Accept-Language de la solicitud; en inglés por defecto:

El grupo actual no admite el modelo solicitado: <model>
The current group does not support the requested model: <model>

Precios en hora punta y hora valle

deepseek-v4.1-flash sigue el horario oficial de hora punta/valle de DeepSeek, expresado en hora de Pekín (UTC+8).

• Hora punta: de lunes a viernes, de 09:00 a 12:00 y de 14:00 a 18:00.
• Hora valle: el resto de las horas, incluidas las noches, el hueco de mediodía entre las dos franjas y el fin de semana completo.
• En hora valle, los precios unitarios de entrada, entrada en caché y salida se reducen todos a la mitad.
• Cada franja incluye su minuto de apertura y excluye el de cierre: las 09:00:00 ya son hora punta y las 12:00:00 ya son hora valle.

Cada solicitud se tarifica por el momento en que termina, no por el momento en que empieza. Una que empieza a las 17:59 y termina a las 18:01 se factura íntegra a la tarifa de hora valle; una que empieza a las 08:59 y termina a las 09:01 se factura íntegra a la de hora punta.

Una solicitud lleva siempre un único precio unitario y nunca se parte en el límite de la franja. Por eso dos registros de uso separados por un minuto pueden mostrar precios unitarios distintos para el mismo modelo. Las tarifas que aplican a su clave están en el catálogo de modelos con la sesión iniciada.

Endpoint y parámetros de la solicitud

POST /v1/chat/completions, POST /v1/responses y POST /v1/messages sirven para los tres modelos, y el streaming funciona con normalidad en todos. Codex CLI usa Responses; Claude Code usa Anthropic Messages, como se explica en Claude Code y Anthropic Messages.

• La compleción de relleno intermedio (FIM) no está disponible: vive en una ruta que HopBase no enruta.
• La compleción por prefijo sí está disponible; vea Compleción por prefijo.

La tabla cubre POST /v1/chat/completions. La pasarela solo rechaza messages vacío; el resto de límites son del servicio del modelo.

• messages[].role es system / user / assistant / tool / developer.
• thinking.type es enabled / disabled / adaptive; otros valores (como auto) devuelven 400.
• Un max_tokens negativo devuelve 400; por encima del techo no se rechaza y la salida se corta en silencio (vea Salida de razonamiento).
• stream_options.include_usage no afecta a la facturación.
• prefix solo va en el último mensaje assistant.
• Con image_url.url, el cuerpo completo de la solicitud es ≤ 60 MB.

Textos de error tomados de registros de producción (2026-09):

400 missing messages field                   messages ausente (pasarela)
400 messages must not be an empty array      messages vacío (pasarela)
400 expected a value <= 2                    temperature mayor que 2

En /v1/responses la salida se limita con max_output_tokens, que debe estar entre 1 y 393.216. temperature vuelve a ser 0–2, y una solicitud con caching debe llevar también store: true. Fuera de rango:

400 max_output_tokens must be less than or equal to 393216

Para todos los parámetros, consulte la referencia de la API de Chat Completions y elija la familia de modelos DeepSeek.

Entrada de imágenes

deepseek-v4.1-flash lee imágenes de forma nativa, en este mismo endpoint y con el formato estándar de partes de contenido de OpenAI. image_url.url acepta tanto un URI data: como una URL https:// accesible públicamente, y en un mismo mensaje pueden ir varias imágenes.

El cuerpo completo de la solicitud tiene un límite de 60 MB. Base64 añade cerca de un tercio, así que las imágenes juntas deben quedar por debajo de unos 45 MB; envíe las imágenes grandes como URL https://. Por encima del límite:

413 Request body exceeds the size limit (60 MB)

Las imágenes son entrada normal: se contabilizan en prompt_tokens.

400 Model deepseek-v4-pro-202606 does not accept image input. Remove the image from the request, including earlier turns of the conversation, or use a model that supports images.

{
  "model": "deepseek-v4.1-flash",
  "messages": [
    {
      "role": "user",
      "content": [
        { "type": "text", "text": "¿Qué hay en cada una de estas dos imágenes?" },
        { "type": "image_url", "image_url": { "url": "data:image/png;base64,iVBORw0KGgo..." } },
        { "type": "image_url", "image_url": { "url": "https://example.com/chart.png" } }
      ]
    }
  ]
}

Salida de razonamiento

DeepSeek devuelve su traza de razonamiento en un campo reasoning_content aparte, no dentro de content. Léalo explícitamente si lo necesita.

completion_tokens ya incluye los tokens de razonamiento, así que trátelo como la longitud real de salida y no sume reasoning_tokens encima. Esto se diferencia de Grok, donde el endpoint de chat los informa por separado y hay que sumarlos.

El razonamiento sale del mismo presupuesto de max_tokens que la respuesta, y se genera primero. Si el presupuesto es demasiado pequeño, el razonamiento se lo lleva entero; la llamada devuelve igualmente 200, con esta firma:

• finish_reason es length.
• content es una cadena vacía.
• completion_tokens_details.reasoning_tokens es igual al presupuesto que indicó.

Lea esa combinación como «suba max_tokens», no como una solicitud fallida. Con max_tokens: 16 este modelo devuelve un razonamiento cortado y ni una palabra de respuesta.

Esa regla del presupuesto vale para deepseek-v4.1-flash. En deepseek-v4-pro-202606 y deepseek-v4-flash-202605, max_tokens no limita el razonamiento mientras está activo: en pruebas, max_tokens: 64 devolvió entre 144 y 161 tokens de salida en Chat Completions y hasta 1.299 en Anthropic Messages, todos facturados. Con el razonamiento desactivado, el tope es exacto.

Los dos techos no se comportan igual. Una entrada que supera la ventana de contexto (1,048,576 tokens según las pruebas) se rechaza con un 400 antes de generar nada, y no se factura. En Chat Completions, un max_tokens por encima del techo de salida no se rechaza: la llamada devuelve 200 y la salida se corta en silencio en el techo real, así que una respuesta correcta no demuestra que su presupuesto se haya aceptado.

Herramientas y compleción por prefijo

Llamada a herramientas

La llamada a funciones estándar de OpenAI funciona de principio a fin: una llamada o varias en paralelo, tool_choice con auto, none, required o el nombre de una función, y resultados role: "tool" devueltos al modelo.

Este es un modelo de razonamiento y aun así acepta required. No hace falta desactivar el razonamiento, y la respuesta vuelve con finish_reason: "tool_calls".

Compleción por prefijo

Puede darle al modelo el comienzo de su propia respuesta para que siga a partir de ahí: haga que la última entrada de messages sea un mensaje assistant y márquelo con prefix: true. El content devuelto contiene solo la continuación; su texto no se repite.

En este modo el modelo no genera traza de razonamiento: reasoning_content no aparece, reasoning_tokens es 0 y todo el presupuesto se dedica a la continuación.

{
  "model": "deepseek-v4.1-flash",
  "messages": [
    { "role": "user", "content": "List three primary colors, comma separated, nothing else." },
    { "role": "assistant", "content": "red, green,", "prefix": true }
  ]
}

El content que vuelve en ese ejemplo es blue, un único token de salida.

Caché de prefijo y conciliación

La caché de prefijo es implícita: no hay nada que activar ni ningún parámetro de control que enviar. Un acierto se informa en el campo estándar de OpenAI usage.prompt_tokens_details.cached_tokens. Un acierto necesita al menos 256 tokens de prefijo común; por debajo de eso cached_tokens se queda en 0.

Su registro de uso de HopBase y el cuerpo de la respuesta cuentan la entrada de forma distinta, lo cual importa al conciliar:

Es decir, la entrada más la entrada en caché del registro equivalen al prompt_tokens de la respuesta. La lectura de caché se tarifica aparte de la entrada normal; consulte el catálogo de modelos con la sesión iniciada para ver la tarifa que aplica a su clave.

Claude Code y Anthropic Messages

POST /v1/messages acepta solicitudes estándar de Anthropic Messages para los tres modelos y las pasa a la interfaz compatible con Anthropic del propio modelo, así que Claude Code y el SDK de Anthropic se conectan directamente. En el SDK, el Base URL es https://api.hop-base.com, sin /v1.

Con CC Switch, abra el menú ··· de la clave en la consola, seleccione Importar CCS y luego Claude Code. La importación rellena el modelo; mantenga el formato predeterminado de Anthropic, sin enrutamiento local. Para configurarlo a mano:

export ANTHROPIC_BASE_URL="https://api.hop-base.com"
export ANTHROPIC_AUTH_TOKEN="sk-your-key"
export ANTHROPIC_MODEL="deepseek-v4-pro-202606"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="deepseek-v4-flash-202605"
export CLAUDE_CODE_MAX_CONTEXT_TOKENS=1000000
claude

Claude Code no conoce estos ID, así que CLAUDE_CODE_MAX_CONTEXT_TOKENS le indica la ventana de contexto real; sin ella, Claude Code compacta la conversación al llegar a 200K tokens. Los tres modelos están en el mismo grupo, así que basta con una clave. Más opciones en Claude Code.

• El razonamiento llega en bloques thinking y cuenta en output_tokens. thinking: {"type": "disabled"} lo desactiva.
• Una herramienta con nombre en tool_choice ({"type": "tool", "name": …}) se llama como se pide. {"type": "any"} se ignora, y el modelo puede responder con texto.
• Solo deepseek-v4.1-flash lee imágenes; una imagen enviada a los otros dos devuelve 400, como se explica en Entrada de imágenes.
• Un max_tokens por encima del tope de salida no se rechaza.
• Los puntos de corte cache_control se eliminan antes del envío, así que la caché explícita no está disponible; la caché de prefijo automática sigue funcionando. En pruebas del 2026-10-03, a partir del segundo turno Claude Code leyó de la caché entre el 94 % y el 99 % del prompt.

Al conciliar Anthropic Messages, input_tokens excluye la parte en caché y coincide con Tokens de entrada del registro de uso; cache_read_input_tokens coincide con Tokens de entrada en caché.

Comportamiento de la pasarela

• Entre los campos de Responses eliminados en silencio están stream_options, truncation, user, reasoning.summary y text.verbosity.
• Tipos no admitidos, por ejemplo: local_shell_call, file_search, code_interpreter.
• El campo model de la respuesta siempre refleja el ID público que solicitó, así que un cliente que verifique response.model == request.model sigue funcionando.

Próximos pasos

• DeepSeek Harness: el archivo de configuración y el formulario de proveedor personalizado del runtime de agentes dsh; esta página es el contrato de modelo que hay detrás
• OpenAI SDK: el patrón general de Chat Completions
• Claude Code: conexión directa por Anthropic Messages
• Códigos de error y reintentos
• Concurrencia, tiempos de espera y facturación