Cómo configurar Astra en Codex sin malgastar tu cuota de uso
Neaptide · 20 de septiembre de 2026 · 13 min de lectura · Actualizado: 3 de octubre de 2026
Elige el nivel de razonamiento de Astra, revisa las instrucciones del proyecto y define tareas claras en Codex. Prompts, contexto y seguimiento del consumo.
En este artículo
Codex termina de modificar el formulario, pero el nombre de la empresa no llega al correo comercial. Antes de subir el esfuerzo de razonamiento, comprueba si el agente conocía ese requisito y podía verificar la entrega. Configurar Astra empieza por delimitar la tarea y decidir cómo aceptar el resultado.
Antes de cambiar de modelo, revisa las instrucciones. Puede que haya reglas antiguas, una petición demasiado amplia o criterios poco claros para dar el trabajo por terminado. Un modelo más capaz también necesita un encargo bien definido.
Para empezar bastan tres cambios. Adapta el esfuerzo de razonamiento a la tarea. Quita los pasos obligatorios que no aporten nada a ese trabajo. Describe un resultado que puedas comprobar. Después compara, en tus propios proyectos, el consumo y las correcciones que han hecho falta.
Este artículo parte del análisis de GPT-6 Astra publicado por Edvard Grishin en su canal sobre IA y automatización de negocios. El vídeo está en ruso. Del vídeo tomamos las cuestiones prácticas y contrastamos los detalles técnicos con la documentación de OpenAI. Los ejemplos son didácticos. Ninguno procede de un proyecto de un cliente de Neaptide.
Distingue el modelo del entorno en el que trabaja
Astra es el modelo. Codex es el entorno que le da acceso a archivos y herramientas. La posibilidad de abrir una web, modificar un proyecto o ejecutar una comprobación depende de ese entorno, su configuración y sus permisos.
Por eso, un consejo para la API no siempre tiene un ajuste equivalente en la aplicación. Tampoco des por hecho que el tamaño de contexto anunciado para el modelo está disponible entero en tu sesión.
Si estás empezando, consulta la guía de primeros pasos con Codex. Nuestro análisis de GPT-6 Astra explica sus capacidades y las pruebas publicadas. Aquí nos centramos en el trabajo diario.
Ajusta el razonamiento a la dificultad de la tarea
La API de Astra admite cinco valores de reasoning.effort: low, medium, high, xhigh y max. El ajuste determina cuánto esfuerzo dedica el modelo a razonar. Los controles disponibles pueden variar según la interfaz. Fuente: ficha del modelo de OpenAI.
No hace falta seleccionar el máximo para cada encargo. Prueba primero con tareas conocidas cuyo resultado puedas evaluar. La tabla propone por dónde empezar a comparar. No garantiza ninguna calidad.
| Tarea | Ajuste inicial que puedes probar | Qué comprobar |
|---|---|---|
| Corregir una errata o sustituir un texto aprobado | Low | Se han cambiado todas las partes previstas y el diseño sigue funcionando |
| Añadir un campo a un formulario existente | Low o Medium | Funcionan la validación, el envío y el almacenamiento |
| Encontrar la causa de un fallo intermitente | Medium y, si hace falta, High | La causa se puede reproducir y la corrección se ha comprobado |
| Planificar una migración de datos | Incluir High en la comparación | El plan contempla pérdida de datos, compatibilidad y reversión; lo revisa un especialista |
Low no siempre sale más barato al terminar. Con tres rondas de correcciones tras el primer resultado, el ahorro inicial se esfuma. Un esfuerzo mayor tampoco evita la revisión: razonar más tiempo no demuestra que una solución sea correcta.
Compara el coste de una tarea terminada y aceptada. Cuenta la espera, el consumo y tu propia intervención: cuántas veces has tenido que explicar de nuevo el encargo, detectar errores o pedir cambios.
Tras un intento fallido, anota la causa. Si el agente no sabía que el campo debía incluirse en el correo, aclara el criterio. Si no encontró el código de envío, indica la ruta o pide que lo busque. Prueba un esfuerzo mayor cuando ya disponga de la información y la dificultad esté en el razonamiento. Cambia un solo factor cada vez.
Comprueba si las reglas antiguas generan trabajo innecesario
Puede que tu proyecto acumule instrucciones como «lee toda la arquitectura antes de cada cambio» o «ejecuta todas las comprobaciones después de cualquier modificación». Quizá fueron útiles en su momento. Ahora imponen el mismo trabajo al crear una integración y al cambiar un título.
OpenAI recomienda revisar las instrucciones de AGENTS.md y de las habilidades utilizadas con Astra, porque el modelo es sensible a ellas. Las reglas contradictorias pueden provocar pausas y solicitudes de aprobación innecesarias. Recomendaciones de OpenAI para Astra.
Una regla útil explica cuándo y para qué hace falta una acción.
| Regla demasiado general | Regla más precisa para un proyecto de ejemplo |
|---|---|
| Lee toda la documentación antes de cada cambio | Antes de modificar el formulario, lee la documentación de sus campos y del envío |
| Pide permiso siempre antes del siguiente paso | Haz los cambios y comprobaciones locales de forma autónoma; pide autorización por separado para publicar |
| Ejecuta todos los tests tras cada modificación | Si cambia el cálculo de precios, comprueba el cálculo y el proceso de compra; antes de publicar, ejecuta los controles obligatorios del proyecto |
No elimines los requisitos de pruebas porque el nuevo modelo supuestamente «ya lo comprueba todo». Las verificaciones obligatorias y las restricciones de acceso se quedan. Las que conviene reescribir son las reglas que exigen el mismo esfuerzo sea cual sea la tarea.
Puedes solicitar la revisión así:
Revisa las instrucciones actuales del proyecto y las habilidades en uso.
Busca repeticiones, contradicciones y requisitos que generen
trabajo innecesario en tareas pequeñas.
Para cada observación, indica el archivo, la regla concreta,
un ejemplo del problema y una redacción alternativa.
Conserva los requisitos de seguridad, tratamiento de datos
y comprobaciones obligatorias.
Presenta primero tus propuestas. Todavía no cambies las reglas.También hay una razón técnica para mantener las instrucciones breves. Codex las reúne a partir de varios archivos, con un límite conjunto de 32 KiB por defecto. Si tienes muchas reglas, comprueba cuáles se han cargado realmente. Cómo lee Codex los archivos AGENTS.md.
Define cuándo se puede dar el trabajo por terminado
«Haz que el formulario sea más cómodo» deja demasiadas decisiones abiertas. El agente podría rediseñarlo cuando el problema real es que las consultas no llegan al equipo comercial.
A quien dirige un negocio le conviene más describir el recorrido del cliente y un resultado comprobable. Por ejemplo:
Añade un campo opcional «Empresa» al formulario de la página del servicio.
Incluye su valor en el correo que recibe el equipo comercial.
El trabajo estará terminado cuando:
1. El formulario se envíe con el campo relleno o vacío.
2. El correo de prueba contenga el nombre de empresa introducido.
3. El campo y el botón quepan en el ancho de una pantalla móvil.
4. Los campos obligatorios existentes se validen como antes.
Haz los cambios y las comprobaciones locales de forma autónoma.
Utiliza datos de prueba. No publiques cambios ni envíes correos
a clientes reales.
Muestra el resultado e indica qué has comprobado y qué no has podido comprobar.No hace falta dictar el código. Queda claro para qué se cambia el formulario y cómo se va a aceptar el trabajo. Si no se puede acceder al servicio de correo, el agente debe decirlo. Que el formulario se vea bien no demuestra que el mensaje se haya entregado.
Guarda esta estructura como plantilla: tarea, comportamiento esperado, restricciones, comprobaciones y resultado que debe entregarse. Completa los detalles para cada encargo.
Este formulario necesita tres pruebas: el valor aparece en la interfaz, el servidor lo acepta y un destinatario de prueba recibe el correo con ese valor. Un HTTP 200 solo confirma una parte del recorrido. Si no puedes comprobar el último paso, el informe debe indicar qué quedó sin verificar.
Amplía el contexto solo cuando haya un motivo
El contexto es la información con la que trabaja el modelo en una petición: conversación, instrucciones, documentos y resultados de herramientas. Una ventana grande ayuda cuando hay que comparar mucho material. No convierte los archivos irrelevantes en información útil.
La ficha oficial de Astra indica una ventana de 1.050.000 tokens. En la API, las peticiones con más de 272.000 tokens de entrada tienen tarifas superiores: las de entrada y caché se multiplican por 2, y las de salida por 1,5, para toda la petición. Son condiciones de la API. El consumo de tu suscripción no se calcula con esa fórmula. Especificaciones y condiciones de precio de Astra.
Antes de ampliar el contexto, revisa los materiales. Para cambiar un formulario hacen falta su código, sus reglas de validación y los detalles del envío. Es poco probable que ayuden las propuestas comerciales antiguas o todo el archivo de notas del proyecto.
Si el trabajo dura varios días, mantén un documento breve con las decisiones, los archivos modificados, las comprobaciones y lo pendiente. Al iniciar una nueva sesión, añade los archivos fuente actualizados. Un resumen no sustituye a los documentos que respaldan sus conclusiones.
Usa subagentes cuando puedas repartir el trabajo
Un subagente es un asistente separado al que el agente principal encarga parte de la tarea. En una revisión web, uno podría comprobar el formulario, otro la búsqueda del catálogo y otro el menú móvil. Cada uno devuelve sus observaciones y los pasos para reproducir los problemas.
OpenAI recomienda valorar si las tareas son independientes y tener cuidado con la edición simultánea de archivos, porque los cambios pueden entrar en conflicto. Cada agente consume tokens por su propio trabajo. Aumentar su número no garantiza un ahorro. Documentación de subagentes.
Para una corrección pequeña, varios asistentes rara vez se justifican. En una revisión amplia, define el alcance y la respuesta esperada de cada uno. En lugar de «revisa la web», pide «comprueba estos tres casos de envío del formulario, enumera los fallos y los pasos para reproducirlos; no cambies el código».
Después de reunir los resultados, comprueba el recorrido completo. Tres revisiones parciales satisfactorias no demuestran que todo funcione en conjunto.
Un diagrama de dependencias ayuda a repartir la tarea. Revisar el menú no tiene por qué esperar a la revisión del buscador. El recorrido completo del cliente, en cambio, solo puede comprobarse una vez unidos los cambios. Dos asistentes que editan el mismo código de envío ya no trabajan de forma independiente.
Controla el consumo con datos
El vídeo propone expresar el presupuesto en lenguaje natural. Esa instrucción puede marcar una intención, pero «detente cuando quede un 25 %» no es un límite garantizado. Para eso el agente necesitaría datos de consumo actualizados y un mecanismo para detenerse a tiempo.
El consumo de Codex depende del modelo, la dificultad, el contexto, las herramientas y la caché. OpenAI advierte que la longitud del mensaje no basta para estimarlo. Consulta la interfaz de uso para ver la cuota disponible y los momentos de restablecimiento. Cómo funcionan los límites de Codex.
Lleva un registro sencillo de varias tareas habituales:
| Tarea | Modelo y esfuerzo | Consumo según los datos disponibles | Correcciones | Resultado aceptado |
|---|---|---|---|---|
| Sustituir texto | … | … | … | Sí / no |
| Modificar un formulario | … | … | … | Sí / no |
| Investigar un fallo | … | … | … | Sí / no |
Es una plantilla para tus propios registros. No contiene mediciones de Neaptide. Si hay otras tareas en paralelo, no puedes atribuir toda la reducción de la cuota a una sola. En la API, registra el consumo de cada petición. En una suscripción, utiliza el detalle disponible y anota sus limitaciones.
Cambia un ajuste cada vez. Si reduces las reglas, cambias de modelo y añades asistentes a la vez, no sabrás qué ha influido en el resultado.
Convierte las operaciones repetidas en automatizaciones
Imagina que cada semana recibes un archivo de consultas, unificas los nombres de sus columnas y preparas un resumen. La primera vez, el agente puede ayudarte a entender el formato y escribir el procesamiento. Si las reglas no cambian, a partir de ahí basta con ejecutar ese script.
Decide qué debe ocurrir si aparece una columna nueva, el archivo está vacío o una fecha no es válida. Conserva el original y prevé avisos de error. De lo contrario, la automatización solo servirá para producir informes erróneos más deprisa.
El proceso no se vuelve gratuito: siguen existiendo costes de ejecución, servicios externos y mantenimiento. Pero ya no necesitas pedir al modelo que diseñe el mismo tratamiento cada semana. Vuelve a recurrir al agente cuando cambien los datos o los requisitos.
Empieza por una tarea conocida
En la próxima tarea conocida, registra los criterios de aceptación, el contexto disponible y el esfuerzo inicial. Después, cambia solo el factor que explique el problema encontrado. Varias comparaciones así aportan más que seleccionar siempre el máximo o pedir al agente que «gaste menos».
- Análisis de GPT-6 Astra de Edvard Grishin: más de 35 funciones y comparación de Codex con Claude Code
- Canal de Edvard Grishin sobre IA y automatización de negocios
- OpenAI: GPT-6 Astra
- OpenAI: Model guidance
- OpenAI: Reasoning models
- OpenAI: AGENTS.md
- OpenAI: Subagents
- OpenAI: Pricing
Fuentes y verificación
Fuentes técnicas y cálculos verificados el 3 de octubre de 2026. Los escenarios y esquemas son ejemplos didácticos de Neaptide. No se realizaron pruebas comparativas de rendimiento.