Más allá de Python y TypeScript: Los otros SDK oficiales de Claude
La mayoría de los tutoriales de Claude asumen que estás escribiendo en Python o TypeScript.
//
Busca en todas las páginas de la documentación
La mayoría de los tutoriales de Claude asumen que estás escribiendo en Python o TypeScript.
La línea de SDK de Anthropic es más amplia que eso.
Además de Python y TypeScript, Anthropic mantiene SDK oficiales para Go, Java, C#, PHP y Ruby.
Cada uno te da el mismo acceso a Claude que los SDK de Python y TypeScript, solo que envuelto en las convenciones de su propio lenguaje.
Esta página es la rampa de acceso para ese conjunto más amplio: qué son realmente estos SDK, cómo se relacionan entre sí y cómo decidir cuál elegir.
tool_use). Capa de compatibilidad con OpenAI, un atajo separado cubierto en otra parte de esta sección.Cada SDK oficial de Claude, independientemente del lenguaje, es una biblioteca cliente sobre la misma API HTTP: la API de Mensajes.
Eso significa que la forma de la solicitud (un model, un array messages, system, max_tokens, tools opcionales, etc.) y la forma de la respuesta (un array content de bloques, un stop_reason, uso de tokens) son idénticas sin importar qué SDK envíe la solicitud.
Lo que difiere es cómo el SDK de cada lenguaje te permite construir esa solicitud y consumir esa respuesta.
Una analogía útil: piensa en la API de Mensajes como una única cocina de restaurante, y cada SDK como un estilo diferente de menú escrito para un comensal de un idioma diferente.
Los platos que salen de la cocina son los mismos; el menú que lees para pedirlos se ve nativo en tu idioma.
anthropic-sdk-go es el SDK oficial de Go.
Te proporciona structs tipados para solicitudes y respuestas, un iterador de streaming y soporte estructurado para tool_use, todo construido con las convenciones de Go: retornos de error explícitos, opciones funcionales para la configuración del cliente y sin excepciones.
Los SDK de Java y C# se basan en los modelos de objetos de sus plataformas: patrones de constructor y objetos de solicitud tipados en Java, clases de solicitud/respuesta fuertemente tipadas y async/await en C#.
Los SDK de PHP y Ruby también prefieren sus propios modismos: PHP típicamente expresa esquemas de herramientas y opciones como arrays asociativos, mientras que Ruby expresa la misma información como hashes y aprovecha las firmas de métodos flexibles de Ruby.
La autenticación es consistente en todos ellos: el constructor del cliente de cada SDK acepta una clave API, convencionalmente leída de una variable de entorno ANTHROPIC_API_KEY, y la adjunta a las solicitudes salientes de la misma manera que lo hacen los SDK de Python y TypeScript.
client := anthropic.NewClient(
option.WithAPIKey(os.Getenv("ANTHROPIC_API_KEY")),
)Esa única llamada es la forma del "hola mundo" en cada uno de estos SDK: construye un cliente a partir de una clave API, luego llama al endpoint de Mensajes a través de él.
Dado que los siete SDK oficiales se asientan sobre la misma API de Mensajes, una solicitud construida en Go y una solicitud construida en Ruby producen un JSON funcionalmente idéntico en la red.
Esto tiene una consecuencia práctica: la documentación, el diseño de prompts y las notas sobre el comportamiento del modelo escritas para el SDK de Python o TypeScript siguen siendo aplicables cuando trabajas en Go, Java, C#, PHP o Ruby.
Solo el código que construye la solicitud se ve diferente.
Donde los SDK divergen genuinamente es en tres áreas cubiertas por otros artículos en esta sección: la sintaxis de definición de tool_use, el consumo de streaming y los tipos de error/excepción.
Tool_use es la divergencia más marcada.
Go, Java y C# se basan en structs y esquemas tipados para describir la entrada de una herramienta; PHP y Ruby se basan en arrays asociativos y hashes, ya que ninguno de los lenguajes tiene tipado estático de primera clase para esto como Go, Java y C#.
El formato de red que recibe Claude, un input_schema como JSON Schema, es idéntico en ambos casos.
El streaming es la segunda divergencia.
Java y C# exponen el primitivo de streaming nativo de su plataforma: un iterador sobre el que se itera en Java, un enumerable asíncrono o un stream basado en callbacks en C#.
El SDK de Go expone un iterador de streaming en el mismo espíritu que el de Java.
El streaming de PHP y Ruby tiende a seguir un patrón de callback o generador dependiendo de la versión del SDK.
En todos los casos, lo que se está transmitiendo es la misma secuencia de eventos enviados por el servidor: message_start, content_block_delta, message_delta, message_stop, y así sucesivamente.
El manejo de errores es la tercera divergencia, y la más específica del lenguaje.
Go devuelve errores como valores, siguiendo la convención de Go.
Java y C# lanzan excepciones tipadas que se mapean a categorías de estado HTTP (autenticación, límite de tasa, sobrecarga, etc.).
PHP y Ruby lanzan excepciones o errores que siguen la propia jerarquía de clases de cada lenguaje.
Nada de esto cambia qué error ocurrió en el lado de Anthropic; solo cambia cómo tu código que llama lo nota y lo maneja.
Elegir un SDK es realmente elegir un objetivo de despliegue, no una preferencia personal de lenguaje.
Si tu equipo ejecuta un backend políglota, por ejemplo, una puerta de enlace API en Go, un service mesh en Java y un panel de administración en Ruby, es completamente normal usar tres SDK oficiales diferentes de Claude en ese stack, todos hablando con la misma API de Mensajes con los mismos nombres de modelos y los mismos prompts.
No hay un impuesto de compatibilidad entre SDK por hacer esto: nada en la API de Mensajes se preocupa de qué SDK envió la solicitud.
Existe un camino separado, más rápido pero más estrecho, para los equipos que ya tienen código del SDK de OpenAI: la capa de compatibilidad con OpenAI te permite apuntar ese código existente a Claude cambiando la URL base y el nombre del modelo, sin adoptar un SDK nativo de Anthropic en absoluto.
Ese camino sacrifica la completitud por la velocidad, ya que no todos los parámetros de OpenAI se mapean limpiamente a la API de Mensajes, y se cubre en profundidad en otra parte de esta sección.
| Enfoque | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| SDK Nativo Go/Java/C#/PHP/Ruby | Superficie completa de la API de Mensajes, tipado, manejo de errores idiomático | Una dependencia más por lenguaje en un stack políglota | Servicios de producción ya escritos en ese lenguaje |
| Capa de compatibilidad con OpenAI | Rápida adopción, cambio mínimo de código | Algunos parámetros no se mapean limpiamente; no es la superficie completa de la API de Mensajes | Migración rápida o pruebas lado a lado, no la ruta de producción a largo plazo |
| Llamadas HTTP manuales | Sin dependencia alguna | Reimplementas tú mismo el tipado, los reintentos y el análisis de streaming | Entornos donde no existe un SDK oficial para el lenguaje |
A medida que Anthropic lanza nuevas capacidades, como nuevas características de tool_use o nuevos tipos de bloques de contenido, espera que los SDK de Python y TypeScript las reciban primero, y que Go, Java, C#, PHP y Ruby les sigan.
Para la mayoría del código de aplicación, este retraso es invisible, ya que la superficie principal de la API de Mensajes (enviar mensajes, recibir contenido, usar herramientas, streaming) ha sido estable en los siete SDK durante mucho tiempo.
tool_use en sí mismo, lo que Claude envía y espera recibir, es idéntico en todas partes. Solo la sintaxis para definirlo y leerlo difiere según el lenguaje.anthropic-sdk-go)Los cinco son mantenidos directamente por Anthropic.
Sí. Cada SDK oficial, en cualquiera de los siete lenguajes, es un cliente para la misma API de Mensajes. La forma del JSON de solicitud y respuesta es idéntica independientemente de qué SDK la envíe.
No. Python, TypeScript, Go, Java, C#, PHP y Ruby son todos SDK de primera parte mantenidos por Anthropic. Ninguno es una bifurcación comunitaria o un wrapper no oficial.
El protocolo es el mismo en todas partes. La sintaxis difiere: Go, Java y C# usan structs tipados para los esquemas de herramientas, mientras que PHP y Ruby usan arrays asociativos y hashes respectivamente. Lo que Claude recibe en la red es idéntico en ambos casos.
Sí, los cinco soportan respuestas en streaming. Java y C# utilizan el iterador de streaming nativo de su plataforma o el mecanismo de callback asíncrono; Go expone un iterador de streaming similar. Los eventos del servidor subyacentes son los mismos en todos los SDK.
A veces. Las capacidades de API nuevas y de vanguardia tienden a aterrizar primero en Python y TypeScript, y los otros SDK les siguen. El núcleo estable (mensajes, herramientas, streaming) ha sido consistente en los siete durante mucho tiempo.
No, es algo diferente. Es un endpoint de compatibilidad que te permite apuntar el código existente del SDK de OpenAI (en cualquier lenguaje que soporte OpenAI) a Claude cambiando la URL base y el nombre del modelo, en lugar de adoptar un SDK nativo de Anthropic. Cubre una superficie de parámetros más estrecha que los SDK nativos.
Sí. Dado que cada SDK habla con la misma API de Mensajes, un servicio Go y un servicio Ruby pueden llamar a Claude, con los mismos nombres de modelo y diseño de prompts, sin problemas de compatibilidad entre ellos.
No. El constructor del cliente de cada SDK acepta una clave API, convencionalmente obtenida de una variable de entorno ANTHROPIC_API_KEY, y la adjunta a las solicitudes de la misma manera.
Comienza con la página de Fundamentos para una primera llamada en cada lenguaje, luego con la inmersión específica de Go si estás trabajando en Go, y la página de comparación de uso de herramientas si necesitas tool_use específicamente.
tool_usetool_use subyacente que todos estos SDK envuelvenVersiones del Stack: Escrito contra la línea de modelos de Claude actual a partir de ~junio de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (el predeterminado), y Claude Haiku 4.5 - y los SDK oficiales actuales para Go, Java, C#, PHP y Ruby. Los nombres de los modelos, las versiones de los SDK y los precios cambian rápidamente; verifica los detalles actuales en platform.claude.com/docs antes de confiar en ellos.
Revisado por Chris St. John·Última actualización: 15 jul 2026