Токены: стоимость и оптимизация
Проектное предложение от 22 сентября 2026 года. Маршрутизация моделей, Jev, учёт баланса и биллинг пока не реализованы.
Основная цель
Оптимизируем стоимость успешно завершённой и проверенной задачи. Дешёвый вызов не помогает, если после него нужны повторные попытки или ручное исправление. Качество результата и разрешения на изменения сохраняются при любом выборе модели.
Цена для клиента и наши расходы
Подписка $10 в месяц за сайт включает $10 внутреннего баланса агента по тарифам Securify. При использовании своего агента клиент платит Securify фиксированные $10 за сайт, а расходы на модель оплачивает своему провайдеру. Клиентская модель оплаты →
Для встроенного агента ведём два отдельных учёта:
- Расход клиента: фактическое использование × опубликованный тариф Securify.
- Себестоимость: счёт провайдера за модели плюс инструменты, вычисления, хранение, повторные попытки и поддержка.
Экспериментальная наценка 100% означает множитель ×2 к выбранной базе стоимости модели. Например, вызов стоимостью $0,01 списывает $0,02 внутреннего баланса. При таком правиле полностью потраченный баланс $10 соответствует $5 расходов на модели. Оставшиеся $5 выручки ещё должны покрыть остальные расходы: это не чистая прибыль и не доказанная маржинальность продукта.
Это иллюстрация одной модели ценообразования, а не окончательный тариф. Внешнему клиенту не требуется раскрывать нашу закупочную цену, но нужны понятные собственные ставки и история списаний. Изменение модели не должно незаметно менять уже согласованный бюджет задачи.
Нельзя обещать, что баланс всегда расходуется ровно вдвое быстрее, чем у своего агента: модели, контекст, кеширование и число попыток могут отличаться. Дешевле для Securify и дешевле для клиента — разные показатели; измеряем оба.
Как распределять работу
| Работа | Предлагаемый исполнитель | Почему |
|---|---|---|
| Проверка прав, путей, лимитов, хешей и состояния подключения | Обычный код | Известные правила не требуют модели |
| Намерение клиента, выбор категории или релевантного фрагмента | Jev, если подтвердится польза | Узкий структурированный ответ |
| Простые уточнения и объяснение готового результата | Недорогая языковая модель или шаблон | Не нужен сложный анализ для каждого сообщения |
| Неоднозначная находка, план изменения, сложный контекст | Более сильная модель | Ошибки здесь могут увеличить стоимость всей задачи |
| Проверка результата | Инструменты и функциональные проверки; модель объясняет вывод | Уверенный текст не заменяет проверку сайта |
Путь не обязан проходить через все модели. Очевидную сложную задачу сразу передаём сильной модели, без лишнего платного промежуточного вызова. При неопределённости собираем данные или повышаем уровень модели. Решение о правах всегда остаётся в коде сервиса.
Где применить Jev
Первый кандидат — определение намерения сообщения. В дальнейшем можно исследовать отбор релевантных свидетельств, но не скрывать исходные сигналы сканеров по решению модели. Jev даёт структурированный ответ, а не объяснение или патч. Роль TypeSafe и эксперимент →
Дополнительный вызов полезен, только если снижает стоимость всей задачи при сопоставимом качестве. Если основной агент повторяет ту же работу, Jev может добавить расходы. Цены проверяем перед экспериментом по прайсу провайдера, а экономию измеряем на наших данных.
Как уменьшать контекст и число вызовов
- Сканировать и фильтровать файлы инструментами. Передавать модели конкретные находки, пути, хеши и нужные фрагменты вместо всего сайта.
- Хранить структурированное состояние задачи: цель, разрешения, факты, нерешённые вопросы и ссылки на артефакты. Не пересылать всю историю постоянно.
- Использовать краткие сводки со ссылками на исходные свидетельства. Для решения об изменении агент должен иметь возможность прочитать оригинал.
- Возвращать из MCP ограниченные структурированные результаты, пагинацию и явные признаки пропусков. Не скрывать неполноту ради меньшего контекста.
- Кешировать пригодные результаты по клиенту, сайту, хешам данных, версии инструмента, модели и skill. Инвалидировать после изменений; не переиспользовать чужие данные, устаревшие разрешения или старую проверку как новую.
- Проверить кеширование префиксов у выбранного провайдера отдельно. Не считать скидку гарантированной до измерения реальных usage.
- Ограничить число попыток и повтор одинаковых действий без новых данных. При достижении лимита возвращать понятный статус, а не продолжать цикл.
Бюджет задачи и надёжность списаний
Предлагаем до запуска оценивать диапазон расходов и резервировать бюджет в пределах согласованного лимита. После выполнения сверять резерв с фактическим usage; неиспользованную часть освобождать. Записывать версию тарифов, модель, входные, выходные и кешированные токены, себестоимость и клиентское списание.
Идентификатор операции предотвращает повторное списание при повторной доставке события. Неудачные вызовы и технические повторы учитываются как наши расходы; правила их оплаты клиентом нужно определить до запуска биллинга. Округляем денежные суммы при отображении, сохраняя точность внутреннего учёта.
Для операций записи заранее предусматриваем бюджет на проверку и восстановление. Если его недостаточно, запись не начинаем. Исчерпание клиентского баланса не должно оставлять уже начатое изменение без проверки: завершение или восстановление становится обязательством сервиса. Новые задачи при этом ждут пополнения. Автоматическую докупку без выбранного клиентом условия не включаем.
В режиме своего агента Securify не контролирует его контекст и стоимость модели. Экономим компактными ответами MCP, точными skills и качеством инструментов. Наши внутренние вызовы Jev, если появятся, учитываем в себестоимости сервиса, без скрытой доплаты за токены внешнему клиенту.
План эксперимента
Сначала измеряем основной процесс. Затем по одному проверяем сокращение контекста, кеширование, выбор моделей и Jev — на одинаковых задачах и правах.
Сравниваем стоимость успешно проверенной задачи, качество, ручные вмешательства, время и расход клиентского баланса. Включаем ложные срабатывания, нехватку данных, несколько языков и ошибки инструментов. Экономия не компенсирует ухудшение критических проверок.
Маршрутизацию сначала оцениваем без влияния на действия. Учёт использования и выбор моделей через Agentfy ещё нужно подтвердить по его API.