Mistral Small 4 combina seguimiento general de instrucciones, razonamiento y programación en un solo modelo multimodal. Su desarrollador lo describe como una unificación de las familias Instruct, Magistral de razonamiento y Devstral de programación. Acepta texto e imágenes y devuelve texto, con llamadas a funciones y salida JSON disponibles para aplicaciones asistidas por herramientas.
Arquitectura y funciones principales
La versión tiene 119,000 millones de parámetros totales y activa 6,500 millones por token. Su arquitectura de mezcla de expertos contiene 128 expertos, con 4 activos, y su desarrollador documenta una ventana de contexto de 256k. El número de parámetros activos y de expertos describe cómo se organiza el modelo; se distingue de la cantidad de contenido textual o visual incluido en una tarea.
El modelo proporciona funciones de instrucciones y razonamiento en el mismo checkpoint. Su desarrollador también identifica visión, seguimiento de prompts de sistema y compatibilidad multilingüe con decenas de idiomas, entre ellos inglés, francés, español, alemán, italiano, portugués, neerlandés, chino, japonés, coreano y árabe. Por ello, una instrucción de texto puede preguntar por una imagen o combinar un requisito escrito con evidencia visible, y devolver la respuesta como texto.
Una tarea visual puede proporcionar una página documental y pedir los valores relevantes para una condición identificada. Mantén legibles las etiquetas y unidades e indica si el resultado debe conservar la redacción original, resumirla o compararla con otra fuente. Una tarea de interfaz puede acompañar una captura de pantalla con el objetivo del usuario y solicitar el control visible relevante y la evidencia que respalda un siguiente paso propuesto.
Elección del modo de instrucciones o razonamiento
La ficha publicada documenta el esfuerzo de razonamiento none para una respuesta inmediata de tipo instrucción y high para razonamiento; recomienda high para prompts complejos. La elección se hace por solicitud dentro del mismo modelo Small 4. Una clasificación habitual o una reescritura breve puede tener un contrato de respuesta distinto al de un problema matemático, visual o de programación que necesite una explicación desarrollada.
Su desarrollador recomienda una temperatura de 0.7 para el esfuerzo de razonamiento high. Para none, especifica temperaturas entre 0.0 y 0.7 según la tarea. Estos ajustes describen los modos documentados y no convierten el esfuerzo de razonamiento en una garantía de resultado correcto. Define las suposiciones, el formato de salida y el material fuente relevante antes de elegir cuánto razonamiento requiere la tarea.
Para un problema desarrollado, proporciona la condición completa y solicita los pasos justificados importantes seguidos de la expresión final. Para una tarea de código, proporciona el requisito, la función afectada y una entrada concreta; solicita la implementación propuesta por separado de la explicación y los ejemplos. Las demostraciones de uso de su desarrollador incluyen seguimiento de instrucciones, una herramienta de cálculo aplicada a una imagen y razonamiento visual, e ilustran cómo el texto y la evidencia visual pueden intervenir en estas tareas diferentes.
Programación, documentos y herramientas
El modelo está orientado a exploración de bases de código y agentes de ingeniería de software, asistentes generales, comprensión documental e investigación. Una solicitud a un agente de programación puede indicar el módulo que debe cambiar, la interfaz que debe conservar y el comportamiento que debe resultar. Proporciona el código fuente relevante y la evidencia del fallo. El modelo puede proponer la siguiente operación o un cambio de código, mientras que la aplicación proporciona acceso al repositorio, ejecución y retroalimentación.
Para extraer información documental, identifica los campos requeridos y cómo representar información faltante. Un registro útil puede separar el identificador del documento, la declaración de la fuente, el requisito interpretado y la pregunta pendiente. La ficha del servicio de su desarrollador enumera salida estructurada personalizada y preguntas sobre documentos; estas últimas usan procesamiento documental y OCR para preparar texto y estructura antes del análisis con el modelo de lenguaje. Una pregunta directa sobre una imagen y un flujo documental asistido por OCR deben conservar su propia preparación de entrada.
Las llamadas a funciones requieren herramientas descritas con claridad. El modelo selecciona una función y crea argumentos; la aplicación ejecuta la operación y devuelve su resultado para la respuesta posterior. La misma lógica se aplica tanto si la tarea es una consulta como un cálculo o una operación de programación. El formato JSON organiza una respuesta, mientras que una llamada a herramienta solicita una acción externa; no deben tratarse como resultados intercambiables.
La ficha del servicio también enumera salidas predichas, prefijos de respuesta, procesamiento por lotes y conversaciones con agentes. Las salidas predichas son útiles cuando un documento o archivo de código se debe regenerar con un cambio limitado y se conoce el resto del contenido. Especifica la edición y el material que debe conservarse. La continuación de prefijo usa un inicio conocido de la respuesta, mientras que el procesamiento por lotes se refiere al envío de trabajo y no a un modo adicional de razonamiento.
Límites de contexto y edición
Planea la tarea escrita, el material visual, la conversación y la respuesta deseada según el contexto documentado de 256k. El ejemplo de uso publicado configura un contexto de 262,144 tokens, mientras que su ejemplo de generación de 1,024 tokens no constituye una capacidad máxima de salida independiente. Las fuentes consultadas no proporcionan un límite estricto de longitud de respuesta independiente para sustituir la extensión elegida para la tarea.
Small 4 tiene su propia arquitectura de mezcla de expertos de 119B y modos híbridos. No debe heredar la arquitectura densa de 128B de Medium 3.5 ni las ediciones independientes Instruct y Reasoning de Ministral 3. Su desarrollador también publica artefactos distintos de cuantización y decodificación especulativa; son artefactos de despliegue separados, no modalidades de contenido diferentes. Conserva la versión identificada Small 4 y el modo solicitado para la explicación, registro estructurado o resultado de código real.
", "aboutText": "Mistral Small 4 combina seguimiento general de instrucciones, razonamiento y programación en un solo modelo multimodal. Su desarrollador lo describe como una unificación de las familias Instruct, Magistral de razonamiento y Devstral de programación. Acepta texto e imágenes y devuelve texto, con llamadas a funciones y salida JSON disponibles para aplicaciones asistidas por herramientas.\n\nArquitectura y funciones principales\n\nLa versión tiene 119,000 millones de parámetros totales y activa 6,500 millones por token. Su arquitectura de mezcla de expertos contiene 128 expertos, con 4 activos, y su desarrollador documenta una ventana de contexto de 256k. El número de parámetros activos y de expertos describe cómo se organiza el modelo; se distingue de la cantidad de contenido textual o visual incluido en una tarea.\n\nEl modelo proporciona funciones de instrucciones y razonamiento en el mismo checkpoint. Su desarrollador también identifica visión, seguimiento de prompts de sistema y compatibilidad multilingüe con decenas de idiomas, entre ellos inglés, francés, español, alemán, italiano, portugués, neerlandés, chino, japonés, coreano y árabe. Por ello, una instrucción de texto puede preguntar por una imagen o combinar un requisito escrito con evidencia visible, y devolver la respuesta como texto.\n\nUna tarea visual puede proporcionar una página documental y pedir los valores relevantes para una condición identificada. Mantén legibles las etiquetas y unidades e indica si el resultado debe conservar la redacción original, resumirla o compararla con otra fuente. Una tarea de interfaz puede acompañar una captura de pantalla con el objetivo del usuario y solicitar el control visible relevante y la evidencia que respalda un siguiente paso propuesto.\n\nElección del modo de instrucciones o razonamiento\n\nLa ficha publicada documenta el esfuerzo de razonamiento none para una respuesta inmediata de tipo instrucción y high para razonamiento; recomienda high para prompts complejos. La elección se hace por solicitud dentro del mismo modelo Small 4. Una clasificación habitual o una reescritura breve puede tener un contrato de respuesta distinto al de un problema matemático, visual o de programación que necesite una explicación desarrollada.\n\nSu desarrollador recomienda una temperatura de 0.7 para el esfuerzo de razonamiento high. Para none, especifica temperaturas entre 0.0 y 0.7 según la tarea. Estos ajustes describen los modos documentados y no convierten el esfuerzo de razonamiento en una garantía de resultado correcto. Define las suposiciones, el formato de salida y el material fuente relevante antes de elegir cuánto razonamiento requiere la tarea.\n\nPara un problema desarrollado, proporciona la condición completa y solicita los pasos justificados importantes seguidos de la expresión final. Para una tarea de código, proporciona el requisito, la función afectada y una entrada concreta; solicita la implementación propuesta por separado de la explicación y los ejemplos. Las demostraciones de uso de su desarrollador incluyen seguimiento de instrucciones, una herramienta de cálculo aplicada a una imagen y razonamiento visual, e ilustran cómo el texto y la evidencia visual pueden intervenir en estas tareas diferentes.\n\nProgramación, documentos y herramientas\n\nEl modelo está orientado a exploración de bases de código y agentes de ingeniería de software, asistentes generales, comprensión documental e investigación. Una solicitud a un agente de programación puede indicar el módulo que debe cambiar, la interfaz que debe conservar y el comportamiento que debe resultar. Proporciona el código fuente relevante y la evidencia del fallo. El modelo puede proponer la siguiente operación o un cambio de código, mientras que la aplicación proporciona acceso al repositorio, ejecución y retroalimentación.\n\nPara extraer información documental, identifica los campos requeridos y cómo representar información faltante. Un registro útil puede separar el identificador del documento, la declaración de la fuente, el requisito interpretado y la pregunta pendiente. La ficha del servicio de su desarrollador enumera salida estructurada personalizada y preguntas sobre documentos; estas últimas usan procesamiento documental y OCR para preparar texto y estructura antes del análisis con el modelo de lenguaje. Una pregunta directa sobre una imagen y un flujo documental asistido por OCR deben conservar su propia preparación de entrada.\n\nLas llamadas a funciones requieren herramientas descritas con claridad. El modelo selecciona una función y crea argumentos; la aplicación ejecuta la operación y devuelve su resultado para la respuesta posterior. La misma lógica se aplica tanto si la tarea es una consulta como un cálculo o una operación de programación. El formato JSON organiza una respuesta, mientras que una llamada a herramienta solicita una acción externa; no deben tratarse como resultados intercambiables.\n\nLa ficha del servicio también enumera salidas predichas, prefijos de respuesta, procesamiento por lotes y conversaciones con agentes. Las salidas predichas son útiles cuando un documento o archivo de código se debe regenerar con un cambio limitado y se conoce el resto del contenido. Especifica la edición y el material que debe conservarse. La continuación de prefijo usa un inicio conocido de la respuesta, mientras que el procesamiento por lotes se refiere al envío de trabajo y no a un modo adicional de razonamiento.\n\nLímites de contexto y edición\n\nPlanea la tarea escrita, el material visual, la conversación y la respuesta deseada según el contexto documentado de 256k. El ejemplo de uso publicado configura un contexto de 262,144 tokens, mientras que su ejemplo de generación de 1,024 tokens no constituye una capacidad máxima de salida independiente. Las fuentes consultadas no proporcionan un límite estricto de longitud de respuesta independiente para sustituir la extensión elegida para la tarea.\n\nSmall 4 tiene su propia arquitectura de mezcla de expertos de 119B y modos híbridos. No debe heredar la arquitectura densa de 128B de Medium 3.5 ni las ediciones independientes Instruct y Reasoning de Ministral 3. Su desarrollador también publica artefactos distintos de cuantización y decodificación especulativa; son artefactos de despliegue separados, no modalidades de contenido diferentes. Conserva la versión identificada Small 4 y el modo solicitado para la explicación, registro estructurado o resultado de código real.", "editorialOverlay": { "copy_fields": { "practical_html": "Ejemplo técnico en inglés
Repair a last-line parser\n\nThis Python parser loses a final line without a trailing newline: def lines(text):\n return text.split("\\n")[:-1]\nReturn a corrected function that preserves nonempty final lines, avoids an artificial last empty line when text ends in a newline and returns [] for empty text. Include tests for all three cases.A corrected Python function, a short explanation and tests for newline, no-newline and empty input.Check that the last real line is retained and that only a trailing separator’s artificial empty entry is removed.mistralai/mistral-small-2603Mistral Small 4 es un modelo híbrido de texto e imágenes con capacidades de instrucciones, razonamiento y programación. Su versión de mezcla de expertos de 119B activa 6.5B de parámetros por token y admite un contexto de 256k según su desarrollador, esfuerzo de razonamiento seleccionable, JSON y llamadas a funciones.
Esta descripción cubre las capacidades del modelo. Las entradas, salidas y opciones disponibles en Ailoot se indican a continuación para el método seleccionado.
Mistral Small 4 combina seguimiento general de instrucciones, razonamiento y programación en un solo modelo multimodal. Su desarrollador lo describe como una unificación de las familias Instruct, Magistral de razonamiento y Devstral de programación. Acepta texto e imágenes y devuelve texto, con llamadas a funciones y salida JSON disponibles para aplicaciones asistidas por herramientas.
Arquitectura y funciones principales
La versión tiene 119,000 millones de parámetros totales y activa 6,500 millones por token. Su arquitectura de mezcla de expertos contiene 128 expertos, con 4 activos, y su desarrollador documenta una ventana de contexto de 256k. El número de parámetros activos y de expertos describe cómo se organiza el modelo; se distingue de la cantidad de contenido textual o visual incluido en una tarea.
El modelo proporciona funciones de instrucciones y razonamiento en el mismo checkpoint. Su desarrollador también identifica visión, seguimiento de prompts de sistema y compatibilidad multilingüe con decenas de idiomas, entre ellos inglés, francés, español, alemán, italiano, portugués, neerlandés, chino, japonés, coreano y árabe. Por ello, una instrucción de texto puede preguntar por una imagen o combinar un requisito escrito con evidencia visible, y devolver la respuesta como texto.
Una tarea visual puede proporcionar una página documental y pedir los valores relevantes para una condición identificada. Mantén legibles las etiquetas y unidades e indica si el resultado debe conservar la redacción original, resumirla o compararla con otra fuente. Una tarea de interfaz puede acompañar una captura de pantalla con el objetivo del usuario y solicitar el control visible relevante y la evidencia que respalda un siguiente paso propuesto.
Elección del modo de instrucciones o razonamiento
La ficha publicada documenta el esfuerzo de razonamiento none para una respuesta inmediata de tipo instrucción y high para razonamiento; recomienda high para prompts complejos. La elección se hace por solicitud dentro del mismo modelo Small 4. Una clasificación habitual o una reescritura breve puede tener un contrato de respuesta distinto al de un problema matemático, visual o de programación que necesite una explicación desarrollada.
Su desarrollador recomienda una temperatura de 0.7 para el esfuerzo de razonamiento high. Para none, especifica temperaturas entre 0.0 y 0.7 según la tarea. Estos ajustes describen los modos documentados y no convierten el esfuerzo de razonamiento en una garantía de resultado correcto. Define las suposiciones, el formato de salida y el material fuente relevante antes de elegir cuánto razonamiento requiere la tarea.
Para un problema desarrollado, proporciona la condición completa y solicita los pasos justificados importantes seguidos de la expresión final. Para una tarea de código, proporciona el requisito, la función afectada y una entrada concreta; solicita la implementación propuesta por separado de la explicación y los ejemplos. Las demostraciones de uso de su desarrollador incluyen seguimiento de instrucciones, una herramienta de cálculo aplicada a una imagen y razonamiento visual, e ilustran cómo el texto y la evidencia visual pueden intervenir en estas tareas diferentes.
Programación, documentos y herramientas
El modelo está orientado a exploración de bases de código y agentes de ingeniería de software, asistentes generales, comprensión documental e investigación. Una solicitud a un agente de programación puede indicar el módulo que debe cambiar, la interfaz que debe conservar y el comportamiento que debe resultar. Proporciona el código fuente relevante y la evidencia del fallo. El modelo puede proponer la siguiente operación o un cambio de código, mientras que la aplicación proporciona acceso al repositorio, ejecución y retroalimentación.
Para extraer información documental, identifica los campos requeridos y cómo representar información faltante. Un registro útil puede separar el identificador del documento, la declaración de la fuente, el requisito interpretado y la pregunta pendiente. La ficha del servicio de su desarrollador enumera salida estructurada personalizada y preguntas sobre documentos; estas últimas usan procesamiento documental y OCR para preparar texto y estructura antes del análisis con el modelo de lenguaje. Una pregunta directa sobre una imagen y un flujo documental asistido por OCR deben conservar su propia preparación de entrada.
Las llamadas a funciones requieren herramientas descritas con claridad. El modelo selecciona una función y crea argumentos; la aplicación ejecuta la operación y devuelve su resultado para la respuesta posterior. La misma lógica se aplica tanto si la tarea es una consulta como un cálculo o una operación de programación. El formato JSON organiza una respuesta, mientras que una llamada a herramienta solicita una acción externa; no deben tratarse como resultados intercambiables.
La ficha del servicio también enumera salidas predichas, prefijos de respuesta, procesamiento por lotes y conversaciones con agentes. Las salidas predichas son útiles cuando un documento o archivo de código se debe regenerar con un cambio limitado y se conoce el resto del contenido. Especifica la edición y el material que debe conservarse. La continuación de prefijo usa un inicio conocido de la respuesta, mientras que el procesamiento por lotes se refiere al envío de trabajo y no a un modo adicional de razonamiento.
Límites de contexto y edición
Planea la tarea escrita, el material visual, la conversación y la respuesta deseada según el contexto documentado de 256k. El ejemplo de uso publicado configura un contexto de 262,144 tokens, mientras que su ejemplo de generación de 1,024 tokens no constituye una capacidad máxima de salida independiente. Las fuentes consultadas no proporcionan un límite estricto de longitud de respuesta independiente para sustituir la extensión elegida para la tarea.
Small 4 tiene su propia arquitectura de mezcla de expertos de 119B y modos híbridos. No debe heredar la arquitectura densa de 128B de Medium 3.5 ni las ediciones independientes Instruct y Reasoning de Ministral 3. Su desarrollador también publica artefactos distintos de cuantización y decodificación especulativa; son artefactos de despliegue separados, no modalidades de contenido diferentes. Conserva la versión identificada Small 4 y el modo solicitado para la explicación, registro estructurado o resultado de código real.
POST /v1/chat/completionstexttext| Campo | Tipo | Requisito | Valores y límites | Predeterminado |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObligatorio | Valores y límites mistralai/mistral-small-2603 | Predeterminado— |
Campomessages | Tipomessage[] | RequisitoObligatorio | Valores y límites Número mínimo de elementos: 1 | Predeterminado— |
Campomessages[].role | Tipostring | RequisitoObligatorio | Valores y límites Ejemplos: system, user, assistant, tool, function Condiciones: Estos roles están representados explícitamente por los tipos de compatibilidad del código fuente; el conjunto exacto de roles depende del modelo. Depende del modelo | Predeterminado— |
Campomessages[].content | Tipostring|content_part[]|null | RequisitoOpcional | Valores y límites | Predeterminado— |
Campomessages[].tool_calls | Tipotool_call[] | RequisitoOpcional | Valores y límites | Predeterminado— |
Campomessages[].tool_call_id | Tipostring | RequisitoOpcional | Valores y límites Se aplica cuando: role=tool; utiliza el ID real devuelto | Predeterminado— |
Campomessages[].name | Tipostring | RequisitoOpcional | Valores y límites | Predeterminado— |
Campomessages[].reasoning_content | Tipostring | RequisitoOpcional | Valores y límites Se aplica cuando: Devuelve en los turnos siguientes el razonamiento realmente recibido cuando este modelo lo utilice | Predeterminado— |
Campomessages[].reasoning_details | Tipoobject|array | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campomax_tokens | Tipointeger | RequisitoOpcional | Valores y límites Mínimo: 1 Depende del modelo | Predeterminado— |
Campomax_completion_tokens | Tipointeger | RequisitoOpcional | Valores y límites Mínimo: 1 Depende del modelo | Predeterminado— |
Campostream | Tipoboolean | RequisitoOpcional | Valores y límites | Predeterminadofalse |
Campostream_options.include_usage | Tipoboolean | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campotemperature | Tiponumber | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campotop_p | Tiponumber | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campostop | Tipostring|string[] | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campotools | Tipofunction_tool[] | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campotools[].type | Tipostring | RequisitoOpcional | Valores y límites function Depende del modelo | Predeterminado— |
Campotools[].function.name | Tipostring | RequisitoObligatorio | Valores y límites Se aplica cuando: herramienta de función proporcionada | Predeterminado— |
Campotools[].function.description | Tipostring | RequisitoOpcional | Valores y límites | Predeterminado— |
Campotools[].function.parameters | TipoJSON_schema | RequisitoOpcional | Valores y límites | Predeterminado— |
Campotool_choice | Tipostring|object | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campoparallel_tool_calls | Tipoboolean | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Camporesponse_format | Tipoobject | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Camporeasoning_effort | Tipostring | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Camporeasoning | Tipoobject | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Camposervice_tier | Tipostring | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campoinstructions | Tipostring | RequisitoOpcional | Valores y límites Campo de compatibilidad | Predeterminado— |
Campofunctions | Tipofunction[] | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campofunction_call | Tipostring|object | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campoprompt_cache_options | Tipoobject | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campomodalities | Tipostring[] | RequisitoOpcional | Valores y límites text | Predeterminado— |
Campoprovider | Tipoobject | RequisitoOpcional | Valores y límites Condiciones: provider.options se rechaza en esta ruta de texto Ultra | Predeterminado— |
Campocache_control.ttl | Tipostring | RequisitoOpcional | Valores y límites Condiciones: 1h se rechaza en los campos reales de caché de instrucciones | Predeterminado— |
Texto · Texto UTF8
messages[].content
| Parámetro | Contrato |
|---|---|
Parámetrocontent_type | Contratoapplication/json |
Parámetrorequired | Contratomodel, messages |
Parámetromaterial_types | Contratotext |
Parámetromessages | Contratomatriz de mensajes con estructura role/content |
Parámetrofile_material | Contratodocumento real en UTF-8 insertado como texto literal; no se deduce ningún ID de archivo |
Parámetrooptional_controls | Contratostream, temperature, top_p, stop, max_tokens, max_completion_tokens, reasoning, response_format, tools, tool_choice |
Parámetrocontrol_scope | Contratodepende del modelo; las herramientas de funciones del usuario difieren de las herramientas alojadas |
Parámetrooutput_modalities | Contratotext |
Parámetrohosted_operations | Contratofalse |
Parámetromultimodal_input_binding | Contratonull |
Ciclo de vida: synchronous_or_streamed
Envía el ID exacto del modelo junto con messages.
La longitud del contexto no es un límite máximo de salida.
Un archivo de texto puede aportar texto literal; las entradas de imagen, audio u objetos de archivo requieren una vinculación exacta.
Las referencias tarifarias no añaden opciones a la solicitud. Los parámetros admitidos se indican en el método seleccionado.
Relaciona cada cargo con las condiciones mostradas. Usa una tarifa para cada conjunto de configuraciones alternativas.
| Configuración | Tabla de tarifas | Tokens de contexto, más de | Tokens de contexto, hasta inclusive | Cargo |
|---|---|---|---|---|
| ConfiguraciónTarifas base por token | Tabla de tarifasTarifa base | Tokens de contexto, más de— | Tokens de contexto, hasta inclusiveSin límite superior | Cargo Entrada · Tokens de entrada $0.0003 / 1K tokens Salida · Tokens de salida $0.0012 / 1K tokens Entrada · Lectura de caché $0.00003 / 1K tokens Entrada · Escritura en caché — / 1K tokens Entrada · Escritura en caché, 1 hora — / 1K tokens |
| ConfiguraciónNivel 1 por longitud de la solicitud | Tabla de tarifas— | Tokens de contexto, más de0 | Tokens de contexto, hasta inclusiveSin límite superior | Cargo Entrada · Tokens de entrada $0.0003 / 1K tokens Salida · Tokens de salida $0.0012 / 1K tokens Entrada · Lectura de caché $0.00003 / 1K tokens Entrada · Escritura en caché — / 1K tokens Entrada · Escritura en caché, 1 hora — / 1K tokens |
Ailoot reserva un monto estimado antes de la solicitud. Tras obtener el resultado, liquida el cargo definitivo según el uso medido. En las respuestas en flujo, la liquidación usa el registro de uso final. Cómo funcionan la reserva y la liquidación →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads('{"model": "mistralai/mistral-small-2603", "messages": [{"role": "user", "content": "Explain the difference between an observation and a hypothesis in three sentences."}]}')\n\nPath("request.json").write_text(json.dumps(p,ensure_ascii=False))\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/chat/completions \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nr=json.loads(Path("result.json").read_text())\nfor x in r.get("choices",[]):\n if x.get("message",{}).get("content"): print(x["message"]["content"])\nPY_RESULT\nfrom openai import OpenAI\nimport os\n\nif not os.environ.get("AILOOT_API_KEY", "").strip(): raise SystemExit("Set AILOOT_API_KEY before making a request")\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nresult=client.chat.completions.create(model='mistralai/mistral-small-2603',messages=[{"role":"user","content":"Explain observations and hypotheses in three sentences."}])\nimport base64, json\nfrom pathlib import Path\n\ndef save_result(data, stem="result"):\n # Keep every field, including usage, IDs, reasoning and tool requests.\n Path(stem + ".json").write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")\n print(json.dumps(data, ensure_ascii=False, indent=2))\n def save_blob(encoded, suffix, label):\n raw = base64.b64decode(encoded, altchars=b"-_", validate=True)\n ext = "png" if raw.startswith(b"\\x89PNG\\r\\n\\x1a\\n") else "jpg" if raw.startswith(b"\\xff\\xd8") else "webp" if raw[:4] == b"RIFF" and raw[8:12] == b"WEBP" else suffix\n file = Path(stem + "-" + label + "." + ext)\n file.write_bytes(raw)\n print("Saved", file)\n for index, block in enumerate(data.get("content") or []):\n print("Content", index, json.dumps(block, ensure_ascii=False))\n for choice in data.get("choices") or []:\n print("Choice", choice.get("index"), json.dumps(choice.get("message", choice.get("delta", {})), ensure_ascii=False))\n for index, item in enumerate(data.get("output") or []):\n print("Output", index, json.dumps(item, ensure_ascii=False))\n if item.get("type") == "image_generation_call" and item.get("result"):\n save_blob(item["result"], item.get("output_format") or "bin", "output-" + str(index))\n for ci, candidate in enumerate(data.get("candidates") or []):\n for pi, part in enumerate((candidate.get("content") or {}).get("parts") or []):\n print("Candidate/part", ci, pi, json.dumps(part, ensure_ascii=False))\n blob = part.get("inlineData") or part.get("inline_data")\n if blob and blob.get("data"):\n mime = blob.get("mimeType") or blob.get("mime_type")\n suffix = {"image/png":"png", "image/jpeg":"jpg", "image/webp":"webp", "audio/wav":"wav", "audio/mpeg":"mp3", "video/mp4":"mp4"}.get(mime, "bin")\n save_blob(blob["data"], suffix, "candidate-" + str(ci) + "-part-" + str(pi))\n\nsave_result(result.to_dict(mode="json"))\nfrom openai import OpenAI\nimport os\nfrom pathlib import Path\n\nif not os.environ.get("AILOOT_API_KEY", "").strip(): raise SystemExit("Set AILOOT_API_KEY before making a request")\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nimport base64, json\nfrom pathlib import Path\n\ndef save_result(data, stem="result"):\n # Keep every field, including usage, IDs, reasoning and tool requests.\n Path(stem + ".json").write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")\n print(json.dumps(data, ensure_ascii=False, indent=2))\n def save_blob(encoded, suffix, label):\n raw = base64.b64decode(encoded, altchars=b"-_", validate=True)\n ext = "png" if raw.startswith(b"\\x89PNG\\r\\n\\x1a\\n") else "jpg" if raw.startswith(b"\\xff\\xd8") else "webp" if raw[:4] == b"RIFF" and raw[8:12] == b"WEBP" else suffix\n file = Path(stem + "-" + label + "." + ext)\n file.write_bytes(raw)\n print("Saved", file)\n for index, block in enumerate(data.get("content") or []):\n print("Content", index, json.dumps(block, ensure_ascii=False))\n for choice in data.get("choices") or []:\n print("Choice", choice.get("index"), json.dumps(choice.get("message", choice.get("delta", {})), ensure_ascii=False))\n for index, item in enumerate(data.get("output") or []):\n print("Output", index, json.dumps(item, ensure_ascii=False))\n if item.get("type") == "image_generation_call" and item.get("result"):\n save_blob(item["result"], item.get("output_format") or "bin", "output-" + str(index))\n for ci, candidate in enumerate(data.get("candidates") or []):\n for pi, part in enumerate((candidate.get("content") or {}).get("parts") or []):\n print("Candidate/part", ci, pi, json.dumps(part, ensure_ascii=False))\n blob = part.get("inlineData") or part.get("inline_data")\n if blob and blob.get("data"):\n mime = blob.get("mimeType") or blob.get("mime_type")\n suffix = {"image/png":"png", "image/jpeg":"jpg", "image/webp":"webp", "audio/wav":"wav", "audio/mpeg":"mp3", "video/mp4":"mp4"}.get(mime, "bin")\n save_blob(blob["data"], suffix, "candidate-" + str(ci) + "-part-" + str(pi))\n\nwith client.chat.completions.stream(model='mistralai/mistral-small-2603',messages=[{"role":"user","content":"Explain observations and hypotheses in three sentences."}]) as stream:\n with Path("stream-events.jsonl").open("w",encoding="utf-8") as log:\n for event in stream:\n payload=event.to_dict(mode="json")\n log.write(json.dumps(payload,ensure_ascii=False)+"\\n"); log.flush()\n print(json.dumps(payload,ensure_ascii=False))\n final=stream.get_final_completion()\n save_result(final.to_dict(mode="json"),"stream-result")\njson o SSE
Conserva todas las respuestas, archivos y partes de contenido completos recibidos.
Conserva cada alternativa y su contenido, llamadas de herramientas y razonamiento. En SSE, ensambla los fragmentos incrementales por índice de alternativa/herramienta y conserva el motivo final de terminación y el uso.
Conserva los ID de solicitud y respuesta y los encabezados. No se proporciona una URL genérica para recuperar tareas de texto.
| Campo | Tipo |
|---|---|
Campochoices[].index | Tipointeger |
Campochoices[].message.content | Tipostring|null |
Campochoices[].message.tool_calls | Tipotool_call[] |
Campochoices[].message.reasoning_content | Tipostring |
Campochoices[].message.reasoning_details | Tipoobject|array |
Campochoices[].finish_reason | Tipostring|null |
Campousage | Tipoobject |
| Respuesta | Condición | Siguiente paso |
|---|---|---|
Respuesta400 · invalid_request_error | CondiciónCampos obligatorios, representación del material o valor del parámetro no válidos | Siguiente pasoCorrige los campos indicados antes de una nueva solicitud de creación. |
Ailoot Ultra mistralai/mistral-small-2603
Usa las rutas de método indicadas arriba.
mistralai/mistral-small-2603Mistral Small 4 es un modelo híbrido de texto e imágenes con capacidades de instrucciones, razonamiento y programación. Su versión de mezcla de expertos de 119B activa 6.5B de parámetros por token y admite un contexto de 256k según su desarrollador, esfuerzo de razonamiento seleccionable, JSON y llamadas a funciones.
Esta descripción cubre las capacidades del modelo. Las entradas, salidas y opciones disponibles en Ailoot se indican a continuación para el método seleccionado.
Mistral Small 4 combina seguimiento general de instrucciones, razonamiento y programación en un solo modelo multimodal. Su desarrollador lo describe como una unificación de las familias Instruct, Magistral de razonamiento y Devstral de programación. Acepta texto e imágenes y devuelve texto, con llamadas a funciones y salida JSON disponibles para aplicaciones asistidas por herramientas.
Arquitectura y funciones principales
La versión tiene 119,000 millones de parámetros totales y activa 6,500 millones por token. Su arquitectura de mezcla de expertos contiene 128 expertos, con 4 activos, y su desarrollador documenta una ventana de contexto de 256k. El número de parámetros activos y de expertos describe cómo se organiza el modelo; se distingue de la cantidad de contenido textual o visual incluido en una tarea.
El modelo proporciona funciones de instrucciones y razonamiento en el mismo checkpoint. Su desarrollador también identifica visión, seguimiento de prompts de sistema y compatibilidad multilingüe con decenas de idiomas, entre ellos inglés, francés, español, alemán, italiano, portugués, neerlandés, chino, japonés, coreano y árabe. Por ello, una instrucción de texto puede preguntar por una imagen o combinar un requisito escrito con evidencia visible, y devolver la respuesta como texto.
Una tarea visual puede proporcionar una página documental y pedir los valores relevantes para una condición identificada. Mantén legibles las etiquetas y unidades e indica si el resultado debe conservar la redacción original, resumirla o compararla con otra fuente. Una tarea de interfaz puede acompañar una captura de pantalla con el objetivo del usuario y solicitar el control visible relevante y la evidencia que respalda un siguiente paso propuesto.
Elección del modo de instrucciones o razonamiento
La ficha publicada documenta el esfuerzo de razonamiento none para una respuesta inmediata de tipo instrucción y high para razonamiento; recomienda high para prompts complejos. La elección se hace por solicitud dentro del mismo modelo Small 4. Una clasificación habitual o una reescritura breve puede tener un contrato de respuesta distinto al de un problema matemático, visual o de programación que necesite una explicación desarrollada.
Su desarrollador recomienda una temperatura de 0.7 para el esfuerzo de razonamiento high. Para none, especifica temperaturas entre 0.0 y 0.7 según la tarea. Estos ajustes describen los modos documentados y no convierten el esfuerzo de razonamiento en una garantía de resultado correcto. Define las suposiciones, el formato de salida y el material fuente relevante antes de elegir cuánto razonamiento requiere la tarea.
Para un problema desarrollado, proporciona la condición completa y solicita los pasos justificados importantes seguidos de la expresión final. Para una tarea de código, proporciona el requisito, la función afectada y una entrada concreta; solicita la implementación propuesta por separado de la explicación y los ejemplos. Las demostraciones de uso de su desarrollador incluyen seguimiento de instrucciones, una herramienta de cálculo aplicada a una imagen y razonamiento visual, e ilustran cómo el texto y la evidencia visual pueden intervenir en estas tareas diferentes.
Programación, documentos y herramientas
El modelo está orientado a exploración de bases de código y agentes de ingeniería de software, asistentes generales, comprensión documental e investigación. Una solicitud a un agente de programación puede indicar el módulo que debe cambiar, la interfaz que debe conservar y el comportamiento que debe resultar. Proporciona el código fuente relevante y la evidencia del fallo. El modelo puede proponer la siguiente operación o un cambio de código, mientras que la aplicación proporciona acceso al repositorio, ejecución y retroalimentación.
Para extraer información documental, identifica los campos requeridos y cómo representar información faltante. Un registro útil puede separar el identificador del documento, la declaración de la fuente, el requisito interpretado y la pregunta pendiente. La ficha del servicio de su desarrollador enumera salida estructurada personalizada y preguntas sobre documentos; estas últimas usan procesamiento documental y OCR para preparar texto y estructura antes del análisis con el modelo de lenguaje. Una pregunta directa sobre una imagen y un flujo documental asistido por OCR deben conservar su propia preparación de entrada.
Las llamadas a funciones requieren herramientas descritas con claridad. El modelo selecciona una función y crea argumentos; la aplicación ejecuta la operación y devuelve su resultado para la respuesta posterior. La misma lógica se aplica tanto si la tarea es una consulta como un cálculo o una operación de programación. El formato JSON organiza una respuesta, mientras que una llamada a herramienta solicita una acción externa; no deben tratarse como resultados intercambiables.
La ficha del servicio también enumera salidas predichas, prefijos de respuesta, procesamiento por lotes y conversaciones con agentes. Las salidas predichas son útiles cuando un documento o archivo de código se debe regenerar con un cambio limitado y se conoce el resto del contenido. Especifica la edición y el material que debe conservarse. La continuación de prefijo usa un inicio conocido de la respuesta, mientras que el procesamiento por lotes se refiere al envío de trabajo y no a un modo adicional de razonamiento.
Límites de contexto y edición
Planea la tarea escrita, el material visual, la conversación y la respuesta deseada según el contexto documentado de 256k. El ejemplo de uso publicado configura un contexto de 262,144 tokens, mientras que su ejemplo de generación de 1,024 tokens no constituye una capacidad máxima de salida independiente. Las fuentes consultadas no proporcionan un límite estricto de longitud de respuesta independiente para sustituir la extensión elegida para la tarea.
Small 4 tiene su propia arquitectura de mezcla de expertos de 119B y modos híbridos. No debe heredar la arquitectura densa de 128B de Medium 3.5 ni las ediciones independientes Instruct y Reasoning de Ministral 3. Su desarrollador también publica artefactos distintos de cuantización y decodificación especulativa; son artefactos de despliegue separados, no modalidades de contenido diferentes. Conserva la versión identificada Small 4 y el modo solicitado para la explicación, registro estructurado o resultado de código real.
POST /v1/messagestextjson, sse| Campo | Tipo | Requisito | Valores y límites | Predeterminado |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObligatorio | Valores y límites mistralai/mistral-small-2603 | Predeterminado— |
Campomessages | Tipomessage[] | RequisitoObligatorio | Valores y límites | Predeterminado— |
Campomessages[].role | Tipostring | RequisitoObligatorio | Valores y límites user, assistant | Predeterminado— |
Campomessages[].content | Tipostring | RequisitoObligatorio | Valores y límites | Predeterminado— |
Campomax_tokens | Tipointeger | RequisitoObligatorio | Valores y límites | Predeterminado— |
Campostream | Tipoboolean | RequisitoOpcional | Valores y límites | Predeterminadofalse |
Texto · Texto UTF-8
cadena messages[].content
| Parámetro | Contrato |
|---|---|
Parámetrocontent_type | Contratoapplication/json |
Parámetrorequired | Contratomodel, messages, max_tokens |
Parámetrooptional_controls | Contratostream |
Parámetromaterial_types | Contratotext |
Parámetrotext_file_material | ContratoLee el documento real en UTF-8 y coloca su texto en el campo input indicado o en la cadena de contenido del mensaje. |
Ciclo de vida: synchronous_or_streamed
Las referencias tarifarias no añaden opciones a la solicitud. Los parámetros admitidos se indican en el método seleccionado.
Relaciona cada cargo con las condiciones mostradas. Usa una tarifa para cada conjunto de configuraciones alternativas.
| Configuración | Tabla de tarifas | Tokens de contexto, más de | Tokens de contexto, hasta inclusive | Cargo |
|---|---|---|---|---|
| ConfiguraciónTarifas base por token | Tabla de tarifasTarifa base | Tokens de contexto, más de— | Tokens de contexto, hasta inclusiveSin límite superior | Cargo Entrada · Tokens de entrada $0.0003 / 1K tokens Salida · Tokens de salida $0.0012 / 1K tokens Entrada · Lectura de caché $0.00003 / 1K tokens Entrada · Escritura en caché — / 1K tokens Entrada · Escritura en caché, 1 hora — / 1K tokens |
| ConfiguraciónNivel 1 por longitud de la solicitud | Tabla de tarifas— | Tokens de contexto, más de0 | Tokens de contexto, hasta inclusiveSin límite superior | Cargo Entrada · Tokens de entrada $0.0003 / 1K tokens Salida · Tokens de salida $0.0012 / 1K tokens Entrada · Lectura de caché $0.00003 / 1K tokens Entrada · Escritura en caché — / 1K tokens Entrada · Escritura en caché, 1 hora — / 1K tokens |
Ailoot reserva un monto estimado antes de la solicitud. Tras obtener el resultado, liquida el cargo definitivo según el uso medido. En las respuestas en flujo, la liquidación usa el registro de uso final. Cómo funcionan la reserva y la liquidación →
{\n "model": "mistralai/mistral-small-2603",\n "max_tokens": 128,\n "messages": [\n {\n "role": "user",\n "content": "Summarize the incident report."\n }\n ],\n "stream": false\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_TEXT_FILE:?Set your actual UTF-8 document}"\nexport AILOOT_TEXT_FILE\npython3 - <<'PY_REQUEST'\nimport json, os\nfrom pathlib import Path\n\nsource_file = Path(os.environ['AILOOT_TEXT_FILE'])\nif not source_file.is_file():\n raise SystemExit('Set AILOOT_TEXT_FILE to your actual UTF-8 document')\ntext = source_file.read_text(encoding='utf-8')\nif not text.strip():\n raise SystemExit('Choose a document containing text')\npayload = {'model': 'mistralai/mistral-small-2603', 'max_tokens': 128, 'messages': [{'role': 'user', 'content': 'Summarize the incident report.'}]}\npayload['messages'][0]['content'] = 'Summarize this material and quote supporting source passages.\\n\\n' + text\nPath('request.json').write_text(json.dumps(payload, ensure_ascii=False), encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/messages \\\n -H "x-api-key: $AILOOT_API_KEY" -H 'anthropic-version: 2023-06-01' -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\n\nresult = json.loads(Path('result.json').read_text(encoding='utf-8'))\nprint(json.dumps(result, ensure_ascii=False, indent=2))\nPY_RESULT\nimport json, os\nfrom pathlib import Path\n\nsource_file = Path(os.environ['AILOOT_TEXT_FILE'])\nif not source_file.is_file():\n raise SystemExit('Set AILOOT_TEXT_FILE to your actual UTF-8 document')\ntext = source_file.read_text(encoding='utf-8')\nif not text.strip():\n raise SystemExit('Choose a document containing text')\npayload = {'model': 'mistralai/mistral-small-2603', 'max_tokens': 128, 'messages': [{'role': 'user', 'content': 'Summarize the incident report.'}]}\npayload['messages'][0]['content'] = 'Summarize this material and quote supporting source passages.\\n\\n' + text\nfrom urllib.request import Request, urlopen\nfrom urllib.error import HTTPError\n\napi_key = os.environ['AILOOT_API_KEY']\nif not api_key.strip():\n raise SystemExit('Set AILOOT_API_KEY before making a request')\nheaders = {'x-api-key': 'PLACEHOLDER_KEY', 'anthropic-version': '2023-06-01', 'Content-Type': 'application/json'}\nheaders['x-api-key'] = api_key\nrequest = Request('https://api.ailoot.ai/v1/messages', data=json.dumps(payload, ensure_ascii=False).encode('utf-8'), headers=headers, method='POST')\ntry:\n with urlopen(request, timeout=120) as response:\n raw = response.read()\n Path('response-headers.txt').write_text(str(response.headers), encoding='utf-8')\nexcept HTTPError as error:\n Path('result.json').write_bytes(error.read())\n Path('response-headers.txt').write_text(str(error.headers), encoding='utf-8')\n raise\nPath('result.json').write_bytes(raw)\nimport json\nfrom pathlib import Path\n\nresult = json.loads(Path('result.json').read_text(encoding='utf-8'))\nprint(json.dumps(result, ensure_ascii=False, indent=2))\nJSON o SSE
Conserva todas las respuestas, archivos y partes de contenido completos recibidos.
Conserva todos los bloques de contenido, las firmas de razonamiento y los ID reales de uso de herramientas. Ensambla todos los fragmentos incrementales de los bloques SSE; el primer bloque de texto no constituye la salida completa.
Conserva los ID de solicitud y respuesta y los encabezados. No se proporciona una URL genérica para recuperar tareas de texto.
| Campo | Tipo |
|---|---|
Campoid | Tipostring |
Campomodel | Tipostring |
Campocontent[] | Tipotext|thinking|tool_use|other content block |
Campostop_reason | Tipostring|null |
Campousage | Tipoobject |
| Respuesta | Condición | Siguiente paso |
|---|---|---|
Respuesta400 · invalid_request_error | CondiciónCampos obligatorios, representación del material o valor del parámetro no válidos | Siguiente pasoCorrige los campos indicados antes de una nueva solicitud de creación. |
Ailoot Ultra mistralai/mistral-small-2603
Usa las rutas de método indicadas arriba.
Ejemplo técnico en inglés
Repair a last-line parser\n\nThis Python parser loses a final line without a trailing newline: def lines(text):\n return text.split("\\n")[:-1]\nReturn a corrected function that preserves nonempty final lines, avoids an artificial last empty line when text ends in a newline and returns [] for empty text. Include tests for all three cases.A corrected Python function, a short explanation and tests for newline, no-newline and empty input.Check that the last real line is retained and that only a trailing separator’s artificial empty entry is removed.