Как настроить Astra в Codex и не тратить лимиты впустую
Neaptide · 20 сентября 2026 г. · 13 мин чтения · Обновлено: 3 октября 2026 г.
Как выбрать уровень рассуждения Astra, убрать лишние инструкции и поставить задачу Codex. Примеры промптов, работа с контекстом и проверка расходов.
В этой статье
Codex закончил правку формы, но поле «Компания» не попало в письмо менеджеру. Повышать уровень рассуждения здесь рано: сначала нужно понять, видел ли агент этот критерий и мог ли проверить доставку. Настройка Astra начинается с границ задачи и способа принять результат.
Дело может быть вовсе не в модели. Агента сбивают старые инструкции, слишком широкая задача, размытое условие завершения работы. Плохую постановку более сильная модель за вас не перепишет.
Для начала хватит трёх изменений. Уровень рассуждения выбирайте под конкретную работу. Обязательные действия, которые ей не нужны, уберите. Результат заранее опишите так, чтобы его можно было проверить. После этого сравните расход и число доработок на своих задачах.
Поводом для статьи стал разбор GPT-6 Astra на канале «Эдвард Гришин | AI и автоматизация бизнеса». Из видео мы взяли практические вопросы, а технические детали сверили с документацией OpenAI. Примеры ниже учебные, к клиентским проектам Neaptide они отношения не имеют.
Сначала отделите модель от программы, в которой она работает
Astra — модель. Codex — среда, в которой она получает доступ к файлам и инструментам. От среды, настроек и разрешений зависит, сможет ли агент открыть сайт, изменить проект или запустить проверку.
Поэтому для совета, написанного под API, в приложении может не найтись такой же настройки. С контекстом та же история: опубликованный размер окна не обещает, что столько же доступно в вашей текущей сессии.
Если вы только начинаете, сначала пройдите руководство по работе с Codex. Возможности модели и опубликованные тесты мы отдельно разобрали в обзоре GPT-6 Astra. Здесь речь о повседневной работе.
Выбирайте уровень рассуждения по сложности задачи
У Astra в API пять уровней reasoning.effort: low, medium, high, xhigh и max. Параметр задаёт, сколько усилий модель тратит на рассуждение. В конкретном интерфейсе набор переключателей может быть другим.
Ставить максимум на каждое поручение незачем. Возьмите несколько знакомых задач, результат которых вы в состоянии оценить сами. Таблица ниже подсказывает, с чего начать такое сравнение. Качества на каждом уровне она не гарантирует.
| Задача | С чего попробовать начать | Что проверить |
|---|---|---|
| Исправить опечатку, заменить согласованный текст | Low | Все нужные места изменены, верстка сохранилась |
| Добавить поле в существующую форму | Low или Medium | Поле проверяется, значение передаётся и сохраняется |
| Найти причину ошибки, которая возникает не всегда | Medium, затем High при необходимости | Найдена воспроизводимая причина, исправление проверено |
| Спланировать перенос данных между системами | High как один из вариантов для сравнения | Учтены потери данных, совместимость и откат; план проверен специалистом |
Низкий уровень по итогам работы не всегда дешевле. Три круга исправлений после первого ответа легко съедают всю экономию. Высокий уровень, в свою очередь, не отменяет проверку: долгое рассуждение ещё не значит, что решение верное.
Сравнивайте, во что обошлась задача, доведённая до приёмки. В расчёт идут время ожидания, расход и ваше собственное участие: сколько раз пришлось объяснять заново, искать ошибки и возвращать работу на доработку.
После неудачного запуска запишите причину. Если агент не знал, что поле должно попасть в письмо, уточните критерий. Если не нашёл обработчик отправки, дайте путь или попросите поиск. Поднимать уровень имеет смысл, когда вся нужная информация у агента уже есть, а сама задача трудная. Меняйте один фактор за раз.
Проверьте, не заставляют ли старые правила делать лишнюю работу
В проекте могли накопиться инструкции вроде «перед каждой правкой изучи всю архитектуру» или «после любого изменения выполни все проверки». Когда-то они помогали. Теперь одно и то же требование применяется и к новой интеграции, и к замене заголовка.
Для Astra OpenAI отдельно советует пересмотреть инструкции в AGENTS.md и файлах навыков: модель чувствительна к тому, что там написано. Из-за противоречивых правил агент может останавливаться и просить лишних согласований.
Полезное правило объясняет, когда и зачем требуется действие. Например:
| Слишком общее правило | Более точное правило для учебного проекта |
|---|---|
| Перед любой правкой прочитай всю документацию | Перед изменением формы прочитай описание её полей и отправки данных |
| Всегда спрашивай разрешение на следующий шаг | Локальные правки и проверки выполняй самостоятельно; публикацию согласуй отдельно |
| После каждого изменения запускай все тесты | Для изменения расчёта цены проверь расчёт и оформление заказа; перед выпуском выполни обязательные проверки проекта |
Требования к тестированию не удаляйте: довод «новая модель сама всё проверяет» ничем не подтверждён. Обязательные проверки продукта и ограничения доступа остаются. Переписывать нужно правила, которые навязывают один и тот же объём работы любой задаче.
Попросить ревизию можно так:
Изучи действующие инструкции проекта и используемые навыки.
Найди повторы, противоречия и требования, которые заставляют
делать лишнюю работу на небольших задачах.
Для каждого замечания укажи файл, конкретное правило,
пример проблемы и предлагаемую формулировку.
Сохрани требования к безопасности, данным и обязательным проверкам.
Сначала покажи предложения, сами правила пока не меняй.У коротких инструкций есть и техническое основание. Codex собирает их из нескольких файлов, и общий объём по умолчанию ограничен 32 KiB. Когда правил много, проверьте, какие из них на самом деле загрузились.
Объясните, что именно будет считаться готовой работой
«Сделай удобную форму» оставляет слишком много решений на усмотрение агента. Он возьмётся за оформление, хотя беда была в другом: заявки не доходят до менеджера.
Владельцу бизнеса проще описать путь клиента и результат, который можно проверить. Например:
На странице услуги добавь в форму поле «Компания».
Оно необязательное. Значение должно попадать в письмо менеджеру.
Работа готова, когда:
1. Форма отправляется с заполненным полем и без него.
2. В тестовом письме есть введённое название компании.
3. На телефоне поле и кнопка помещаются по ширине экрана.
4. Существующие обязательные поля проверяются как раньше.
Локальные изменения и проверки выполняй самостоятельно.
Используй тестовые данные. Не публикуй изменения и не отправляй
письма реальным клиентам.
В конце покажи результат и перечисли, что проверено,
а что проверить не удалось.Какой код писать, здесь не сказано, и не нужно. Зато понятно, зачем меняется форма и как принимать работу. Если почтовый сервис недоступен, агент обязан об этом сообщить. Проверка внешнего вида доставку письма не подтверждает.
Такую постановку стоит сохранить как шаблон: задача, ожидаемое поведение, ограничения, проверка, формат результата. Условия в каждую новую задачу вписываете свои.
В примере с формой нужны три разных свидетельства: значение видно в интерфейсе, сервер принял его, письмо с этим значением пришло тестовому получателю. Ответ HTTP 200 подтверждает лишь один участок пути. Если последний участок недоступен, отчёт прямо называет непроверенную часть. Слову «готово» там не место.
Не увеличивайте контекст без понятной причины
Контекст — это всё, с чем модель работает в запросе: переписка, инструкции, документы, результаты инструментов. Большое окно выручает, когда действительно нужно сопоставить много материала. Лишние файлы от этого полезнее не станут.
В официальной карточке Astra указан контекст 1 050 000 токенов. В API запросы с входом свыше 272 000 токенов стоят дороже: вход и кеш считаются с коэффициентом 2, выход — 1,5, причём для всего запроса. Это тариф API. К списанию лимита вашей подписки эта формула не относится.
Прежде чем расширять контекст, посмотрите, что в него попадает. Для правки формы нужны её код, правила валидации и описание отправки. Старые варианты коммерческого предложения и полный архив рабочих заметок, скорее всего, не помогут.
Когда задача тянется несколько дней, ведите короткий рабочий документ: что решили, какие файлы изменили, что проверили и что осталось сделать. При переходе в новую сессию добавьте к нему актуальные исходники. Сама по себе сводка не заменит документы, на которых держатся её выводы.
Субагенты помогают, когда работу можно разделить
Субагент — отдельный помощник, которому основной агент передаёт часть задачи. Например, при проверке сайта один помощник может изучить форму заявки, другой — поиск по каталогу, третий — мобильное меню. Каждый возвращает замечания со способом воспроизведения.
OpenAI советует смотреть, насколько такие задачи независимы, и осторожнее относиться к одновременной правке файлов: изменения могут конфликтовать. Каждый агент к тому же тратит токены на собственную работу. От одного только числа помощников дешевле не станет.
Небольшой правке несколько помощников обычно ни к чему. Для большой проверки заранее задайте каждому предмет работы и ожидаемый ответ. Вместо «проверь сайт» — «проверь три сценария отправки формы, перечисли ошибки и шаги воспроизведения; код не меняй».
Когда результаты собраны, общая проверка всё равно нужна. Три положительных заключения по отдельности ещё не значат, что работает весь путь пользователя.
Разделение работы удобно рисовать как граф зависимостей. Проверке меню незачем ждать проверку поиска, оба результата получаются независимо. Но проверка полного пути клиента начинается после объединения изменений. Если два помощника правят один обработчик формы, независимость уже нарушена.
Контролируйте расход по данным, а не по обещанию в промпте
В видео бюджетом предлагают управлять словами. Такая инструкция обозначит желаемую границу, но просьба «остановись, когда останется 25%» надёжным ограничителем не станет. Агенту для этого нужны актуальные данные о расходе и возможность вовремя прекратить работу.
В Codex расход зависит от модели, сложности задачи, контекста, инструментов и кеширования. OpenAI прямо предупреждает: длина сообщения не позволяет надёжно предсказать расход. Актуальные остатки и время сброса смотрите в интерфейсе использования.
Начните с простого журнала. Для нескольких обычных задач запишите:
| Задача | Модель и уровень | Расход по доступной статистике | Доработки | Результат принят |
|---|---|---|---|---|
| Замена текста | … | … | … | Да / нет |
| Изменение формы | … | … | … | Да / нет |
| Поиск ошибки | … | … | … | Да / нет |
Это шаблон для собственных наблюдений. Замеров Neaptide здесь нет. Если параллельно работают другие задачи, разницу общего остатка нельзя целиком приписать одной из них. Для API сохраняйте статистику конкретных запросов; для подписки используйте доступную детализацию и отмечайте её ограничения.
Меняйте по одной настройке. Иначе после сокращения правил, смены модели и запуска помощников вы не поймёте, что именно повлияло на результат.
Повторяющуюся операцию стоит превратить в обычную автоматизацию
Допустим, каждую неделю вы получаете файл с заявками, приводите названия столбцов к одному виду и готовите сводку. В первый раз агент поможет разобраться в формате и напишет обработку. Если правила не меняются, дальше достаточно запускать готовый скрипт.
Заранее решите, что делать при новом столбце, пустом файле или неправильной дате. Исходный файл сохраняйте, об ошибке сообщайте. Иначе автоматизация просто начнёт быстрее выдавать неверные отчёты.
Бесплатным процесс от этого не становится: остаются расходы на запуск, внешние сервисы и поддержку. Зато не приходится каждую неделю просить модель заново придумать одну и ту же обработку. Агент понадобится снова, когда изменятся данные или требования.
С чего начать в своём проекте
На следующей знакомой задаче зафиксируйте критерий приёмки, доступные материалы и исходный уровень рассуждения. После результата измените только то, что объясняет обнаруженную проблему. Несколько таких сравнений скажут о настройке больше, чем постоянный максимум или обещание агента «тратить меньше».
- Эдвард Гришин: «GPT-6 Astra разбор 35+ функций. Пора переходить на Codex с Claude Code?»
- Канал «Эдвард Гришин | AI и автоматизация бизнеса»
- OpenAI: GPT-6 Astra
- OpenAI: Model guidance
- OpenAI: Reasoning models
- OpenAI: AGENTS.md
- OpenAI: Subagents
- OpenAI: Pricing
Источники и проверка
Технические источники и расчёты проверены 3 октября 2026 года. Сценарии и схемы — учебные примеры Neaptide; сравнительные замеры продуктов не проводились.