Как GPT-5.6-Sol Xhigh сжёг 6,4 млрд токенов на переписывании 460 статей

6 418 529 757 токенов. 222 отдельные ветки работы. 564 хода модели. Около $25 000 по расчётной стоимости использования через API.

Исходная задача звучала намного скромнее: улучшить примерно 460 статей для двух сайтов, AI4SALE и Мед ИТ (MYOD.IT). Полезную техническую часть нужно было сохранить, формулировки в стиле инструкции для внутренней команды заменить на понятный разговор с покупателем, для подходящих материалов подготовить отдельные продающие статьи и расставить публикации по календарю WordPress.

GPT-5.6-Sol в режиме рассуждения xhigh превратил эту работу в бесконечную проверку проверок. Уже исправленные статьи перечитывались заново. Рецензентам передавались устаревшие копии. Несовпадение хеша старого отчёта с новым файлом становилось поводом сомневаться во всём корпусе. Создавались внутренние доказательные материалы, которые не улучшали текст и не приближали публикацию.

Красивого технического названия здесь нет. Это был дорогой операционный пиздец. Модель умела написать статью, проверить её, вызвать скрипт, работать с WordPress и открыть результат в браузере. Но управляющий агент не задал общий предел расходов и не связал завершение задачи с фактической публикацией.

Что требовалось сделать на самом деле

Нормальный процесс для одной статьи состоял из девяти шагов:

1. Один раз прочитать текущий исходный материал.
2. Решить, подходит ли тема для отдельной продающей статьи.
3. Написать новую версию из текущего файла.
4. Провести одну независимую смысловую проверку.
5. Исправить только найденные и точно указанные дефекты.
6. Назначить дату публикации.
7. Создать в WordPress запись типа post.
8. На одной статье проверить административную панель и страницу в браузере.
9. Применить проверенный скрипт к остальной очереди.

До размещения скрипту достаточно было проверить несколько фактов: файл существует, дата указана, запись с таким адресом ещё не создана, тип записи равен post. После успешной пробной публикации тот же маршрут можно было повторить для всей очереди.

Вместо этого система начала производить уверенность для самой себя.

Сколько стоила эта уверенность

Показатель дерева задачи	Зафиксированное значение	Что оно показывает
Общий объём	6 418 529 757 токенов	Совокупная обработка в основной задаче и дочерних ветках
Ветки	222	Количество отдельных контекстов выполнения
Ходы	564	Количество взаимодействий модели в дереве задачи
Материалы	Около 460	Русские и английские статьи в проекте
Среднее отношение	Около 13,95 млн токенов на статью	Масштаб потерь процесса, а не сложность текста
Расчётная стоимость	Около $25 000	Оценка эквивалента через API, а не утверждение о счёте

При такой оценке одна статья обошлась примерно в $54 модельных расходов. За эти деньги материал должен писать сильный отраслевой журналист с интервью, исследованием и редактором. Здесь большая часть суммы ушла на повторную обработку уже готового текста.

Как сильная модель построила глупую систему

1. Для каждой статьи не определили единственный текущий файл

Одна и та же статья существовала как исходник, исправленная версия, копия для рецензента, строка в реестре, запись в отчёте и объект WordPress. Управляющий агент не закрепил один обязательный источник перед раздачей работы.

Рецензент мог получить версию до последнего исправления. Он честно находил в ней старую проблему. Автор открывал актуальный файл и видел, что проблема уже устранена. Вместо признания устаревшего входа система решала, что качество статьи снова вызывает сомнения.

2. Несовпадение хеша превратили в смысловую проблему

Хеш отвечает на узкий вопрос: совпадают ли байты двух файлов. Он не определяет качество текста, готовность к публикации и применимость старого отчёта к новой версии.

В этом процессе устаревший хеш получил слишком много власти. Когда отчёт относился к прежнему файлу, нужно было отбросить отчёт и проверить только не прошедшее правило на текущем файле. Вместо этого запускалось новое чтение статьи. Новый рецензент предлагал другую формулировку, появлялось очередное исправление, хеш снова менялся.

3. Проверка стала самостоятельным продуктом

Бизнесу были нужны опубликованные статьи. Внутренняя система считала прогрессом отчёты, таблицы, статусы, доказательные материалы и утверждения, что пакет проверен. Агентам было проще создать ещё один внутренний документ, чем доказать результат в WordPress и браузере.

Так возникает опасная ловушка. Дополнительная проверка выглядит осторожной. Ещё один отчёт выглядит ответственным. Повторный проход кажется небольшой ценой за уверенность. Если общая цена нигде не считается, каждое локальное решение кажется разумным, а вся система становится безумно дорогой.

4. Готовые статьи возвращались в начало процесса

Статусы «написано», «проверено», «исправлено», «готово», «в очереди», «запланировано» и «видно на сайте» обсуждались, но не работали как строгая последовательность. Готовая статья могла снова попасть на полную смысловую проверку из-за старого отчёта или несоответствия реестра.

Для возврата не требовалось нового доказательства дефекта в текущем файле. Система снова платила за уже принятую работу.

5. Большой унаследованный контекст умножал стоимость каждого хода

Режим xhigh полезен для сложного выбора, но здесь он усилил ошибку управления. Дочерние агенты получали длинную историю, старые заключения, новые правила, тела статей, пояснения статусов и предыдущие исправления. Перед работой с одним файлом модель повторно обрабатывала огромный объём прошлого контекста.

Проблема возникла не из-за недостатка интеллекта. Модель заставили согласовывать несколько источников истины, хотя устаревшие источники следовало сразу исключить.

6. Точные факты поручили дорогой рассуждающей модели

Наличие файла, дата, тип записи WordPress, отсутствие дубля, код ответа страницы и наличие нужного блока проверяются обычной программой. Здесь агенты многократно читали отчёты об этих фактах и формулировали уровень уверенности.

Самая мощная модель в цепочке стала очень дорогой заменой проверки файлов, дат и нескольких полей базы данных.

7. Завершение объявили до проверки результата на сайте

Провал стал очевиден, когда количество статей в административной панели AI4SALE не изменилось. Одна запись была создана как page, хотя все статьи сайта имели тип post. Другая проверка подтвердила правильную дату, но не ответила на главный вопрос: открывается ли материал по нужному адресу и нормально ли выглядит.

Система потратила миллиарды токенов на доказательства, но не выполнила простую приёмку: создать одну отложенную запись, увидеть её в правильном разделе WordPress, открыть страницу в браузере и проверить отображение.

Почему почти универсальный ИИ сам не остановился

Интеллект модели не заменяет цель, которую забыл задать управляющий процесс. Основной агент определял число дочерних задач, состав контекста, количество проходов и причины повторного открытия работы. Рецензенты выполняли полученные задания. Дочерние агенты не могли самостоятельно изменить общую экономику проекта.

Не хватало четырёх простых ограничений:

• одного текущего файла для каждой статьи;
• приёмки, связанной с публикацией;
• максимального числа написаний и проверок;
• общего предела токенов и расчётной стоимости для всего дерева задачи.

Без них почти универсальная система может быть разумной на каждом отдельном шаге и нелепой в целом. Любую следующую проверку можно объяснить. Итогом всё равно становятся $25 000 за перемещение текста между файлами.

Как выглядел бы нормальный скрипт публикации

for article in manifest:
    assert article.source_file.exists()
    assert article.publish_at is not None
    assert article.post_type == "post"

    current = wordpress.find_by_slug(article.slug)
    if current:
        assert current.status in {"future", "publish"}
        continue

    post_id = wordpress.create_post(
        title=article.title,
        slug=article.slug,
        content=article.html,
        status="future",
        date=article.publish_at,
    )

    result = wordpress.get(post_id)
    assert result.post_type == "post"
    assert result.status == "future"
    assert result.date == article.publish_at

Сначала этот код запускается для одной статьи. Затем статья проверяется в административной панели и браузере. После успешной приёмки тот же скрипт обрабатывает остальные строки реестра. Ошибка одной строки требует исправить строку или общий программный дефект. Она не требует снова читать 460 текстов.

Какое правило появилось после провала

1. До раздачи работы фиксируются текущий источник, приёмка, число проходов, общий предел расходов и условие остановки.
2. По умолчанию выполняются одно написание и одна независимая смысловая проверка.
3. Исправляются только точно указанные дефекты.
4. Новая полная проверка требует нового доказательства проблемы.
5. Точные факты проверяются скриптами.
6. На одном материале проверяется весь путь до рабочей системы.
7. Принятый способ масштабируется без повторного аудита всего корпуса.

Главный урок неприятен: мощная модель способна дольше скрывать плохой процесс, потому что продолжает производить правдоподобные результаты. Нужна не более слабая модель. Нужна меньшая и понятная система с ограниченной стоимостью и однозначным концом.

Вопросы руководителя после перерасхода ИИ

Термины

• GPT-5.6-Sol: техническое название модели, использованной в основной задаче.
• xhigh: название повышенного режима рассуждения модели.
• Токен: единица обработки текста моделью. Она не равна слову или символу.
• API: программный интерфейс, через который приложения вызывают модель и получают измеряемое потребление.
• Хеш: короткий цифровой отпечаток файла, используемый для проверки совпадения его содержимого.
• WordPress: система управления сайтом, в которой статьи создаются как записи типа post.

Если нужен не только разбор провала, но и рабочая защита, посмотрите, как Мед ИТ ограничивает повторные проверки и общую стоимость ИИ-агента.