¿Necesitamos razonamiento profundo? Por qué Fable 5.1 y Astra parecen inteligentes y Gemini 3.8 Flash parece tonto

TL;DR

• Estás comparando dos modelos insignia con uno de uso general. Fable 5.1 y GPT-6 Astra (septiembre de 2026, $10 de entrada /$50 de salida por millón de tokens) frente a Gemini 3.8 Flash (septiembre de 2026, $0.75 /$3.75 de lanzamiento). Distinto precio, distinto trabajo.
• El modelo insignia de Google es antiguo. Al 18 de septiembre de 2026, el modelo Pro publicado sigue siendo Gemini 3.1 Pro Preview, de febrero de 2026. Flash es reciente. Pro lleva siete meses sin renovarse.
• Pensar más suele perjudicar. ACL Findings 2026 encontró un patrón claro: las tareas fáciles empiezan a fallar después de ~2K tokens de razonamiento y las difíciles después de ~8K. A partir de ~7K tokens, los modelos cambian más respuestas correctas por incorrectas que al revés.
• Pruébalo tú mismo más abajo. Un prompt para corregir un bug, tres respuestas: una corrección rápida, una lenta que cuesta 10x por el mismo resultado y una cadena larga que abandona la respuesta correcta a fuerza de darle vueltas.
• Una nueva opción: omitir el razonamiento por completo. Jev de TypeSafe AI (acceso anticipado, 15 de septiembre de 2026) devuelve decisiones tipadas —opción, puntuación, probabilidad de sí/no— en ~100 ms a $0.042 por millón de tokens de entrada. Sin chat. Sin ensayos. Solo un número que tu código puede usar.
• Mi opinión: no compres tokens. Prueba los niveles de esfuerzo con una muestra pequeña de tus propias tareas. Identifica qué tipos necesitan max y cuáles funcionan bien con low. Envía el resto a verificaciones económicas o a Jev.

Qué aprenderás aquí

• Por qué la comparación entre Fable/Astra y Flash es engañosa, en términos sencillos
• Cómo responde un modelo al mismo prompt con esfuerzo low y max, con tokens y costo
• Cómo se ve una traza de razonamiento y cómo el exceso de análisis puede cambiar una respuesta correcta por una incorrecta
• Qué te venden realmente Fable 5.1 y Astra (un presupuesto de razonamiento, no magia)
• Qué es Jev, cuándo supera a un modelo de chat y cómo llamarlo
• Cómo probar los niveles de esfuerzo con una muestra pequeña para dejar de adivinar

Dos modelos insignia y uno de uso general

Hazles la misma pregunta difícil a tres modelos. Fable 5.1 piensa con cuidado. Astra piensa durante mucho tiempo. Flash responde rápido y de forma superficial.

Esa descripción es real. La conclusión que la gente extrae de ella es incorrecta.

Al 18 de septiembre de 2026, estos tres modelos no son equivalentes:

Fuentes: Descripción general de Fable 5.1, documentación de esfuerzo, lanzamiento de Astra de OpenAI, blog de Gemini 3.8 Flash, página de modelos Gemini (consultada el 18 de septiembre de 2026), página de Gemini 3.1 Pro.

Hay dos hechos más importantes que cualquier tabla de benchmarks.

Primero, la diferencia de precio es enorme. Fable y Astra cuestan alrededor de 13x la tarifa de lanzamiento de Flash. Que un modelo de $10/$50 razone más que uno de $0.75/$3.75 ante el mismo prompt es exactamente lo previsto. No demuestra que Flash sea tonto.

Segundo, el modelo insignia de Google está desactualizado. La página de Gemini del 18 de septiembre de 2026 todavía presenta 3.1 Pro y 3.1 Deep Think de febrero, además de «3.5 Pro próximamente». El propio blog de Google del 2 de septiembre dice que Flash es la línea que avanza rápido: tres lanzamientos de Flash en seis semanas.

Las tablas de los proveedores reflejan esto. Flash iguala o supera a los modelos insignia en tareas acotadas y bien definidas —programación, finanzas, asuntos legales— y se queda atrás en trabajo autónomo abierto. Un ejemplo: Terminal-Bench 4.0 (trabajo autónomo general) muestra Astra con 57.9% y Fable 5.1 con 55.8% frente a Flash con 19.1% en las tablas de septiembre publicadas por los proveedores. En el acotado DeepSWE v1.1, Flash alcanza 73.7–73.8%, muy cerca de Astra con 74.1%.

Considera cada dato como una cifra reportada por el proveedor, no verificada de manera independiente. Los harnesses de prueba varían según el proveedor, así que las cifras exactas no son comparables. Sin embargo, el patrón se mantiene: lo barato y rápido gana en tareas acotadas; lo caro y lento gana en trabajo autónomo abierto.

Criterio editorial: la impresión de que es «tonto» viene de tres diferencias acumuladas: categoría de precio (uso general frente a insignia), antigüedad (septiembre frente a febrero) y tipo de tarea (acotada frente a abierta). Corrige la comparación antes de culpar al modelo.

Mira la diferencia: un prompt, tres respuestas

Basta de teoría. Aquí está el mismo prompt para corregir un bug, ejecutado de tres maneras. Este es el patrón que verás en tus propios logs.

El prompt (un bug rutinario de reintentos):

Fix this Python retry helper. It should retry 3 times with
exponential backoff (1s, 2s, 4s), only retry on TimeoutError,
and stop retrying on ValueError.

def call_api(fn):
    for i in range(5):
        try:
            return fn()
        except Exception:
            continue
    return None

Respuesta 1 — esfuerzo bajo: rápida y correcta.

def call_api(fn):
    import time
    delays = [1, 2, 4]
    for attempt, delay in enumerate(delays + [None]):
        try:
            return fn()
        except ValueError:
            raise
        except TimeoutError:
            if attempt == 3:
                raise
            time.sleep(delay)

Tokens: ~200 de razonamiento + ~150 de salida. Costo en un modelo insignia de $10/$50: alrededor de $0.01. Tiempo: ~12 segundos en una prueba secundaria. Correcta.

Respuesta 2 — esfuerzo máximo: lenta y también correcta.

El modelo vuelve a deducir las matemáticas del backoff, debate entre tenacity y bucles hechos a mano, revisa los casos límite dos veces y llega a la misma corrección.

Tokens: ~5,700 de razonamiento + salida. Costo: alrededor de $0.30. Tiempo: ~105 segundos. La misma respuesta correcta. Aproximadamente 10x el costo y 8x la espera, sin obtener nada adicional.

Esto coincide con dos pequeñas pruebas secundarias en Astra (ComputingForGeeks y SynthorAI, septiembre de 2026): de low a max pasó de ~213 a ~5,684 tokens de razonamiento con la misma respuesta correcta.

Respuesta 3 — demasiado razonamiento: lenta e incorrecta.

En tareas fáciles, las cadenas largas suelen convertir una respuesta correcta en una incorrecta. La traza se ve así (resumen abreviado, no una cadena de pensamiento en bruto):

Step 1: Correct fix drafted (retry only TimeoutError, 1s/2s/4s).
Step 2: "Wait — should ValueError also retry? What if the API wraps
  timeouts as ValueError? Let me handle both..."
Step 3: Rewrites to retry on all exceptions. Breaks the spec.
Final: returns the buggy version with extra comments.

Ese es, en miniatura, el resultado de ACL Findings 2026: a partir de cierto punto, el razonamiento adicional genera más cambios de respuestas correctas a incorrectas que a la inversa. Las tareas fáciles llegan a ese punto cerca de ~2K tokens. Las difíciles, cerca de ~8K. Más allá de ~7K, los cambios perjudiciales superan a los beneficiosos.

Cómo escribir un prompt para cada nivel:

# For routine work — ask for short reasoning explicitly:
"Fix the retry helper. Reply with corrected code + 3 bullet
notes max. Do not explore alternatives."

# For hard work — ask for checks, not length:
"Fix the retry helper. Before answering, list 2 failure modes
of your fix and how you ruled each out. Keep it under 200 words
plus code."

Los prompts cortos como el primero mantienen a low enfocado. El segundo ayuda con high sin invitar a una divagación de 6K tokens. La longitud no es calidad. Las comprobaciones sí aportan calidad.

Cuándo perjudican más tokens

La teoría popular dice: más razonamiento, respuesta más inteligente. Una investigación de 2026 lo midió y encontró una curva con un pico. Un poco de razonamiento ayuda. Demasiado perjudica.

ACL Findings 2026 — «Cuando pensar más perjudica» (artículo):

• Los problemas fáciles empiezan a fallar cerca de los 2K tokens de razonamiento. Los difíciles, cerca de los 8K.
• Después de ~7K tokens, los cambios de correcto a incorrecto superan a los de incorrecto a correcto.
• Detenerse temprano conserva ~97% de la precisión máxima con ~60% del cómputo.

ICLR 2026 — OptimalThinkingBench (artículo) probó 33 modelos de dos maneras: preguntas sencillas (¿analizan demasiado los modelos?) y tareas difíciles (¿razonan menos de lo necesario?). Resultado: los modelos de razonamiento analizan demasiado las preguntas fáciles sin obtener beneficios. Los modelos sin razonamiento no piensan lo suficiente en las tareas difíciles. Ningún modelo acierta en ambos casos. La puntuación más alta fue la de o3, con 71.1%.

Trabajos anteriores observaron el mismo pico: Cuando más es menos (arXiv 2502.07266) y Hacia un escalado óptimo del razonamiento (arXiv 2502.18080). Los modelos más capaces necesitan cadenas más cortas: un «sesgo hacia la simplicidad» que puedes ver en los resultados de Fable Low (Fable Low vs Opus Low vs Sonnet Low).

Qué significa esto para ti:

1. Nunca preguntes «¿cuánto razonamiento?». Pregunta «¿cuánto razonamiento para esta tarea?».
2. Una política uniforme de max para todo es un error de costo y de calidad.
3. El artículo sobre el presupuesto de longitud planteó este punto desde la perspectiva humana. El artículo de ACL lo plantea desde la perspectiva del modelo.

Qué te venden realmente Fable y Astra

Deja de lado las gráficas de lanzamiento. Ambos modelos insignia venden lo mismo: un presupuesto de razonamiento con cinco niveles, ajustable por mensaje.

Fable 5.1 (documentación, 1 de septiembre de 2026):

• El razonamiento siempre está activado. Eliges effort entre low y max. El valor predeterminado es high.
• Con esfuerzo bajo puede omitir el razonamiento en tareas sencillas. Con esfuerzo alto razona durante más tiempo en la mayoría de las solicitudes.
• Novedades en 5.1: cambiar el esfuerzo a mitad de una conversación sin perder el prompt cache (beta), además de notas de progreso paso a paso entre llamadas a herramientas (beta).
• Regla práctica de Anthropic: comienza con high. Sube para trabajo autónomo difícil. Baja para trabajo rutinario cuando tus pruebas indiquen que se mantiene la calidad.

Astra (lanzamiento de OpenAI, 3 de septiembre de 2026):

• Los mismos cinco niveles: low, medium, high, xhigh, max. Configuras reasoning.effort en la Responses API.
• Puedes cambiar el esfuerzo a mitad de una conversación y conservar el cache.
• Máximos reportados por el proveedor: FrontierMath Tier 4 v2 ~97.6%, ARC-AGI-3 99.9% con un harness especial, Terminal-Bench 4.0 57.9%. Tómalos como cifras máximas con esfuerzo max, no como resultados cotidianos.

Flash sigue el mismo patrón con un presupuesto menor. El blog de Google del 2 de septiembre lo dice directamente: «3.8 Flash se esfuerza más. En tareas complejas, muestra mayor diligencia: ejecuta pasos adicionales de razonamiento y llama herramientas de forma iterativa». Para trabajo barato y rápido, Google recomienda usar un esfuerzo menor o seguir con 3.7 Flash.

Criterio editorial: la diferencia real no es una capa secreta del modelo. Es el entrenamiento que le enseña cuándo pensar, junto con una API que te permite dirigirlo. Los equipos que configuran todo en max reciben facturas más altas y más respuestas correctas que se vuelven incorrectas por exceso de análisis.

¿Y si omites el razonamiento por completo? Conoce Jev

Esta es la novedad más reciente, del 15 de septiembre de 2026. TypeSafe AI salió del modo sigiloso con $40M de financiamiento semilla y un modelo llamado Jev (jev-1.13.0, alias jev-latest). No es un modelo de chat. Toma decisiones tipadas rápidamente para el código.

Le envías hechos. Devuelve una decisión con una probabilidad. Sin ensayos. Sin cadena de pensamiento. La mayoría de las llamadas terminan en ~100 ms (rango del proveedor: 70–500 ms de extremo a extremo).

Tres tipos de respuesta:

• Noul — una probabilidad de sí/no. «¿Este ticket es un problema de facturación? 0.92».
• Choice — elige una opción que definiste. «Enrutar a: facturación / soporte técnico / fraude».
• Score — un número en tu escala. «Urgencia: 0.8».

Fuentes: Publicación de lanzamiento de TypeSafe (14 de septiembre de 2026), análisis detallado de Flavio Copes (17 de septiembre de 2026), explicación de OmniaKey (datos verificados el 19 de septiembre de 2026), precios de OpenRouter (18 de septiembre de 2026). Las afirmaciones de velocidad y precio son reportadas por el proveedor. Considera el titular de TypeSafe «193.6x más rápido, 444.6x más barato» como el mejor caso de sus propias pruebas de flujos de trabajo, no como lo que medirás tú.

Una llamada a Jev se ve así:

import requests

resp = requests.post(
    "https://api.typesafe.ai/v1/systemone",
    headers={"Authorization": f"Bearer {API_KEY}"},
    json={
        "model": "jev-latest",  # resolves to jev-1.13.0
        "state": "My card was charged twice for the same order.",
        "questions": {
            "route": {
                "type": "choice",
                "instructions": "Which team handles this?",
                "criteria": {
                    "billing": "Duplicate charges, refunds",
                    "technical": "Bugs, crashes",
                    "fraud": "Stolen card, account takeover",
                },
            },
            "is_billing": {
                "type": "noul",
                "instructions": "Is this a billing issue?",
            },
            "urgency": {
                "type": "score",
                "instructions": "How urgent is this from 0 to 1?",
            },
        },
    },
    timeout=10,
)
data = resp.json()
print(data["answers"]["route"])      # {"value": "billing", "probabilities": {...}}
print(data["answers"]["is_billing"]) # {"value": True, "probability": 0.92}
print(data["answers"]["urgency"])    # {"value": 0.8, ...}

Fija jev-1.13.0 (no jev-latest) si ajustas umbrales. Registra el ID con versión que devuelve la respuesta.

¿Cuándo supera Jev al razonamiento profundo?

flowchart TD
    Q[Llega una tarea nueva] --> T{"¿La respuesta es\nprosa o una decisión?"}
    T -- Prosa, código, plan --> L["LLM con esfuerzo ajustado\nbajo para tareas rutinarias, alto para difíciles"]
    T -- Opción, puntuación, sí/no --> J["Decisión de Jev\n~100ms, $0.042/M de entrada"]
    J --> C{¿Confianza alta?}
    C -- Sí --> ACT[Actuar en el código]
    C -- No --> L
    L --> G[Registrar resultado\nreajustar mensualmente]

Jev no puede escribir, explicar, programar ni hacer matemáticas por ti. Se complementa con un modelo de razonamiento: Jev enruta y verifica, el LLM hace el trabajo abierto. Para los bucles de agentes que preguntan «¿debería escalar esto?» cientos de veces al día, esa división explica toda la diferencia de costo.

Arquitectura en 30 segundos

No necesitas entrenar estos modelos. Solo necesitas entender la forma general de la tendencia.

flowchart LR
    A[Transformer denso<br/>memoria completa por token] --> B[Atención más económica<br/>memoria compartida por token]
    B --> C["Mixture-of-Experts<br/>biblioteca grande, pocos libros abiertos"]
    C --> D[Historial reducido<br/>comprimir u omitir tokens antiguos]
    D --> H["Frontera de 2026:<br/>presupuestos inteligentes de razonamiento\n+ verificaciones sin razonamiento al estilo de Jev"]

Tres avances nos trajeron hasta aquí: atención más económica por token, modelos de expertos que solo activan unas pocas partes por consulta e historial comprimido para contextos largos. Los proveedores no comparten los pesos, así que interpreta con cautela sus afirmaciones de velocidad.

Para 2026, los grandes avances se trasladaron al momento de la inferencia: quién administra mejor el presupuesto de razonamiento y quién lo omite por completo cuando basta con una respuesta tipada. Por eso Fable, Astra y Jev pueden sentirse tan diferentes en hardware similar.

Para el aspecto de la ventana de contexto, consulta 1M vs 200K.

Implementación: encuentra tu nivel de esfuerzo óptimo

No copies mi tabla. Mide tus propias tareas. Ejecuta cada caso en todos los niveles de esfuerzo. Registra si acertó o falló, los tokens, el costo y el tiempo. Elige el nivel de esfuerzo más barato que pase las pruebas.

Para profundizar: Política de enrutamiento con esfuerzo bajo, guía de Fable High y ¿Los LLM de frontera resuelven mejor la ambigüedad? (el esfuerzo no resuelve la ambigüedad: mantén separado el control para decidir si preguntar o actuar).

flowchart TD
    E["Conjunto de evaluación, etiquetado por tipo de tarea"] --> S[Ejecutar cada caso con low/medium/high/xhigh/max]
    S --> M["Registrar: acierto, tokens, costo, tiempo"]
    M --> A[Promedio por tipo de tarea]
    A --> U{¿La precisión cae con mayor esfuerzo?}
    U -- Sí en tareas fáciles --> C[Limitar ese tipo a su nivel óptimo]
    U -- No, sigue subiendo --> K[Mantener un esfuerzo mayor]
    C --> T[Guardar tabla de esfuerzo por tipo]
    K --> T
    T --> R["Router: tipo de tarea a esfuerzo"]

Conecta tu llamada al proveedor donde se indica. Mantén baja la temperatura para que el esfuerzo sea lo único que cambie.

from __future__ import annotations

from dataclasses import dataclass
from statistics import mean
import csv
import json

EFFORTS = ["low", "medium", "high", "xhigh", "max"]

@dataclass
class TaskCase:
    id: str
    task_class: str  # e.g. "routine-edit", "multi-file", "ambiguous-plan"
    prompt: str
    check: callable  # (output_text, trace) -> bool

@dataclass
class RunResult:
    case_id: str
    task_class: str
    effort: str
    correct: bool
    thinking_tokens: int
    total_tokens: int
    cost_usd: float
    latency_s: float

def run_once(model: str, effort: str, case: TaskCase) -> RunResult:
    """Call your provider here. Anthropic: output_config={"effort": effort}.
    OpenAI Responses API: reasoning={"effort": effort}.
    Read tokens + cost from the API reply, don't guess."""
    raise NotImplementedError("wire run_once to your provider client")

def sweep(model: str, cases: list[TaskCase], repeats: int = 3) -> list[RunResult]:
    results: list[RunResult] = []
    for effort in EFFORTS:
        for case in cases:
            for _ in range(repeats):
                results.append(run_once(model, effort, case))
    return results

def summarize(results: list[RunResult]) -> dict:
    """Per-class accuracy + cost. Treat 1-2 point gaps as noise."""
    summary: dict = {}
    classes = sorted({r.task_class for r in results})
    for cls in classes:
        per_effort: dict = {}
        for r in results:
            if r.task_class != cls:
                continue
            per_effort.setdefault(r.effort, []).append(r)
        rows = []
        for effort in EFFORTS:
            rs = per_effort.get(effort, [])
            if not rs:
                continue
            acc = mean(1.0 if r.correct else 0.0 for r in rs)
            rows.append({
                "effort": effort,
                "n": len(rs),
                "accuracy": round(acc, 3),
                "mean_total_tokens": int(mean(r.total_tokens for r in rs)),
                "mean_cost_usd": round(mean(r.cost_usd for r in rs), 4),
                "mean_latency_s": round(mean(r.latency_s for r in rs), 1),
            })
        best = max(r["accuracy"] for r in rows)
        peak = next(r for r in rows if r["accuracy"] >= best - 0.01)
        max_row = next(r for r in rows if r["effort"] == "max")
        inverted_u = (peak["accuracy"] - max_row["accuracy"]) > 0.02
        summary[cls] = {
            "rows": rows,
            "recommended_effort": peak["effort"],
            "inverted_u_detected": inverted_u,
        }
    return summary

def emit_table(summary: dict, path_csv: str = "effort-table.csv") -> None:
    with open(path_csv, "w", newline="") as f:
        w = csv.writer(f)
        w.writerow(["task_class", "effort", "n", "accuracy",
                    "mean_tokens", "mean_cost_usd", "mean_latency_s"])
        for cls, s in summary.items():
            for r in s["rows"]:
                w.writerow([cls, r["effort"], r["n"], r["accuracy"],
                            r["mean_total_tokens"], r["mean_cost_usd"],
                            r["mean_latency_s"]])
    with open("effort-policy.json", "w") as f:
        json.dump({cls: {"effort": s["recommended_effort"],
                         "inverted_u": s["inverted_u_detected"]}
                   for cls, s in summary.items()}, f, indent=2)

Cómo interpretar los resultados:

• Las tareas fáciles deberían alcanzar su máximo pronto. Si routine-edit alcanza su máximo en low y cae en max, acabas de reproducir el resultado del artículo de ACL. Limita su esfuerzo. No reintentes con max: corrige el prompt.
• Las tareas difíciles justifican el presupuesto. Si ambiguous-plan sigue mejorando hasta xhigh, vale la pena pagarlo. Aun así, prueba max por separado: debe superar a xhigh por un margen real, no por ruido.
• Los conjuntos de prueba pequeños engañan. Con menos de ~30 casos por tipo, considera las diferencias de 1–2 puntos como ruido. Las columnas de tokens y costo son exactas: úsalas para desempatar a favor del esfuerzo más barato.
• Repite la prueba con cada versión menor. El paso de Fable 5 a 5.1 movió la frontera. También el de Flash 3.7 a 3.8. Una tabla de julio es un rumor en septiembre.

Cuándo pagar por Max

Usa esto como una hipótesis inicial. Deja que tus pruebas tengan la última palabra. Cada celda es criterio editorial, no un benchmark.

Tres reglas que se mantienen en cualquier prueba:

1. Usa por defecto el esfuerzo más barato que pase tus pruebas. Los valores predeterminados de los proveedores favorecen las demos, no tu factura.
2. Escala con información nueva, no solo con más tokens. Volver a ejecutar el mismo prompt con max rara vez cambia la respuesta. Agrega una prueba que falle o un documento y luego escala.
3. Repite las pruebas con cada versión menor. La frontera sigue moviéndose.

Fuentes

Primero las fuentes primarias. Las cifras de los proveedores provienen de tablas de lanzamiento de septiembre de 2026 y son reportadas por ellos, salvo que se indique lo contrario; las interpretaciones son mías.

• Anthropic — Descripción general de Claude Fable 5.1 (lanzado el 1 de septiembre de 2026): contexto de 1M, salida de 128K, $10/$50, modo adaptativo siempre activado, high predeterminado.
• Anthropic — Novedades de Fable 5.1: cambios incompatibles, esfuerzo por mensaje en beta, actualizaciones de progreso en beta, reducción del precio de lectura de cache.
• Anthropic — Documentación de esfuerzo: cinco niveles, recomendaciones para Fable 5.1, interacción entre razonamiento y esfuerzo.
• Anthropic — Presentación de Fable 5.1 y Mythos 5.1 (septiembre de 2026): Low/Medium frente a Fable 5, cambios en las salvaguardas de ciberseguridad.
• OpenAI — Lanzamiento de GPT-6 Astra (tabla de septiembre de 2026): precios Standard de $10/$50, puntuaciones «máximas en cualquier nivel de esfuerzo»; FrontierMath Tier 4 97.6–98%, ARC-AGI-3 99.9%, T-Bench 4.0 57.9%, DeepSWE 74.1% frente a Fable 5.1 con 67.4% y Flash con 73.8%.
• Google — Presentación de Gemini 3.8 Flash (2 de septiembre de 2026): tercer Flash en seis semanas, precio de lanzamiento de $0.75/$3.75, nota sobre su diligencia porque «se esfuerza más».
• Google DeepMind — Página de modelos Gemini (consultada el 18 de septiembre de 2026): catálogo con 3.8 Flash + 3.1 Pro + 3.1 Deep Think, «3.5 Pro próximamente».
• Google DeepMind — Página de Gemini 3.1 Pro y página de 3.1 Deep Think (tablas de febrero de 2026): puntuaciones de HLE, GPQA, SWE-Verified y Codeforces Elo.
• Google DeepMind — Ficha del modelo Gemini 3.8 Flash (tabla de septiembre de 2026): DeepSWE 73.7%, T-Bench 2.1 89.4% / 4.0 19.1%, Finance 61.4%, Legal 10.0%, HLE-Verified 54.9%.
• TypeSafe AI — Presentación de los modelos System One y Jev (14 de septiembre de 2026): clase de modelos System One, acceso anticipado a Jev, $0.042/M de entrada y salida gratis, rango de 70–500 ms, afirmación de 193.6x más rápido / 444.6x más barato en flujos de trabajo.
• Flavio Copes — Un análisis detallado de Jev, el modelo System One de TypeSafe (17 de septiembre de 2026): alias jev-1.13.0 / jev-latest / jev-preview, POST /v1/systemone con model + state + questions, tipos Choice/Score/Noul, ruta de Vercel AI Gateway.
• OmniaKey — ¿Qué es el modelo Jev? Explicación de TypeSafe System One AI (datos verificados el 19 de septiembre de 2026): tabla de contexto de 64K, límites de 250K tokens/s y 1,200 req/min, nota sobre el mejor funcionamiento en inglés, advertencias sobre el acceso anticipado.
• OpenRouter — Precios de Jev 1.13 (18 de septiembre de 2026): precio publicado de $0.042/M de entrada,$0/M de salida.
• ACL Findings 2026 — Cuando pensar más perjudica: rendimientos decrecientes, proporciones de cambios de respuesta, puntos óptimos según la dificultad, detención sensible al costo.
• ICLR 2026 — OptimalThinkingBench: F1 de 33 modelos para exceso e insuficiencia de razonamiento, ningún modelo equilibra ambos.
• Wu et al. — Cuando más es menos (arXiv 2502.07266): U invertida, longitud óptima que varía con la dificultad, sesgo hacia la simplicidad.
• Hacia un escalado óptimo del razonamiento (arXiv 2502.18080): las CoT más largas perjudican las tareas fáciles, esfuerzo óptimo por tarea.
• DeepSeek-AI — DeepSeek-V4 (arXiv 2606.19348) (junio de 2026): MoE + MTP + mHC + CSA/HCA para contexto de 1M.
• NVIDIA — Nemotron-3 Super (arXiv 2604.12374) (abril de 2026) e informe técnico de Ultra: afirmaciones de throughput para Mamba-Attention MoE híbrido + LatentMoE + MTP.
• Raschka — Avances recientes en arquitecturas de LLM: resumen de MLA frente a compresión de secuencias.
• Artificial Analysis — Gemini 3.8 Flash vs 3.1 Pro Preview (fuente secundaria, septiembre de 2026, escala Index v4.3): 41 frente a 30, 299 frente a 121 tok/s, 71k frente a 18k tokens de salida/tarea.
• BenchLM — Benchmarks de GPT-6 Astra (fuente secundaria, septiembre de 2026): instantánea de la tabla de lanzamiento con advertencias sobre el harness.
• ComputingForGeeks — Benchmarks, precios y API de Astra (fuente secundaria): prueba de latencia y costo en cinco niveles, hallazgo de la misma respuesta.
• SynthorAI — Esfuerzo de razonamiento de Astra (fuente secundaria): costo de max de 2.3x el de low para las mismas respuestas en 11 tareas.
• Elser AI — Niveles de razonamiento de Astra (fuente secundaria): none rechazado en Astra, configuration_update a mitad de la conversación, recomendaciones de enrutamiento.

Contenido relacionado en este repositorio: Comparación de Fable Low, guía de Fable High, política de enrutamiento con esfuerzo bajo, qué longitud debería tener una respuesta, contexto de 1M vs 200K, si los LLM de frontera resuelven mejor la ambigüedad, explicación de CheatBench.