GPT-4.1 mini es el modelo pequeño de la familia GPT-4.1 que OpenAI presentó el 14 de abril de 2025. Recibe texto e imágenes y genera texto. Admite llamadas a funciones y salidas estructuradas, por lo que se puede considerar para funciones concretas como extraer campos, ordenar notas o consultar información de varios documentos.
En 2026 todavía tiene sentido evaluarlo para una tarea bien definida. Según los precios oficiales de la API de OpenAI, consultados el 30 de octubre de 2026, sus tarifas Standard de entrada y salida de texto son inferiores a las del modelo insignia más reciente GPT-6 Astra. Eso permite incluirlo entre los candidatos para una función pequeña; no demuestra que sea más barato que cualquier modelo nuevo ni que reduzca el trabajo total. La revisión de errores también cuenta. Esta comparación no representa lo que facturó Crazyrouter en la prueba que explico aquí.
Lo probé organizando documentos de un proyecto ficticio mediante la API de Crazyrouter. Pudo combinar un cambio de responsable con otro de fecha y conservar una condición del documento original. Sin embargo, cuando encontró dos fechas incompatibles, dejó un estado que no reflejaba la necesidad de confirmarlas. Para una aplicación que convierte notas en tareas, ambas observaciones importan.
Los datos y las llamadas son del 30 de octubre de 2026. El experimento se hizo con documentos, instrucciones y respuestas en chino simplificado; este artículo no mide el desempeño en español.
Qué pedirle a GPT-4.1 mini antes de automatizar una lista
La documentación de OpenAI indica una ventana de contexto de 1.047.576 tokens, una salida máxima de 32.768 tokens y un corte de conocimiento del 1 de junio de 2024. La ventana amplia permite reunir fuentes relacionadas en una solicitud. No garantiza que cada detalle se interprete correctamente, ni equivale a una cantidad fija de palabras.
Para empezar, elegiría una salida que se pueda contrastar: responsable, fecha límite y condición de aceptación, con los documentos que respaldan cada tarea. Así se puede distinguir entre encontrar un dato y aplicar bien una modificación. Pedir únicamente «resume estas notas» deja más trabajo pendiente si lo que necesita la aplicación es una lista actualizada.
Explicar código o interpretar una imagen son otras posibilidades descritas para el modelo, pero no formaron parte de esta prueba. Tampoco ejecuté herramientas externas. Aunque el modelo proponga una llamada a una función, es la aplicación la que debe ejecutarla y controlar sus efectos.
Primera llamada: una nota con respuesta conocida
Usé la interfaz Chat Completions compatible con OpenAI de Crazyrouter. Existe también el acceso por la API de OpenAI; las direcciones de esta sección corresponden al canal que utilicé. Para probarlo, crea una cuenta o inicia sesión, genera una clave API y comprueba la disponibilidad del modelo y las condiciones actuales. El catálogo de modelos de conversación de Crazyrouter sirve como punto de consulta; es un catálogo general, no una medición de calidad.
Base URL: https://api.crazyrouter.com/v1
Model: gpt-4.1-mini
API key: leer tu clave Crazyrouter desde una configuración segura
Si tu cliente permite definir una conexión compatible con OpenAI, introduce esos valores en los campos correspondientes. Para HTTP directo, envía un POST a https://api.crazyrouter.com/v1/chat/completions, con autenticación Bearer y Content-Type: application/json. Si el cliente añade la ruta por su cuenta, utiliza solo la Base URL. No incluyas la clave en código público ni en capturas.
Este cuerpo ilustra una primera solicitud con una nota y su modificación. Está escrito en español para explicar el procedimiento; no es el prompt original del experimento y no lo he enviado a la API.
{
"model": "gpt-4.1-mini",
"messages": [
{
"role": "system",
"content": "Devuelve un objeto JSON con owner, deadline y sources. Usa una fecha ISO. Aplica solo el cambio indicado y conserva lo demás. No inventes datos; usa null si falta información."
},
{
"role": "user",
"content": "Nota A: Marta prepara el informe para el 9 de noviembre de 2026. Nota B, aprobada y vigente: la fecha del informe cambia al 12 de noviembre de 2026; la responsable sigue siendo la misma."
}
],
"temperature": 0,
"max_tokens": 6000,
"stream": false,
"response_format": { "type": "json_object" }
}
El texto generado se obtiene en choices[0].message.content. Antes de conectarlo a otra función, comprobaría que no esté vacío ni truncado, que se pueda interpretar como JSON y que mantenga a Marta como responsable con la fecha del 12 de noviembre. Es el resultado esperado de este ejemplo, no una respuesta observada del modelo.
Para aislar problemas, puedes empezar solo con la nota A y añadir la B después. Si no recibes contenido, revisa la conexión y la respuesta del servicio. Si sí recibes contenido pero los campos no coinciden con las notas, ya estás ante un problema de resultado, no ante una prueba suficiente de que la función está lista.
La prueba completa: decidir qué cambios están vigentes
En el experimento real preparé 51 documentos cortos sobre doce tareas. Había versiones iniciales, cambios aprobados, borradores, discusiones y registros antiguos que reutilizaban los mismos identificadores. Los nombres y los hechos eran ficticios. Cada solicitud completa registró 26.430 tokens de entrada, lejos del máximo de contexto.
Pedí una fila por tarea con id, owner, deadline, status, acceptance, sources y conflicts. El momento de referencia del escenario era el 30 de octubre de 2026 a las 18:00. Solo se debían aplicar cambios ya vigentes, sustituir los campos expresamente modificados y conservar el resto. Los borradores y los documentos de otros proyectos no podían sobrescribir la tarea actual.
También fijé dos reglas para lo incierto: dejar null cuando faltara información y conservar las alternativas cuando hubiera decisiones incompatibles sin prioridad definida. En el segundo caso, el estado debía pasar a «por confirmar».
Esto evita una simplificación habitual: tratar el documento más reciente como si contuviera toda la verdad. T06 tenía una modificación aprobada cuya vigencia empezaba el 2 de noviembre. En las dos respuestas, el modelo mantuvo al responsable anterior y la condición de devolver los primeros 20 resultados, sin adelantar la nueva cantidad de 50.
Lo que sí resolvió: una tarea repartida entre tres documentos
El documento B01 de T01 asignaba el trabajo a Zhou Ning para el 4 de noviembre y exigía conservar registros de auditoría durante 180 días. C01 cambiaba la fecha al 9 de noviembre. C02 transfería la responsabilidad a Zheng Yan y mantenía las demás condiciones.
El modelo devolvió a Zheng Yan, la fecha 2026-11-09 y la conservación de 180 días. También incluyó B01, C01 y C02 como fuentes. Los dos intentos completos coincidieron en estos datos.
Figura 1. Diagrama que preparé con los documentos ficticios y la primera respuesta completa. Conserva los valores chinos y las explicaciones en inglés; el texto de esta sección los explica en español. No es una captura de una aplicación. Las relaciones entre campos y fuentes proceden de mi revisión; la API devolvió las fuentes de la tarea como conjunto.
Ahí hay una función aprovechable: reunir cambios parciales sin perder lo que sigue vigente. No se trata solo de redactar un resumen agradable. La salida contiene valores concretos que se pueden contrastar y después utilizar, si pasan las comprobaciones necesarias. El experimento no incluyó una interfaz que permitiera abrir automáticamente la cita exacta de cada campo.
Lo que dejaría pendiente antes de importar
T02 tenía dos decisiones válidas, con fechas del 10 y del 12 de noviembre. Ninguna anulaba a la otra. GPT-4.1 mini devolvió deadline: null y conservó las dos fechas con sus fuentes, pero dejó status: "待办", que significa «por hacer». El valor exigido era 待确认, «por confirmar».
Además, conflicts debía ser un arreglo de cadenas de texto y contenía un arreglo anidado. La respuesta seguía siendo JSON válido: poder leerla con un parser no garantizaba que tuviera los tipos ni el estado correctos.
Figura 2. Casos de la primera respuesta guardada, con valores originales en chino y explicaciones en inglés. T03 requiere pedir información; T02 requiere resolver decisiones existentes. Las acciones sugeridas son propuestas, no resultados de una corrección automática. El estado erróneo y el arreglo anidado no se repararon.
Antes de importar una fila, comprobaría los tipos, su correspondencia con las fuentes y la coherencia entre campos. Si las fuentes mantienen una fecha en disputa, el estado no debería presentar la tarea como una asignación normal ya definida. Esa comprobación necesita información sobre el conflicto, no solo mirar si deadline está vacío.
T03 muestra por qué: responsable y fecha eran null porque no estaban en los documentos, y no porque hubiera dos decisiones enfrentadas. La aplicación debería ayudar a formular la siguiente pregunta correcta. No construí esa pantalla ni medí un proceso de aprobación; es una decisión de diseño que se desprende de las respuestas observadas.
Qué permiten concluir estas llamadas
Preparé las respuestas esperadas antes de llamar al modelo. Después comparé los campos, las fuentes y la estructura con un programa y revisé los documentos. Cada uno de los dos intentos completos obtuvo 47/48 campos principales correctos, 12/12 filas con las fuentes requeridas y 11/12 filas con la estructura solicitada. Por T02, ninguno cumplió todos los requisitos.
Hubo una prueba previa con tres tareas y dos solicitudes completas sobre las mismas doce. Fueron tres llamadas de generación en total, sin solicitudes de reparación ni cambios manuales en las respuestas. No son 24 tareas independientes, ni una estimación de estabilidad a largo plazo.
Los parámetros de las solicitudes completas fueron temperature=0, max_tokens=6000, stream=false y response_format=json_object. No envié un JSON Schema estricto. Por tanto, este fallo de tipos no demuestra un fallo de la imposición de esquemas estrictos. Tampoco probé imágenes, ejecución de herramientas, el límite de contexto ni documentos en español.
Finalmente, hay que considerar la vida útil del modelo. El aviso de OpenAI del 14 de octubre de 2026 programa la retirada de gpt-4.1-mini-2025-04-14 de su API para el 14 de enero de 2027. Una llamada exitosa a través de Crazyrouter no permite deducir su calendario futuro de disponibilidad.
Antes de financiar una prueba propia, revisaría las condiciones de uso, la facturación y la disponibilidad del canal. Después conservaría unas pocas notas con respuestas conocidas: un cambio válido, un dato ausente y un conflicto sin resolver. Ese pequeño conjunto permite evaluar otro modelo sin perder el criterio de la función. Si ya conviertes notas en tareas, ¿qué señal utilizas para impedir que una decisión pendiente termine como una tarea confirmada?