Бухгалтерский учет ресурсов

Начнем с Лимиты использования Правило принадлежит одному пулу выделенных счетов в одном рабочем пространстве. Его членство в аккаунте остается фиксированным, пока существует правило. Членам нужен прямой доступ пула и персональный ключ, связанный с правилом; обычный ключ не конвертируется автоматически. Все ключи одного участника для правила делят одну книгу.

Доля общего бюджета

По доле поддерживает общий суточный/месячный бюджет либо до 8 окон длительности со своим бюджетом в каждом. Одинаковые проценты участников, в сумме не более 100%, применяются ко всем выбранным окнам. Основа — токены или внутренние USD:

• По акциям токенов: Зарегистрированные входные и выходные токены учитываются по отношению к доле каждого участника; кэшированный вход является частью входных данных и не учитывается дважды.
• По сумме доли: Войди во внутренний USD Ввод, кэширование и вывод каждого запроса преобразуются с использованием модели цен, сохраненных при пересмотре этого правила. В этих ценах не указывается формула взимания платы за подписку поставщика.

В каждом окне лимит участника равен бюджету окна, умноженному на долю и округлённому вниз до минимальной единицы. Например, 25% от 1 M токенов — это 0,25 M. Положительная доля, округляющаяся до нуля, отклоняется. Нераспределённые доли и остатки округления автоматически не передаются другим. Допуск проверяет личный и групповой бюджет, включая потребление бывших участников. Лимит не начинается заново для каждого аккаунта подписки.

Они являются Внутренние бюджетыСконфигурированная сумма токенов не раскрывает фактическую емкость подписки и внутреннюю емкость. USD Это не денежный баланс или счет-фактура. SubLane Проверяет доступную квоту; поставщик может отклонить запросы до исчерпания внутреннего бюджета.

Ограничения по времени

Временные окна — отдельный тип распределения. Можно задать до 8 условий целыми часами/днями, от 1 часа до 365 дней, с общим внутренним лимитом USD по умолчанию. Каждый участник учитывается независимо и может переопределять условия. Пустой лимит означает отсутствие ограничения для этого условия: использование записывается без квоты и временного резервирования риска. Каждый завершённый запрос оценивается один раз по сохранённым ценам и учитывается во всех окнах. Исчерпание конечного условия или нехватка резерва блокирует новые запросы.

Окна отсчитываются от активации и независимо обновляются через фиксированную длительность. Сброс пятичасового окна не удаляет недельный расход. Это не скользящие интервалы оглядки назад, и они не следуют сбросам поставщика. Часовой пояс экземпляра меняет только отображение.

Участники и запланированные изменения

Изменить текущих участников немедленно меняет доли или личные лимиты, сохраняя потребление и резервы принятых запросов. Увеличение должно помещаться во всех текущих общих бюджетах; удаление и повторное добавление не очищают историю. При бюджете 100 и расходе A в 40 лимиты A/B/C по 33 требуют 106 и отклоняются, а 40/30/30 допустимы. После обновления снова проверяются все окна; расписание не обходит нехватку бюджета.

Бюджеты, лимиты окон по умолчанию и цены вступают в силу в сохранённое время либо на следующей границе текущего плана. Для нескольких окон используется самая длинная текущая длительность. Якорь, границы и расход сохраняются; короткое окно может ещё идти, а снижение лимита — сделать его исчерпанным. Новые цены не пересчитывают старые запросы.

Обычное редактирование бюджета/цен сохраняет записанный состав участников, даже если получатель больше не входит в список с доступом. Сохранение настройки не восстанавливает доступ. Новые получатели и новый структурный период требуют текущего разрешения группы.

Независимый план участников в следующей версии запрещает автоматический перенос немедленного изменения и возвращает конфликт. Явно пересмотрите или отмените тот план; остальные совместимые настройки бюджета/цен сохраняются. Фоновое обновление не подставляет новые версии в старый черновик. При конфликте используйте Обновить и проверить.

Изменение единицы, типа распределения или плана сброса требует подтверждения настоящей структурной замены. ID правила, группы и Key сохраняются; время активации становится новым якорем учёта. Одно изменение участников или цен не создаёт новый период.

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

Отменить запланированное изменение можно лишь при наличии текущей действующей версии. Если есть только начальный план, доступны пауза и перенос. Начальный перенос атомарно заменяет версию. Пауза не удаляет читаемую конфигурацию и не отменяет или откладывает активацию; после неё доступ по-прежнему запрещён, пока правило на паузе.

Начальный состав исправляется через полный редактор (PATCH /api/allocations/{id}). Требуются проверенная пара ревизий и время активации; сохранённые время и якорь остаются, права получателей на группу проверяются заново. Исправление допускается только без текущей версии и без зарегистрированных запросов. Ревизия, метаданные и аудит сохраняются одной транзакцией; ошибка или наступление активации откатывает всё. Отмена начального плана по-прежнему запрещена.

Если одобренная следующая версия действительно отличается структурой от текущей, существующее подтверждение нового периода доступно и при сохранении запланированной структуры черновика. Повторное подтверждение открывает её участников для правки. Обычные правки бюджета/цен сохраняют участников и якорь без подтверждения. Снятие этого необязательного подтверждения показывает и отправляет сохранённый состав. Замена всё ещё требует настоящего структурного отличия от текущей версии.

В отношении квот использования по ценам (По сумме, Доля в суммеи Временные окна), SubLane Если у модели нет текущей каталожной цены, то она повторно используется, когда она доступна, поэтому запросы к ней остаются заблокированными до тех пор, пока не вступит в силу ценовая ревизия. Предупреждения о покрытии цен вычисляются, когда читается правило, а не хранятся в его пересмотре: восстановленная каталожная цена автоматически очищает предупреждение каталога, в то время как модель, отсутствующая в сохраненном ценовом снимке, остается помеченной до тех пор, пока не будет включена новая редакция. Недоступные каталоги счетов сохраняют ранее сохраненные ставки и показывают предупреждение до тех пор, пока не восстановится открытие. Экономия терпит неудачу только в том случае, если не останется полезной цены. Без загруженного каталога цен или сохраненного ценового кэша нельзя создать новое ценовое ограничение использования; обновить каталог или обеспечить ценовой запас перед повторным повторением.

Для модели без сохранённой цены предупреждение показывает, когда вступит в силу исправление, сохранённое сейчас. Окна используют следующую границу самой длинной текущей длительности; повторное сохранение не делает цену доступной немедленно. Запланированная версия показывает своё время и предупреждает, что без исправленной замены модель останется заблокирована после активации.

Прямые ограничения и ожидание использования

По токенам устанавливает лимит токена участника напрямую. По сумме Устанавливает прямое внутреннее USD Ограничение с использованием сохраненных моделей цен. Оба используют один и тот же учет токенов или цен в качестве соответствующей базы акций.

Достоверное итоговое использование рассчитывается без ожидания процентов поставщика. Запрос без достоверных итогов остаётся на исправление; частичные наблюдения видны, но не являются расходом или резервом. Активный запрос резервирует 10% личного лимита, зафиксированного при допуске, минимум одну единицу в каждом конечном окне; последующие изменения не меняют резерв. В каждом таком окне допускается до четырёх одновременно выполняемых запросов участника, начатых в нём; общий бюджет проверяет также риск группы. Резерв освобождается в конце. Крупный запрос может превысить лимит, а неизвестное использование делает оценку неполной: это мягкие ограничения. Сначала видны последние 256 ожидающих записей. Учёт привязывается к допуску после очереди, диагностика длительности — к прибытию.

Для Codex потоки, SubLane может продолжать чтение вверх по течению в течение 3 секунд после того, как клиент отключается для захвата надежного конечного использования. Неудавшееся терминальное событие, которое включает полное использование, также может быть заряжено. Повторные сбои вверх по течению временно охлаждают затронутую учетную запись; успешный ответ без окончательного использования остается на рассмотрении без охлаждения учетной записи. Если учетная запись временно не удается, SubLane повторно запрашивается, прежде чем принять на работу пострадавшего члена, обеспеченную дополнительными ограничениями использования; другие члены могут продолжить работу.

Суточные/месячные правила сохраняют выбранные дату и время в часовом поясе экземпляра; отсутствующее число заменяется последним днём месяца. По умолчанию это 00:00 ежедневно либо первое число в 00:00. Обычные изменения сохраняют якорь. Пауза и отзыв доступа блокируют последующие запросы и ходы WebSocket без потери истории. Обновление квот, карты сброса, повторная авторизация и перезапуск не пополняют локальный бюджет.

Выбор Начните следующий период при создании правила окна времени запускается после наибольшей настроенной продолжительности.

Читайте и исправляйте балансы

Депутаты считают, что их собственное ограничение использования использованиеАдминистраторы рабочего пространства открыты Лимиты использования → Посмотреть использование Все сконфигурированные временные окна появляются под одним членом со своим собственным лимитом, использованной суммой, оставшейся суммой, подверженностью риску и моментом сброса; статус участника отражает наиболее ограничительное условие. USD наряду с зарегистрированными токенами; токены используют M, где 1 M = 1,000,000 tokensЛичные отчеты не раскрывают личности подписных счетов.

Баланс разделяет используемый Временные оговорки отражают только просьбы в полете; ожидающее использование остается видимым для исправления и не учитывается как использованное ограничение использования или резервная емкость. Зал приема включает автоматический буфер риска; это не является дополнительным расходным ограничением использования. Таким образом, положительное оставшееся ограничение использования может совпадать с Новые запросы временно приостановлены когда другой запрос нуждается в большем бронировании, чем текущий запасной зал, или четыре запроса все еще находятся в полете. Статус следует той же проверке риска текущего цикла, что и вход в шлюз. Это снимок и может меняться по мере завершения запросов. До окончания текущего цикла записи остаются видимыми для исправления, но не приостанавливают его прием.

Когда отложенная запись не может быть решена автоматически, администратор может ввести входные, выходные и кэшированные входные данные, подтвержденные достоверными доказательствами. Коррекция использует сохраненное правило учета запроса и пишет событие аудита. Не рассматривайте пропущенное использование как ноль или введите придуманные итоговые данные.

Администраторы рабочей среды управляют правилами /api/allocationsЧлены читают свои собственные балансы на /api/me/allocationsКлючи связываются с правилом scheme_idВидишь? рабочие места и личный API ключи.

Условия записи API

Чтение сохраняет формат ответа и добавляет write_conditions с допускающими null полями expected_current_revision_id и expected_next_revision_id. Оба обязательны для изменения существующего правила: полного PATCH, участников, отмены/переноса и замены. Отсутствующие или устаревшие условия дают HTTP 409 без изменений. Пересмотрите данные, не запрашивайте новые ID для автоматической повторной отправки старого черновика. Явное включение/пауза и исправление отдельного запроса сохраняют свои контракты.

Будущие версии требуют подтверждённый сервером expected_effective_at в секундах UTC; структурная замена также требует confirm_replacement=true. POST /api/allocations/{id}/preview принимает schedule, reschedule или replace. Участники используют POST /api/allocations/{id}/members, запланированные действия — POST /api/allocations/{id}/cancel и POST /api/allocations/{id}/reschedule. Полное сохранение не меняет включение: используйте POST /api/allocations/{id}/enabled.

Первое создание без условия времени сохраняет прежнее немедленное/отложенное начало. Если передан expected_effective_at, требуется start_next=true: календарный старт совпадает со следующей границей; старт по длительности остаётся будущим и не дальше одной максимальной длительности от времени сервера. Явный null даёт 409 из-за обязательного условия, неверный формат — 400, истёкшее/изменённое время — 409. POST /api/allocations/preview только предлагает начальное время, не создавая правило; ошибка подтверждения не переключает запрос на безусловное создание.