Перейти к основному содержанию
Вы почти никогда не запускаете один ключ. У реального рабочего пространства есть production-ключ, staging-ключ, локальный ключ разработчика, может быть, разовый для нагрузочного теста — все вызывают одни и те же модели через один и тот же шлюз. Различайте их тегом environment: короткой свободной меткой, которую вы ставите на каждый ключ, чтобы консоль, ваша команда и вкладка Usage Tracking могли группировать ключи по тому, где они работают. Это маленькое организационное поле, а не применяющее — оно не меняет того, что может делать ключ. О лимитах, ограничивающих ключ (модели, IP, расходы, срок действия, политики), начните с обзора ограниченных ключей.

​
1. Зачем тег окружений API-ключа

Когда каждый ключ выглядит как sk-orca-•••• в списке, вы не можете отличить production-ключ от одноразового dev-ключа — а это именно тот ключ, который вы не хотите по ошибке ротировать, отзывать или поднимать ему лимит расходов. Тег environment превращает анонимную учётку в помеченную:
  • С одного взгляда — список ключей показывает, какие ключи prod, staging или dev, так что вы действуете с нужным.
  • По расходам — вкладка Usage Tracking может сворачивать расходы по окружению, так что «во сколько нам обходится staging на этой неделе» — это один фильтр, а не таблица.
  • По соглашению — общий словарь (prod / staging / dev) по всему рабочему пространству, так что коллега, читающий список, понимает вашу раскладку без вопросов.
Тег свободный и только описательный. Он не ограничивает модели, IP, расходы или политику — это другие поля ключа. Два ключа с тегом prod не получают никакого особого обращения помимо общей метки.

​
2. Что принимает поле

environment — опциональная короткая текстовая метка на объекте ключа:
СвойствоПоведение
ТипСвободная строка — без фиксированного enum. prod, staging, dev — это соглашения, а не встроенные значения.
ДлинаОбрезается от окружающих пробелов и ограничивается 32 символами; всё длиннее усекается.
Пустой / не заданКлюч без тега читается как непомеченное состояние и сворачивается в сегмент unlabeled в Usage Tracking.
Влияние на трафикНет — чисто организационное.
Выберите маленький, стабильный словарь и придерживайтесь его. prod, staging, dev достаточно для большинства команд; согласованность — это то, что делает тег полезным, когда вы фильтруете расходы. Поле свободного текста с prod, Prod и production в нём сводит цель на нет.

​
3. Задайте тег на ключе

Задайте environment в редакторе ключа в консоли (/console/token) — там же, где вы задаёте лимиты моделей и привязки политик. Создание или редактирование ключей требует роли Developer или выше.
1

Откройте ключ

В консоли перейдите в Keys (/console/token) и создайте новый ключ или отредактируйте существующий.
2

Задайте метку окружения

Введите короткую метку — например, prod — в поле Environment. Держите её короче 32 символов.
3

Сохраните

Тег теперь прикреплён к ключу. Он появляется в списке ключей и становится доступным как измерение Usage Tracking.
Редактирование ключа для изменения несвязанного поля (переименование, новый лимит расходов) сохраняет существующий тег окружения — тег меняется только когда вы явно его задаёте. Чтобы очистить тег, задайте полю пустое значение; это намеренный сброс обратно в непомеченное состояние.

​
4. Сегментируйте расходы по окружению

Когда ваши ключи помечены, вкладка Usage Tracking (консоль → Overview) может группировать расходы, запросы и токены по измерению environment. Она сворачивает использование каждого ключа под его меткой окружения, с непомеченными ключами, собранными под unlabeled. Это отвечает на вопросы, которые не может представление по ключу, на уровне, на котором вы реально планируете бюджет:
  • Сколько тратит staging против prod на этой неделе?
  • Новый dev-ключ превысил то, что мы ожидали?
  • Какое окружение вызвало всплеск во вторник?
То же представление также сегментирует по ключу, модели, участнику и задаче сценария — окружение это то, что отображает где выполнялся трафик. Сегментация расходов читает только строки потребления, ограничена вашим рабочим пространством, так что числа сходятся с Billing.
Измерение окружения читает текущую метку на каждом ключе, когда вы загружаете отчёт. Перепометка ключа меняет, как его историческая трата сворачивается в следующий раз, когда вы открываете представление — тег это живое свойство ключа, а не штамп, замороженный на прошлых запросах.

​
5. Разобранный пример: три ключа, одно рабочее пространство

Небольшая команда, запускающая один продукт в трёх окружениях:
КлючenvironmentДругая область (часть, которая реально применяет)
Production-агентprodтесный firewall_policy_id, недельный credit_limit_usd, закреплённый allow_ips
Staging-агентstagingразрешающая политика firewall в shadow-режиме, более низкий лимит
Локальный devdevmodel_limits на одну дешёвую модель, ближайший expired_time
Теги не меняют ни один из этих лимитов — они делают три ключа читаемыми. Список читается с одного взгляда, вкладка Usage показывает три полосы расходов вместо трёх непрозрачных id ключей, а когда вы ротируете prod-ключ, вы уверены, что схватили нужный.
Сочетайте тег окружения с реальным применением, чтобы каждый ключ был и помечен, и ограничен. Тег говорит вам, что такое ключ; чек-лист минимальных полномочий гарантирует, что он не может больше, чем нужно этому окружению.

​
6. Теги vs. применение — не путайте их

Тег окружения — самое лёгкое поле на ключе. Легко потянуться к нему как к контролю безопасности; он им не является. Если вы хотите, чтобы dev-ключ был неспособен бить по production-моделям или тратить реальные деньги, метка этого не сделает — это сделают применяющие поля:

Лимиты моделей

model_limits — это то, что реально не даёт dev-ключу вызвать frontier-модель, а не тег dev.

Квота, лимит и срок действия

credit_limit_usd и expired_time ограничивают расходы и время жизни. Тег организует; эти ограничивают.

Привязка политик

guardrail_id и firewall_policy_id прикрепляют политики содержимого и вызовов инструментов, управляющие трафиком ключа.

Объект токена

Полный справочник поле-за-полем для ключа, включая тег окружения.

​
7. Куда это вписывается

Тег окружения — один срез более широкой модели ключей: узкие, помеченные идентичности для каждого агента и каждого места, где он работает.

Обзор ограниченных ключей

Хаб для каждого поля, которое несёт ключ.

Область и ключи

Как рабочие пространства, политики и ключи вкладываются друг в друга.

Управление ключами

Создавайте, редактируйте и отзывайте ключи в консоли.
Тег — самая дешёвая инвестиция в опрятное рабочее пространство: несколько символов на ключ, и разница между списком, который вы можете читать, и тем, который не можете. Ставьте на каждый ключ его окружение в момент создания — и пусть другие поля делают применение.