Além de Python e TypeScript: Os Outros SDKs Oficiais do Claude
A maioria dos tutoriais do Claude assume que você está escrevendo em Python ou TypeScript.
//
Busque em todas as páginas da documentação
A maioria dos tutoriais do Claude assume que você está escrevendo em Python ou TypeScript.
A linha de SDKs da Anthropic é mais ampla do que isso.
Além de Python e TypeScript, a Anthropic mantém SDKs oficiais para Go, Java, C#, PHP e Ruby.
Cada um deles oferece o mesmo acesso ao Claude que os SDKs de Python e TypeScript, apenas encapsulado nas convenções de sua própria linguagem.
Esta página é a porta de entrada para esse conjunto mais amplo: o que esses SDKs realmente são, como eles se relacionam entre si e como decidir qual deles usar.
tool_use. Camada de compatibilidade OpenAI, um atalho separado abordado em outra parte desta seção.Todo SDK oficial do Claude, independentemente da linguagem, é uma biblioteca cliente sobre a mesma API HTTP: a API de Mensagens.
Isso significa que a estrutura da requisição (um model, um array messages, system, max_tokens, tools opcionais, etc.) e a estrutura da resposta (um array content de blocos, um stop_reason, uso de tokens) são idênticas, não importa qual SDK envie a requisição.
O que difere é como o SDK de cada linguagem permite que você construa essa requisição e consuma essa resposta.
Uma analogia útil: pense na API de Mensagens como uma única cozinha de restaurante, e cada SDK como um estilo diferente de cardápio escrito para um cliente de idioma diferente.
Os pratos que saem da cozinha são os mesmos; o cardápio que você lê para pedi-los parece nativo para o seu idioma.
anthropic-sdk-go é o SDK oficial para Go.
Ele fornece structs tipadas para requisição e resposta, um iterador de streaming e suporte estruturado para tool_use, tudo construído com as convenções do Go: retornos de erro explícitos, opções funcionais para configuração do cliente e nenhuma exceção.
Os SDKs Java e C# baseiam-se nos modelos de objeto de suas plataformas: padrões de builder e objetos de requisição tipados em Java, classes de requisição/resposta fortemente tipadas e async/await em C#.
Os SDKs PHP e Ruby também favorecem seus próprios idiomas: PHP geralmente expressa esquemas de ferramentas e opções como arrays associativos, enquanto Ruby expressa as mesmas informações como hashes e aproveita as assinaturas flexíveis de métodos do Ruby.
A autenticação é consistente em todos eles: o construtor do cliente de cada SDK aceita uma chave de API, convencionalmente lida a partir de uma variável de ambiente ANTHROPIC_API_KEY, e a anexa às requisições de saída da mesma forma que os SDKs de Python e TypeScript.
client := anthropic.NewClient(
option.WithAPIKey(os.Getenv("ANTHROPIC_API_KEY")),
)Essa única chamada é a forma do "olá, mundo" em cada um desses SDKs: construir um cliente a partir de uma chave de API, em seguida, chamar o endpoint de Mensagens através dele.
Como todos os sete SDKs oficiais se baseiam na mesma API de Mensagens, uma requisição construída em Go e uma requisição construída em Ruby produzem JSON funcionalmente idêntico na rede.
Isso tem uma consequência prática: a documentação, o design de prompts e as notas sobre o comportamento do modelo escritas para o SDK de Python ou TypeScript ainda se aplicam quando você está trabalhando em Go, Java, C#, PHP ou Ruby.
Apenas o código que constrói a requisição parece diferente.
Onde os SDKs realmente divergem é em três áreas cobertas por outros artigos nesta seção: sintaxe de definição de tool_use, consumo de streaming e tipos de erro/exceção.
O tool_use é a divergência mais acentuada.
Go, Java e C# utilizam structs e esquemas tipados para descrever o input_schema de uma ferramenta; PHP e Ruby utilizam arrays associativos e hashes, já que nenhuma dessas linguagens possui tipagem estática de primeira classe para isso como Go, Java e C#.
O formato de rede que o Claude recebe, um input_schema como JSON Schema, é idêntico de qualquer forma.
O streaming é a segunda divergência.
Java e C# expõem o primitivo de streaming nativo de suas plataformas: um iterador sobre o qual você itera em Java, um async enumerable ou um stream orientado a callbacks em C#.
O SDK do Go expõe um iterador de streaming no mesmo espírito do Java.
O streaming em PHP e Ruby tende a seguir um padrão de callback ou gerador, dependendo da versão do SDK.
Em todos os casos, o que está sendo transmitido é a mesma sequência de eventos enviados pelo servidor: message_start, content_block_delta, message_delta, message_stop, e assim por diante.
O tratamento de erros é a terceira divergência, e a mais específica da linguagem.
Go retorna erros como valores, seguindo a convenção do Go.
Java e C# lançam exceções tipadas que mapeiam para categorias de status HTTP (autenticação, limite de taxa, sobrecarga, etc.).
PHP e Ruby levantam exceções ou erros que seguem a própria hierarquia de classes de cada linguagem.
Nada disso muda o que ocorreu como erro no lado da Anthropic; apenas muda como seu código chamador o percebe e o trata.
Escolher um SDK é realmente escolher um alvo de implantação, não uma preferência pessoal de linguagem.
Se sua equipe executa um backend poliglota, por exemplo, um gateway de API em Go, um service mesh em Java e um painel de administração em Ruby, é totalmente normal usar três SDKs oficiais diferentes do Claude em toda essa stack, todos se comunicando com a mesma API de Mensagens com os mesmos nomes de modelo e os mesmos prompts.
Não há um custo de compatibilidade entre SDKs para fazer isso: nada na API de Mensagens se importa com qual SDK enviou a requisição.
Um caminho separado, mais rápido, porém mais restrito, existe para equipes que já possuem código de SDK OpenAI: a camada de compatibilidade OpenAI permite que você aponte esse código existente para o Claude trocando a URL base e o nome do modelo, sem adotar um SDK nativo da Anthropic.
Esse caminho troca completude por velocidade, já que nem todos os parâmetros OpenAI se mapeiam perfeitamente para a API de Mensagens, e é coberto em profundidade em outra parte desta seção.
| Abordagem | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
| SDK Nativo Go/Java/C#/PHP/Ruby | Superfície completa da API de Mensagens, tipado, tratamento de erros idiomático | Mais uma dependência por linguagem em uma stack poliglota | Serviços de produção já escritos nessa linguagem |
| Camada de compatibilidade OpenAI | Rápido de adotar, mudança mínima de código | Alguns parâmetros não se mapeiam perfeitamente; não é a superfície completa da API de Mensagens | Migração rápida ou testes lado a lado, não o caminho de produção a longo prazo |
| Chamadas HTTP manuais | Nenhuma dependência | Você reimplementa a tipagem, retentativas e análise de streaming por conta própria | Ambientes onde nenhum SDK oficial existe para a linguagem |
À medida que a Anthropic lança novas funcionalidades, como novos recursos de tool_use ou novos tipos de blocos de conteúdo, espere que os SDKs de Python e TypeScript as recebam primeiro, com Go, Java, C#, PHP e Ruby seguindo.
Para a maioria do código de aplicação, esse atraso é invisível, pois a superfície principal da API de Mensagens (enviar mensagens, receber conteúdo, usar ferramentas, streaming) tem sido estável em todos os sete SDKs por muito tempo.
tool_use funciona de maneira diferente dependendo do SDK." O protocolo tool_use em si, o que o Claude envia e espera de volta, é idêntico em todos os lugares. Apenas a sintaxe para defini-lo e lê-lo difere por linguagem.anthropic-sdk-go)Todos os cinco são mantidos diretamente pela Anthropic.
Sim. Todo SDK oficial, em qualquer uma das sete linguagens, é um cliente para a mesma API de Mensagens. A forma do JSON de requisição e resposta é idêntica, independentemente de qual SDK a enviou.
Não. Python, TypeScript, Go, Java, C#, PHP e Ruby são todos SDKs de primeira parte, mantidos pela Anthropic. Nenhum é um fork da comunidade ou um wrapper não oficial.
O protocolo é o mesmo em todos os lugares. A sintaxe difere: Go, Java e C# usam structs tipadas para esquemas de ferramentas, enquanto PHP e Ruby usam arrays associativos e hashes, respectivamente. O que o Claude recebe na rede é idêntico de qualquer forma.
Sim, todos os cinco suportam respostas em streaming. Java e C# usam o iterador de streaming nativo de sua plataforma ou o mecanismo de callback assíncrono; Go expõe um iterador de streaming semelhante. Os eventos subjacentes enviados pelo servidor são os mesmos em todos os SDKs.
Às vezes. Novas capacidades de API de ponta tendem a chegar primeiro em Python e TypeScript, com os outros SDKs seguindo. O núcleo estável (mensagens, ferramentas, streaming) tem sido consistente em todos os sete há muito tempo.
Não, é algo diferente. É um endpoint de compatibilidade que permite apontar código existente de SDK OpenAI (em qualquer linguagem suportada pela OpenAI) para o Claude, alterando a URL base e o nome do modelo, em vez de adotar um SDK nativo da Anthropic. Ela cobre uma superfície de parâmetros mais restrita do que os SDKs nativos.
Sim. Como cada SDK se comunica com a mesma API de Mensagens, um serviço Go e um serviço Ruby podem ambos chamar o Claude, com os mesmos nomes de modelo e design de prompt, sem quaisquer preocupações de compatibilidade entre eles.
Não. O construtor do cliente de cada SDK aceita uma chave de API, convencionalmente obtida de uma variável de ambiente ANTHROPIC_API_KEY, e a anexa às requisições da mesma forma.
Comece com a página de Fundamentos para uma primeira chamada em cada linguagem, depois com o aprofundamento específico para Go se você estiver trabalhando em Go, e a página de comparação de uso de ferramentas se você precisar especificamente de tool_use.
tool_usetool_use que todos esses SDKs encapsulamVersões da Stack: Escrito contra a linha de modelos do Claude atual em ~junho de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (o padrão) e Claude Haiku 4.5 - e os SDKs oficiais atuais para Go, Java, C#, PHP e Ruby. Nomes de modelos, versões de SDK e preços mudam rapidamente - verifique os detalhes atuais em platform.claude.com/docs antes de confiar neles.
Revisado por Chris St. John·Última atualização: 15 de jul. de 2026