Skip to main content
OpenAICodexлимиты

OpenAI двічі обнулив ліміти Codex

OpenAI дійсно двічі скинув ліміти Codex наприкінці червня 2026 року після регресійного багу, який надто швидко спалював щотижневі квоти користувачів. Для бізнесу це важливий сигнал: змінюється не лише доступність моделі, а й уся стратегія AI-автоматизації, управління витратами та планування навантажень у робочих процесах.

Технічний контекст

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

Подія сталася не сьогодні, а наприкінці червня 2026 року, приблизно 29-30 числа. Тож це вже не гаряча новина, а хороший розбір того, як OpenAI лагодить виробничий збій прямо на ходу та як це впливає на практичне впровадження ШІ.

Я покопався в деталях, і ось що дійсно важливо. Перше повне скидання повернуло користувачам доступ після поломки, а друге прийшло приблизно через годину як додатковий кредит на наступні 24 години. Паралельно OpenAI увімкнув reset banking: тепер один безкоштовний скид можна зберегти та активувати пізніше вручну.

Це не косметика. Якщо раніше ліміт був просто неприємною стіною, то тепер OpenAI робить його трохи ближчим до керованого ресурсу. Для тих, хто будує інтеграцію ШІ в IDE, CLI та агентні пайплайни, це вже архітектурна деталь, а не маркетингова дрібниця.

Що це змінює для бізнесу та автоматизації

Мій перший висновок простий: якщо ваш робочий процес зав'язаний на Codex, не можна вважати ліміти стабільною константою. Вони можуть змінюватися не лише через тариф, а й через аварійні виправлення, тому на продакшені потрібні запасні маршрути, локальні черги та fallback на інші моделі.

Другий момент – гроші. Коли баг з'їдає тижневу квоту за кілька годин, ламається не тільки UX, а й економіка AI-автоматизації. Маленькі команди виграють від тимчасових послаблень, а от тим, хто обіцяє клієнтам передбачуваний SLA, доводиться проектувати систему з запасом.

І так, reset banking мені подобається більше, ніж саме подвійне скидання. Це вже схоже на інструмент, який можна вбудувати в реальний процес, а не на разову компенсацію після пожежі.

Я завжди дивлюся на такі речі не як глядач, а як інженер: де крихкість, де можна втратити гроші, де користувачеві раптово перекриють кисень. Якщо у вас схожа історія з розробкою AI-рішень, давайте спокійно розберемо архітектуру: у Nahornyi AI Lab я допомагаю будувати AI-автоматизацію так, щоб одна чужа помилка не зупинила весь ваш процес.

Раніше ми детально розглядали, як тригери безпеки в OpenAI API сповіщають власників акаунтів і чому для стабільної роботи потрібне розділення середовищ. Ця тема набуває особливої актуальності на тлі почастішання автоматичних коригувань лімітів, про які зараз говорять користувачі.

Поділитися статтею