Паралельні хмарні задачі Codex: скільки запускати і скільки це коштує

Коротко (TL;DR)

• Паралельні хмарні задачі Codex — це кілька незалежних контейнерів, кожен зі своєю копією репозиторію. Одна задача — один контейнер, один чекаут, один дифф на виході. Формулювання OpenAI пряме: хмара існує, щоб «запускати задачі кодингу в паралельних хмарних середовищах».
• Жорсткої задокументованої стелі на кількість одночасних задач немає. Станом на 13 серпня 2026 такого числа немає ні на сторінці хмари, ні в прайсингу, ні в довіднику опцій із 372 ключів, ні у довідці CLI. Обмежує вас бюджет плану, а він обчислюється за обсягом роботи, а не за кількістю задач.
• Числа «6 потоків» і «3–5 агентів», якими забита видача, до хмари стосунку не мають. Це про локальні субагенти, і навіть там шістка — не задокументований дефолт, а значення з прикладу конфігурації.
• Ізоляція є, координації немає. Контейнери не заважають одне одному на диску, але п’ять задач від однієї гілки зійдуться в конфлікті під час злиття. Різати роботу за зонами запису доведеться вам.
• --attempts — це не паралель задач, а паралель спроб однієї задачі. Діапазон 1–4, за замовчуванням 1 (перевірено на codex-cli 0.147.0).
• Головна ціна паралелі — не гроші, а рев’ю. Шість готових діффів одночасно — це шість розборів, і саме тут утворюється черга.

Далі — як це влаштовано покроково, як різати задачу на паралельні частини, де все ламається і скільки це коштує. Усі команди та значення звірені з документацією OpenAI і з самим CLI версії 0.147.0 станом на 13 серпня 2026.

Три механізми паралельного Codex: хмара, субагенти та worktree

Головна плутанина теми виникає ще до першої команди. Коли розробник шукає, як запустити кілька агентів Codex одразу, видача відповідає йому матеріалами про три різні речі впереміш — і числа з однієї механіки переносяться на іншу.

За документацією OpenAI станом на 13 серпня 2026, під час старту чату обирається одне з трьох середовищ: Local, Worktree і Cloud. Перші два виконуються на вашому комп’ютері, третє — у хмарному середовищі. Worktree тут — штатна можливість Git: друга робоча копія репозиторію в окремому каталозі, яка має власні файли, але спільну з основною копією історію комітів (сам прийом не залежить від інструмента, і докладно він розібраний на прикладі кількох агентів у git worktree). Додатково існує четвертий, ортогональний механізм: субагенти — допоміжні агенти, яких основна сесія породжує всередині себе і результати яких збирає в одну відповідь.

Різниця принципова. Субагенти розв’язують проблему контексту: офіційна документація пояснює їх через «забруднення контексту» і «context rot» — галасливі логи та результати пошуку не повинні завалювати головний потік. Хмарні задачі розв’язують проблему часу і машини: робота йде не у вас, а ви вільні.

BINANCE SIMPLE EARNЗмусь крипту працюватиВідсотки на USDT і BTC без блокування — гроші лишаються під рукою.Розмістити

Якщо шукатимете подробиці в англомовних джерелах, зважайте, що запити там розведені за механіками, і це заощаджує час: codex parallel agents та codex run multiple agents виводять на десктоп-застосунок і паралельні потоки, codex multiple tasks — на хмарні задачі, а codex parallel subagents, codex spawn multiple agents і codex parallel threads — на локальні потоки всередині однієї сесії.

OpenAI Codex у CI/CD: коди повернення, потік JSONL і ціна прогону

Пісочниця Codex не закриває читання: модель загроз і чек-лист

Codex Code Review на GitHub: тільки P0 і P1, правила в AGENTS.md і боротьба з шумом

Оточення хмарних завдань Codex: setup-скрипт, кеш і доступ до інтернету

MCP-сервери в Codex: config.toml, транспорти і чому сервер не відповідає

Далі у статті мова про хмару. Про те, як влаштована одна така задача від постановки до готового pull request, у нас є окремий розбір — хмарні задачі Codex; тут ми його не переказуємо, а беремо те, що з’являється саме через множинність.

Як живе одна хмарна задача Codex: від контейнера до діффа

Щоб розуміти, що при паралелі множиться, а що лишається спільним, потрібен життєвий цикл однієї задачі. За офіційною документацією Codex Cloud він складається з п’яти кроків:

1. Контейнер і чекаут. Codex створює контейнер і викачує репозиторій на обраній гілці або на конкретному коміті.
2. Setup-скрипт. Встановлюються залежності; під час відновлення закешованого контейнера може відпрацювати ще й maintenance-скрипт.
3. Налаштування мережі. Застосовується політика інтернету середовища. У setup-фази доступ до мережі є, у агент-фази за замовчуванням немає.
4. Цикл агента. Агент виконує команди термінала, править код, ганяє перевірки. Якщо в репозиторії лежить AGENTS.md, команди лінта і тестів він бере звідти.
5. Відповідь і дифф. Агент показує резюме та дифф змінених файлів. Далі людина або просить доопрацювання, або відкриває pull request.

Із цього списку випливають три речі, важливі для паралелі. Перше: множиться крок 1 — контейнерів стає стільки, скільки задач, і вони одне про одного не знають. Друге: не множиться крок 3 — політика мережі та секрети налаштовуються на середовище, а не на задачу, тобто одне налаштування діє одразу на весь запущений потік. Третє: крок 5 не автоматичний — pull request відкриває людина, і це ваш запобіжник: навіть невдало запущена пачка з шести задач не псує основну гілку сама собою.

Окремо варто запам’ятати: setup-скрипт виконується в окремій сесії Bash від агент-фази. Тому export до агента не доживає — змінні треба прописувати в ~/.bashrc або задавати в налаштуваннях середовища. Під час паралельного запуску ця деталь б’є по всіх задачах одразу, а виглядає як «в агента чомусь немає змінної».

Скільки хмарних задач Codex можна запустити одночасно

Це головне питання, заради якого статтю й відкривають, тож відповідь одразу: жорсткого задокументованого ліміту на кількість одночасних хмарних задач у Codex станом на 13 серпня 2026 немає.

Перевірено за чотирма місцями, де таке число мало б стояти: сторінка Codex Cloud, сторінка прайсингу, довідник опцій конфігурації (372 унікальні ключі) та довідка самого CLI. У жодному з них стелі одночасних задач немає. По видачі при цьому ходять конкретні числа на кшталт «на Pro можна 3 задачі, на Plus одну» — під час перевірки першоджерела вони не підтвердилися: сторінка, на яку посилається пошукова зведення з цими числами, містить таблицю п’ятигодинних вікон витрати, а не обмеження паралельності.

BINANCE COPY TRADINGКопітрейдинг на BinanceВідкрита статистика трейдерів, старт з $10, вимкнення одним кліком.Обрати трейдера

Що обмежує вас насправді — три речі, і жодну з них не вимірюють кількістю задач:

• Бюджет плану. За документацією OpenAI витрата залежить від обсягу і складності роботи, моделі та місця виконання, а не від кількості запущених задач. Докладний розбір того, як влаштоване саме вікно витрати, — у статті про ліміти Codex.
• Ваша швидкість рев’ю. Задачі завершуються приблизно одночасно, а розбирати діффи ви будете послідовно.
• Здатність розрізати роботу. Про це нижче окремий розділ — це і є справжня стеля.

Натомість поряд існують стелі, які легко переплутати з лімітом задач. Їх корисно знати в обличчя:

Практичний висновок тверезий: якщо продукт вас не зупиняє, обмеження доведеться ввести самому. Орієнтир із практики спільноти — 3–5 одночасних задач, і це саме консенсус практиків, а не ліміт продукту: число повторюється в кількох незалежних авторів, але жоден не посилається на документацію. Перевіряти його варто не вірою, а власним лічильником витрати після першої ж пачки.

agents.max_threads = 6: чому рантайм Codex дає чотири слоти

Найтиражованіше твердження в цій темі звучить так: «у Codex за замовчуванням шість паралельних потоків, ключ agents.max_threads». Воно трапляється і в англомовних гайдах, і в українських та російських розборах. З ним три проблеми, і розбиратися в них варто, бо саме на це число люди спираються, плануючи паралель.

Проблема перша: це не про хмару. agents.max_threads керує субагентами — потоками всередині однієї локальної сесії. До кількості хмарних задач ключ стосунку не має взагалі.

Проблема друга: дефолт не задокументований. Офіційний довідник опцій описує ключ agents.max_concurrent_threads_per_session (а agents.max_threads — його застарілий синонім) і каже дослівно: коли значення не задане, Codex обирає замовчування сам. Конкретного числа ні на цій сторінці, ні на сторінці субагентів немає. Звідки тоді шістка? Судячи з усього, із прикладів конфігурації на сторінці субагентів: там в одному прикладі стоїть max_concurrent_threads_per_session = 8, в іншому = 6. Ілюстрацію прочитали як норму.

Проблема третя: ключ може взагалі не працювати. У багтрекері openai/codex лежать два звіти, які пояснюють, чому в людей «шість у конфігурації, а по факту чотири». В issue #33039 (відкритий 14 липня 2026) користувач ставить max_threads = 6 і отримує від рантайму чотири слоти. В issue #33447 (відкритий 15 липня 2026) картина розкривається: у нового мультиагентного рантайму власний ключ, features.multi_agent_v2.max_concurrent_threads_per_session, а ліміт за замовчуванням — чотири потоки разом із кореневим, тобто три підпорядковані. Автор звіту піднімав max_threads до 10 і до 111 — задача продовжувала повідомляти: «There are 4 available concurrency slots… including you».

Коротко, що звідки взялося:

Перевірити існування цієї поверхні можна самому. На codex-cli 0.147.0 команда codex features list друкує серед іншого:

multi_agent                          stable             true
multi_agent_v2                       stable             false

Тобто прапорець реальний і має статус stable, хоча станом на 13 серпня 2026 вимкнений, а ключів multi_agent_v2 в офіційному довіднику опцій немає жодного. Практичний висновок: якщо вам потрібно керувати кількістю локальних субагентів, не вірте числу зі статті — перевірте, що каже сама задача. Запитайте в Codex, скільки в нього слотів паралельності, і ви побачите фактичне значення, а не бажане.

Декомпозиція фічі: що різати на паралельні задачі, а що ні

Усі посібники з паралельного Codex починаються словами «візьміть незалежні задачі». Методу, як зробити їх незалежними, не дає ніхто — а це і є основна робота.

Правило, з якого варто виходити, коротке: різати треба за зонами запису, а не за змістом. Дві задачі безпечно йдуть паралельно тоді, коли множини файлів, які вони змінять, не перетинаються. Змістова незалежність («це ж різні фічі») нічого не гарантує: дві різні фічі, які обидві чіпають роутер або файл міграцій, зіткнуться.

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

Робочий чек-лист перед запуском пачки. Задача годиться в паралельний потік, якщо на всі чотири питання відповідь «так»:

1. Зону запису названо заздалегідь. Ви можете перелічити каталоги і файли, які задача має право змінити.
2. Зона не перетинається із сусідами по пачці. Перевіряється списком, а не відчуттям.
3. Задача перевірювана окремо. У неї є свій тест або свій спосіб переконатися, що її зроблено, — без результатів сусідніх задач.
4. Задача не змінює спільний контракт. Схема БД, публічний інтерфейс, формат конфігурації, залежності — усе, на що спираються решта, має бути вже зафіксоване.

Як це виглядає на живій фічі. Припустімо, треба додати експорт звітів у CSV. Поганий розріз — «фронт», «бек», «тести» трьома паралельними задачами: усі троє впруться у формат даних, якого ще немає, і кожна вигадає свій. Добрий розріз — двотактний:

• Такт 1, послідовно: одна задача фіксує контракт — формат рядка, назви колонок, сигнатуру ендпоінта. Це змінює спільний контракт, отже паралелити не можна.
• Такт 2, паралельно: три задачі на зафіксованому контракті — генератор CSV у своєму модулі, кнопка і запит на фронті, набір тестів у своєму каталозі. Зони запису не перетинаються, кожна перевірювана.

Щоб правило було під рукою, ось типові розрізи однієї фічі та їхня доля в паралелі:

Формулювати кожну задачу все одно доводиться повноцінно: паралель не скасовує якості постановки, а множить ціну поганої. Як писати саме формулювання, розібрано окремо — як ставити задачу Codex. До цього додається одна вимога, якої немає в одиночної задачі: у тексті задачі варто прямо назвати її зону запису («змінюй лише файли в app/export/, решту не чіпай»). Це дешева страховка від того, що агент дорогою вирішить поправити сусідній модуль.

Конфлікти гілок і pull request: де паралель сходиться назад

Окремі контейнери створюють приємну ілюзію: задачі нічого одна про одну не знають, отже й заважати не можуть. На диску — не можуть. У репозиторії — ще й як.

Механіка проста. Кожна задача стартує від обраної гілки або коміту, тобто всі п’ять задач пачки бачать однаковий вихідний код. Жодна з них не побачить правок сусіда, бо сусідів ще не злито. П’ять діффів приїжджають до вас побудованими від однієї бази, і якщо двоє чіпали один файл — конфлікт спливе під час злиття.

Формально це і є межа між ізоляцією та координацією. У заявці на доопрацювання в багтрекері openai/codex (issue #37226, відкритий 6 серпня 2026) проблему сформульовано дослівно: «chat isolation is not filesystem isolation» — ізоляція чатів не дорівнює ізоляції файлової системи. Там же перелічено те, що сьогодні лягає на користувача: вирішувати, хто працює де, призначати власників файлів, узгоджувати порядок передавання і злиття. Тобто паралель у Codex сьогодні — це ізоляція виконання без координації результату.

Окремо про гілки. Git ставить фізичну межу, яку варто знати: одна гілка не може бути викачана у двох робочих каталогах одночасно. Спроба дає помилку на кшталт:

fatal: 'feature/a' is already used by worktree at '<WORKTREE_PATH>'

Причина не в Codex: гілка — це єдине змінюване посилання, і Git серіалізує операції над ним, щоб коміти не губилися. Саме тому локальні worktree Codex працюють у стані detached HEAD (робоча копія стоїть на конкретному коміті, а не на гілці) — так їх можна створювати пачками, не займаючи гілок. Для хмарної паралелі висновок практичний: одна задача — одна гілка, спільна гілка на пачку задач не працює за будовою Git.

Практичний порядок злиття, який заощаджує найбільше часу: спочатку зливати те, що змінює спільне (міграції, конфігурації, контракти), потім ізольовані модулі, а спірні перетини лишати на кінець — на той момент частина з них відпаде сама.

best-of-N через –attempts: одна задача, до чотирьох спроб

--attempts — найбільш недозрозумілий прапорець теми, бо його регулярно приймають за спосіб запустити кілька задач. Це не так: прапорець замовляє кілька спроб однієї й тієї самої задачі, щоб ви обрали найкращий результат.

Синтаксис постановки задачі з термінала (команда codex cloud станом на 13 серпня 2026 позначена як експериментальна):

codex cloud exec --env <ENV_ID> --attempts 3 \
  "Перепиши експорт CSV на потоковий запис. Змінюй лише app/export/, тести не чіпай."

Межі прапорця варто знати точно, бо довідка їх не друкує — у --help вказано лише [default: 1]. Реальний діапазон видає валідатор продукту. На codex-cli 0.147.0 спроба вийти за межі відповідає так:

error: invalid value '0' for '--attempts <ATTEMPTS>': attempts must be between 1 and 4

Те саме на 5 і на 99, а значення від 1 до 4 проходять перевірку. Разом: діапазон 1–4, за замовчуванням 1. Скільки спроб реально було в задачі, видно в полі attempt_total у виводі codex cloud list --json.

Коли що обирати:

Важливе застереження про ціну: --attempts 3 — це приблизно потрійна робота моделі за однією задачею. Прапорець не безкоштовний прискорювач, а спосіб обміняти бюджет на якість вибору там, де ви заздалегідь не знаєте, який підхід правильний.

Ізоляція середовища: інтернет, секрети і спільний кеш на всі задачі

Тонке місце паралелі: контейнери різні, а налаштування в них спільні, бо налаштовується середовище, а не задача. Кожне послаблення, зроблене заради однієї задачі, автоматично отримують усі решта в цьому середовищі.

Пара деталей, на яких спотикаються найчастіше.

Пресет «спільні залежності» — це рівно 71 домен (пораховано за офіційним списком станом на 13 серпня 2026): від alpinelinux.org до yarnpkg.com, увесь типовий набір реєстрів пакетів і репозиторіїв. Сторонні перекази зазвичай пишуть «понад сімдесят» — точне число корисне, коли ви вирішуєте, чи вистачить пресета, чи доведеться дописувати домени руками. Увесь вихідний трафік середовища в будь-якому разі йде через HTTP/HTTPS-проксі.

Секрети поводяться протилежно до очікування. Вони доступні setup-скриптам і видаляються до старту агент-фази. Це регулярно читають як поломку: в issue #34460 (відкритий 21 липня 2026) секрет налаштований у середовищі, але задача повідомляє, що змінної немає. Поведінку задумано саме так — те, що потрібне агенту в рантаймі, передається змінними середовища, а не секретами.

І третє, про що варто пам’ятати саме при паралелі: ризик множиться разом із задачами. Офіційна документація розбирає prompt injection (підміну інструкцій через недовірений текст, який агент читає) на живому прикладі — в описі issue ховалася вказівка надіслати останній коміт на чужий сервер через curl, і агент, виконавши її, витік би здійснив. Коли таких задач одночасно п’ять і всі вони читають зовнішні тікети, обсяг недовіреного входу зростає вп’ятеро, а перевіряє його та сама одна людина. Як влаштовані самі рівні доступу агента, розібрано у статті про режими схвалення і пісочницю.

Ціна паралелі: як кілька задач з’їдають ліміт плану

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

Звідси проста арифметика планування. Якщо ваша типова задача коштує умовну одиницю витрати, то пачка коштує:

Витрата пачки ≈ (кількість задач) × (кількість спроб) × (вартість типової задачі)

Чотири задачі з --attempts 3 — це близько дванадцяти типових задач, а не чотири. Саме тут тижневі бюджети й закінчуються в середу.

Що це дає на практиці — на складі планів станом на 13 серпня 2026 (Free, Go за 8 доларів, Plus за 20, Pro від 100 з тирами 5x і 20x до лімітів Plus, плюс Business та Enterprise):

Що буває, коли паралель іде врознос, задокументовано. У issue #30246 (відкритий 26 червня 2026, мітки bug і rate-limits) користувач плану за 100 доларів описує, як тижневий бюджет закінчився приблизно за дві доби на простих задачах рев’ю: за логами 4101 і 4139 викликів API 19 і 20 червня проти звичайних 81–198 на день, до 632 записів паралельних сесій в одну секунду і 248 сесій за два дні; поповнення згоріло одразу після нарахування. Це звіт користувача, а не вимірювання вендора — але точніших даних щодо ціни неконтрольованої паралелі у відкритих джерелах немає, і порядок величин він показує переконливо.

Звідси два правила, які коштують дешевше за будь-який ліміт. Перше: починати з двох-трьох задач і дивитися на лічильник витрати, а не виставляти одразу шість. Друге: --attempts більше одиниці вмикати свідомо, під конкретну задачу з неочевидним рішенням, а не тримати як налаштування за замовчуванням.

Моніторинг пачки задач: codex cloud list, status, diff і apply

Коли задач більше двох, вкладка браузера перестає бути зручним пультом. З термінала пачка видна однією командою. Повний набір підкоманд на codex-cli 0.147.0:

codex cloud            # інтерактивний список задач (позначено [EXPERIMENTAL])
codex cloud exec       # поставити задачу без запуску інтерфейсу
codex cloud status     # стан конкретної задачі
codex cloud list       # список задач
codex cloud diff       # показати дифф задачі
codex cloud apply      # застосувати дифф локально

Робочий прийом: codex cloud list --json плюс будь-який парсер JSON дає таблицю «що готово, що ще йде» за секунду і добре лягає в маленький скрипт-пульт. Поле attempt_total при цьому одразу показує, у яких задач було кілька спроб і де, відповідно, є з чого обирати. Як влаштований сам термінальний цикл роботи з Codex, розібрано у статті про робочий цикл Codex CLI.

Приймання кількох готових діффів: у якому порядку розбирати

Паралель переносить вузьке місце з написання коду на його перевірку. Шість задач завершуються майже одночасно, і далі все впирається у вас. Порядок розбору заощаджує більше часу, ніж будь-яке налаштування.

1. Спочатку відсортуйте за зоною запису, а не за часом готовності. Першим розбирається те, що змінює спільне — міграції, конфігурації, контракти. Поки це не злито, решта діффів може виявитися побудованою на застарілій базі.
2. По кожній задачі звірте зону запису з обіцяною. Дифф, що заліз за межі оголошених файлів, — привід не приймати одразу, навіть якщо код виглядає добре: саме так паралельні задачі й стикаються.
3. Перевірте, що задача перевірювана. Чи є тест, чи пройшов він у лозі задачі. Резюме агента — це його слова про свою роботу, а не результат перевірки.
4. Там, де було кілька спроб, порівнюйте за підходом. У attempt_total більше одиниці дивіться не «який дифф коротший», а який підхід ви готові підтримувати через півроку.
5. Зливайте по одному й оновлюйте базу. Після кожного злиття сусідні задачі варто перевірити на актуальність, а спірні — перезапустити від оновленої бази.
6. Відхиляйте пачку цілком, якщо розійшлися всі. Коли три задачі з чотирьох зробили не те, проблема майже завжди в постановці, а не в моделі: дешевше переформулювати і запустити заново, ніж лагодити чотири результати руками.

Правило, яке варто зафіксувати одразу: паралель має бути обмежена вашою пропускною здатністю рев’ю, а не лімітом плану. Якщо черга неперевірених діффів росте швидше, ніж ви її розбираєте, задач у потоці забагато — і зайві витрачають бюджет намарно, бо на момент розбору їхня база застаріє.

Ризики паралельного Codex: відмови, задокументовані в багтрекері

Чесна картина станом на 13 серпня 2026: продукт активно розвивається, репозиторій openai/codex тримає близько 105,7 тисячі зірок і близько 12,3 тисячі відкритих issue (без урахування пул-реквестів), і паралельні сценарії — помітна їх частина. Нижче відмови, задокументовані в багтрекері. Це звіти користувачів, а не підтверджені вендором дефекти, але знати їх корисно: вони описують саме ті граблі, на які наступають при паралелі.

Окремо варто сказати, чого в цьому списку немає. Немає жодної відмови, за якої паралельні задачі самі собою псують основну гілку: результат приїжджає діффом на рев’ю, а pull request відкриває людина. Ціна помилки при невдалій паралелі — витрачений бюджет і витрачений час на розбір, але не зламаний репозиторій.

Що застаріє першим. Найшвидше змінюються: статус експериментальної команди codex cloud і склад її підкоманд, діапазон --attempts, склад і ціни планів, ключі мультиагентної паралельності (multi_agent_v2 станом на 13 серпня 2026 існує, але вимкнений і в довіднику опцій відсутній) та список доменів у пресеті. Перевірити в себе це дешево: codex cloud exec --help покаже актуальні прапорці, codex features list — стан експериментальних поверхонь, а сторінка Codex Cloud — поточний життєвий цикл задачі.

Часті запитання

Чи є в Codex ліміт на кількість одночасних хмарних задач?

Задокументованої стелі немає: станом на 13 серпня 2026 такого числа немає ні на сторінці Codex Cloud, ні в прайсингу, ні в довіднику опцій, ні в довідці CLI. Обмежує бюджет плану, який обчислюється за обсягом роботи, а не за кількістю задач, і ваша швидкість розбору результатів. Практики зазвичай тримають 3–5 одночасних задач, але це їхній досвід, а не ліміт продукту.

Чим паралельні хмарні задачі відрізняються від субагентів Codex?

Це різні механізми. Хмарна задача — окремий контейнер зі своєю копією репозиторію, працює без вашої машини і завершується діффом та pull request. Субагенти — потоки всередині однієї локальної сесії, вони ділять вашу робочу копію і потрібні насамперед для читання: розвідки по коду, тестів, тріажу. Числа на кшталт «шість потоків» стосуються субагентів і на хмару не переносяться.

Що буде, якщо дві задачі змінять один і той самий файл?

На рівні контейнерів нічого: вони ізольовані й одна про одну не знають. Проблема спливе під час злиття — обидві задачі стартували від однієї бази і не бачили правок сусіда, тому другий pull request дасть конфлікт. Лікується порядком: зливати по одному, а задачу з перетином перезапускати вже від оновленої бази. Розводити зони запису потрібно до запуску.

Скільки коштує –attempts 4 порівняно з однією спробою?

Близько чотириразової витрати на цю задачу: прапорець замовляє чотири незалежні спроби одного й того самого завдання. Точної формули списання OpenAI не публікує, тому рахувати варто множниками: пачка обходиться приблизно як «кількість задач × кількість спроб» типових задач. Тримати --attempts більше одиниці за замовчуванням не варто — це інструмент для задач із неочевидним рішенням.

Чи працює інтернет усередині паралельних хмарних задач?

В агент-фазі за замовчуванням вимкнений, у setup-скриптів доступ є. Вмикається інтернет налаштуванням середовища, а не окремої задачі, тому послаблення одразу поширюється на всі задачі цього середовища. Можна обмежити доступ списком доменів (пресет спільних залежностей містить 71 домен) і дозволити лише методи GET, HEAD та OPTIONS.

Чи можна ставити хмарні задачі Codex із термінала?

Так, командою codex cloud exec --env <ENV_ID> з текстом задачі; базова гілка задається прапорцем --branch, кількість спроб — --attempts. Стежити за пачкою зручно через codex cloud list --json, забирати результат — командою codex apply <TASK_ID>. На codex-cli 0.147.0 команда codex cloud позначена як експериментальна, тому набір підкоманд варто звіряти командою codex cloud --help.