Сожалеем, что ввели в заблуждение! Разумеется, мы не планировали как-либо скрыто "обдирать" пользователей — дело в логике некоторых провайдеров и в механизме расчётов нашего сервиса.
Бесплатными моделями являются только те, которые помечены лейблом Free — например, kodikrouter/free. В описании модели kodikrouter/pareto-code указано, что это, по сути, автовыбор модели под вашу задачу. По этой причине, к сожалению, не сможем вернуть средства, ушедшие на тест, т.к. они ушли провайдерам моделей.
Добавим специальный индикатор для пользователей, чтобы такие модели было проще отличить.
Немного про механику бесплатных моделей. Если рядом с моделью не указано, что она бесплатная (Free), это значит, что она не является бесплатной. В некоторых случаях стоимость может быть настолько маленькой, что в силу округления и отображения знаков после запятой цена выглядит как 0 рублей. Однако фактически такая модель всё равно тарифицируется за каждый запрос. Подскажите какую модель вы использовали? Если модель действительно была бесплатной, а средства всё равно списались, мы просто компенсируем эти расходы. Коллекторов в команде не собираемся держать).
По поводу лимитов: вы можете установить ограничения на уровне API-ключа (в личном кабинете) и таким образом контролировать расходы.
По умолчанию лимита нет по следующей причине: мы не можем прервать запрос посреди выполнения в тот момент, когда баланс достигает нуля. Если бы система останавливала запрос на полпути, тогда пользователи, наоборот, бы жаловались на то, что задача не была завершена. По этой же причине аналогичный подход используется в OpenRouter.
Цены на модели зависят от их провайдеров. Мы агрегируем к ним удобный доступ — однако не можем сделать ту или иную модель бесплатной или изменить её стоимость.
Именно! Вопрос в наших реалиях актуальный, поэтому мы озаботились его универсальным решением как для соло-разработчиков, так и для команд любого масштаба. Сами запросы в роутере, разумеется, всё равно уходят к LLM в облако — без этого никак.
Но мы выстроили вокруг этого шага два слоя защиты в зависимости от уровня требований.
Во-первых, для всех пользователей у нас работает KodikShield — отдельный шифрующий слой на стороне KodikRouter. Он действует как анонимайзер на основе NER-модели и заменяет на плейсхолдеры все типы уязвимых данных (ФИО, номера телефонов, ключи шифрования, API-токены, в сумме девять типов) ещё до того, как запрос уходит к провайдеру LLM. Анонимайзер можно включать/выключать и настраивать: априори шифруется девять типов данных, но можно задавать их и кастомно. KodikShield в процессе получения юридического заключения от лицензиата ФСТЭК. К сожалению занимает несколько месяцев, но первично уже одобрили.
Во-вторых, для enterprise-клиентов мы поддерживаем on-premise развёртывание самого KodikRouter внутри контура компании. В этом случае анонимизация происходит локально, и чувствительные данные не покидают периметр — до наших серверов вообще ничего не доходит, только уже обезличенный запрос идёт дальше к LLM.
Да, шлюзов много, и спорить с этим было бы странно. Мы не пытаемся делать вид, что «изобрели API-router для РФ». Но увидели ряд проблем, которые смогли закрыть: ограниченный каталог моделей, нестабильная работа части решений, а также отсутствие вещей вроде анонимизации данных и on-prem сценариев.
А усталость от нейрослоп-текстов хорошо понимаем, бессмысленная вода нам самим не нравится. Но как раз поэтому все наши хабрапосты написаны вручную. Тексты про ИИ в любом случае требуются, но где-то это бездумная копипаста из LLM без проверки фактов, а где-то над каждой строчкой думали люди. Нам близок второй вариант.
У нас есть документация на kodikrouter.ru/docs и список моделей на kodikrouter.ru/models, имеющаяся информация в основном публикуется там. Если будут возникать вопросы, на которые там нет ответов — можете задавать их все здесь или напрямую нам, постараемся на все ответить.
Вопрос наценки, конечно, всегда один из самых обсуждаемых. В целом, вы правы: если человеку нужен просто прямой доступ к API без каких-либо дополнительных слоев — OpenRouter может быть выгоднее. Мы не пытались это отрицать.
Берем 10% не только за "проксирование запросов". Внутри ещё:
— инфраструктура и маршрутизация — переключение между моделями в случае падения основной — хранение истории и биллинг — поддержка, которая оперативно отвечает — анонимизация уязвимых данных
Все это требует ресурса, поэтому и образовались эти 10% сверху. Ну и, как по-нашему, хорошая альтернатива на рынке никогда не лишняя, здоровая конкуренция в итоге всем идет на пользу.
На Хабре недавно была новость о том, что усложняется доступ из России к шлюзу OpenRouter, и судя по комментариям к ней, для аудитории Хабра эта тема актуальна.
Изначально доступом к моделям мы занимались в рамках редактора Kodik, но глядя на подобные новости и новые ограничения, поняли, что шлюз будет полезен и как отдельный проект.
Немного дополнили текст после вашего комментария. Здесь важно учитывать, что работа ведётся «в вакууме»:
Во-первых, без использования интернета.
А во-вторых, без участия человека, который мог бы направлять по ходу действия.
В таких условиях сделать проект, проходящий 95% тестов, у лучшей модели получилось в 3% случаев. Но при реальном применении в сложных проектах, конечно, стоит обращаться к моделям не в формате «сделай весь проект сама безнадзорно», а компетентно ими управлять.
Сами пробовали только через сайт и несложными промптами, но на такие модель отвечала в целом уместно. Например, если сначала спросить про любимую книгу (назвала «Робинзона Крузо»), а потом для проверки уточнять «а кто там был вторым персонажем», «на каком языке они общались».
Это интересный вопрос, да. Пока что таких результатов никто не добился, но и мощных ретро-моделей ещё не было. А Демис Хассабис (DeepMind) называл возможным критерием определения AGI как раз подобное: «Если модель, обученная на данных до 1911 года, сможет сама открыть теорию относительности».
Авторы talkie эту его идею упомянули в своём посте, так что тоже явно об этом думают. И любопытно будет последить за развитием в этом направлении.
Да, посту Mozilla не помешало бы больше подробностей «какими именно были уязвимости», в идеале — с подробным разбором отдельных примеров. Но возможно, там пока что слишком заняты устранением уязвимостей и не хотят давать много пищи для ума злоумышленникам, а позже больше информации сообщат.
Спасибо за комментарий, тут интересно узнать разные мнения. Мы перевели текст, потому что с «прогнозом от Mozilla» интересно ознакомиться в любом случае. А насколько именно он сбудется — думаем, полностью покажет только время.
Например, про «271 уязвимость» сразу хочется понять: а в других известных проектах теперь сколько найдут? У Mozilla больше других или меньше? Пока что полной информации нет, будем следить за этим.
Про «стиль работы» — да, мы тоже подобное ощущаем, и нам он тоже у Claude нравится. А вот в случае с Gemini стиль работы не нравится, но при этом в отношении дизайна он хорош.
По нашей практике, если видим, что качество генерации кода по субъективной оценке падает, то смотрим сразу на несколько метрик одновременно: прохождение юнит- и интеграционных тестов, соблюдение инвариантов бизнес-логики, а также сравнение результатов с прошлой версией спецификации. Субъективная оценка ревьюеров важна, но для объективности её комбинируем с автоматикой.
Для диффа между версиями спецификации мы используем подход, где фиксируем ключевые элементы функционала и ограничения в виде отдельных блоков. Так проще выявлять, что действительно изменилось, а что лишь косметика, и минимизировать шум от полного пересмотра спецификации. Пока это совсем не тривиально, и полностью автоматизировать это LLM пока не позволяет. Но помогает разбивка на мелкие, атомарные элементы, которые можно проверять отдельно.
Спасибо за развёрнутый комментарий, очень в точку.
Про DDD — полностью согласны, у нас похожие наблюдения: чем «человечнее» и семантически богаче код, тем лучше с ним работает LLM. По сути, хорошие имена и явные границы домена начинают играть роль дополнительного контекста, которого модели обычно не хватает.
Про риск-менеджмент тоже болезненно знакомо. Есть ощущение, что ИИ действительно убирает тот естественный “фильтр боли”, который раньше заставлял инвестировать в архитектуру — теперь многое «как будто работает», и это создаёт иллюзию, что можно не думать о последствиях.
А в случае с джунами наш прогноз оптимистичнее: думаем, что из-за «парадокса Джевонса» количество вакансий будет расти (софт начнут делать даже в тех компаниях, где раньше этим не занимались), а способные джуны с ИИ смогут быстрее прежнего осваивать технологии и сократить путь к сеньору, так что толковые люди понадобятся.
В общем, спасибо, что так подробно дополнили — как раз ради таких комментариев и писали пост.
Да, SDD у нас используется, но не как жёсткий формальный процесс, а как часть рабочего флоу. Перед задачами фиксируем ожидаемый результат, ограничения и инварианты, чтобы агент не «додумывал» и не уходил в лишние части системы, а дальше спокойно уточняем и обновляем спецификацию по ходу работы. По сути, это не «написали документ и забыли», а живой слой между задачей и кодом, который постоянно синхронизируется с реальностью. В связке с TDD и риск-менеджментом это даёт гораздо более предсказуемый результат, чем каждый из подходов по отдельности.
Сожалеем, что ввели в заблуждение! Разумеется, мы не планировали как-либо скрыто "обдирать" пользователей — дело в логике некоторых провайдеров и в механизме расчётов нашего сервиса.
Бесплатными моделями являются только те, которые помечены лейблом Free — например, kodikrouter/free. В описании модели kodikrouter/pareto-code указано, что это, по сути, автовыбор модели под вашу задачу. По этой причине, к сожалению, не сможем вернуть средства, ушедшие на тест, т.к. они ушли провайдерам моделей.
Добавим специальный индикатор для пользователей, чтобы такие модели было проще отличить.
Немного про механику бесплатных моделей. Если рядом с моделью не указано, что она бесплатная (Free), это значит, что она не является бесплатной. В некоторых случаях стоимость может быть настолько маленькой, что в силу округления и отображения знаков после запятой цена выглядит как 0 рублей. Однако фактически такая модель всё равно тарифицируется за каждый запрос. Подскажите какую модель вы использовали? Если модель действительно была бесплатной, а средства всё равно списались, мы просто компенсируем эти расходы. Коллекторов в команде не собираемся держать).
По поводу лимитов: вы можете установить ограничения на уровне API-ключа (в личном кабинете) и таким образом контролировать расходы.
По умолчанию лимита нет по следующей причине: мы не можем прервать запрос посреди выполнения в тот момент, когда баланс достигает нуля. Если бы система останавливала запрос на полпути, тогда пользователи, наоборот, бы жаловались на то, что задача не была завершена. По этой же причине аналогичный подход используется в OpenRouter.
Цены на модели зависят от их провайдеров. Мы агрегируем к ним удобный доступ — однако не можем сделать ту или иную модель бесплатной или изменить её стоимость.
На данный момент зафиксировали курс ЦБ + 3руб + 10%. Возможно сейчас это и не подарок, но мы делаем KodikRouter не ради быстрой прибыли.
Наша конечная цель в том, чтобы предоставить решение, которое может помочь ускорить темпы роста нашей ИИ-индустрии.
Да, подписка для домашнего использования звучит сильно приятнее, чем считать токены.
Мыслим с вам в одну сторону, так что, возможно, скоро будет повод вернуться к этой теме)
Ещё на стадии проектирования KodikRouter хотели подобных казусов избежать. Оставим их на совести продуктов, в которых эти казусы случаются.
В нашем решении все параметры настраиваемые и соблюдаются строго, в этом мы максимально уверены. Будем рады, если протестируете.
Именно! Вопрос в наших реалиях актуальный, поэтому мы озаботились его универсальным решением как для соло-разработчиков, так и для команд любого масштаба. Сами запросы в роутере, разумеется, всё равно уходят к LLM в облако — без этого никак.
Но мы выстроили вокруг этого шага два слоя защиты в зависимости от уровня требований.
Во-первых, для всех пользователей у нас работает KodikShield — отдельный шифрующий слой на стороне KodikRouter. Он действует как анонимайзер на основе NER-модели и заменяет на плейсхолдеры все типы уязвимых данных (ФИО, номера телефонов, ключи шифрования, API-токены, в сумме девять типов) ещё до того, как запрос уходит к провайдеру LLM. Анонимайзер можно включать/выключать и настраивать: априори шифруется девять типов данных, но можно задавать их и кастомно. KodikShield в процессе получения юридического заключения от лицензиата ФСТЭК. К сожалению занимает несколько месяцев, но первично уже одобрили.
Во-вторых, для enterprise-клиентов мы поддерживаем on-premise развёртывание самого KodikRouter внутри контура компании. В этом случае анонимизация происходит локально, и чувствительные данные не покидают периметр — до наших серверов вообще ничего не доходит, только уже обезличенный запрос идёт дальше к LLM.
Оба решения удовлетворяют требованиям 152-ФЗ.
Спасибо, что заметили, добавим. Пока что можно ориентироваться на OpenRouter.
Да, шлюзов много, и спорить с этим было бы странно. Мы не пытаемся делать вид, что «изобрели API-router для РФ». Но увидели ряд проблем, которые смогли закрыть: ограниченный каталог моделей, нестабильная работа части решений, а также отсутствие вещей вроде анонимизации данных и on-prem сценариев.
А усталость от нейрослоп-текстов хорошо понимаем, бессмысленная вода нам самим не нравится. Но как раз поэтому все наши хабрапосты написаны вручную. Тексты про ИИ в любом случае требуются, но где-то это бездумная копипаста из LLM без проверки фактов, а где-то над каждой строчкой думали люди. Нам близок второй вариант.
У нас есть документация на kodikrouter.ru/docs и список моделей на kodikrouter.ru/models, имеющаяся информация в основном публикуется там. Если будут возникать вопросы, на которые там нет ответов — можете задавать их все здесь или напрямую нам, постараемся на все ответить.
Вопрос наценки, конечно, всегда один из самых обсуждаемых. В целом, вы правы: если человеку нужен просто прямой доступ к API без каких-либо дополнительных слоев — OpenRouter может быть выгоднее. Мы не пытались это отрицать.
Берем 10% не только за "проксирование запросов". Внутри ещё:
— инфраструктура и маршрутизация
— переключение между моделями в случае падения основной
— хранение истории и биллинг
— поддержка, которая оперативно отвечает
— анонимизация уязвимых данных
Все это требует ресурса, поэтому и образовались эти 10% сверху. Ну и, как по-нашему, хорошая альтернатива на рынке никогда не лишняя, здоровая конкуренция в итоге всем идет на пользу.
На Хабре недавно была новость о том, что усложняется доступ из России к шлюзу OpenRouter, и судя по комментариям к ней, для аудитории Хабра эта тема актуальна.
Изначально доступом к моделям мы занимались в рамках редактора Kodik, но глядя на подобные новости и новые ограничения, поняли, что шлюз будет полезен и как отдельный проект.
Немного дополнили текст после вашего комментария. Здесь важно учитывать, что работа ведётся «в вакууме»:
Во-первых, без использования интернета.
А во-вторых, без участия человека, который мог бы направлять по ходу действия.
В таких условиях сделать проект, проходящий 95% тестов, у лучшей модели получилось в 3% случаев. Но при реальном применении в сложных проектах, конечно, стоит обращаться к моделям не в формате «сделай весь проект сама безнадзорно», а компетентно ими управлять.
На HuggingFace выложены и base model, и instruction-версия, на сайте — вторая из них.
Сами пробовали только через сайт и несложными промптами, но на такие модель отвечала в целом уместно. Например, если сначала спросить про любимую книгу (назвала «Робинзона Крузо»), а потом для проверки уточнять «а кто там был вторым персонажем», «на каком языке они общались».
Это интересный вопрос, да. Пока что таких результатов никто не добился, но и мощных ретро-моделей ещё не было. А Демис Хассабис (DeepMind) называл возможным критерием определения AGI как раз подобное: «Если модель, обученная на данных до 1911 года, сможет сама открыть теорию относительности».
Авторы talkie эту его идею упомянули в своём посте, так что тоже явно об этом думают. И любопытно будет последить за развитием в этом направлении.
Да, посту Mozilla не помешало бы больше подробностей «какими именно были уязвимости», в идеале — с подробным разбором отдельных примеров. Но возможно, там пока что слишком заняты устранением уязвимостей и не хотят давать много пищи для ума злоумышленникам, а позже больше информации сообщат.
Спасибо за комментарий, тут интересно узнать разные мнения. Мы перевели текст, потому что с «прогнозом от Mozilla» интересно ознакомиться в любом случае. А насколько именно он сбудется — думаем, полностью покажет только время.
Например, про «271 уязвимость» сразу хочется понять: а в других известных проектах теперь сколько найдут? У Mozilla больше других или меньше? Пока что полной информации нет, будем следить за этим.
Про «стиль работы» — да, мы тоже подобное ощущаем, и нам он тоже у Claude нравится. А вот в случае с Gemini стиль работы не нравится, но при этом в отношении дизайна он хорош.
По нашей практике, если видим, что качество генерации кода по субъективной оценке падает, то смотрим сразу на несколько метрик одновременно: прохождение юнит- и интеграционных тестов, соблюдение инвариантов бизнес-логики, а также сравнение результатов с прошлой версией спецификации. Субъективная оценка ревьюеров важна, но для объективности её комбинируем с автоматикой.
Для диффа между версиями спецификации мы используем подход, где фиксируем ключевые элементы функционала и ограничения в виде отдельных блоков. Так проще выявлять, что действительно изменилось, а что лишь косметика, и минимизировать шум от полного пересмотра спецификации. Пока это совсем не тривиально, и полностью автоматизировать это LLM пока не позволяет. Но помогает разбивка на мелкие, атомарные элементы, которые можно проверять отдельно.
Спасибо за развёрнутый комментарий, очень в точку.
Про DDD — полностью согласны, у нас похожие наблюдения: чем «человечнее» и семантически богаче код, тем лучше с ним работает LLM. По сути, хорошие имена и явные границы домена начинают играть роль дополнительного контекста, которого модели обычно не хватает.
Про риск-менеджмент тоже болезненно знакомо. Есть ощущение, что ИИ действительно убирает тот естественный “фильтр боли”, который раньше заставлял инвестировать в архитектуру — теперь многое «как будто работает», и это создаёт иллюзию, что можно не думать о последствиях.
А в случае с джунами наш прогноз оптимистичнее: думаем, что из-за «парадокса Джевонса» количество вакансий будет расти (софт начнут делать даже в тех компаниях, где раньше этим не занимались), а способные джуны с ИИ смогут быстрее прежнего осваивать технологии и сократить путь к сеньору, так что толковые люди понадобятся.
В общем, спасибо, что так подробно дополнили — как раз ради таких комментариев и писали пост.
Да, SDD у нас используется, но не как жёсткий формальный процесс, а как часть рабочего флоу. Перед задачами фиксируем ожидаемый результат, ограничения и инварианты, чтобы агент не «додумывал» и не уходил в лишние части системы, а дальше спокойно уточняем и обновляем спецификацию по ходу работы. По сути, это не «написали документ и забыли», а живой слой между задачей и кодом, который постоянно синхронизируется с реальностью. В связке с TDD и риск-менеджментом это даёт гораздо более предсказуемый результат, чем каждый из подходов по отдельности.