Árbol de conocimiento
Seguridad ofensiva
Shells
Transferencia de archivos
Aplicaciones web
Razonamiento
Algunos modelos pueden dedicar más trabajo a una tarea antes de dar la respuesta final. Las APIs y los harnesses suelen exponer esta opción como un nivel de reasoning effort: por ejemplo, low, medium o high.
El control no describe paso a paso lo que ocurre dentro del modelo. A efectos prácticos indica cuánto esfuerzo queremos que dedique a la solicitud. Un nivel mayor puede ayudar cuando la tarea exige relacionar varias piezas, probar hipótesis o corregir una decisión a partir de resultados nuevos.
Cuándo aporta valor
Extraer un número de un JSON o clasificar una entrada sencilla normalmente no necesita mucho reasoning. Investigar por qué falla un test ambiguo puede ser diferente: quizá haya que leer varios ficheros, entender qué cambió, ejecutar el test y revisar el error siguiente.
En este segundo caso, dar más margen al modelo puede mejorar la investigación. No garantiza una respuesta mejor. También puede hacer que explore caminos innecesarios o tarde más en llegar a una solución sencilla.
La forma útil de elegir el nivel es probarlo con las tareas reales. Si medium resuelve de forma consistente el tipo de trabajo que importa, subir siempre a high solo porque existe no aporta necesariamente nada.
Tiempo, tokens y coste
Más reasoning suele aumentar la latencia y el consumo. La forma exacta de contabilizarlo depende de la API: el proveedor puede incluir esos tokens dentro del output, mostrarlos como un detalle separado o no exponerlos de la misma forma.
Por eso conviene medir el resultado completo:
- Si la tarea se resolvió correctamente.
- Cuánto tardó.
- Cuántos tokens o llamadas consumió.
El coste económico de ese uso se explica en Costes de API. En una tarea corta, unos segundos o unos pocos tokens adicionales pueden ser irrelevantes. En un agente que realiza muchas inferencias, la diferencia se repite en cada iteración.
Reasoning durante un trabajo con tools
En un agente, el razonamiento no ocurre solo antes de la respuesta final. El modelo puede decidir leer un fichero, observar el resultado, cambiar de hipótesis y ejecutar un test. Después utiliza ese nuevo resultado para decidir el paso siguiente.
Por ejemplo, un coding agent puede empezar pensando que el fallo está en la implementación, leer el test y descubrir que la expectativa quedó desactualizada. El siguiente paso cambia porque apareció evidencia nueva. Ese recorrido forma parte del bucle de agente.
Un effort mayor puede afectar tanto al análisis como a las tool calls que el modelo decide realizar. Lo importante no es obtener una explicación visible más larga, sino si la configuración ayuda a completar mejor la tarea.