Ошибка Anthropic API key в OpenClaw останавливает выбранный Anthropic route, но причина не всегда в самом ключе. Один и тот же симптом может появиться из-за missing provider auth, отклоненного или отозванного key, OAuth refresh failure, старого environment override, недоступной модели, состояния аккаунта или cooldown после более раннего сбоя. Если в логе видны AUTH_TOKEN_MISMATCH, PAIRING_REQUIRED или device-token ошибки, это не Anthropic API key: сначала исправьте gateway/client auth, затем повторите проверку Anthropic route.
Короткий ответ
Сначала соберите доказательства:
bashopenclaw status openclaw gateway status openclaw logs --follow openclaw doctor openclaw models status
Если models status показывает missing Anthropic auth, запустите onboarding или настройте Anthropic auth profile способом, который поддерживает ваша текущая версия OpenClaw. Если Anthropic возвращает authentication_error, проверьте в Anthropic Console, какой ключ был отправлен и имеет ли этот аккаунт доступ к выбранной модели. Если используется OAuth или CLI-backed auth, обновите или замените профиль. Если env | grep -i anthropic показывает старые значения, удалите override из того окружения, которое реально запускает gateway.
Сначала разделите тип ошибки
| Симптом | Владелец | Первое действие |
|---|---|---|
No API key found for provider 'anthropic' | OpenClaw не загрузил Anthropic provider auth | onboarding или новый auth profile |
authentication_error, invalid bearer token | Anthropic отклонил credential | проверить ключ, аккаунт и фактический route |
permission_error, 403 | credential принят, но ресурс запрещен | проверить model access, policy, account state |
OAuth token refresh failed | OAuth/CLI-backed auth | обновить профиль или перейти на direct API key |
all in cooldown | состояние OpenClaw после прошлых отказов | найти первую provider failure в логах |
AUTH_TOKEN_MISMATCH / PAIRING_REQUIRED | gateway/client auth | чинить token или pairing, не Anthropic key |
cooldown особенно часто вводит в заблуждение. Он означает, что OpenClaw временно не использует route после серии отказов. Это не доказывает, что текущий key уже неверен. Ищите строку лога, которая появилась до cooldown.
Проверьте effective credential, а не только файл
Надежная проверка начинается с вопроса: какой credential OpenClaw действительно отправляет в Anthropic? На практике credential может прийти из shell env, Docker .env, service environment, per-agent auth profile, старого config fragment или provider gateway route.
Не делайте вывод только по префиксу ключа. Формат может помочь найти очевидно неверный секрет, но не доказывает валидность. Доказательство появляется только тогда, когда Anthropic принимает credential для модели, которую вы выбрали.
Минимальная внешняя проверка должна использовать текущие Anthropic API docs и модель, доступную вашему аккаунту:
bashcurl -s https://api.anthropic.com/v1/messages \ -H "x-api-key: YOUR_KEY_HERE" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{"model":"YOUR_ACCESSIBLE_MODEL","max_tokens":10,"messages":[{"role":"user","content":"hi"}]}' \ | head -c 200
Если прямой provider call успешен, проблема чаще находится в OpenClaw route, auth profile, base URL, allowlist или env override. Если Anthropic возвращает authentication error, вернитесь в Anthropic Console и проверьте status ключа, account state и model access. Не публикуйте фиксированный billing threshold или tier rule без текущей проверки.
Для ручного config используйте только путь и schema, которые поддерживает текущая документация OpenClaw. Ниже форма намерения, а не гарантированная schema:
json{ "env": { "ANTHROPIC_API_KEY": "your-current-anthropic-key" }, "agents": { "defaults": { "model": { "primary": "anthropic/model-you-can-access" } } } }
После изменения проверьте route командой openclaw models status или эквивалентной provider-status командой вашей версии. Файл с ключом не равен рабочей модели.
OAuth и CLI-backed auth
OAuth или CLI-backed auth удобны только там, где текущая документация OpenClaw явно поддерживает этот route. Они добавляют browser flow, token refresh, host policy, account policy и storage path. Для production и headless-серверов direct API key или проверенный provider gateway обычно проще аудировать.
Если вы остаетесь на OAuth, уточните текущую refresh-команду и credential path. Старые примеры с paste-token, setup-token или plugin command могут быть версионными. Bootstrap/setup token должен использоваться для provisioning: создать или обновить настоящий auth profile, а затем исчезнуть из CI logs, compose files и долгоживущих environment variables.
Уберите environment override
Переменные окружения часто создают ситуацию, где вы редактируете один credential, а OpenClaw отправляет другой. Проверьте окружение того процесса, который реально запускает gateway:
bashenv | grep -i anthropic env | grep -i claude
Особенно важны:
ANTHROPIC_API_KEYANTHROPIC_AUTH_TOKENANTHROPIC_BASE_URLANTHROPIC_API_URL- Docker compose
.envилиenvironment - per-agent auth profile
Если переменная не должна быть активной, удалите ее из service environment, Docker, LaunchAgent, systemd или CI. unset в текущем терминале не меняет уже запущенный gateway.
Разберите cooldown
Cooldown защищает gateway от повторных отказов. Он может быть вызван 401, 403, 429, timeout, billing/account state, network failure или upstream outage. Поэтому recovery строится не вокруг перезапуска, а вокруг первой ошибки.
Порядок действий:
- Найдите в logs первую provider failure перед cooldown.
- Исправьте владельца: key, quota, billing/account state, base URL, model access или network.
- Подождите естественного восстановления cooldown или перезапустите gateway только после исправления root cause.
- Проверьте Anthropic route через
models statusи маленький запрос.
Перезапуск очищает локальное состояние, но не дает quota, не чинит revoked key и не открывает недоступную модель. Если причина осталась, cooldown вернется.
Выберите метод auth осознанно
Direct API key подходит для server, CI, team route и ситуаций, где нужен понятный billing owner. Ротация, отзыв и model access проверяются через Anthropic Console.
OAuth / CLI-backed auth используйте только если ваша версия OpenClaw поддерживает этот путь и вы принимаете refresh/browser/account-policy риски.
Setup/bootstrap token нужен для provisioning, а не для долгих inference-запросов. Он должен создать auth profile и исчезнуть из долгоживущих окружений.
Auth profiles помогают разделить agents, teams и billing owners, но новый agent может не наследовать credential автоматически. Настройте профиль явно.
Профилактика
- Добавьте
openclaw models statusв health check. - Запишите для каждого provider route billing owner, model access и source of secret.
- Оставьте один authoritative credential source.
- Перед обновлением OpenClaw читайте release notes по auth, provider profiles, cooldown и failover.
- Fallback routes используйте только после проверки endpoint, model ID, quota, price и tool support.
- Если добавляете laozhang.ai как provider gateway, рассматривайте его как отдельный route с собственной ценой, quota и model mapping, а не как замену Anthropic Console.
FAQ
Я поменял key, но ошибка осталась. Почему?
Скорее всего, OpenClaw использует другой credential source. Сравните logs, models status, service environment, Docker .env и per-agent auth profile.
Почему при правильном key вижу all in cooldown?
Cooldown пришел из прошлого отказа. Найдите первую failure в логах. Если root cause уже исправлен, подождите или перезапустите gateway, затем проверьте route.
Можно ли держать OAuth и API key одновременно?
Можно, если ваша версия поддерживает несколько auth profiles, но сложность растет. Для одного server route обычно лучше один способ auth и понятный owner.
Как узнать, какой auth сейчас используется?
Запустите openclaw models status, посмотрите provider auth profile/config path и gateway logs. Важен effective route, а не файл, который кажется главным.
Почему новый agent не видит credential?
Per-agent auth profile может не наследоваться. Запустите onboarding для нового agent или настройте его provider profile по текущей документации OpenClaw.
