Ошибка "invalid beta flag" в OpenClaw означает, что upstream Claude-compatible route отклонил Anthropic beta header. Текущий fix — не слепо добавлять "beta_features": []. По состоянию на 8 мая 2026 года OpenClaw подавляет implicit Anthropic beta headers на non-direct anthropic-messages endpoints, Bedrock имеет dedicated amazon-bedrock provider с AWS SDK credential chain, а 1M context beta отправляется только когда params.context1m: true явно задан для eligible Anthropic model.
Это меняет диагностику. Если вы всё ещё видите invalid beta flag, ищите explicit anthropic-beta header в custom provider, stale OpenClaw binary, proxy pretending to be native Anthropic, или direct Anthropic long-context request с credentials, которые не eligible для beta.
Краткое содержание
- Сначала определите route: direct Anthropic,
amazon-bedrock, Google Vertex или custommodels.providersproxy. - Не начинайте со старого
beta_featuressnippet. Текущая provider logic OpenClaw подавляет implicit beta headers для non-direct Anthropic-compatible endpoints. - Если route — Bedrock, используйте
amazon-bedrockprovider shape, AWS SDK credentials, правильный region и model discovery/access checks. Не вставляйте fake Anthropic API key в Bedrock. - Если route — direct Anthropic, проверьте, включён ли
params.context1m: true. OpenClaw mapping отправитcontext-1m-2025-08-07beta header, и credential должен быть eligible. - Если route — proxy, удалите explicit
models.providers.<id>.headers["anthropic-beta"], если proxy docs не требуют конкретный supported beta. - Если config и route выглядят верно, выполните
openclaw config validate,openclaw doctorиopenclaw gateway status, чтобы найти stale Gateway, damaged config или old binary drift.
Идентификация ошибки Invalid Beta Flag
Ошибка "invalid beta flag" проявляется по-разному, но полезные evidence всегда находятся в Gateway logs и resolved provider route. Не классифицируйте проблему только по пустому ответу в chat surface; используйте openclaw logs --follow, openclaw models status и active model ref.
При просмотре логов через openclaw logs --follow вы столкнетесь с одним из этих шаблонов ошибок. Пользователи AWS Bedrock обычно видят "ValidationException: invalid beta flag" в теле ответа. Пользователи Google Vertex AI сталкиваются с "400 Bad Request: invalid beta flag" с похожими симптомами. JSON-форматированный ответ об ошибке выглядит так:
json{ "type": "error", "error": { "type": "invalid_request_error", "message": "invalid beta flag" } }
Старые руководства описывали это почти исключительно как AWS Bedrock или Google Vertex issue. Сейчас это слишком широко. Современный OpenClaw setup может получить тот же visible error через stale custom proxy, explicit anthropic-beta override, direct Anthropic long-context beta с ineligible credentials или старый OpenClaw install без текущей provider safety behavior.
Чтобы отделить это от ordinary auth или gateway failure, выполните:
bashopenclaw logs --follow openclaw models status openclaw config validate openclaw gateway status openclaw doctor
Log line должен назвать upstream route или response body. Model status должен показать, использует ли OpenClaw direct provider, Bedrock/Vertex provider или custom proxy. Только после этого меняйте config.
Быстрое исправление (Начните здесь)
Самый быстрый безопасный fix — убрать beta header с маршрута, который не должен его получать, затем validate config и перезапустить Gateway или дождаться hot reload. Точное изменение зависит от provider surface.
Для custom Anthropic-compatible proxy проверьте models.providers и удалите hard-coded beta header, если proxy явно его не поддерживает:
json{ "models": { "providers": { "my-proxy": { "api": "anthropic-messages", "baseUrl": "https://proxy.example.com", "headers": { "anthropic-beta": "REMOVE_THIS_UNLESS_SUPPORTED" } } } } }
Для direct Anthropic 1M context отключите beta, если не уверены, что credential eligible:
json{ "agents": { "defaults": { "models": { "anthropic/claude-opus-4-6": { "params": { "context1m": false } } } } } }
Для Bedrock перейдите на dedicated provider shape вместо Anthropic-compatible header tweaks. Bedrock использует AWS credentials, region и permissions вроде model invoke/list access; Anthropic API key в model provider config не нужен.
После каждого изменения выполните:
bashopenclaw config validate openclaw gateway restart openclaw logs --follow
Понимание причины ошибки

Корень ошибки не в том, что OpenClaw всегда должен отключать все beta-функции. Ошибка появляется, когда provider route, через который идёт запрос, не совместим с Anthropic beta header или context параметром. Direct Anthropic, Bedrock, Vertex-style managed services, LiteLLM proxy и OpenAI-compatible gateway по-разному интерпретируют headers, model names, tool calling и context settings.
Текущий provider layer OpenClaw уже подавляет implicit beta headers на non-direct Anthropic-compatible endpoints. Поэтому старый совет «сначала поставьте beta_features в пустой массив» больше не является безопасным первым шагом. Он может скрыть реальную проблему: Bedrock настроен как direct Anthropic, OpenAI-compatible proxy используется как Anthropic-native API, или params.context1m: true включён для route, который этого не поддерживает.
Сначала ответьте на три вопроса:
- Что показывает
openclaw models status: direct Anthropic, Bedrock или custom proxy? - В логах отклоняется
anthropic-betaheader, context parameter или сам model ID? - Вы явно задавали
params.context1m: true, custombaseURLили proxy-layer header injection?
Пока эти вопросы не прояснены, исправление будет случайным.
Исправление по provider route

Direct Anthropic route: оставьте Anthropic-native provider, проверьте API key, model name и региональную доступность. Включайте params.context1m: true только если вам действительно нужен 1M context и выбранная модель это поддерживает. После изменения выполните:
bashopenclaw config validate openclaw models status openclaw logs --follow
AWS Bedrock route: не настраивайте Bedrock как обычный Anthropic baseURL. Используйте provider path amazon-bedrock, а аутентификацию отдайте AWS SDK credential chain. Для Bedrock важны region, model ID, IAM permissions и AWS profile, а не Anthropic API key.
yamlmodels: providers: bedrock: type: amazon-bedrock region: us-east-1
Custom proxy / OpenAI-compatible route: воспринимайте его как OpenAI-compatible endpoint, а не Anthropic-native endpoint. Проверьте, инжектит ли proxy anthropic-beta header, поддерживает ли tool calling и возвращает ли реальные upstream errors. Если proxy принимает OpenAI schema, не смешивайте с ним Anthropic-native parameters.
yamlmodels: providers: proxy: type: openai baseUrl: https://your-compatible-endpoint.example/v1
LiteLLM или общий командный proxy: если ошибка идёт из proxy layer, исправление должно быть там, а не только в локальном OpenClaw config. Зафиксируйте, какие headers proxy пересылает, как он переписывает model names и не смешивает ли Bedrock/Anthropic routes под одним alias. После изменения proxy повторите end-to-end request.
Рекомендации для корпоративного развертывания
Корпоративные команды часто выбирают Bedrock или Vertex-style route ради IAM, VPC endpoints, регионального контроля, audit logs и compliance boundary. Эти требования обычно важнее отдельного beta header. Поэтому правильный вопрос в enterprise-среде: какие возможности разрешены на текущем managed route, а какие должны оставаться только в direct Anthropic route.
Если политика требует, чтобы AI processing оставался в конкретном регионе или облаке, сохраняйте managed provider route и помечайте beta-only функции как недоступные или требующие исключения. Не переключайтесь на неизвестный proxy только ради обхода invalid beta flag: это меняет data processor, logging boundary и compliance responsibility.
Документируйте provider route, model ID, auth method, разрешённые context parameters и fallback provider. Тогда при обновлении OpenClaw, proxy или cloud provider команда будет сравнивать route contract, а не начинать с случайных snippets.
Предотвращение: route validation перед запуском
Предотвращение invalid beta flag — это не хранение старого config snippet, а проверка маршрута перед запуском:
- Запустите
openclaw config validate, чтобы проверить provider type, base URL, auth fields и model ID. - Запустите
openclaw models status, чтобы убедиться, что фактический route совпадает с ожидаемым. - Запустите
openclaw gateway status, чтобы убедиться, что daemon не держит старую конфигурацию. - Выполните маленький реальный запрос и проверьте
openclaw logs --followнаanthropic-beta, context или model ID errors. - Если есть proxy layer, сохраните proxy version, route alias и header rewrite rules.
Советы по устранению неполадок и FAQ
Вопрос: Я обновил OpenClaw, но ошибка осталась. Значит, исправление не работает?
Не обязательно. Проверьте, перезапущен ли gateway daemon, не перекрывает ли config старая переменная окружения и не инжектит ли proxy layer старый header. Часто после обновления продолжает работать старый daemon или общий proxy.
Вопрос: Можно ли использовать 1M context?
Да, но только на поддерживающем direct Anthropic route и eligible model. Не ставьте params.context1m: true на Bedrock или неизвестный proxy route в надежде, что upstream разберётся сам.
Вопрос: Почему у другого пользователя сработало простое удаление beta config?
Скорее всего, у него другая версия, другой proxy layer или direct Anthropic route. Симптом одинаковый, но root cause может отличаться. Route-first диагностика надёжнее старого универсального snippet.
Вопрос: Это баг OpenClaw?
Точнее это provider compatibility boundary. OpenClaw находится между несколькими model providers и proxy layers, поэтому должен решать, какие headers и parameters допустимы для конкретного route. Текущие версии снижают риск implicit beta headers, но custom proxies, explicit parameters и старые daemons всё ещё могут вызвать ту же ошибку.
Вопрос: Как подтвердить, что исправление готово к production?
Сохраните минимум три доказательства: openclaw config validate проходит, openclaw models status показывает правильный provider, реальный request log больше не содержит invalid beta flag. Для enterprise deployment сохраните также provider route decision и proxy-layer summary.
