HN Showcase
Back to browse
GitHub Repository

Production-ready LLM API translation layer for Python — bidirectional conversion between OpenAI, Anthropic & Google formats via hub-and-spoke IR. Optional API gateway. Streaming & non-streaming. Zero core deps. Contributions welcome!

39 starsPython

Translate LLM API Calls Across OpenAI, Anthropic, and Gemini

by Oaklight·Apr 20, 2026·2 points·0 comments
Visit ProjectView on HN

AI Analysis

●●SolidBig BrainNiche Gem

Hub-and-spoke IR translates LLM APIs without N^2 adapter hell.

Strengths
  • •Hub-and-spoke intermediate representation avoids writing N^2 provider adapters manually.
  • •Bidirectional conversion supports streaming, tool calls, and multimodal inputs accurately.
  • •Zero core dependencies keeps the package lightweight and easy to vendor.
Weaknesses
  • •LiteLLM already dominates the unified client space with more provider support.
  • •Translation layer adds latency compared to using native SDKs directly.
Category
AI/ML
Target Audience

Backend engineers building multi-provider LLM applications

Similar To

LiteLLM · LangChain · Portkey

Post Description

I built this after getting tired of maintaining one-off adapters between OpenAI, Anthropic, and Gemini APIs in the same project.

The idea is to translate through a shared intermediate representation instead of writing every provider pair separately. So instead of OpenAI->Anthropic, OpenAI->Gemini, Anthropic->Gemini, etc., each provider just maps to/from the IR.

This is not a unified client like LiteLLM. It's a translator/proxy: give it an OpenAI-style request and it can produce the Anthropic/Gemini equivalent, including streaming, tool calls, and multimodal inputs.

It's open source, and there's also a gateway mode if you want to run it as a proxy in front of multiple providers.

Would especially love feedback on where translation breaks down or gets too lossy across providers.

Docs: https://llm-rosetta.readthedocs.io Paper/design notes: https://arxiv.org/abs/2604.09360

Similar Projects