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

Это не один неудачный ответ и не спор о вкусе. В публичных тредах и технических отчётах повторяется один и тот же перелом: конкретный рабочий процесс сначала держался, а затем начал срываться под прежним названием модели. Пользователи приносили не только ругань, но и версии клиентов, журналы tool calls, response metadata, токенные распределения и сравнения близких задач.

Срез публичных данных — 2 сентября 2026 года. Astra объявлена близким релизом, но точная дата не названа.


🔥 Восемь переходов — след ведёт не только к модели

Мемная версия проста: перед новым запуском OpenAI нажимает кнопку «сделать старую модель тупее». Факты интереснее и неприятнее. В одном эпизоде менялся post-training, в другом Codex лишался рабочих инструментов, в третьем selector показывал одну модель, а сервер называл другую, в четвёртом reasoning останавливался на подозрительно круглой границе.

Значит, вопрос не в том, существует ли одна секретная кнопка. Вопрос в другом: сколько разных способов ухудшить один облачный продукт помещается под неизменным ярлыком? Хронология даёт ответ по нарастающей — от пользовательского «раньше работало» до технических следов в runtime и телеметрии.

📊 Вся картина одним взглядом

  • GPT‑4o → GPT‑4.1. Следующий релиз — 14.04.2025. Сигналы: 30.01, за 74 дня; 03.04, за 11 дней. Строгий сигнал есть, но рядом известное обновление 4o.
  • GPT‑4.1 / GPT‑4o → GPT‑5. Следующий релиз — 07.08.2025. Сигналы: 26.05, за 73 дня; 04.06, за 64 дня. Строгий сигнал есть, но источники смешивают разные модели и продукты.
  • GPT‑5 / GPT‑5‑Codex → GPT‑5.1. Следующий релиз — 12.11.2025. Сигналы: 09.10, за 34 дня; 11.10, за 32 дня; 06.11, за 6 дней. Один из самых сильных кластеров.
  • GPT‑5.1 → GPT‑5.2. Следующий релиз — 11.12.2025. Между релизами всего 29 дней, поэтому проверка окна 30–90 дней математически невозможна.
  • GPT‑5.2 → GPT‑5.3‑Codex. Следующий релиз — 05.02.2026. Сигнал: 10.01, за 26 дней. Строгий сигнал не найден, но compute официально менялся.
  • GPT‑5.3‑Codex → GPT‑5.4. Следующий релиз — 05.03.2026. Сигнал: 09.02, за 24 дня. Интервал между релизами короче 30 дней.
  • GPT‑5.4 → GPT‑5.5. Следующий релиз — 23.04.2026. Сигналы: 09.04, за 14 дней; 19.04, за 4 дня. Только поздняя предрелизная волна.
  • GPT‑5.5 → GPT‑5.6. Следующий релиз — 09.07.2026. Сигналы: 24.05, за 46 дней; 26.05, за 44 дня; 07.06, за 32 дня. Самое чистое совпадение.

Два перехода сразу отсекают красивую легенду: новая версия выходила раньше, чем старая успевала прожить хотя бы тридцать дней. Среди остальных переходов четыре дают жалобы внутри окна 30–90 дней, ещё два — только в последние четыре недели. Это не статистическое доказательство общего умысла. Это карта эпизодов, в которой повторяется симптом, а механизм каждый раз приходится устанавливать заново.


🎭 GPT‑4o → GPT‑4.1: под одним именем жили разные модели

GPT‑4o вышла 13 мая 2024 года, а GPT‑4.1 — 14 апреля 2025 года. Между ними успела появиться GPT‑4.5, однако именно GPT‑4.1 стала следующим крупным шагом в кодировании, следовании инструкциям и длинном контексте.

🧱 За 74 дня: Custom GPT «полностью испортилась»

30 января 2025 года на форуме OpenAI появился тред о резком ухудшении GPT‑4o после недавнего обновления. Автор использовал настроенную Custom GPT для творческой работы и подчёркивал, что до изменения она стабильно соблюдала структуру, стиль и заданные отношения между персонажами. Затем ответы стали фрагментарными, инструкции начали теряться, а давно отлаженное поведение исчезло.

“My experience with my custom GPT was completely ruined.”

Скриншот OpenAI Developer Community: автор пишет, что после обновления GPT‑4o его Custom GPT оказалась полностью испорчена

Жалоба сообщества: после обновления прежнее поведение Custom GPT исчезло — открыть исходный тред ↗.

Это важный тип свидетельства: не сравнение двух разных моделей, а до и после обновления одного и того же ярлыка.

Однако уже 11 февраля появился противоположный тред. Другой пользователь заметил, что GPT‑4o стала медленнее, внимательнее и лучше пишет код.

🪫 За 11 дней: «GPT стала действительно тупой в первом квартале»

3 апреля появился ещё один тред, где ухудшение приписывалось сразу GPT‑4o и GPT‑4.5 в течение первого квартала 2025 года. Само объяснение, которое модель затем придумала о собственных alignment-изменениях, доказательством считать нельзя. Языковая модель не имеет доступа к внутреннему журналу выкладок только потому, что говорит об этом уверенным тоном.

🧾 Что признала сама OpenAI

Официальный анонс GPT‑4.1 содержит особенно важную фразу: многие улучшения новой серии уже постепенно внедрялись в latest-версию GPT‑4o, и этот процесс должен был продолжаться.

Через две недели после релиза GPT‑4.1 OpenAI пришлось откатить другое обновление GPT‑4o из-за чрезмерной угодливости модели. В расширенном разборе компания сообщила, что с момента запуска GPT‑4o выпустила пять крупных обновлений основной модели, каждое с новым посттренингом, а также меняла системные инструкции.

Архивный скриншот официальной страницы OpenAI: после запуска GPT‑4o компания выпустила пять крупных обновлений поведения и полезности

Официальное подтверждение: под ярлыком GPT‑4o вышли пять крупных обновлений поведения — страница OpenAI ↗.

Это не доказывает намеренного ухудшения перед GPT‑4.1. Но полностью разрушает удобную корпоративную отговорку «название модели не изменилось, значит модель та же».

Так появляется первая трещина в ярлыке. Изменение GPT‑4o под прежним названием подтверждено официально; ухудшение отдельных старых workflow видно в пользовательских отчётах. Связь с подготовкой GPT‑4.1 не установлена, а противоположные отзывы не дают объявить деградацию глобальной.

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


📉 GPT‑4.1 → GPT‑5: источники начали появляться из воздуха

GPT‑5 вышла 7 августа 2025 года. Строгое предрелизное окно начинается 9 мая, поэтому майские и июньские жалобы подходят по времени почти идеально.

🔗 За 73 дня: GPT‑4.1 начала выдумывать источники

26 мая пользователь форума OpenAI сообщил, что GPT‑4.1 в последние дни стала заметно чаще придумывать источники и фальшивые URL. Другой участник написал, что переключение на GPT‑4o прекращало проблему. Позднее в том же обсуждении ухудшение датировали концом мая.

Скриншот OpenAI Developer Community: пользователь GPT‑4.1 сообщает о частых выдуманных источниках и фальшивых URL

Жалоба сообщества: GPT‑4.1 стала чаще придумывать источники и URL — открыть исходный тред ↗.

Сигнал выглядит убедительно по форме, но имеет существенную оговорку: GPT‑4.1 появилась в ChatGPT только 14 мая. Между пользовательским запуском и первой жалобой прошло двенадцать дней. Это может быть не «успевшая хорошо работать старая модель стала хуже», а просто раннее обнаружение дефекта свежего релиза.

🧠 За 64 дня: «становится всё глупее» несколько месяцев

4 июня появился Reddit-тред с прямым заголовком: «ChatGPT становится всё глупее. Куда нам бежать?» Тело обсуждения не удалось независимо восстановить через доступные live, JSON, old.reddit и архивные маршруты. Поэтому этот источник учитывается как свидетельство существования жалобы, но не используется для сильных выводов о её деталях или массовости.

🪃 Временная близость к официальному откату

24–25 апреля OpenAI развернула обновление GPT‑4o, которое сделало модель чрезмерно соглашательской. 28–29 апреля обновление откатили. Иными словами, заметный пользовательский перелом «после конца апреля» совпадает не только с ожиданием GPT‑5, но и с документированным неудачным изменением существующей модели.

Технически более простая версия выглядит так:

Цепочка эпизода: обновление GPT‑4o → изменение поведения → откат → майско-июньская волна жалоб → релиз GPT‑5.

Связь по времени с GPT‑5 существует. Но конкретный известный инцидент GPT‑4o объясняет жалобы лучше, чем гипотеза о тайном урезании серверов ради августовского запуска.

Временное совпадение с GPT‑5 есть, но причинный след распадается: GPT‑4.1 была слишком свежей, GPT‑4o только что пережила признанный неудачный апдейт, а в обсуждениях смешивались разные продукты. Этот эпизод усиливает хронологию, но не даёт единого механизма.

Зато осенью 2025 года спор о впечатлениях закончился. Codex не просто отвечал хуже — у него начали отказывать руки.


🧨 Codex → GPT‑5.1: агент перестал делать работу

GPT‑5.1 вышла 12 ноября 2025 года. Здесь предрелизная картина значительно чище: несколько независимых сообщений появляются почти одновременно, а один из багов воспроизводится на уровне runtime.

📴 За 34 дня: «Codex больше вообще не пишет код»

9 октября пользователь официального форума написал, что за предыдущую неделю Codex разрушил несколько копий кодовой базы, перестал вносить реальные изменения и начал создавать текстовые описания того, что следовало бы сделать.

“Now Codex does not write code at all.”

Скриншот OpenAI Developer Community: автор жалуется, что Codex перестал писать код и выдаёт объяснения вместо изменений

Жалоба сообщества: Codex подменял реальное изменение кода текстом о том, что надо сделать — открыть исходный тред ↗.

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

🐇 В те же дни: 50 минут работы превратились в десять

На Reddit появился тред с прямым вопросом: не стал ли Codex «тупым за последние несколько дней». Его тело не было независимо восстановлено, поэтому заголовок остаётся только слабым сигналом времени. Доказательную нагрузку этого раздела несут соседние проверенные источники: форумная жалоба о подмене кода объяснениями и воспроизводимый runtime-баг.

🛠️ За 32 дня: агенту переломали руки на уровне sandbox

11 октября в репозитории Codex появился баг-репорт о регрессии sandbox и сетевых разрешений. Даже при полном доступе агент не мог выполнять ожидаемые операции, получал отказы инструментов, повторно запрашивал подтверждения, зацикливался или переходил к догадкам.

Скриншот GitHub issue openai/codex 5090: runtime продолжал блокировать операции при заявленном полном доступе и включённой сети

Технический отчёт: ограничение находилось в runtime, а не только в пользовательской конфигурации — GitHub issue #5090 ↗.

С точки зрения пользователя такая поломка выглядит ровно как падение интеллекта:

раньше агент находил файл и запускал команду
теперь агент рассуждает, просит разрешение, снова рассуждает и ничего не делает

Но базовая модель в этом сценарии может быть совершенно ни при чём. Умному агенту просто не выдали рабочие руки, а затем оценили его по тому, сколько мебели он собрал.

🚨 За шесть дней: «Codex стремительно деградирует»

6 ноября появился крупный тред, где автор утверждал, что до середины сентября Codex был надёжным рабочим инструментом, а затем большая часть задач стала зависать, завершаться отказом или создавать новые регрессии.

Особенно интересен контрольный пример: внешний агент, использующий GPT‑5, по словам автора работал лучше официального Codex. Если одна и та же базовая модель лучше ведёт себя в другом harness, подозрение падает на системный промпт, context management, tools, routing и клиентскую обвязку.

🧭 Важная развилка: старая модель или новый Codex?

15 сентября, почти за два месяца до GPT‑5.1, OpenAI выпустила GPT‑5‑Codex. Значительная часть октябрьских проблем могла быть последствием именно этой перестройки продукта.

Получается любопытная, но менее конспирологическая последовательность:

Цепочка эпизода: новый GPT‑5‑Codex → изменения клиента и runtime → октябрьские сбои → ноябрьская волна жалоб → GPT‑5.1.

Эти сообщения складываются в первый по-настоящему сильный кластер:

Дата До GPT‑5.1 Сигнал
09.10.2025 34 дня Codex перестал выполнять кодовые задачи
11.10.2025 32 дня Воспроизводимая регрессия sandbox и tools
06.11.2025 6 дней Широкая волна «сервис стремительно деградирует»
12.11.2025 0 Релиз GPT‑5.1

Предрелизное ухудшение продукта здесь подтверждается значительно сильнее, чем в предыдущих эпизодах. Но самая весомая улика ведёт к Codex runtime и обновлению агентной системы, а не к намеренной порче весов GPT‑5.

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


🧮 GPT‑5.1 → GPT‑5.2: здесь гипотезу спасать нельзя

GPT‑5.1 вышла 12 ноября, а GPT‑5.2 — 11 декабря 2025 года. Между релизами прошло всего 29 дней.

Это означает, что GPT‑5.1 физически не могла начать деградировать за 30–90 дней до GPT‑5.2: в начале исследуемого окна её ещё не существовало.

Показательный community-тред всё же существует — и именно его дата проводит границу. Автор сравнивает gpt-5-chat с 51c и 52c, жалуясь, что новые варианты хуже следуют инструкциям, чаще повторяются и менее аккуратно форматируют ответы.

Скриншот OpenAI Developer Community от 12 декабря 2025 года: автор считает chat-варианты GPT‑5.1 и GPT‑5.2 хуже GPT‑5-chat в следовании инструкциям и качестве ответов

Жалоба сообщества опубликована уже после релиза GPT‑5.2 и потому показывает недовольство новыми chat-вариантами, а не предрелизную деградацию GPT‑5.1 — открыть исходный тред ↗.

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

Переход GPT‑5.1 → GPT‑5.2 ничего не подтверждает и ничего не опровергает. Он просто непригоден для заданного временного окна.


⏱️ GPT‑5.2 → GPT‑5.3: OpenAI уменьшила время на размышление

GPT‑5.3‑Codex вышла 5 февраля 2026 года. Чистого пользовательского сигнала внутри строгого окна найти не удалось. Зато за 26 дней до релиза произошло нечто гораздо более интересное, чем очередной тред «кажется, стало хуже».

🎩 За 26 дней: выбрана GPT‑5.2, отвечает GPT‑5.1‑Codex‑Max

10 января в GitHub появился issue: конфигурация явно указывала gpt-5.2, но сообщение об ошибке показывало, что запрос обслуживает gpt-5.1-codex-max. До 9 января тот же сценарий работал.

Скриншот GitHub issue openai/codex 9039: в конфигурации выбрана GPT‑5.2, а сообщение об ошибке называет GPT‑5.1‑Codex‑Max

Технический отчёт: выбранный selector и model ID, названный сервером в сообщении об ошибке, не совпали — GitHub issue #9039 ↗.

Это не анализ стиля ответа и не догадка по длине reasoning. В конкретном self-report выбранная конфигурация и model ID, указанный в сообщении об ошибке, расходились.

🧠 В тот же день OpenAI уменьшила thinking time

Официальные Model Release Notes фиксируют следующую последовательность:

Дата Изменение GPT‑5.2
10 января Уменьшено стандартное время размышления для Standard и Light
10 января Extended непреднамеренно уменьшен вместе с ними
3 февраля Standard сокращён ещё немного
4 февраля Extended возвращён к прежнему значению
5 февраля Выпущена GPT‑5.3‑Codex

OpenAI объяснила такие изменения поиском баланса между скоростью и качеством.

Архивный скриншот Model Release Notes OpenAI: Standard и Light thinking time уменьшили, а Extended непреднамеренно снизили и затем восстановили

Официальное подтверждение: OpenAI уменьшала thinking time, а случайное снижение Extended позднее исправила — Model Release Notes ↗.

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

Строгое окно 30–90 дней здесь не подтверждено: лучшие сигналы появились за 26 дней. Зато исчезла абстракция «модель как будто думает меньше». Thinking time действительно менялся под тем же названием, Extended был урезан случайно, а в отдельном self-report выбранный selector расходился с model ID из сообщения об ошибке. Мотив неизвестен: данных об освобождении ресурсов именно под GPT‑5.3‑Codex нет.

Через месяц selector и указанный сервером model ID снова разошлись — уже без необходимости судить о качестве ответа.


🪄 GPT‑5.3 → GPT‑5.4: выбрали новую модель, получили старую

Между GPT‑5.3‑Codex и GPT‑5.4 прошло всего 28 дней: 5 февраля и 5 марта 2026 года. Поэтому строгая проверка периода 30–90 дней снова невозможна.

Тем не менее 9 февраля появился технический отчёт: пользователь выбрал GPT‑5.3‑Codex и в интерфейсе, и в конфигурации, однако поток SSE содержал:

response.model = gpt-5.2-2025-12-11

Issue сохранился в официальном репозитории Codex.

Скриншот GitHub issue openai/codex 11189: интерфейс и конфигурация показывают GPT‑5.3‑Codex, а SSE — GPT‑5.2

Технический отчёт: GPT‑5.3 была выбрана в клиенте, но в ответе зафиксирована GPT‑5.2 — GitHub issue #11189 ↗.

Для гипотезы «старая модель тупеет за один–три месяца» этот переход бесполезен. Для понимания облачного продукта — очень полезен: оценивать стабильность только по названию в selector нельзя.


🌀 GPT‑5.4 → GPT‑5.5: час работы превратился в восемь минут

GPT‑5.4 вышла 5 марта, GPT‑5.5 — 23 апреля 2026 года. Интервал в 49 дней позволяет искать строгий сигнал, но подходящего свидетельства «раньше было хорошо, затем стало хуже» в первых трёх неделях найдено не было.

19 марта появился тред о GPT‑5.4 как о «упрямом стажёре», требующем постоянного надзора. Но автор честно сообщил, что недостаточно использовал предыдущие версии для исторического сравнения. Поэтому этот пост показывает плохой опыт, а не деградацию со временем.

🪨 За 14 дней: «тупая как камень последние недели»

9 апреля пользователь форума OpenAI сообщил, что GPT‑5.4 в Codex последние недели делает базовые ошибки, игнорирует запросы и теряет инструкции.

“Dumb as a rock these past few weeks.”

Скриншот OpenAI Developer Community: пользователь GPT‑5.4 сообщает о базовых ошибках и потере инструкций в последние недели

Жалоба сообщества: за две недели до GPT‑5.5 модель допускала базовые ошибки и не выполняла просьбы — открыть исходный тред ↗.

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

⌛ За четыре дня: 60 минут превратились в восемь

19 апреля появился более контролируемый пример. Пользователь повторял один класс длинной задачи с большим набором файлов, сопоставлением источников и конкретным письменным deliverable.

Ранний запуск GPT‑5.4 Pro Standard работал около часа и завершил работу. Поздний запуск той же модели занял примерно восемь минут, но выдал краткое резюме вместо основного результата.

Такое изменение хорошо согласуется с adaptive reasoning или сокращённым бюджетом, но одиночный опыт не раскрывает серверную причину.

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

раньше — длительный запуск и готовый результат
позже — быстрое завершение и пропущенный deliverable
через несколько дней — новая модель

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

У GPT‑5.5 масштаб доказательств меняется: к форумной жалобе добавляются повторная задача, локальная телеметрия и распределение reasoning-токенов.


🏆 GPT‑5.5 → GPT‑5.6: жалоба превратилась в телеметрию

GPT‑5.5 вышла 23 апреля, GPT‑5.6 — 9 июля 2026 года. Между ними прошло 77 дней — почти идеальный интервал для проверки.

Именно здесь жалобы складываются не в одну эмоциональную ветку, а в последовательную лесенку из форума, GitHub, локальной телеметрии и анализа reasoning-токенов.

🧱 За 46 дней: «раньше xhigh работал часами»

24 мая на форуме OpenAI появился тред о заметной деградации GPT‑5.5. Автор специально зафиксировал контрольные условия: кодовая база существенно не менялась, workflow оставался прежним, а модель раньше хорошо исправляла те же классы проблем.

Затем GPT‑5.5 начала:

  • хуже соблюдать инструкции;
  • слишком рано объявлять патч готовым;
  • создавать крупные регрессии;
  • игнорировать коррекции пользователя;
  • быстрее завершать xhigh, не доходя до прежней глубины.

“Previously xhigh would run for hours…”

Скриншот OpenAI Developer Community: при прежних кодовой базе и workflow GPT‑5.5 стала хуже соблюдать инструкции и преждевременно объявлять патч готовым

Жалоба сообщества: workflow не менялся, но GPT‑5.5 стала раньше завершать работу и возвращать ошибочные патчи — открыть исходный тред ↗.

В последующих сообщениях другие пользователи описали похожий перелом «с прошлой недели». Некоторые вернулись к GPT‑5.4 и получили более стабильное поведение. Представитель сообщества сообщил о выпущенном исправлении, но часть участников ответила, что проблема сохранилась.

📦 За 44 дня: подозрение на swap или requantization

26 мая в официальном репозитории Codex появился issue о значительной регрессии codex-5-5 на xhigh.

Автор сравнивал текущее состояние с тем, как модель работала несколькими неделями ранее. Симптомы включали игнорирование AGENTS.md, повторное внесение уже исправленных ошибок, потерю цели многошагового workflow, пропущенные или выдуманные tool calls. Проблема проявлялась и в CLI, и в IDE.

Пользователь прямо спросил, не была ли модель обновлена, заменена или переквантизована. Это важная гипотеза автора, но не установленный факт. Сам issue подтверждает только наблюдаемый перелом и его воспроизведение в нескольких интерфейсах.

Скриншот GitHub issue openai/codex 24539: автор фиксирует потерю инструкций AGENTS.md и возврат уже исправленных ошибок в CLI и IDE

Техническая жалоба: инструкции теряются, а исправленные ошибки возвращаются в нескольких клиентах — GitHub issue #24539 ↗.

📊 За 32 дня: 2 702 запроса превращают ощущение в телеметрию

7 июня появился один из наиболее содержательных отчётов всей ретроспективы. Автор проанализировал локальные JSONL-сессии Codex:

  • 2 702 пользовательских запроса;
  • 56 717 tool calls;
  • 530 сессий;
  • несколько одних и тех же проектов в разные периоды.

В качестве косвенного показателя использовалась доля запросов, содержащих признаки исправления агента, раздражения или повторного указания на уже объяснённую ошибку.

  • Базовый период, 24 апреля — 10 мая: 786 запросов; 31 запрос с маркерами исправления; доля — 3,9%.
  • Переходный период, 11–24 мая: 1 097 запросов; 64 запроса с маркерами исправления; доля — 5,8%.
  • Поздний период, 25 мая — 7 июня: 819 запросов; 99 запросов с маркерами исправления; доля — 12,1%.

Скриншот GitHub issue openai/codex 26876: локальная выборка из 2 702 запросов показывает рост маркеров исправления и раздражения с 3,9 до 12,1 процента

Технический отчёт одного автора: в локальной выборке доля маркеров раздражения выросла с 3,9% до 12,1% — GitHub issue #26876 ↗.

В отдельных стабильных проектах рост был ещё резче:

Проект Базовый период Переходный Поздний
Проект A 3,1% 6,4% 20,3%
Проект B 2,9% 4,2% 14,9%

Это не лабораторный benchmark. Пользователь мог постепенно ставить более сложные задачи, а фразы раздражения остаются косвенным показателем. Но сравнение внутри тех же проектов серьёзно ослабляет объяснение «просто кодовая база стала другой».

Ещё одна честная деталь: несколько проектов в той же статистике не показали ухудшения. Значит, даже сильная телеметрия не доказывает глобальное падение интеллекта модели. Она показывает выраженную временную регрессию в отдельных повторяющихся workflow.

💸 За 14 дней: десять итераций вместо одной

25 июня пользователь Pro сообщил о резком изменении поведения за предыдущие два дня. Экран Flutter, аналогичный созданному моделью двумя днями ранее, вместо одного качественного прохода потребовал около десяти итераций. Модель хуже использовала память проекта и инструкции AGENTS.md.

“The last two days GPT 5.5 doesn’t feel like 5.5.”

Скриншот GitHub issue openai/codex 30137: автор сообщает о деградации качества, дизайна и памяти GPT‑5.5 на близкой повторной Flutter-задаче

Жалоба пользователя: похожая Flutter-задача вместо одного прохода потребовала около десяти итераций — GitHub issue #30137 ↗.

Сила этого свидетельства не в эмоциональной формулировке, а в близком повторе одной и той же практической задачи.

🧮 За 12 дней: reasoning останавливается на подозрительно круглых границах

27 июня появился технический анализ 390 195 записей о токенах из 865 сессий. GPT‑5.5 составляла лишь 19,3% всех ответов, но на неё приходилось 82% случаев, когда reasoning завершался ровно на 516 токенах.

Скриншот GitHub issue openai/codex 30364: таблица по 390 195 записям показывает концентрацию exact‑516 событий у GPT‑5.5

Технический анализ: GPT‑5.5 дала 19,3% ответов, но 82% событий с точным значением 516 reasoning-токенов — GitHub issue #30364 ↗.

Доля ответов GPT‑5.5, остановившихся точно на этой границе среди ответов с не менее чем 516 reasoning-токенами, менялась так:

Месяц 2026 года Exact 516
Февраль 0,11%
Март 2,45%
Апрель 4,25%
Май 53,30%
Июнь 35,84%

Одновременно среднее число reasoning-токенов снизилось:

Месяц Среднее число reasoning-токенов
Февраль 268,1
Март 256,8
Апрель 228,7
Май 106,9
Июнь 168,5

Наблюдались также пики около 1 034 и 1 552 токенов, похожие на ступенчатые лимиты.

Автор корректно подчеркнул, что анализ не доказывает скрытое обрезание chain of thought. Более узкий вывод выглядит надёжнее: у GPT‑5.5 возникло выраженное кластеризованное поведение, согласующееся с фиксированным reasoning budget, scheduler, fallback или другим серверным порогом.

🏗️ Контраргумент: модель не тупеет, проект раздувается

14 июня на Reddit появился контрпост с тезисом прямо в заголовке: «GPT‑5.5 не урезали — просто ваш проект раздулся». Тело поста независимо не восстановлено, поэтому ему нельзя приписывать подробную аргументацию. Сам альтернативный механизм, однако, реален: поздняя задача может стать объективно тяжелее из-за выросшей кодовой базы, накопленных компромиссов, конфликтующих правил и засорённого контекста.

Это сильное объяснение части жалоб. Оно особенно правдоподобно там, где пользователь сравнивает ранний маленький проект с поздним большим.

Но оно хуже объясняет несколько деталей:

  • одновременный перелом у разных пользователей;
  • возврат качества при переключении на предыдущую модель;
  • одинаковые задачи и почти одинаковые файлы;
  • резкое сокращение reasoning-времени;
  • пики на фиксированных токенных границах;
  • сообщение о выпущенном исправлении.

🧷 Здесь жалоба выдерживает проверку с четырёх сторон

Это самый сильный случай всей ретроспективы не из-за громкости формулировок, а из-за разных независимых углов наблюдения.

Цепочка сильнейшего эпизода: сильный старт GPT‑5.5 → жалобы → локальная телеметрия → повторная задача → токенные аномалии → GPT‑5.6.

Проверка Результат
У модели было зафиксировано сильное исходное состояние
Те же проекты и workflow стали требовать больше исправлений
Жалобы появились за 30–90 дней до следующей модели
Есть количественная локальная телеметрия
Есть независимые форумные и GitHub-сигналы
Доказана квантизация
Доказана подготовка ресурсов именно под GPT‑5.6

В отдельных повторяющихся workflow временная регрессия здесь выглядит очень правдоподобно. Причина остаётся неизвестной: checkpoint, reasoning budget, routing, scheduler, системные инструкции или сочетание нескольких факторов.

После GPT‑5.6 история перестаёт быть ретроспективой. Astra ещё не имеет даты, а значит перед нами не доказанный новый цикл, а открытый эксперимент, за которым уже наблюдают пользователи.


👀 GPT‑5.6 → Astra: следующий эксперимент уже идёт

1 сентября 2026 года OpenAI опубликовала материал Path to Astra и сообщила о приближении следующей системы. Точной даты релиза пока нет, поэтому невозможно честно вычислить, находятся ли текущие жалобы за 12, 30 или 60 дней до точки ноль.

Тем не менее симптомы уже подозрительно знакомы.

🤖 После 25 июля: ломается стабильный multi-agent workflow

В GitHub issue от 27 июля описано ухудшение GPT‑5.6 Sol в ранее надёжной последовательности subagents. Первый spawn_agent выполнялся правильно, но вместо следующего запуска модель начинала выбирать несвязанный exec, фиктивный wait или shell-placeholder. Затем цикл повторялся.

Автор воспроизводил проблему с чистым CODEX_HOME, разными версиями клиента и несколькими аккаунтами. Старый baseline давал 17 успешных переходов spawn → spawn, а серия новых не дала ни одного.

Скриншот GitHub issue openai/codex 35620: прежде надёжная цепочка последовательных subagents стала выбирать exec и wait вместо следующего spawn

Технический отчёт: после 25 июля цепочка spawn → spawn перестала воспроизводиться на новых запусках — GitHub issue #35620 ↗.

Такой отчёт не доказывает, что checkpoint Sol стал глупее. Наблюдение совместимо с дрейфом tool-selection или runtime, но по одному self-report конкретная причина остаётся открытой.

🏛️ Август: governance вместо результата

Другой issue описывает характерную для длинных агентных задач патологию: ограниченное изменение кода разрастается в самоподдерживающуюся инфраструктуру проверок.

Агент добавляет hash-схемы, snapshots, подписи, retries, состояния и approval gates. Затем новые сущности требуют миграций, тестов и документации. В следующей сессии модель принимает созданные ею же вспомогательные конструкции за обязательные требования проекта.

Скриншот GitHub issue openai/codex 39059: ограниченная задача разрастается в самоподдерживающуюся систему проверок и governance

Жалоба пользователя: вспомогательная инфраструктура вытесняет исходную ограниченную задачу — GitHub issue #39059 ↗.

Итог выглядит солидно только по количеству diff:

больше файлов
больше проверок
больше токенов
больше архитектурных решений без владельца
меньше выполненной исходной задачи

Это уже не обычная ошибка программирования. Это потеря иерархии целей: вспомогательная активность вытесняет deliverable.

🔄 Часть нынешней боли находится в runtime

Отдельное сравнение GPT‑5.6 Luna на разных версиях Codex CLI показало резкую регрессию высоких уровней effort. Старый клиент завершал сложный запуск, а новый мог зациклиться на compaction, многократно перерабатывать контекст и не сходиться часами. При этом качество успешно завершённых запусков не обязательно ухудшалось.

Скриншот GitHub issue openai/codex 41318: сравнение двух Codex CLI показывает рост времени и стоимости high-effort запусков Luna и один несошедшийся прогон

Технический отчёт: новый CLI резко увеличил время и стоимость, а худший прогон не сошёлся — GitHub issue #41318 ↗.

Это сильный аргумент против слишком простой версии «у модели испортили веса». Иногда агент не становится менее умным — он просто тратит весь вечер на пережёвывание собственного контекста.

🔮 Почему Astra пока нельзя объявлять причиной

OpenAI официально пишет, что ради Astra менялись процессы безопасности и подготовки релиза. Но публичных данных, связывающих эти работы с текущими проблемами GPT‑5.6, нет.

Текущую ситуацию правильнее считать открытым наблюдением, а не девятым подтверждённым повтором:

Наблюдение Статус
Жалобы на drift и незавершённые задачи существуют Подтверждено обсуждениями и issue
Некоторые регрессии зависят от Codex runtime Есть технические свидетельства
Похожие симптомы могут возникать в других agent harness Возможный указатель на общий serving-слой
Astra близка к релизу Подтверждено OpenAI
GPT‑5.6 намеренно урезали ради Astra Не доказано

Астра здесь выполняет последнюю функцию: показывает, насколько легко знакомый симптом превратить в готовое обвинение раньше доказательств. Чтобы не повторить эту ошибку, пора отделить правила отбора от самого рассказа.


🔬 Где заканчивается улика и начинается удобная история

В строгий зачёт попадали только жалобы за 30–90 дней до следующего релиза, где автор сравнивал состояние одного workflow во времени. Сигналы за 1–29 дней отмечались отдельно. Жалоба на уже вышедшую новую модель не могла подменить ухудшение старой.

Вес тоже был разным. Официальный откат или изменение thinking time сильнее форумного впечатления; response metadata, воспроизводимый runtime-баг и локальная телеметрия сильнее заголовка треда. Публичные обсуждения при этом смещены к проблемам: они показывают характер поломки, но не долю всех пострадавших пользователей.

Эта граница не обезвреживает вывод. Она делает его точнее: намеренная «лоботомия» не доказана, а изменчивость оплаченного рабочего продукта — доказана на нескольких разных слоях.


⚖️ Четыре вещи доказаны — и умысла среди них нет

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

🧾 Подтверждено официально или технически

Поведение меняется без смены названия. GPT‑4o получила несколько крупных mainline-обновлений с новым посттренингом, а один из апдейтов пришлось откатить.

Thinking budget регулируется на сервере. GPT‑5.2 получила уменьшенное время размышления; Extended был случайно урезан и позднее восстановлен.

Выбранные selector/config и названный сервером model ID могут расходиться. В нескольких GitHub self-reports конфигурация и response.model указывали разные версии; независимо установленный backend эти отчёты не доказывают.

Версия агентного runtime способна резко изменить результат. Sandbox, tool permissions и compaction давали воспроизводимые регрессии без доказанного изменения базовой модели.

Один ярлык не фиксирует весь обслуживающий стек. OpenAI прямо описывает routing, scheduling, caching и model implementation как отдельные слои эффективности GPT‑5.6; приведённые выше отчёты отдельно показывают изменения thinking time, runtime и несовпадения model ID.

🕵️ Не доказано

Нет публичных данных, подтверждающих, что OpenAI перед каждым релизом:

  • специально квантует старый флагман;
  • сознательно уменьшает его интеллект ради маркетингового контраста;
  • систематически пересаживает платных пользователей на дешёвый backend;
  • освобождает GPU под новинку за счёт тайного ухудшения старой модели;
  • проводит один и тот же предрелизный сценарий по заранее установленному календарю.

🧬 Вы покупаете не модель, а движущуюся мишень

В локальном запуске файл весов можно хешировать и повторить эксперимент на том же runtime. В облачном продукте пользователь получает не файл, а услугу.

Рабочая схема анализа: за одним ярлыком нужно проверять snapshot, thinking budget, routing, system prompt, context, tools и agent harness.

Изменение любого блока может выглядеть как «модель отупела».

Что изменилось Как это ощущается
Сократили thinking time Ответ быстрее, но поверхностнее; пропущены проверки
Router выбрал лёгкий режим Та же надпись внезапно даёт более слабую траекторию
Включился fallback Качество плавает после лимита или при нагрузке
Изменился system prompt Модель становится многословнее, угодливее или чрезмерно инициативной
Compaction потерял ограничения Агент забывает исходную цель длинной задачи
Tools не передались Агент рассуждает, но не может открыть файл или выполнить команду
Sandbox ужесточился Возникают циклы подтверждений и ложные отказы
Обновился harness Та же модель иначе планирует, проверяет и завершает работу
Проект вырос Раньше простая задача действительно стала объективно сложнее

OpenAI отдельно описывает, что эффективность GPT‑5.6 зависит не только от самой модели, но и от маршрутизации, scheduling, кеширования, реализаций kernels и speculative decoding. Это нормально для современной инфраструктуры. Проблема начинается тогда, когда все эти слои меняются без стабильного пользовательского контракта.

Архивный скриншот официальной страницы OpenAI: качество и эффективность GPT‑5.6 зависят от routing, scheduling, kernels, caching и реализации модели

Официальное объяснение: результат складывается из нескольких движущихся слоёв serving stack — страница OpenAI ↗.

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


🪞 Контраргументы сильны — но не закрывают технический след

Ретроспектива не должна превращать каждую неудачную сессию в улику против OpenAI. Существует несколько сильных альтернативных объяснений.

🏗️ Проект стал сложнее

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

🧑‍💻 Изменился сам пользовательский workflow

После первых удачных недель модели доверяют более длинные и рискованные задачи. Ошибки становятся дороже, а требования к автономности — выше. Субъективное «раньше была умнее» иногда означает «раньше ей давали задачи на двадцать минут».

🎰 Срабатывает память о лучших ответах

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

📣 Форумы измеряют боль, а не среднее качество

Человек, у которого всё работает, закрывает задачу и идёт дальше. Человек, потерявший восемь часов и половину лимита, пишет длинный тред с логами. Публичная выборка закономерно драматичнее реального среднего.

🧩 Но эти объяснения не закрывают всю картину

Они плохо работают там, где присутствуют:

  • одинаковые файлы и близкая повторная задача;
  • server metadata с другим model ID;
  • жёсткие токенные границы;
  • привязка к версии клиента;
  • официальный откат;
  • официальное уменьшение thinking time;
  • серия независимых жалоб в один период.

Именно поэтому наиболее сильные эпизоды — не самые громкие посты, а случаи, где субъективная жалоба подкреплена техническим следом.


🧪 Как перестать быть бесплатным QA-отделом

Чтобы уверенно заявить о предрелизном ухудшении модели, одного форума недостаточно. Нужен воспроизводимый набор данных.

🧰 Минимальный тестовый контур

Элемент Зачем нужен
Закреплённый набор задач Исключает постепенное усложнение проекта
Одинаковые system prompts и tools Отделяет модель от agent harness
Версии клиента и конфигурации Позволяет заметить runtime-регрессию
Response metadata Фиксирует названный сервером model ID для сравнения с selector/config, но не доказывает backend независимо
Время, токены, tool calls, compaction Обнаруживает сокращённый reasoning или циклы
Несколько повторов Снижает влияние случайности генерации
Контрольная модель Помогает проверить, связан ли сбой с конкретным alias или сохраняется в контрольном запуске
Публичный pinned snapshot Позволяет отделить новую выкладку от старой

Идеальный эксперимент выглядел бы так:

Контрольный тест: фиксированные задачи → одинаковый клиент и tools → сохранение metadata → слепая оценка → повтор на другом harness.

Проблема в том, что облачный пользователь обычно не получает главного элемента — закреплённого snapshot. Поэтому даже аккуратный внешний benchmark измеряет весь сервис, а не только веса модели.


📋 Вердикт: в нескольких случаях это было не ощущение

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

Гипотеза Итог
Перед несколькими следующими релизами пользователи сообщали об ухудшении прежнего workflow Да, такие эпизоды повторяются
Это происходит буквально перед каждым релизом Нет: два перехода непроверяемы, два дают только поздние сигналы
В строгом окне 30–90 дней есть несколько сильных кластеров Да: особенно перед GPT‑5.1 и GPT‑5.6
Под прежним названием OpenAI меняет поведение системы Подтверждено официально
Thinking budget может уменьшаться без переименования модели Подтверждено официально
Выбранные selector/config иногда расходятся с названным сервером model ID Зафиксировано в технических self-reports
Codex runtime способен сделать хорошую модель беспомощной Подтверждено воспроизводимыми issue
Старые модели каждый раз специально квантуют Доказательств нет
Старую модель намеренно портят, чтобы новая выглядела лучше Доказательств нет
Нынешние проблемы GPT‑5.6 вызваны подготовкой Astra Не подтверждено

📐 Сухая статистика

Из восьми изученных переходов:

  • 4 содержат подходящие жалобы в строгом окне 30–90 дней;
  • 2 дают только поздние сигналы за 1–29 дней;
  • 2 невозможно проверить, потому что между релизами прошло меньше 30 дней.

Эти числа нельзя превращать в вероятность вроде «OpenAI лоботомирует модель в 67% релизов». Исследование не имеет случайной выборки, базовой частоты жалоб и полного доступа к внутренним изменениям. Но оно уверенно опровергает более слабое утверждение:

«Пользователям всегда просто кажется; под тем же названием ничего существенного не меняется».

Меняется. Иногда это признаёт сама OpenAI.


🪦 Платящий пользователь стал QA-отделом OpenAI

Мемная версия истории звучит так:

Перед новым релизом кто-то нажимает кнопку «квантизировать старую модель», чтобы освободить GPU и заставить пользователей захотеть новинку.

Публичные данные этого не доказывают.

Но более осторожная версия выдерживает проверку:

OpenAI меняет отдельные слои production stack вокруг действующих моделей — post-training и reasoning budget; технические отчёты также показывают отдельные routing-, sandbox- и compaction-регрессии. В ряде описанных workflow такие изменения совпадали с ухудшением результата под прежним названием.

Иногда модель действительно получает меньше времени на размышление. В отдельных self-reports выбранные selector/config расходились с model ID, названным сервером; какой backend обслуживал inference, независимо не установлено. Иногда Codex runtime блокировал ожидаемые операции, а новая версия клиента зацикливалась на compaction. Иногда поведение меняли неудачным посттренингом и затем откатывали.

То есть единой кнопки:

СДЕЛАТЬ СТАРУЮ МОДЕЛЬ ТУПОЙ

может и не существовать.

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

Главная проблема здесь не в том, что быстро развивающийся облачный сервис иногда ломается. Это неизбежно.

Главная проблема — отсутствие стабильного, версионированного рабочего контракта:

одно название ≠ один snapshot
одно название ≠ один reasoning budget
одно название ≠ один model ID, указанный в ответе
одно название ≠ одинаковые tools
одно название ≠ одинаковое агентное поведение

Пользователь не обязан различать checkpoint, router, scheduler и sandbox, чтобы признать провал провалом. Он купил способность выполнить работу — и в описанных эпизодах именно она пропадала.

Для автора технического отчёта это выглядело как платное участие в production-тестировании. Пользователи ловят регрессии, сравнивают версии, собирают телеметрию и восстанавливают последствия тихих изменений. Бесплатный QA-отдел получился отличный. Только оплачивает его сам QA-отдел.

Поэтому минимальное требование к OpenAI звучит не радикально: точный model ID, понятный changelog, предупреждение до изменения поведения и возможность закрепить рабочую версию. Пока этого нет, фраза «ChatGPT был умнее вчера» остаётся не мемом, а нормальным описанием движущегося коммерческого продукта.