Esta página es una traducción de la documentación en inglés. Los comandos, identificadores y ejemplos no cambian. Runtime 7.24.4 · SDK 2.6.7. Original en inglés

Controles de razonamiento del modelo actual

Estado: Activo

Alcance: estado actual

Última revisión: 2026-09-14

Responsable: runtime de ax-code

AX Code elige los controles de razonamiento usando el ID de modelo de origen y el protocolo del SDK. Estos perfiles cubren las rutas Chat compatibles con OpenAI para los ID exactos de abajo. Conservan el comportamiento existente del SDK nativo, de la GPU privada, de AX Engine y de las pasarelas restringidas.

Las opciones explícitas de razonamiento del modelo o del agente y las variantes elegidas anulan la política automática de esfuerzo. Una declaración negativa de capacidad de razonamiento impide las variantes automáticas de esfuerzo y estos controles auxiliares. GLM y DeepSeek conservan el valor predeterminado del proveedor cuando las solicitudes ordinarias no eligen un esfuerzo. Las solicitudes auxiliares usan sus propios controles sin cambiar la selección guardada del usuario.

Conflictos de opciones de Qwen y herramientas forzadas

Qwen 3.8 acepta reasoning_effort o thinking_budget, nunca ambos. Un presupuesto explícito de pensamiento suprime la selección automática de esfuerzo. Cuando las opciones fusionadas contienen a la vez un esfuerzo y un presupuesto, gana el esfuerzo. high y max se normalizan a xhigh, minimal a low, y none desactiva el pensamiento. Las rutas de planes de Alibaba conservan su techo existente de presupuesto de tokens, incluida la reserva acotada cuando no se elige un esfuerzo. Estas correspondencias siguen la API Chat de Alibaba.

El modo de pensamiento de Qwen rechaza las llamadas a herramientas forzadas. Para tool_choice: required, AX Code desactiva el pensamiento de esa solicitud y quita las opciones incompatibles de esfuerzo, presupuesto y conservación. Los turnos automáticos de herramientas posteriores reanudan el esfuerzo elegido. El manejo existente de herramientas exigidas de DeepSeek también mantiene el pensamiento desactivado para esa solicitud, como exige su API de modo de pensamiento.

Continuidad del razonamiento

Qwen, GLM y DeepSeek reproducen el razonamiento almacenado mediante reasoning_content. Las solicitudes Chat de MiniMax M2.7/M3 usan reasoning_split: true para que el SDK reciba el razonamiento aparte y pueda reproducirlo con exactitud. Esto evita convertir el razonamiento de la pasarela al formato <mm:think> que usan los despliegues de GPU privada. Un reasoning_split: false explícito conserva la reproducción nativa de <think>. Las firmas de Anthropic y el manejo de etiquetas de GPU privada conservan sus caminos existentes. Consulta la API Chat de MiniMax.

El pensamiento conservado entre turnos de GLM sigue siendo optativo mediante options.preserveThinking: true del proveedor durante las solicitudes elegibles de agente largo. Envía thinking: { type: "enabled", clear_thinking: false }. Actívalo solo para un historial completo y sin modificar del mismo modelo; puede aumentar la entrada facturada. La reproducción ordinaria de un turno de herramientas no exige esta opción. Z.ai documenta los requisitos de conservación. GLM 5.3 siempre razona, así que las solicitudes auxiliares usan esfuerzo bajo en lugar de desactivarlo. Controles de GLM 5.3.

Despliegues personalizados

Una pasarela puede exponer el mismo ID de modelo con un dialecto de parámetros distinto. Para conservar el comportamiento de transformación anterior de un modelo, define options.nativeReasoning: false en la configuración de proveedor de ese modelo:

{
  "provider": {
    "my-gateway": {
      "models": {
        "glm-5.3": {
          "options": { "nativeReasoning": false }
        }
      }
    }
  }
}

Es una renuncia local al perfil, no una orden de desactivar el pensamiento del modelo. Se quita antes de enviar la solicitud. Las variantes configuradas de forma explícita siguen siendo controles del usuario. El SDK nativo de DeepSeek no obtiene variantes de esfuerzo de este perfil porque su serializador instalado no las admite.

La aceptación de la API, la continuación de herramientas y la reproducción exacta del cliente son evidencia de compatibilidad. No demuestran que un origen honre cada indicio de esfuerzo, que su caché acierte más a menudo, ni que mejoren la calidad o la velocidad de programación. Usa la evaluación del harness emparejada para las comparaciones a nivel de tarea.