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": null, "copy_sha256": null, "copy_source": null, "html_sha256": "af0aea1d0e73f9d5a4b7585b53ff7574b5bbab4189ec3970d983d383dfdcf93f", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "es-mx", "methods": [ { "html": "mistralai/mistral-small-2603:batchMistral 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/batchestexttext| Campo | Tipo | Requisito | Valores y límites | Predeterminado |
|---|---|---|---|---|
Campoendpoint | Tipostring | RequisitoObligatorio | Valores y límites /v1/chat/completions | Predeterminado— |
Campomodel | Tipostring | RequisitoObligatorio | Valores y límites mistralai/mistral-small-2603:batch | Predeterminado— |
Camporequests | Tipobatch_item[] | RequisitoObligatorio | Valores y límites Número mínimo de elementos: 1 | Predeterminado— |
Camporequests[].custom_id | Tipostring | RequisitoObligatorio | Valores y límites | Predeterminado— |
Camporequests[].body.messages | Tipomessage[] | RequisitoObligatorio | Valores y límites | Predeterminado— |
Campocompletion_window | Tipostring | RequisitoOpcional | Valores y límites 24h | Predeterminado— |
Campoprovider | Tipoobject|null | RequisitoOpcional | Valores y límites | Predeterminado— |
Camporequests[].body.model | Tipostring | RequisitoOpcional | Valores y límites mistralai/mistral-small-2603:batch, mistralai/mistral-small-2603 | Predeterminado— |
Campoprovider.only | Tipostring[] | RequisitoOpcional | Valores y límites mistral | Predeterminado— |
Campoprovider.allow_fallbacks | Tipoboolean|null | RequisitoOpcional | Valores y límites false, null | Predeterminado— |
| Parámetro | Contrato |
|---|---|
Parámetrocontent_type | Contratoapplication/json |
Parámetrorequired | Contratoendpoint, model, requests |
Parámetromaterial_types | Contratotext |
Parámetrorepresentation | Contratorequests[] en línea; cada elemento tiene custom_id y body |
Parámetrorequest_endpoint_profile | Contrato/v1/chat/completions |
Parámetrofile_material | ContratoQuien realiza la llamada puede leer localmente el JSONL UTF-8 real e incorporarlo a requests[]. No se utiliza el campo purpose para cargas, ni input_file_id ni referencias a archivos. Si falta el material del cliente o está vacío, la preparación se detiene antes del POST. |
Parámetroserialization_order | Contratoendpoint, model, provider (si se proporciona), completion_window (si se proporciona), requests al final |
Parámetrooptional_controls | Contratoprovider.only, provider.allow_fallbacks, completion_window |
Parámetroschema_scope | ContratoCuerpos de solicitudes de texto de Chat Completions dentro de la estructura Batch en línea documentada. |
Ciclo de vida: asynchronous
GET /v1/batches/{operation_id} · El response.id real de la respuesta de creación original; el mismo usuario, clave y grupo
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.00015 / 1K tokens Salida · Tokens de salida $0.0006 / 1K tokens Entrada · Lectura de caché $0.000015 / 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.00015 / 1K tokens Salida · Tokens de salida $0.0006 / 1K tokens Entrada · Lectura de caché $0.000015 / 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\nfrom pathlib import Path\nbody=json.loads('{"endpoint":"/v1/chat/completions","model":"mistralai/mistral-small-2603:batch","requests":[{"custom_id":"req-0001","body":{"messages":[{"role":"user","content":"Hello!"}],"max_tokens":16}}]}')\nPath("batch-request.json").write_text(json.dumps(body,ensure_ascii=False),encoding="utf-8")\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/batches \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @batch-request.json -D batch-response-headers.txt -o batch-create-response.json\nimport json, os\nfrom pathlib import Path\nfrom urllib.request import Request, urlopen\n\ndef prepare_requests(customer_path):\n path = Path(customer_path)\n if not path.is_file(): raise ValueError("Customer JSONL file is missing")\n items = [json.loads(line) for line in path.read_text(encoding="utf-8").splitlines() if line.strip()]\n if not items: raise ValueError("Customer JSONL contains no requests")\n ids = set()\n for item in items:\n if set(item) != {"custom_id", "body"}: raise ValueError("Each item needs custom_id and body")\n cid = item["custom_id"]\n if not isinstance(cid, str) or not cid.strip() or cid in ids: raise ValueError("custom_id must be nonempty and unique")\n ids.add(cid)\n if not isinstance(item["body"], dict) or not item["body"].get("messages"): raise ValueError("Supply actual text messages")\n supplied_model = item["body"].get("model")\n if supplied_model is not None and supplied_model not in ['mistralai/mistral-small-2603:batch', 'mistralai/mistral-small-2603']: raise ValueError("body.model must be an exact documented caller or wire ID")\n return {"endpoint":"/v1/chat/completions", "model":"mistralai/mistral-small-2603:batch", "requests":items}\n\nif __name__ == "__main__":\n material = os.environ.get("AILOOT_BATCH_REQUESTS_JSONL", "")\n if not material: raise SystemExit("Set AILOOT_BATCH_REQUESTS_JSONL to your actual customer file")\n body = prepare_requests(material)\n key = os.environ.get("AILOOT_API_KEY", "")\n if not key: raise SystemExit("Set AILOOT_API_KEY")\n request = Request("https://api.ailoot.ai/v1/batches", data=json.dumps(body, ensure_ascii=False).encode("utf-8"), headers={"Authorization":"Bearer " + key, "Content-Type":"application/json"}, method="POST")\n with urlopen(request) as response:\n raw = response.read()\n Path("batch-create-response.json").write_bytes(raw)\n print(raw.decode("utf-8"))\nimport json\nfrom pathlib import Path\nraw = Path("batch-status-response.json").read_bytes()\nresponse = json.loads(raw)\nif response.get("status") != "completed":\n raise SystemExit("Keep the original operation; read its status without resubmitting")\nresults = response.get("results")\nif not isinstance(results, list) or not results:\n raise SystemExit("Preserve the original response; completed results are missing")\nPath("batch-results.jsonl").write_text("".join(json.dumps(item, ensure_ascii=False) + "\\n" for item in results), encoding="utf-8")\n# Preserve batch-status-response.json with aggregate usage and every result/error.\nJSON de results[].response.body en línea
GET /v1/batches/{operation_id}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\nBATCH_OPERATION_ID="$(python3 - <<'PY_ID'\nimport json\nfrom pathlib import Path\nfrom urllib.parse import quote\nresponse = json.loads(Path("batch-create-response.json").read_text(encoding="utf-8"))\noperation = response.get("id")\nif not isinstance(operation, str) or not operation: raise SystemExit("No actual original operation ID; preserve the response and do not resubmit")\nprint(quote(operation, safe=""))\nPY_ID\n)"\ncurl --fail-with-body --silent --show-error "https://api.ailoot.ai/v1/batches/$BATCH_OPERATION_ID" \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -o batch-status-response.json\nConserva todas las respuestas, archivos y partes de contenido completos recibidos.
Conserva el JSON completo del estado original, cada result/custom_id y el cuerpo completo de la respuesta o del error. Guarda results[] completados como JSONL sin filtrar.
Conserva el ID de la operación original. La respuesta 503 result_pending_check incluye X-Should-Retry:false; nunca vuelvas a enviar un lote original cuyo resultado sea desconocido.
| Campo | Tipo |
|---|---|
Camporesults[].custom_id | Tipostring |
Camporesults[].response.body.choices[].message.content | Tipostring|null |
Camporesults[].error | Tipoobject|null |
Campousage | Tipoobject|null |
Campoid | Tipostring |
Campomodel | Tipostring |
Campoendpoint | Tipostring |
Campostatus | Tipostring |
Camporequest_counts | Tipoobject |
Camporesults[].id | Tipostring |
Camporesults[].response.status_code | Tipointeger |
Camporesults[].response.request_id | Tipostring |
| Respuesta | Condición | Siguiente paso |
|---|---|---|
Respuesta400 · invalid_request_error | CondiciónLa estructura en línea documentada no es válida, hay claves duplicadas, existe un problema con la identidad de los elementos o hay un conflicto entre las capacidades configuradas del modelo. | Siguiente pasoCorrige los campos indicados antes de realizar cualquier nuevo envío. |
Respuesta401 · authentication_error | CondiciónClave de API no válida. | Siguiente pasoUsa la clave de Ailoot autorizada. |
Respuesta403 · permission_error | CondiciónGrupo de Batch no disponible. | Siguiente pasoVerifica los permisos de la clave y el grupo. |
Respuesta422 · invalid_request_error | CondiciónBatch usa facturación contra saldo; se rechazan las solicitudes de creación con una suscripción. | Siguiente pasoUsa el grupo autorizado con facturación contra saldo. |
Respuesta422 · price_unavailable | CondiciónNo se puede cotizar la entrada de Batch. | Siguiente pasoConserva la respuesta; usa la entrada documentada para la familia. |
Respuesta402 · billing_error | CondiciónReserva de Batch no disponible. | Siguiente pasoResuelve los requisitos de admisión antes de realizar una nueva solicitud. |
Respuesta503 · price_unavailable | CondiciónPrecio del método Batch o tarifas nativas no disponibles. | Siguiente pasoConserva la respuesta; no sustituyas los precios. |
Respuesta503 · api_error | CondiciónLa ruta exacta del proveedor no está disponible. | Siguiente pasoConserva la respuesta para reparar la ruta. |
Respuesta503 · result_pending_check | CondiciónEl resultado original requiere una revisión; X-Should-Retry:false. | Siguiente pasoConserva el operation_id/id original y consulta su estado; nunca repitas el POST original. |
Respuesta404 · not_found | CondiciónLa operación de consulta de estado de Batch no existe o pertenece a otra identidad. | Siguiente pasoUsa el id original exacto y el mismo usuario, clave y grupo. |
Ailoot Ultra mistralai/mistral-small-2603:batch
Usa las rutas de método indicadas arriba.