В YAML есть что-то типа merge, через якоря, коряво, косо, но есть.
Не соглашусь с тем что все кроме формата данных надо кидать в обвязку. Тем же merge хотелось бы управлять на уровне файла, что-то типа
include language.xxx
include country.xxx, merge_left: true
include currency.xxx, merge_right: true
Но с include проблема в другом, в редакторе не видно финального конфига, и собственно он не может быть провалидирован через схему. Тут только надежда на то что конфиг из валидных кусков будет валидным(и это работает с простыми типами и вариацией только типов). Но опять таки это все ломается, если у схемы и валидации есть условия, например одно поле зависит от другого (тут только валидация при старте поможет).
Поэтому и валидацию идеально было бы разделить на две части. Валидация через схему, только типов и чтобы было в редакторе. И валидация при старте с условиями и возможно кастомными валидаторами. Выдуманный пример, есть у нас в конфиге допустим адрес какого-то биткоин кошелька, с точки зрения данных это строка и ее вариация ничего не даст, но вот для prod/test кошельки должны быть разные и валидные, и для этого надо вызвать кастомный валидатор.
Опишу свою позицию в плане конфигурации. В конфигурации есть две крайности, или переменные окружения (.env, .env.production) или инструменты. А между этими крайностями есть много форматов конфигурации и каждый имеет свои недостатки.
Как для меня выглядит нормальная конфигурация.
Нативная поддержка схемы данных и валидации, конвертировать yaml/toml/etc в json и потом валидировать не вариант, не видно ошибок при редактировании конфига;
Поддержка окружения, например dev/prod/test/e2e.
Вложение конфигов, например dev.xxx содержит в себе и сразу понятно что и в каком порядке загружаем
include language.xxx
include country.xxx
include currency.xxx
Перекрытие значений или merge для окружений, например добавляем новый язык в общие настройки, и потом для prod окружения его выключаем, подменяя только нужное поле, что-то типа этого
include language.xxx
include country.xxx
include currency.xxx
language:
ita:
enable: false
Разделение конфигураций на открытую и закрытую части, открытая то что можно положить в git, для всех окружений, закрытая то что надо взять откуда-то (из определенного файла, из переменной окружения).
Попробуйте как-то создать конфигурацию эдак на 3-4 тыс ключей (а лучше больше), и для 3-х окружений: dev, prod, test, причем для dev/test должны быть какие-то дефолтные креды для внешних сервисов и настройки (dev и test должны тоже отличаться, dev это локальная разработка, test это какой-то поднятый сервер для qa), а для prod такие креды которые не должны попасть в git. И сразу будет понятно все недостатки и ограничения Вашего решения. Пока из приятного только многострочные значения, кавычки и запятые вкусовщин. Да можно сказать что этого всего нету и в JSON/YAML/TOML и include/expressions/interpolation и логику merge надо будет городить руками, но при этом всем среди простых форматов у JSON явное преимущество из-за наличия схем.
Вообще непонятно в чем отличие от JSON, точнее JSONC. Было бы неплохо увидеть таблицу сравнения хотя бы с JSON и проблем разного рода. Например надо вставить в конфиг дефолтный приватный ключ для тестового окружения, в JSON он выглядит так, в ktav он выглядит так. Или например, ktav для решения этой проблемы использует include с файлом с приватным ключом. Или проблема с установкой log_level при ручном запуске, и что-то типа такого в конфиге ENV('LOG_LEVEL', 'info'), тоесть при ручном запуске просто устанавливаем LOG_LEVEL в переменных окружения, если ничего не выставлено то дефолт info.
Если раньше Павел мог отказать условной Гондураской СБ или играть в юридические игры, то сейчас не сможет. Так как у ГСБ появился хороший рычаг давления в виде экстрадиции в РФ.
Сейчас реально стало тяжелее объяснять разницу между «накидал на коленке» и архитектурным подходом.
Это заказчикам довольно быстро объяснят хакеры, которые будут ломать такие поделки пачками и использовать для "заработка". Вот пару раз попадет заказчик на деньги тогда и задумается.
Так и есть. Подписка за 20 евро, мне не хватает лимитов, следующее по цене это 100 евро, но тяжко такое одному тянуть, а лимитов для одного там с избытком, с коллегой на работе решили на двоих одну брать.
Если не привязываться к провайдеру, то следующая подписка GitHub Copilot Pro+ за 40$. Если не привязываться к одному семейству моделей, то можно использовать например Claude Pro за 20 (или OpenAi Codex за 20) + Copilot Pro за 10 + OpenCode Go за 10. Если не привязываться к подписочным моделям и платить за api, то можно использовать openrouter или OpenCode Zen или вообще редактор Zed и их интеграцией.
В этой связи хотелось бы отметить следующее - применение ИИ, на данный момент, сильно подорвало систему преемственности кадров. Молодой специалист приходил как раз на рутинные должности подготовки и обработки информации (кодер-джун, помощник юриста, составляющий типовые исковые заявления и т.п.).
Я бы еще добавил один неочевидный момент. Рутинные задачи нужны не только для передачи знаний и воспитания специалистов. Они нужны для формирования команды, для распределения нагрузки внутри команды, так как на рутинных задачах можно просто отдохнуть от "творческих задач".
Проблема индустрии в том что сюда идут за длинным рублем, в виду того что в других областях крайне сложно заработать сопоставимые деньги. Все это сопровождается внедрением ии, охлаждением экономики - что только усугубляет проблемы.
Это постоянно происходит, до ИТ все шли в юристы, до юристов, делать евроремонты, до этого были 90-е и шли в челноки. Был ажиотаж среди таксистов, дальнобойщиков, ювелиров. В медицине всегда стремились в гинекологи или стоматологи. Или в косметологию. Даже в ИТ постоянно выделялись какие-то области куда шли, то CV, то ML, сейчас вон ИИ. Просто про это все не так было известно как сейчас, так как не было интернета и разных соцсетей.
Это было правдой когда ThinkPad был частью IBM. После того как подразделение ThinkPad было продано Lenovo, данная линейка скатилась в яму. Перечислю то что стало хуже:
Корпус был из титано-магниевого сплава, а стал из унылого пластика.
Процессор распаян на материке. Лично у меня два раза отпадал процессор от перегрева и приходилось сдавать в ремонт и делать реболлинг.
Формат экрана поменяли с 3:4 на 9:16, из рабочей машины сделали мультимедийную машину.
Убрали лампочку подсветки, вместо этого вставили унылую клавоподсветку.
После проблем с перегревом, хотя раз в год менял термопасту, делал чистку, перешел на маки, и забыл про эти все проблемы как про страшный сон. Алюминиевый корпус весь рассеивает тепло, в отличии от пластикового.
И подобные статьи явно провоцируют у многих желание "подсунуть текст закона на вход AI-фабрике и через неделю получить готовую систему
Это отлично. Это великий фильтр для управленцев и руководителей всех уровней. Пусть они генерит тонны кода сами, попадают на деньги из-за багов и штрафов. Пусть они увольняют разработчиков, а потом нанимают тех же людей за намного большие деньги.
Провайдеры ИИ вряд ли схлопнутся. И в идеальной картине мира нужна отдельная инфраструктура для генерации, доставки токенов и любого взаимодействия между агентами, типа как для газа/воды/электричества. С наймом людей все сложнее, есть автоматизированное производство, со станками чпу, сканерами штрих кодов, роботами доставщиками на складе, и любыми другими автоматизациями. Что будет если часть или вся автоматизация пропадет? Такое производство вряд ли сможет нанять людей как проще так и дешевле. Потому что автоматизация вытесняет часть профессий, люди переучиваются. Попробуй сейчас найти токаря, фрезеровщика, того же кладовщика. И это уже не говоря про офисную и управленческую автоматизацию. Даже если получиться заместить людей, то сильно ли долго такое производство продержится в условиях конкуренции? ИИ это тоже автоматизация, или мета-автоматизация. Да пока зависимости от этой ИИ автоматизации не очень критичная, но это быстро меняется с каждым днем.
Какие-то модели с открытыми весами может и доберутся, но вот железо доступнее не станет.
Предполагаю что это просто очередной передел рынка и расширение существующих монополий. Какое-то количество компаний перейдет на ИИ полностью или почти полностью, как только это произойдет, для этих компаний начнется падение. 5-10-20 месяцев, не важно, код в любом случае так деградирует, что эти компании просто не смогут обслуживать клиентов, а попытка привлечь людей не сработает из-за кучи непонятного кода. Но перед тем как это случиться, эти компании и их инвесторов просто выжмут провайдеры ИИ постоянным повышением цен, ужесточением лимитов и прочими методами.
Проблема джунов и их развития на моей памяти где-то с 2010 года. Разработка была другая, было больше свободы и доступа к проду, было меньше информации, больше ошибок. И софт был разный, со своими особенностями, и клиенты за нужные им функции платили лояльностью и обратной связью. Были стартапы где тоже можно было опыта получить. Потом все стало одинаковое, и началась погоня за девятками стабильности, контуры доступа, всякий маркетинг и сео. В таких условиях опыт особо не получишь, прод сам не сломаешь, сам не починишь, сидишь в песочнице из линтеров, чекеров, тестов. Сейчас опыт можно получить только в крупных компаниях. И есть такое ощущение, что роль кузнецы кадров на себя возьмут стартапы, и их будут покупать не из-за перспективной идеи, а из-за собранной и сработанной команды.
Сначала начинаем с провайдеры с простой подпиской за 10/20 баксов, с 5-и часовыми лимитами и прочими ограничениями. Оптимизируем свою работу за счет умного оркестратора и нужных настроек. Дорогие модели выполняют более сложную работу, дешевые простую и с учетом особенностей моделей, в доке про ohmyopenagent можно про это почитать. Оптимизируем более сложные моменты, например, добавляем lsp сервера, mcp сервера и прочее, чтобы оркестратор например типы для typescript выводил с помощью lsp или фиксил ошибки, а не слал запросы, или mcp для индексации кодовой базы, чтобы не было кучи вызовов grep и анализа выводов этой команды.
Когда упираемся в лимиты, добавляем еще один/два провайдера с простой подпиской за 10/20 баксов. Оптимизируем роутинг, lsp, mcp.
Если опять упираемся в лимиты, то да уже переходим на оплату за API для каких-то моделей, но опять таки оптимизация тут такая же как и в предыдущих пунктах. Никто например не мешает для планировщика использовать github-copilot/claude-opus-4.6, а для кодинга, openrouter/claude-sonnet-4.6 с оплатой за токены.
С оптимизаций роутинга все просто, или делаем `bunx oh-my-openagent install` отвечаем на вопросы какие провайдеры подключены и получаем готовый конфиг с fallback или читаем доки и правим конфиг. В вот с lsp/mcp надо играться и подбирать под свои задачи и свой стек.
И еще все сильно зависит от стиля разработки, при ручной разработке, написал задачу, посмотрел diff, запустил, скинул ошибку, получил фикс довольно сложно попасть в лимиты, и токены улетают не очень сильно. При полностью автоматической разработке каждый шаг очень сильно зависит от предыдущего. Планировщик должен простой промпт преобразовать в хороший план задавая вопросы и анализируя код. От плана зависит то какие задачу каким сабагентам уйдут в работу. От того как задача поставлена сабагенту и какие lsp/mcp доступны такой и будет результат.
Я бы сказал что пока не пройдешь путь с лимитированными планами, и оптимизациями, идти в платное API смысла нету, токены будут улетать.
И еще, если проект большой, и надо модели с большим контекстом, то тут вариант только API. Если окно забито больше чем на 50% то llm начинает галлюцинировать, а на лимитированном плане копилота например всего 128К для любой модели, а через API можно получить окно 1М для Opus/Sonnet
У Вас же просто ручной роутинг без учета особенностей моделей, и вы по сути залили проблему деньгами. За 50 баксов можно взять Copilot Pro+ (40 баксов) + OpenCode Go(10 баксов) - в таком сетапе моделей будет больше(и полностью бесплатные тоже есть в этих планах) и по лимитам явно не меньше чем в Вашем сетапе. Так же явная проблема с том что качество кода всегда плавает из-за того что разные задачи идут в разные модели, с оркестратором качество +- одинаковое из-за того что этапы и модели стандартизированы.
Переходить на оплату по токенам нужно тогда когда не влазишь в лимиты подписки. И тот же opencode(как и другие оркестратор) никак не управляет подписками, он просто подключает провайдер и дергает внутри агента нужную модель в нужно провайдере.
Объясняю на примере Copilit Pro за 10 баксов доступно 300 запросов в месяц, для Cloude Sonnet 4.6 мультипликатор 1, тоесть в месяц доступно 300 запросов, для Grok Code Fast 1 мультипликатор 0.25 тоесть всего доступно 1200 запросов в месяц. Причем один запрос максимально 128К входящих токенов, тоесть в идеальной ситуации мы можем послать 128К * 300 токенов = 37.5M токенов. Да это все в 5 часовых лимитах и прочие ограничения.
А если те же 37.5М токенов заслать через api для того же Cloude Sonnet 4.6 это 3$ за миллион токенов это уже 112.5$.
Но вот для Grok Code Fast 1 ситуация другая, можно послать 128К * 1200 токенов = 150M токенов. Через api 150M токенов для Grok Code Fast 1 обойдутся 30 баксов, по 0.2$ за миллион. Думаю что это из-за того что Microsoft вложился в Anthropic и получает ресурсы по скидки, и заинтересован в раскрутке их моделей.
У opencode go в доке написано
Бесплатные модели включают Big Pickle плюс промо-модели, доступные на данный момент, с квотой 200 запросов/день. Go включает GLM-5.1, GLM-5, Kimi K2.5, Kimi K2.6, MiMo-V2.5-Pro, MiMo-V2.5, Qwen3.5 Plus, Qwen3.6 Plus, MiniMax M2.5, MiniMax M2.7, DeepSeek V4 Pro и DeepSeek V4 Flash с более высокими квотами запросов, применяемыми в скользящих окнах (5 часов, неделя и месяц), что примерно эквивалентно $12 за 5 часов, $30 в неделю и $60 в месяц (фактическое количество запросов зависит от модели и использования).
Тоесть если посылать максимально большие запросы как в примере выше то максимум можно утилизировать на 60$, если сравнивать с ценой за токены.
Похоже что для провайдеров выгодно продавать такие планы, потому что клиенты не утилизируют все запросы по максимуму, плюс многие пользователи берут минималку чтобы просто попробовать, и в реальности не тратят даже 10$ если смотреть по цене api.
У копилота плюс что у него доступны модели Anthropic и OpenAI одновременно, и для оркестраторов это круто, потому что там где сильны модели Anthropic слабы модели от OpenAI и наоборот. Но c 1-го июня майки меняют тарификацию и вроде как мультипликаторы и надо будет смотреть выгодно будет их дальше использовать или нет.
В YAML есть что-то типа merge, через якоря, коряво, косо, но есть.
Не соглашусь с тем что все кроме формата данных надо кидать в обвязку.
Тем же merge хотелось бы управлять на уровне файла, что-то типа
Но с include проблема в другом, в редакторе не видно финального конфига, и собственно он не может быть провалидирован через схему. Тут только надежда на то что конфиг из валидных кусков будет валидным(и это работает с простыми типами и вариацией только типов). Но опять таки это все ломается, если у схемы и валидации есть условия, например одно поле зависит от другого (тут только валидация при старте поможет).
Поэтому и валидацию идеально было бы разделить на две части. Валидация через схему, только типов и чтобы было в редакторе. И валидация при старте с условиями и возможно кастомными валидаторами. Выдуманный пример, есть у нас в конфиге допустим адрес какого-то биткоин кошелька, с точки зрения данных это строка и ее вариация ничего не даст, но вот для prod/test кошельки должны быть разные и валидные, и для этого надо вызвать кастомный валидатор.
Опишу свою позицию в плане конфигурации. В конфигурации есть две крайности, или переменные окружения (.env, .env.production) или инструменты.
А между этими крайностями есть много форматов конфигурации и каждый имеет свои недостатки.
Как для меня выглядит нормальная конфигурация.
Нативная поддержка схемы данных и валидации, конвертировать yaml/toml/etc в json и потом валидировать не вариант, не видно ошибок при редактировании конфига;
Поддержка окружения, например dev/prod/test/e2e.
Вложение конфигов, например dev.xxx содержит в себе и сразу понятно что и в каком порядке загружаем
Перекрытие значений или merge для окружений, например добавляем новый язык в общие настройки, и потом для prod окружения его выключаем, подменяя только нужное поле, что-то типа этого
Разделение конфигураций на открытую и закрытую части, открытая то что можно положить в git, для всех окружений, закрытая то что надо взять откуда-то (из определенного файла, из переменной окружения).
Попробуйте как-то создать конфигурацию эдак на 3-4 тыс ключей (а лучше больше), и для 3-х окружений: dev, prod, test, причем для dev/test должны быть какие-то дефолтные креды для внешних сервисов и настройки (dev и test должны тоже отличаться, dev это локальная разработка, test это какой-то поднятый сервер для qa), а для prod такие креды которые не должны попасть в git. И сразу будет понятно все недостатки и ограничения Вашего решения. Пока из приятного только многострочные значения, кавычки и запятые вкусовщин. Да можно сказать что этого всего нету и в JSON/YAML/TOML и include/expressions/interpolation и логику merge надо будет городить руками, но при этом всем среди простых форматов у JSON явное преимущество из-за наличия схем.
Вообще непонятно в чем отличие от JSON, точнее JSONC. Было бы неплохо увидеть таблицу сравнения хотя бы с JSON и проблем разного рода. Например надо вставить в конфиг дефолтный приватный ключ для тестового окружения, в JSON он выглядит так, в ktav он выглядит так.
Или например, ktav для решения этой проблемы использует include с файлом с приватным ключом. Или проблема с установкой log_level при ручном запуске, и что-то типа такого в конфиге ENV('LOG_LEVEL', 'info'), тоесть при ручном запуске просто устанавливаем LOG_LEVEL в переменных окружения, если ничего не выставлено то дефолт info.
Да, но им пришлось поднапрячься и неизвестно насколько сильно, чтобы всё хотя бы выглядело прилично и законно, и у Павла была юридическая защита.
Если раньше Павел мог отказать условной Гондураской СБ или играть в юридические игры, то сейчас не сможет. Так как у ГСБ появился хороший рычаг давления в виде экстрадиции в РФ.
В битве меча и щита, всегда побеждает меч.
Это заказчикам довольно быстро объяснят хакеры, которые будут ломать такие поделки пачками и использовать для "заработка". Вот пару раз попадет заказчик на деньги тогда и задумается.
Мавзолей на луне, вот это было бы эпично. А очередную АЭС, вот это прям банально.
Если не привязываться к провайдеру, то следующая подписка GitHub Copilot Pro+ за 40$.
Если не привязываться к одному семейству моделей, то можно использовать например Claude Pro за 20 (или OpenAi Codex за 20) + Copilot Pro за 10 + OpenCode Go за 10.
Если не привязываться к подписочным моделям и платить за api, то можно использовать openrouter или OpenCode Zen или вообще редактор Zed и их интеграцией.
Я бы еще добавил один неочевидный момент. Рутинные задачи нужны не только для передачи знаний и воспитания специалистов. Они нужны для формирования команды, для распределения нагрузки внутри команды, так как на рутинных задачах можно просто отдохнуть от "творческих задач".
Это постоянно происходит, до ИТ все шли в юристы, до юристов, делать евроремонты, до этого были 90-е и шли в челноки. Был ажиотаж среди таксистов, дальнобойщиков, ювелиров. В медицине всегда стремились в гинекологи или стоматологи. Или в косметологию. Даже в ИТ постоянно выделялись какие-то области куда шли, то CV, то ML, сейчас вон ИИ. Просто про это все не так было известно как сейчас, так как не было интернета и разных соцсетей.
Это было правдой когда ThinkPad был частью IBM. После того как подразделение ThinkPad было продано Lenovo, данная линейка скатилась в яму. Перечислю то что стало хуже:
Корпус был из титано-магниевого сплава, а стал из унылого пластика.
Процессор распаян на материке. Лично у меня два раза отпадал процессор от перегрева и приходилось сдавать в ремонт и делать реболлинг.
Формат экрана поменяли с 3:4 на 9:16, из рабочей машины сделали мультимедийную машину.
Убрали лампочку подсветки, вместо этого вставили унылую клавоподсветку.
После проблем с перегревом, хотя раз в год менял термопасту, делал чистку, перешел на маки, и забыл про эти все проблемы как про страшный сон. Алюминиевый корпус весь рассеивает тепло, в отличии от пластикового.
Это отлично. Это великий фильтр для управленцев и руководителей всех уровней. Пусть они генерит тонны кода сами, попадают на деньги из-за багов и штрафов. Пусть они увольняют разработчиков, а потом нанимают тех же людей за намного большие деньги.
Всем известны компании где сидит этот 1% разработчиков.
И если бы я сидел в том же Anthropic на халявных токенах, то тоже бы входил в этот 1%.
Провайдеры ИИ вряд ли схлопнутся. И в идеальной картине мира нужна отдельная инфраструктура для генерации, доставки токенов и любого взаимодействия между агентами, типа как для газа/воды/электричества. С наймом людей все сложнее, есть автоматизированное производство, со станками чпу, сканерами штрих кодов, роботами доставщиками на складе, и любыми другими автоматизациями. Что будет если часть или вся автоматизация пропадет? Такое производство вряд ли сможет нанять людей как проще так и дешевле. Потому что автоматизация вытесняет часть профессий, люди переучиваются. Попробуй сейчас найти токаря, фрезеровщика, того же кладовщика. И это уже не говоря про офисную и управленческую автоматизацию. Даже если получиться заместить людей, то сильно ли долго такое производство продержится в условиях конкуренции? ИИ это тоже автоматизация, или мета-автоматизация. Да пока зависимости от этой ИИ автоматизации не очень критичная, но это быстро меняется с каждым днем.
Какие-то модели с открытыми весами может и доберутся, но вот железо доступнее не станет.
Предполагаю что это просто очередной передел рынка и расширение существующих монополий. Какое-то количество компаний перейдет на ИИ полностью или почти полностью, как только это произойдет, для этих компаний начнется падение. 5-10-20 месяцев, не важно, код в любом случае так деградирует, что эти компании просто не смогут обслуживать клиентов, а попытка привлечь людей не сработает из-за кучи непонятного кода. Но перед тем как это случиться, эти компании и их инвесторов просто выжмут провайдеры ИИ постоянным повышением цен, ужесточением лимитов и прочими методами.
Проблема джунов и их развития на моей памяти где-то с 2010 года. Разработка была другая, было больше свободы и доступа к проду, было меньше информации, больше ошибок. И софт был разный, со своими особенностями, и клиенты за нужные им функции платили лояльностью и обратной связью. Были стартапы где тоже можно было опыта получить. Потом все стало одинаковое, и началась погоня за девятками стабильности, контуры доступа, всякий маркетинг и сео. В таких условиях опыт особо не получишь, прод сам не сломаешь, сам не починишь, сидишь в песочнице из линтеров, чекеров, тестов. Сейчас опыт можно получить только в крупных компаниях. И есть такое ощущение, что роль кузнецы кадров на себя возьмут стартапы, и их будут покупать не из-за перспективной идеи, а из-за собранной и сработанной команды.
Скорее всего залезли через другую дыру, а сказали что через эту. Обычно зловреды после заражения закрывают уязвимости.
Я бы сказал так.
Сначала начинаем с провайдеры с простой подпиской за 10/20 баксов, с 5-и часовыми лимитами и прочими ограничениями. Оптимизируем свою работу за счет умного оркестратора и нужных настроек. Дорогие модели выполняют более сложную работу, дешевые простую и с учетом особенностей моделей, в доке про ohmyopenagent можно про это почитать. Оптимизируем более сложные моменты, например, добавляем lsp сервера, mcp сервера и прочее, чтобы оркестратор например типы для typescript выводил с помощью lsp или фиксил ошибки, а не слал запросы, или mcp для индексации кодовой базы, чтобы не было кучи вызовов grep и анализа выводов этой команды.
Когда упираемся в лимиты, добавляем еще один/два провайдера с простой подпиской за 10/20 баксов. Оптимизируем роутинг, lsp, mcp.
Если опять упираемся в лимиты, то да уже переходим на оплату за API для каких-то моделей, но опять таки оптимизация тут такая же как и в предыдущих пунктах. Никто например не мешает для планировщика использовать github-copilot/claude-opus-4.6, а для кодинга, openrouter/claude-sonnet-4.6 с оплатой за токены.
С оптимизаций роутинга все просто, или делаем `bunx oh-my-openagent install` отвечаем на вопросы какие провайдеры подключены и получаем готовый конфиг с fallback или читаем доки и правим конфиг. В вот с lsp/mcp надо играться и подбирать под свои задачи и свой стек.
И еще все сильно зависит от стиля разработки, при ручной разработке, написал задачу, посмотрел diff, запустил, скинул ошибку, получил фикс довольно сложно попасть в лимиты, и токены улетают не очень сильно. При полностью автоматической разработке каждый шаг очень сильно зависит от предыдущего. Планировщик должен простой промпт преобразовать в хороший план задавая вопросы и анализируя код. От плана зависит то какие задачу каким сабагентам уйдут в работу. От того как задача поставлена сабагенту и какие lsp/mcp доступны такой и будет результат.
Я бы сказал что пока не пройдешь путь с лимитированными планами, и оптимизациями, идти в платное API смысла нету, токены будут улетать.
И еще, если проект большой, и надо модели с большим контекстом, то тут вариант только API. Если окно забито больше чем на 50% то llm начинает галлюцинировать, а на лимитированном плане копилота например всего 128К для любой модели, а через API можно получить окно 1М для Opus/Sonnet
У Вас же просто ручной роутинг без учета особенностей моделей, и вы по сути залили проблему деньгами. За 50 баксов можно взять Copilot Pro+ (40 баксов) + OpenCode Go(10 баксов) - в таком сетапе моделей будет больше(и полностью бесплатные тоже есть в этих планах) и по лимитам явно не меньше чем в Вашем сетапе. Так же явная проблема с том что качество кода всегда плавает из-за того что разные задачи идут в разные модели, с оркестратором качество +- одинаковое из-за того что этапы и модели стандартизированы.
Переходить на оплату по токенам нужно тогда когда не влазишь в лимиты подписки. И тот же opencode(как и другие оркестратор) никак не управляет подписками, он просто подключает провайдер и дергает внутри агента нужную модель в нужно провайдере.
Объясняю на примере Copilit Pro за 10 баксов доступно 300 запросов в месяц, для Cloude Sonnet 4.6 мультипликатор 1, тоесть в месяц доступно 300 запросов, для Grok Code Fast 1 мультипликатор 0.25 тоесть всего доступно 1200 запросов в месяц.
Причем один запрос максимально 128К входящих токенов, тоесть в идеальной ситуации мы можем послать 128К * 300 токенов = 37.5M токенов. Да это все в 5 часовых лимитах и прочие ограничения.
А если те же 37.5М токенов заслать через api для того же Cloude Sonnet 4.6 это 3$ за миллион токенов это уже 112.5$.
Но вот для Grok Code Fast 1 ситуация другая, можно послать 128К * 1200 токенов = 150M токенов. Через api 150M токенов для Grok Code Fast 1 обойдутся 30 баксов, по 0.2$ за миллион. Думаю что это из-за того что Microsoft вложился в Anthropic и получает ресурсы по скидки, и заинтересован в раскрутке их моделей.
У opencode go в доке написано
Тоесть если посылать максимально большие запросы как в примере выше то максимум можно утилизировать на 60$, если сравнивать с ценой за токены.
Похоже что для провайдеров выгодно продавать такие планы, потому что клиенты не утилизируют все запросы по максимуму, плюс многие пользователи берут минималку чтобы просто попробовать, и в реальности не тратят даже 10$ если смотреть по цене api.
У копилота плюс что у него доступны модели Anthropic и OpenAI одновременно, и для оркестраторов это круто, потому что там где сильны модели Anthropic слабы модели от OpenAI и наоборот. Но c 1-го июня майки меняют тарификацию и вроде как мультипликаторы и надо будет смотреть выгодно будет их дальше использовать или нет.