Artículo
MiniMax M3.1 Flash: del precio por token al costo por tarea
El 19 de octubre de 2026, MiniMax anunció M3.1 Flash con acceso por API, M Plan y MiniMax Code; los pesos llegarían después, sin fecha. La cuenta, la factura y la elegibilidad en Chile no se verificaron. La decisión empresarial depende del costo por tarea aceptada, de la calidad requerida y del retrabajo que queda después de la respuesta.
MiniMax lo orienta a agentes, programación y uso del computador; aquí no reproducimos sus evaluaciones ni verificamos esas capacidades.
Del precio por token al costo por tarea
Una tarifa responde cuánto se cobra por una unidad de uso. Una tarea real puede reunir instrucciones, documentos, respuestas de herramientas y varias vueltas del modelo. Por eso, multiplicar el precio por el consumo de una sola pregunta no siempre representa el trabajo completo. Antes de comparar opciones, define qué cuenta como resultado: un intento, una tarea terminada o una respuesta que una persona revisó y aceptó. Ese denominador cambia la conversación de presupuesto.
Tres tarifas, tres unidades contables
| Tipo de token | Precio |
|---|---|
| Entrada | US$0,15 |
| Salida | US$0,60 |
| Entrada en caché | US$0,015 |
La entrada agrupa las instrucciones y el contexto que recibe el modelo; la salida, el texto que genera. Una caché puede cambiar el costo de entrada solo para la parte elegible. Un flujo de respuestas largas tendrá una mezcla distinta a otro que procesa mucho contexto y responde poco. Mantén las categorías separadas.
El precio unitario no revela el volumen de una implementación. Lo determinan la longitud de documentos, el historial reenviado y el tamaño de las respuestas. Estima con registros representativos y prueba un caso liviano y otro exigente. Sin mediciones, muestra los supuestos como rango editable, no como presupuesto.
La cuenta de una tarea tiene varias capas
Una hoja sencilla separa tokens de entrada, salida y entrada facturada como caché. Luego reúne todos los intentos atribuibles a una entrega. Anota aparte cualquier gasto en búsquedas, ejecución de código u otros servicios, si el proceso los usa, y el tiempo de revisión humana cuando sea parte de la decisión.
- Consumo: tokens recibidos y generados.
- Proceso: intentos, correcciones y herramientas.
- Resultado: entregas que cumplen criterios acordados.
Indicador de decisión: gasto atribuible dividido por resultados aceptados.
Separar gasto y valor muestra por qué una tarifa menor puede implicar más tiempo de edición. Un resultado aceptado tampoco garantiza valor: puede tener poco impacto o no integrarse al proceso. Declara la unidad de evaluación y la pauta de aceptación para comparar alternativas.
Ejemplo ficticio: cien intentos, ochenta aceptados
Supuesto editorial, no resultado de una prueba: una empresa ejecuta 100 intentos. Cada uno consume 20.000 tokens de entrada y genera 3.000 de salida; una persona acepta 80 resultados. La aritmética de volumen y costo se resume así:
100 × (20.000 entrada + 3.000 salida); 2.000.000 entrada y 300.000 salida. 2 × US$0,15 + 0,3 × US$0,60 = US$0,48; US$0,48 ÷ 80 = US$0,006.
La división del subtotal por las entregas aceptadas produce el indicador del escenario. No es una medición de M3.1 Flash ni una promesa de gasto empresarial. Si cambia el contexto, la cantidad de intentos o la proporción aceptada, cambia el resultado. Mantén visibles esas entradas para ajustar el cálculo.
Este cálculo excluye herramientas, impuestos, reintentos adicionales y tiempo de revisión. Si esos rubros importan, agrégalos como líneas separadas y muestra tanto el subtotal del modelo como el total del proceso. Una factura posterior puede reemplazar el supuesto inicial sin ocultar qué parte del gasto vino de cada componente.
La caché se modela como escenario
Si las solicitudes repiten contexto, la caché podría cambiar el subtotal. Confirma qué parte califica y qué refleja el registro de uso; una repetición visible no demuestra que el servicio la facture como caché. Sin esa lectura, trátala solo como escenario.
Hipótesis, no ahorro observado: se mantiene el ejemplo anterior y se supone que la mitad de los tokens de entrada se factura como caché:
Mitad de 2M de entrada normal y mitad en caché, más 0,3M de salida: US$0,15 + US$0,015 + US$0,18 = US$0,345; elegibilidad y hits no garantizados.
Ese total es una operación aritmética bajo una condición explícita, no un ahorro disponible. Confirma el reporte y la facturación de esos tokens antes de usarlo como proyección. Sin una lectura verificable, conserva el escenario sin caché como referencia.
Una prueba con datos sintéticos valida la fórmula, pero no demuestra el patrón de caché de una cuenta real. En un piloto, guarda por separado el supuesto y el consumo observado; actualiza la estimación cuando tengas una fuente verificable de uso.
Calidad aceptada y retrabajo cambian el denominador
Antes del piloto, define qué significa “aceptado”. En una clasificación puede ser asignar la categoría correcta y señalar los casos inciertos. En un resumen puede ser preservar los datos relevantes, enlazar fuentes y no inventar conclusiones. Una pauta aplicable por más de una persona permite comparar resultados sin depender de “suena bien”.
Registra cada intento como aceptado, corregido, rechazado o detenido por una persona. Divide el gasto atribuible de todos los intentos por las entregas que pasan la pauta. Añade el tiempo de edición si quieres evaluar ahorro operativo. Si un equipo corrige cada respuesta durante varios minutos, limitarse al precio de tokens deja fuera una parte importante del costo.
Compara las opciones con la misma muestra y las mismas reglas. Incluye casos frecuentes y casos que suelen fallar; además del promedio, cuenta errores críticos. Una media favorable puede ocultar una omisión decisiva o un formato que un sistema posterior no puede leer. Las comparaciones promocionales de velocidad o ahorro son preguntas para comprobar con tareas equivalentes, no previsiones de presupuesto.
Acceso por servicio y pesos requieren decisiones distintas
Para cualquier modalidad, verifica qué permite la cuenta, cómo se cobra, qué límites aplican y quién administra el acceso. El nombre de un producto no revela por sí solo la política empresarial, la región habilitada, la retención de datos ni las integraciones. Esas preguntas requieren documentación vigente de la cuenta y revisión contractual.
Un modelo hospedado y unos pesos descargables representan opciones técnicas distintas. Un servicio puede simplificar la prueba inicial, aunque incorpora dependencia del proveedor. Una descarga requeriría evaluar licencia, hardware, operación y mantenimiento. Antes de planificar una instalación local, confirma que los pesos y sus condiciones estén disponibles en una fuente oficial; la posibilidad futura no sirve como base para una decisión presente.
Una página pública tampoco demuestra que una cuenta pueda contratar el servicio desde un país específico. Para resolver elegibilidad y forma de pago, consulta el canal oficial o la consola de cuenta y conserva la respuesta con fecha y condiciones aplicables. La fuente primaria de los datos anteriores es MiniMax: anuncio oficial, 19 octubre 2026.
Un piloto pequeño puede responder preguntas concretas
Empieza con una tarea reversible, datos sintéticos o autorizados y una salida que una persona revise antes de usarla. Define objetivo, ejemplos, pauta de aceptación y gasto máximo. Excluye credenciales y acciones productivas. Si la prueba necesita herramientas, limita los permisos y evita que una respuesta pueda cambiar cuentas, sistemas de clientes o canales públicos.
Usa la misma muestra en cada alternativa y registra instrucciones, resultados, tiempos, consumo y revisión. Conserva los rechazos para medir retrabajo. Si hay herramientas, limita permisos y exige aprobación humana antes de cualquier efecto externo.
Define de antemano cómo termina el piloto: por ejemplo, una aceptación mínima, un máximo de errores críticos y un costo límite por resultado. El equipo fija esos umbrales según el riesgo. Si una dimensión no se puede medir, declárala desconocida y restringe la decisión. Una respuesta correcta aislada o una prueba sintética muestran posibilidad, pero no prueban costo sostenido ni desempeño con datos reales.
Una regla de decisión que el equipo pueda repetir
Resume cada piloto con muestra, pauta, volumen, tarifa, gasto, tiempo de revisión, aceptados y fallas críticas. Añade fecha y fuente; separa observaciones, cálculos y supuestos. Así podrás actualizarlo sin presentar hipótesis como hechos.
Compara el costo por resultado aceptado con el proceso actual y otras opciones usando las mismas tareas y reglas. Incluye privacidad, retención, disponibilidad regional y esfuerzo de integración cuando corresponda, con evidencia para cada punto. No reduzcas la decisión a una cifra: importan el costo, la fiabilidad y las condiciones de uso para esa tarea y ese riesgo.
Avanza por etapas: confirma acceso y condiciones, ejecuta un piloto limitado, lee consumo y calidad, y después estima una operación mayor. Si falta una factura, elegibilidad o medición de aceptación, anótala como pendiente. La pregunta útil no es solo cuánto vale un token, sino cuánto cuesta producir un resultado aceptable bajo las condiciones del equipo.
Para complementar la revisión de resultados, lee METR: revisar agentes exige proteger la evidencia.
Continúa aprendiendo y comparte tus pruebas en la Comunidad de IA.
