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.

The Three-SDK Problem

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.

"Just Use LangChain"

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.

aichain: Change One Line, Leave Everything Else

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 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:

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:

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.

What This Actually Means for Your Workflow

Benchmarking

A new model drops. You add one Model() line to your comparison loop and rerun. No integration work.

Cost Optimization

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.

Resilience

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.

The Right Tool for the Job

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.