LegalOn сократила ежедневные расходы на Codex на 65% без потери скорости

LegalOn сократила оценочные ежедневные расходы на Codex на 65% и при этом не потеряла в скорости разработки. Об этом сообщает блог OpenAI. В заголовке материала фигурирует «вдвое», но фактическая цифра выше: если траты упали на 65%, компания платит около 35% от прежней суммы, то есть примерно в 2,9 раза меньше.

Что именно сделали

В опубликованном кратком описании названы два приёма. Первый: LegalOn сопоставила задачи с вариантами Astra, Sol и Luna. Второй: компания стратегически управляла бюджетами. Что скрывается за названиями Astra, Sol и Luna (разные модели, режимы или конфигурации) и как они различаются по цене и возможностям, в доступном фрагменте не раскрывается. Поэтому домысливать не будем.

Логика при этом понятна и знакома всем, кто платит за токены. Рутинную работу не нужно гнать через самый дорогой вариант. Простые правки, генерацию шаблонного кода и мелкие рефакторинги можно отдавать более дешёвому уровню, а сложные архитектурные решения и запутанный отладочный контекст оставлять тому, что дороже и сильнее.

Ключевые цифры и факты

• Снижение оценочных ежедневных расходов на Codex: 65%.
• Скорость разработки: сохранена, количественных данных в источнике нет.
• Задействованы три варианта: Astra, Sol и Luna.
• Подход: подбор варианта под тип задачи плюс управление бюджетами.
• Тип метрики: именно оценочные дневные затраты, а не подтверждённые счета за период.

Где цифра требует осторожности

Слово «оценочные» здесь важно. Это расчёт, а не итог из бухгалтерии, и от выбранной базы сравнения зависит многое. Если раньше все запросы шли через самый дорогой вариант, то 65% экономии выглядят реалистично и даже скромно. Если базой была уже частично оптимизированная схема, результат заметнее.

Второй вопрос касается скорости. «Сохранили скорость разработки» может означать время цикла от задачи до слияния, число закрытых тикетов или субъективную оценку команды. Без метрики и периода измерения это утверждение остаётся заявлением, а не доказательством. Пока источник не показывает ни числа ревью-итераций, ни доли задач, которые пришлось переделывать на более сильном варианте. А именно такие переделки и съедают экономию.

Наконец, неизвестен масштаб: 65% от небольшой суммы и 65% от крупного бюджета для команды выглядят по-разному.

Что можно взять в работу

Можно применить этот опыт и без доступа к деталям LegalOn.

• Разметьте задачи по сложности. Начните с трёх корзин: механическая правка, типовая фича, нестандартная проблема. Для каждой выберите минимально достаточный вариант.
• Считайте стоимость задачи, а не запроса. Дешёвая модель, которая требует трёх попыток, может обойтись дороже одной попытки сильной.
• Задайте бюджеты по командам или потокам работы и смотрите на них ежедневно. Дневная гранулярность, о которой говорит LegalOn, позволяет заметить перерасход до конца месяца.
• Замеряйте скорость до оптимизации. Без базовой линии вы не сможете проверить, что она осталась прежней.
• Отслеживайте долю эскалаций с дешёвого уровня на дорогой. Если она растёт, маршрутизация настроена неудачно.

Кейс LegalOn показывает, что расходы на ИИ-кодинг поддаются управлению не хуже облачных счетов. Полную картину можно будет оценить, когда появятся детали: что такое Astra, Sol и Luna и как измерялась скорость.