Моя довготривала ціль у Codex: чотири дні, і робота все ще триває
9 жовтня 2026 року моя довготривала ціль у Codex показувала 4 дні, 14 годин, 8 хвилин і 22 секунди. Я зробив знімок екрана, поки Codex усе ще працював над SEO-продуктом, який я ще не запустив. Ціль залишалася відкритою, а попереду було ще більше завдань.
Я попросив його виконати весь план для ще не випущеного SEO-продукту, який я створюю. До того моменту я також попросив його використовувати більше агентів, знизити рівень міркувань, призупиняти роботу для оновлень, продовжити після перезапуску та витрачати менше часу на повторне виконання тестів.
Це моя розповідь про довготривалу ціль у Codex: роботу, яку вона виконала, роботу, що її сповільнила, і рішення, які мені все ще доводилося ухвалювати. Це незавершена розробка, а не бенчмарк і не оголошення про запуск.
Таймер вище належить цілі. Він не підтверджує чотири дні безперервних обчислень моделі. Моя сесія містить явні паузи й відновлення, оновлення застосунку, перезапуск комп’ютера, виконання інструментів і очікування.
Що я попросив Codex створити
Розмова почалася 3 жовтня з меншого питання: чи мають користувачі власні облікові дані для входу, чи можуть вони входити через Google і чи можуть генерувати персональні ключі MCP?
Потім я розширив вимоги. Кожен користувач мав бачити власні проєкти. Користувачі мали мати змогу запрошувати людей до робочого простору. Я хотів налаштування для персональних уподобань і паралельності роботи краулера. Платформа зрештою мала стати комерційною, із безкоштовним початковим запуском.
Я надав значно більший каталог SEO-продуктів, щоб спрямувати розробку. План, що виник у результаті, охоплював 15 напрямів продукту, 42 згадки про застосунки та 19 публічних безкоштовних інструментів, а також функцію ранжування трафіку вебсайтів. Він включав технічне SEO, дослідження ключових слів, позиції, зворотні посилання, видимість в AI, контент, аналітику, локальне SEO та подальші корпоративні функції.
Я також хотів, щоб продукт замовляв статті з контент-рушія, який працює за моїм власним вебсайтом.
Отже, інструкція виконати весь план стосувалася масштабної дорожньої карти продукту. Я допоміг сформувати цей обсяг. Чотириденний таймер для невеликого виправлення помилки розповідав би зовсім іншу історію.
Яку модель і налаштування я використовував
Основний журнал сесії визначає модель як GPT-6.1 Sol, з ідентифікатором gpt-6.1-sol. Зафіксовані ходи містять налаштування міркувань ultra, medium і невелику кількість high. Це ідентифікує основну сесію; це не підтверджує, яка модель працювала за кожного рецензента чи зовнішнього інструмента.
5 жовтня я явно перемкнув рівень зусиль на medium, щоб заощадити токени. Потім я вимкнув turbo з тієї самої причини. Це були мої наміри, а не виміряна економія: у мене немає перевіреного порівняння вартості для цих двох конфігурацій.
Я також попросив більше паралельних агентів. Сесія використовувала делеговану роботу та партнерські перевірки Claude для частин реалізації. Це дозволило окремим завданням рухатися вперед, але також створило роботу з узгодження їхніх результатів і перевірки об’єднаного результату.
Мій попередній порівняльний матеріал про GPT-6.1 Sol→ охоплює опубліковані дані про моделі. Ця розробка є іншим видом доказів: один реальний проєкт зі змінним обсягом і налаштуваннями, а не контрольоване порівняння моделей.
Як довго ціль Codex може продовжувати працювати?
У цьому випадку інтерфейс показував понад чотири дні для тієї самої активної цілі. Це спостереження, яке я можу підтвердити. Це не гарантія максимального часу виконання, і я не можу обчислити активний час інференсу зі знімка екрана.
OpenAI описує Goals in Codex як цілі, що зберігаються між ходами. Codex може продовжувати рух до результату, тоді як користувач може призупинити або відновити роботу. Завершення, переривання, бюджети та блокери впливають на те, чи продовжиться робота.
Мій досвід відповідає цьому сталому робочому процесу. Я міг повертатися до тієї самої цілі після пауз і спрямовувати подальшу роботу. Було корисно зберігати ціль доступною. Але це не робило ціль меншою і не гарантувало, що кожен новий хід наближатиме продукт до запуску.
Що було готово до 9 жовтня?
Журнал виконання від 9 жовтня містив 30 частково виконаних вимог, 39 неоцінених і жодної повністю прийнятої вимоги з 69 пунктів у списку відстеження.
Цей показник потребує контексту. Список вимірює широке приймання продукту. Нуль повністю прийнятих вимог не означає нуль робочого коду. Так само 30 часткових вимог не означають, що продукт готовий на 43 відсотки.
У журналі зафіксовано одноразовий локальний smoke-тест підтримуваної базової роботи з обліковим записом: створити перший обліковий запис, увійти за паролем, прочитати сесію та приватний робочий простір власника, потім вийти й відхилити стару сесію. Це конкретний користувацький сценарій із чітко обмеженим результатом тесту. Це не доказ того, що остання повна версія застосунку готова для клієнтів.
Інший прогрес включав локальну інтеграцію джерела для скидання пароля, чернетки перевірки зворотних посилань, роботу над збереженими звітами Search Console, передавання звітів GA4 за клієнтським токеном і роботу над чернетками статей для LinkedIn. У кількох із цих частин активація все ще була вимкнена, інтеграція — неповною, а перевірка — відкладеною.
У датованих контрольних точках прямо зазначалося, що commit, push або розгортання не виконувалися. Вхід через Google і повна готовність для клієнтів залишалися неперевіреними. У мене була зростаюча локальна реалізація з корисними доказами, а не випущена платформа.
Що сповільнило мою довготривалу ціль у Codex?
Я розширив ціль до дорожньої карти продукту
Додавання входу через Google звучить як одна функція. Додавання приватних клієнтів змінює те, хто може отримувати доступ до проєктів, звітів, фонових завдань та інтеграцій. Я хотів, щоб ця межа зберігалася в усьому застосунку.
Потім я додав дослідження ключових слів, зворотні посилання, генерацію контенту та значно більший каталог. Частина витраченого часу відображає необхідну роботу над широкою ціллю. Моя початкова ціль спрощувала постійне відкриття наступної незавершеної області.
Процес перевірки став надто повторюваним
Я просив ухвалювати рішення на основі джерел, вносити вузькі зміни, проводити перевірки та надавати явні докази. Ці інструкції допомагали запобігати нечітким твердженням про завершення роботи.
Але в сесії накопичувалися повторні перевірки джерел, підготовка до рев’ю та робота над тестовими фікстурами. На мою думку, баланс надто змістився в бік доведення окремих частин до завершення перед переходом до наступного придатного для використання сценарію.
9 жовтня я сказав йому припинити витрачати стільки часу на тести, рухатися до завершення й залишити більший тест на потім. Це не скасувало потреби перевіряти ізоляцію облікових записів. Це змінило послідовність: цілеспрямовані перевірки під час реалізації, а потім ширша перевірка зібраного сценарію.
Деякі помилки належали до налаштування тестів
Одна спроба роботи з базою даних для скидання пароля завершилася помилкою, оскільки синтетичному запису облікового запису бракувало обов’язкового поля відображуваного імені. Виправлення цієї фікстури було необхідним для запуску тесту, але не було новою функцією продукту.
Пізніша довготривала спроба роботи з базою даних завершилася, коли робоча станція перезавантажилася. Журнал виконання не стверджував, що ця спроба була успішною. Подальша діагностика виявила повторне обчислення попередніх контрактів перевірки та буферизований вивід прогресу, через що оцінювати запущений процес стало складніше.
Ці деталі важливі, оскільки очікування неоднозначне. Активний процес може працювати, повторно обчислювати ту саму передумову або створювати вивід, якого я ще не бачу. Сам таймер не може сказати, що саме відбувається.
Більше агентів додало координації
Паралельна робота допомагала з окремими завданнями. Основній сесії все одно потрібно було перевіряти результати, розв’язувати залежності та інтегрувати зміни в один застосунок. Я не можу приписати додаванням агентів прискорення, оскільки не запускав той самий проєкт із ними та без них.
Практичне питання полягало в тому, чи може інший агент завершити незалежну частину, чи створить для основної сесії ще одну передачу роботи.
Що я все ще роблю як людина
Я визначаю напрям продукту й вирішую, які функції мають значення наступними. Я перевіряю, чи описує заявлений прогрес робочу поведінку, локальний вихідний код або неперевірену пропозицію. Я призупиняю роботу, коли мені потрібно оновити Codex або перезапустити комп’ютер, а потім прошу його продовжити зі збереженого стану.
Я також ставлю під сумнів темп. Під час цієї розробки я:
План і журнал виконання дають мені щось для перевірки, окрім повідомлень у чаті. Вони також потребують дисципліни: датована контрольна точка корисна лише тоді, коли в ній зазначено, що змінилося, а що залишається недоведеним.
Цей досвід продовжує компроміс, який я описав у статті Я думав, що AI дасть мені більше вільного часу→. Я можу спробувати створити масштабніший продукт, але все одно витрачаю час на вирішення того, що варто створювати, і на перевірку результату.
Переваги та недоліки на цей момент
З мого досвіду роботи над цим продуктом, найбільша перевага — безперервність. Я можу залишати відкритою масштабну ціль і відновлювати її після переривань. Codex створив локальні реалізації, дослідив помилки та вів докладні записи, які допомагають мені перевіряти роботу.
Він також може виконувати кілька видів роботи в межах одного проєкту: зміни бази даних, поведінку API, frontend-сценарії, транспорт інтеграцій і документацію. Це робить масштабну розробку можливою під моїм керівництвом.
Недолік полягає в тому, що активність може виглядати як прогрес. Багато успішних перевірок можуть співіснувати з незавершеним продуктом. Високий рівень міркувань і більша кількість агентів створюють бюджетні та координаційні рішення, але не гарантують швидшої доставки.
Тривалі запуски також ускладнюють дотримання меж обсягу. Частково виконана дорожня карта дає агенту багато обґрунтованих наступних дій. Мені потрібно вирішувати, яка з них принесе наступний корисний результат.
Я знову використовував би сталу ціль, але задавав би для кожного етапу реалізації меншу ціль приймання. Наприклад: створити обліковий запис, увійти, побачити приватний робочий простір і відхилити доступ із другого облікового запису. Залишити більшу дорожню карту як контекст, завершити цей сценарій, а потім перейти далі.
Що я вимірюватиму далі
SEO-продукт усе ще перебуває в розробці й станом на 9 жовтня не був запущений. Наступний корисний показник — повний користувацький сценарій на поточному зібраному застосунку з чітко переліченими блокерами, що залишилися.
Після цього я хочу отримати докази роботи входу через Google, інтеграцій, прив’язаних до клієнтів, персональних ключів MCP і безпечного випуску. Codex продовжує виконувати завдання; ця стаття фіксує стан на 9 жовтня. Я оцінюватиму розробку за цими результатами, а не за тим, як довго ціль залишається відкритою.
Джерела та обмеження цього опису
Таймер походить із наведеного вище знімка екрана. Ідентифікатор моделі, зміни налаштувань і мої втручання походять з історії основної сесії. Обсяг і показники прогресу походять із плану проєкту та його датованого журналу виконання. Ці записи проєкту є приватними робочими документами; я не публікував журнали або дані клієнтів.
OpenAI у матеріалі Using Goals in Codex пояснює робочий процес зі сталою ціллю. Він підтверджує опис Goals, але не твердження про виконання мого проєкту.
Підрахунок із 69 пунктів — це широкий знімок стану приймання, а не вимірювання кількості годин, що залишилися. Знімок екрана не доводить безперервний інференс, зміни налаштувань не доводять економію коштів, а локальні перевірки не підтверджують готовність до production. Ця розробка все ще триває.
*Цю статтю підготовлено за допомогою AI на основі мого знімка екрана, історії сесії та записів про виконання проєкту. Вона описує одну поточну розробку. Вона не встановлює загального обмеження часу роботи Codex, рейтингу моделей, перевіреної вартості або готовності до production.*