Os cabeçalhos beta permitem que você acesse recursos experimentais e novas capacidades de modelo antes que se tornem parte da API padrão. Esses recursos estão sujeitos a alterações e podem ser modificados ou removidos em versões futuras.
Os cabeçalhos beta são frequentemente usados em conjunto com o namespace beta nos SDKs do cliente

​
Como usar cabeçalhos beta

Para acessar recursos beta, inclua o cabeçalho anthropic-beta em suas solicitações de API: 
POST /v1/messages
Content-Type: application/json
X-API-Key: YOUR_API_KEY
anthropic-beta: BETA_FEATURE_NAME
Ao usar o SDK, você pode especificar cabeçalhos beta nas opções de solicitação: 
from anthropic import Anthropic

client = Anthropic()

response = client.beta.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "Hello, Claude"}
    ],
    betas=["beta-feature-name"]
)
Os recursos beta são experimentais e podem:
  • Ter alterações disruptivas sem aviso
  • Ser descontinuados ou removidos
  • Ter limites de taxa ou preços diferentes
  • Não estar disponíveis em todas as regiões

​
Múltiplos recursos beta

Para usar múltiplos recursos beta em uma única solicitação, inclua todos os nomes de recursos no cabeçalho separados por vírgulas: 
anthropic-beta: feature1,feature2,feature3

​
Convenções de nomenclatura de versão

Os nomes de recursos beta normalmente seguem o padrão: feature-name-YYYY-MM-DD, onde a data indica quando a versão beta foi lançada. Sempre use o nome exato do recurso beta conforme documentado.

​
Tratamento de erros

Se você usar um cabeçalho beta inválido ou indisponível, receberá uma resposta de erro: 
{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "Unsupported beta header: invalid-beta-name"
  }
}

​
Obtendo ajuda

Para perguntas sobre recursos beta:
  1. Verifique a documentação para o recurso específico
  2. Revise o changelog da API para atualizações
  3. Entre em contato com o suporte para assistência com uso em produção
Lembre-se de que os recursos beta são fornecidos “como estão” e podem não ter as mesmas garantias de SLA que os recursos estáveis da API.