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.
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.
Resumo
- Ideia Central: Go, Java, C#, PHP e Ruby possuem cada um um SDK oficial, mantido pela Anthropic, que encapsula a mesma API de Mensagens usada pelos SDKs de Python e TypeScript.
- Por que Importa: A maioria dos backends de produção não é escrita em Python ou TypeScript. Um monólito Java, um microsserviço Go, um aplicativo Rails ou uma stack web PHP podem chamar o Claude nativamente em vez de depender de um sidecar Python ou de chamadas HTTP manuais.
- Conceitos Chave: API de Mensagens, o único protocolo de comunicação que todos os SDKs visam. Cliente tipado, o wrapper específico da linguagem em torno desse protocolo. Convenções idiomáticas, a forma específica da linguagem para requisições, streaming e
tool_use. Camada de compatibilidade OpenAI, um atalho separado abordado em outra parte desta seção. - Quando Usar: Utilize um desses SDKs quando seu serviço já estiver escrito em Go, Java, C#, PHP ou Ruby e você desejar acesso tipado e mantido ao Claude sem um salto entre linguagens.
- Limitações / Compromissos: Esses SDKs geralmente recebem novas superfícies de API um pouco atrás de Python e TypeScript, e exemplos da comunidade são mais escassos, então espere ler o código-fonte ou a referência da API com mais frequência.
- Tópicos Relacionados: Fundamentos da API de Mensagens, uso de ferramentas e chamadas de função, respostas em streaming, a camada de compatibilidade OpenAI.
Fundamentos
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.
Mecânicas e Interações
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.
Considerações Avançadas e Aplicações
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.
Concepções Errôneas Comuns
- "Os SDKs Go/Java/C#/PHP/Ruby são wrappers não oficiais da comunidade." Eles não são. A Anthropic mantém todos os sete SDKs diretamente, da mesma forma que mantém os de Python e TypeScript.
- "Mudar de SDK altera o que o modelo pode fazer." Não altera. O modelo, suas capacidades e seu comportamento são determinados pela API de Mensagens e pelo modelo que você seleciona, não por qual SDK enviou a requisição.
- "Você precisa da camada de compatibilidade OpenAI para usar o Claude de Go, Java, C#, PHP ou Ruby." Você não precisa. Cada uma dessas linguagens tem seu próprio SDK nativo e tipado da Anthropic; a camada de compatibilidade é um atalho separado e mais restrito para equipes que migram código existente de SDK OpenAI.
- "O
tool_usefunciona de maneira diferente dependendo do SDK." O protocolotool_useem 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. - "Esses SDKs estão atrasados em recursos de uma forma que importa para aplicativos típicos." Para a superfície principal, enviar mensagens, usar ferramentas, streaming, todos os sete SDKs estão funcionalmente completos. O atraso afeta principalmente as capacidades mais novas e de ponta.
FAQs
Quais linguagens têm um SDK oficial do Claude além de Python e TypeScript?
- Go (
anthropic-sdk-go) - Java
- C#
- PHP
- Ruby
Todos os cinco são mantidos diretamente pela Anthropic.
Todos esses SDKs se comunicam com a mesma API?
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.
Algum desses SDKs é "mais oficial" que os outros?
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.
Como decido qual SDK usar?
- Combine o SDK com a linguagem em que seu serviço já está escrito, não com a preferência pessoal.
- Se você usa várias linguagens, é normal usar um SDK diferente por serviço.
- Se você já tem código de SDK OpenAI e só precisa de uma migração ou teste rápido, considere a camada de compatibilidade OpenAI em vez de adotar um novo SDK nativo imediatamente.
O `tool_use` funciona da mesma forma em todos os cinco SDKs?
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.
Go, Java, C#, PHP e Ruby suportam streaming?
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.
Esses SDKs demoram mais para receber novos recursos do que Python e TypeScript?
À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.
O que é a camada de compatibilidade OpenAI e ela é um desses SDKs?
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.
Posso misturar SDKs entre serviços da mesma empresa ou produto?
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.
As convenções de autenticação diferem entre os SDKs?
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.
Para onde devo ir a seguir para realmente escrever código em uma dessas linguagens?
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.
Relacionados
- Fundamentos de Outros SDKs Oficiais - envie uma primeira chamada da API de Mensagens em cada uma das cinco linguagens
- Chamando o Claude de Go com o SDK Oficial - um guia mais aprofundado e específico para Go de requisições tipadas, streaming e
tool_use - Uso Idiomático de Ferramentas em Go, Java, C#, PHP e Ruby - compare a sintaxe de definição de ferramentas em todos os cinco SDKs
- Migrando uma Base de Código de SDK OpenAI para o Claude - o atalho da camada de compatibilidade OpenAI e quando passar para um SDK nativo
- Fundamentos de Uso de Ferramentas - o protocolo subjacente de
tool_useque todos esses SDKs encapsulam
Versõ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.