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":
...
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 exists. The pitch is simple: 8 providers, 1 interface, zero lock-in.
Installation note:The package name and the import name differ. Install withpip install aichain
, but import fromyait_aichain
in your code ā as shown in all examples below.
Here's a complete working example ā a single prompt sent to one model:
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?"],
}]
},
)
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:
import os
from yait_aichain import Model, Skill
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 has runnable examples that take about a minute to get working.