AIChain!? Why Another LLM Library?

A developer created aichain, a lightweight Python library that provides a unified interface for eight large language model providers including OpenAI, Anthropic, and Google Gemini. The library aims to eliminate the code duplication and switching costs that arise when supporting multiple AI providers, each with their own SDK, message formats, and authentication patterns. Unlike LangChain, which pulls in over 40 transitive dependencies and complex abstraction layers, aichain offers a thin normalization layer with minimal overhead for sending prompts to multiple models and comparing results.

You wrote an OpenAI integration. Then added Anthropic. Then Gemini. Now look at your code — it's three different applications wearing a trench coat pretending to be one. Every major AI provider ships its own SDK. Reasonable enough — until you need to support more than one. Here's what happens in practice. OpenAI wants messages with content strings. Anthropic wants a separate system parameter and its own message format. Google's Gemini SDK uses generate content with Part objects. Three providers, three client initializations, three response shapes, three error handling paths. You end up with code that looks like this pseudocode, but you've seen the real thing : if provider == "openai": client = OpenAI api key=... response = client.chat.completions.create model=..., messages=... text = response.choices 0 .message.content elif provider == "anthropic": client = Anthropic api key=... response = client.messages.create model=..., max tokens=..., messages=... text = response.content 0 .text elif provider == "google": yet another pattern entirely ... This isn't a hypothetical. This is Tuesday. And here's the thing people miss: this divergence is intentional . Every provider consciously locks you into their ecosystem. That's business, not coincidence. Different parameter names, different response shapes, different auth patterns — all of it raises the switching cost just enough to keep you where you are. Models move fast, too. Whoever was ahead six months ago may not be the leader today. Claude overtook GPT-4 on coding benchmarks like SWE-bench, then Gemini 1.5 landed a million-token context window, and suddenly you need to evaluate all three for your use case. But switching means rewriting integration logic from scratch. Every time. The obvious answer. LangChain abstracts providers behind a common interface. Problem solved, right? Not quite. Install langchain and watch your dependency tree explode. Running pip install langchain pulls in over 40 transitive packages — langchain-core , langchain-community , langchain-openai , and a constellation of sub-packages. The abstraction layers stack up: Runnables, Chains, OutputParsers, PromptTemplates, each with its own configuration surface. For a complex agentic system, that overhead might pay for itself. But if you just want to send the same prompt to three models and compare results? You're hauling a shipping container to carry a sandwich. I tried this path. The project turned into an immovable monster — not because of my code, but because of everything underneath it. Upgrading one sub-package broke three others. Debugging meant reading through abstraction layers I didn't ask for. The library demanded more attention than the actual task. The best abstraction is the one you don't notice. If you're thinking about the library instead of the problem, something went wrong. That failure mode is the specific thing aichain is designed to avoid. Where LangChain builds up, aichain strips down: a thin normalization layer with no abstraction tower to debug and no sprawling dependency graph to maintain. That's why aichain https://github.com/yait-ai/aichain exists. The pitch is simple: 8 providers, 1 interface, zero lock-in. Installation note:The package name and the import name differ. Install with pip install aichain , but import from yait aichain in your code — as shown in all examples below. Here's a complete working example — a single prompt sent to one model: python import os from yait aichain import Model, Skill skill = Skill model=Model "claude-sonnet-4-6", api key=os.getenv "ANTHROPIC API KEY" , input={ "messages": { "role": "user", "parts": "What is {topic} in one sentence?" , } }, Pass the template variable at runtime result = skill.run variables={"topic": "machine learning"} print result Model takes a model name string and figures out the provider automatically. Skill takes a model and a prompt. .run gives you back a string. No output parsers, no runnable sequences, no callback handlers. Now here's where it gets interesting. Want to compare three providers? Same prompt, same logic, one-line swap: python import os from yait aichain import Model, Skill No template variables here — the prompt is fully hardcoded, so .run takes no arguments. PROMPT = { "messages": { "role": "user", "parts": "What is machine learning in one sentence?" , } } models = Model "claude-sonnet-4-6", api key=os.getenv "ANTHROPIC API KEY" , Model "gpt-4o-mini", api key=os.getenv "OPENAI API KEY" , Model "gemini-2.5-flash", api key=os.getenv "GOOGLE AI API KEY" , for model in models: skill = Skill model=model, input=PROMPT result = skill.run print f" {model.name} \n{result}\n" model.name returns the string passed to Model Three providers. One prompt definition. Zero conditional logic. The Model "claude-sonnet-4-6" line is the only thing that determines which provider gets called. Swap "claude-sonnet-4-6" for "gpt-4o-mini" or "gemini-2.5-flash" or "grok-3" — the rest of your code doesn't change. Not one line. A new model drops. You add one Model line to your comparison loop and rerun. No integration work. Your Claude bill is climbing. Switch your non-critical paths to gemini-2.5-flash by changing a string. Test it. If quality holds, ship it. Your primary provider goes down. A fallback is one model-name swap away — because your prompt logic, your variable handling, your output processing are already provider-agnostic. The template variable system {topic} , {text} , etc. means your prompts are reusable across models without reformatting. Define once, run everywhere. Model and Skill will carry you surprisingly far. When your requirements grow, the library grows with you — Chain for multi-step pipelines, Pool for parallel execution, Agent for autonomous workflows. Embedding , VectorDB , and Reranker are there when you need them on the data side. You reach for these when the problem demands them, not because the library herds you through them just to send a single prompt. aichain doesn't have retrieval pipelines or agent frameworks baked into core because most tasks don't need them. It exists because I got tired of rewriting the same integration logic three times with different parameter names. If that sounds familiar, the GitHub repo https://github.com/yaitio/aichain has runnable examples that take about a minute to get working.