# Как распределять расходы на ИИ-программирование по репозиториям и проектам? > Выдавайте ограниченные учетные данные через центральный шлюз и добавляйте к каждому платному событию неизменяемые ID репозитория, проекта, задачи, команды и среды. Сверяйте использование провайдера в ledger и отделяйте общие накладные расходы от напрямую относимой работы. # Как распределять расходы на ИИ-программирование по репозиториям и проектам? Надежное распределение начинается при запросе. Каждый вызов должен содержать неизменяемые ID репозитория, проекта, задачи, команды и среды до отправки провайдеру. Последующее угадывание владельца по пользователю или тексту промпта создает спорные отчеты. Учету нужны почти мгновенные оценки для ограничений и сверенная финансовая картина. ## Определить стабильную иерархию Выбирайте ID, устойчивые к переименованиям: | Измерение | Пример | Назначение | |---|---|---| | ID репозитория | `repo_01J...` | Прямая ответственность за код | | ID проекта | `proj_checkout` | Инициатива или центр затрат | | ID задачи | `task_8421` | Отдельный запуск агента | | ID команды | `team_payments` | Организационный отчет | | Среда | `local`, `ci`, `prod` | Разделение эксперимента и эксплуатации | Отображаемые имена являются атрибутами, не ключами. Записывайте даты смены владельца. ## Автоматически маркировать запросы Получайте ID репозитория из доверенного реестра по нормализованному Git remote, а не из локальной папки. Проект и задачу берите из ticket, CI или управляющей системы. Выдавайте краткоживущие учетные данные, ограниченные этими тегами. Документированные исключения допустимы, но записывайте автора и причину. Свободный текст не должен быть основой учета. ## Использовать единую схему события стоимости Нормализуйте ответы провайдеров: ```json { "event_id": "costevt_01J...", "task_id": "task_8421", "repository_id": "repo_01J...", "project_id": "proj_checkout", "team_id": "team_payments", "provider_request_id": "req_...", "model": "provider/model-version", "input_units": 18240, "output_units": 1330, "estimated_cost_usd": 0.084, "final_cost_usd": null, "rate_card_version": "2026-10-01" } ``` Используйте ту же оболочку с подходящей единицей для поиска, embeddings, sandbox и других инструментов. ## Явно относить работу к нескольким репозиториям У задачи по нескольким репозиториям должна быть родительская задача и дочерние spans. Прямые вызовы относите к активному репозиторию, а действительно общее планирование к родительскому проекту. Не делите все поровну по умолчанию. Если точное распределение невозможно, документируйте правило и применяйте его последовательно. ## Отделить прямые расходы от общих Прямые вызовы принадлежат размеченной задаче. Шлюз, оценки, observability, общий cache и разработка платформы относятся к общему пулу. Распределяйте его по явному показателю, например прямым расходам, активным местам или задачам, и публикуйте прямые и распределенные суммы. | Класс расходов | Метод | Может ли владелец влиять? | |---|---|---| | Inference | Теги запроса | Да | | Поиск и sandbox | Теги запроса | Да | | Общий шлюз | Доля прямых расходов | Частично | | Центральная оценка | Активные репозитории | Частично | | Без распределения | Очередь исключений | Требует исправления | ## Сверять оценки с данными провайдера Для панелей и лимитов используйте мгновенные оценки. Ежедневно сопоставляйте ID провайдера, заменяйте оценки окончательными суммами, а корректировки добавляйте новыми записями. Не перезаписывайте историю. Для позднего использования или возврата сохраните событие и добавьте связанную корректировку. Оповещайте о нераспределенных расходах, несовпавших запросах и больших отклонениях. ## Сохранить конфиденциальность и аудит Тексты промптов и кода не нужны. Достаточно ID, моделей, единиц, времени, цен и ID запросов. Телеметрию содержимого регулируйте отдельно, с коротким хранением и строгим доступом. Хешируйте чувствительные ID, если финансам нужна только группировка. ## Создавать отчеты для разных решений Инженерии нужны расходы на задачу, pull request или принятое изменение. Финансам нужны месячные расходы по центру. Платформе нужна экономика по модели, cache и типу сбоя. Полезные показатели: * прямые и распределенные расходы по репозиторию; * стоимость успешной задачи; * потери на повторах и сбоях; * набор моделей и экономия cache; * доля нераспределенных расходов; * отклонение бюджета по проекту. Не ранжируйте разработчиков по сырым расходам без результата и сложности. ## Сохранить переносимость выбора провайдера Центральный шлюз одинаково ставит теги при нескольких моделях. Atlas Cloud может быть OpenAI-совместимым слоем доступа к тексту, изображениям и видео, а внутренний ledger остается источником данных о владельцах репозитория и проекта. Так можно сменить провайдера без перестройки распределения. ## Итог Распределяйте расходы в момент запроса с помощью стабильных ID и ограниченных учетных данных. Сверяйте итоговые счета в append-only ledger, показывайте общие расходы и считайте нераспределенные траты операционной ошибкой. ## FAQ ### Какие минимальные метаданные нужны для распределения расходов? Записывайте стабильные ID репозитория, проекта или центра затрат, задачи, команды и среды, а также модель, ID запроса провайдера, время, использование и стоимость. Не полагайтесь только на изменяемые названия. ### Должны ли разработчики вводить теги проекта вручную? Предпочтительны автоматические теги из Git remote, CI, системы задач или ограниченного ключа. Ручные теги полезны для исключений, но слишком непоследовательны для основного учета. ### Как распределять общие расходы платформы агентов? Держите общую инфраструктуру в отдельном пуле и распределяйте по документированному показателю, например прямым затратам, активным местам или числу задач. Не скрывайте накладные расходы в цене модели. ### Как учитывать задачу с несколькими репозиториями? Используйте родительскую задачу и дочерние span для каждого репозитория. Прямые вызовы относите к активному репозиторию, а действительно общее планирование к родительскому проекту. ### Нужны ли в отчетах тексты промптов и кода? Нет. Достаточно ID, числа token, моделей, времени и цен. Хранение содержимого регулируйте отдельно, чтобы снизить риски конфиденциальности и безопасности. ### Как часто сверять расходы провайдера? Используйте почти мгновенные оценки для ограничений и ежедневную сверку для финансов. Сопоставляйте ID запросов и добавляйте поздние корректировки, не перезаписывая историю.