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.
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.
Resumen
- Idea Central: Go, Java, C#, PHP y Ruby tienen cada uno un SDK oficial mantenido por Anthropic que envuelve la misma API de Mensajes utilizada por los SDK de Python y TypeScript.
- Por qué Importa: La mayoría de los backends de producción no están escritos en Python o TypeScript. Un monolito Java, un microservicio Go, una aplicación Rails o un stack web PHP pueden llamar a Claude de forma nativa en lugar de recurrir a un sidecar de Python o a llamadas HTTP manuales.
- Conceptos Clave: API de Mensajes, el único protocolo de red al que apuntan todos los SDK. Cliente tipado, el wrapper específico del lenguaje alrededor de ese protocolo. Convenciones idiomáticas, la forma específica del lenguaje de las solicitudes, el streaming y el uso de herramientas (
tool_use). Capa de compatibilidad con OpenAI, un atajo separado cubierto en otra parte de esta sección. - Cuándo Usar: Elige uno de estos SDK cuando tu servicio ya esté escrito en Go, Java, C#, PHP o Ruby y desees un acceso tipado y mantenido a Claude sin un salto entre lenguajes.
- Limitaciones / Compensaciones: Estos SDK generalmente reciben las nuevas superficies de API un poco por detrás de Python y TypeScript, y los ejemplos de la comunidad son más escasos, así que espera leer el código fuente o la referencia de la API con más frecuencia.
- Temas Relacionados: Fundamentos de la API de Mensajes, uso de herramientas y llamadas a funciones, respuestas en streaming, la capa de compatibilidad con OpenAI.
Fundamentos
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.
Mecánicas e Interacciones
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.
Consideraciones Avanzadas y Aplicaciones
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.
Conceptos Erróneos Comunes
- "Los SDK de Go/Java/C#/PHP/Ruby son wrappers no oficiales de la comunidad." No lo son. Anthropic mantiene los siete SDK directamente, de la misma manera que mantiene los de Python y TypeScript.
- "Cambiar de SDK cambia lo que el modelo puede hacer." No lo hace. El modelo, sus capacidades y su comportamiento están determinados por la API de Mensajes y el modelo que seleccionas, no por qué SDK envió la solicitud.
- "Necesitas la capa de compatibilidad con OpenAI para usar Claude desde Go, Java, C#, PHP o Ruby." No es necesario. Cada uno de esos lenguajes tiene su propio SDK nativo y tipado de Anthropic; la capa de compatibilidad es un atajo separado y más estrecho para los equipos que migran código existente del SDK de OpenAI.
- "Tool_use funciona de manera diferente según el SDK." El protocolo
tool_useen 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. - "Estos SDK están atrasados en características de una manera que importe para las aplicaciones típicas." Para la superficie principal, enviar mensajes, usar herramientas, streaming, los siete SDK están funcionalmente completos. El retraso afecta principalmente a las capacidades más nuevas y de vanguardia.
Preguntas Frecuentes
¿Qué lenguajes tienen un SDK oficial de Claude además de Python y TypeScript?
- Go (
anthropic-sdk-go) - Java
- C#
- PHP
- Ruby
Los cinco son mantenidos directamente por Anthropic.
¿Todos estos SDK se comunican con la misma API?
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.
¿Es alguno de estos SDK "más oficial" que los otros?
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.
¿Cómo decido qué SDK usar?
- Haz coincidir el SDK con el lenguaje en el que ya se ejecuta tu servicio, no con tu preferencia personal.
- Si eres políglota, es normal usar un SDK diferente por servicio.
- Si ya tienes código del SDK de OpenAI y solo necesitas una migración o prueba rápida, considera la capa de compatibilidad con OpenAI en lugar de adoptar inmediatamente un nuevo SDK nativo.
¿Funciona tool_use de la misma manera en los cinco SDK?
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.
¿Soportan Go, Java, C#, PHP y Ruby el streaming?
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.
¿Estos SDK se retrasan en la obtención de nuevas características en comparación con Python y TypeScript?
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.
¿Qué es la capa de compatibilidad con OpenAI y es uno de estos SDK?
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.
¿Puedo mezclar SDK entre servicios de la misma empresa o producto?
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.
¿Difieren las convenciones de autenticación entre los SDK?
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.
¿A dónde debo ir ahora para escribir código en uno de estos lenguajes?
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.
Relacionados
- Fundamentos de Otros SDK Oficiales - envía una primera llamada a la API de Mensajes en cada uno de los cinco lenguajes
- Llamando a Claude desde Go con el SDK Oficial - un recorrido más profundo y específico de Go sobre solicitudes tipadas, streaming y
tool_use - Uso Idiomático de Herramientas en Go, Java, C#, PHP y Ruby - compara la sintaxis de definición de herramientas en los cinco SDK
- Migrando una Base de Código del SDK de OpenAI a Claude - el atajo de la capa de compatibilidad con OpenAI, y cuándo pasar a un SDK nativo
- Fundamentos del Uso de Herramientas - el protocolo
tool_usesubyacente que todos estos SDK envuelven
Versiones 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.