Open-weight models quietly got good this year — good enough that for most real engineering work I genuinely can't tell them apart from the flagships. And they're a fraction of the price. On paper, everyone should already be using them.
In practice, they don't, and it's not because the models are bad. It's because actually using cheap inference is a hassle. Between finding a provider, wiring up a gateway, managing keys, and figuring out billing, there's enough friction that most people just keep paying OpenAI out of inertia. I know, because I spent a while on the annoying side of it.
The models are cheap. The plumbing is the problem.
Here's the thing I kept running into: getting low-cost inference for open models is very doable, but the path from "cheap compute exists" to "I can just make an API call and pay for it like a normal person" is full of small headaches. Provider accounts. Wallets. Prepaid ledgers. No clean way to just put in a card and get an API key that works with the tools you already use.
None of that is hard, exactly. It's just enough papercuts that it isn't worth it for most developers — so the cheap models sit there unused while people overpay for the convenient ones.
That gap is the whole reason I built something.
So I built the easy part and hid the hard part
I took the annoying plumbing — the inference sourcing, the gateway, the metering, the key management — and put a boring, familiar surface on top of it:
It's OpenAI-compatible, so you change a base URL and keep your code.
You pay with a card or USDT, top up a prepaid balance, and that's it. No wallet, no subscription, no crypto rabbit hole unless you want one.
Every key has a hard budget cap, so a runaway loop stops instead of surprising you.
I called it Khidi — ხიდი, "bridge" in Georgian. The name is the whole idea: a bridge from the tools you already use to models that cost a tenth as much. Full disclosure up front: I run it (khidi.ai), so read this as a founder explaining what he built, not a neutral review. The pitch is simple — the cheap models were always available; I just made them as easy to use and pay for as the expensive ones.
What it costs
A typical coding-agent month is roughly 50M input + 10M output tokens. Same requests, different providers:
Provider (model)Price /1M (in · out)Monthly billOpenAI (GPT-5.5)$5.00 · $30.00$550.00Anthropic (Claude Opus 4.8)$5.00 · $25.00$500.00Moonshot (Kimi K2.6, direct)$0.95 · $4.00$87.50Kimi K2.6, at ~half vendor price$0.50 · $2.00$45.00
And this isn't cheap-because-worse. On contamination-resistant benchmarks — resolving real GitHub issues, using tools — the open flagships hold their own: Kimi K2.6 scores 58.6 on SWE-Bench Pro (ahead of GPT-5.4's 57.7 and Claude Opus 4.6's 53.4), and 92.5 on DeepSearchQA (ahead of GPT-5.4's 78.6). Vendor-reported for the exact versions, spring 2026.
How you use it
Keep the OpenAI SDK. Change one line:
pythonfrom openai import OpenAI
client = OpenAI(
base_url="[https://api.khidi.ai/v1](https://api.khidi.ai/v1)",
api_key="sk-...",
)
client.chat.completions.create(
model="kimi-k2.6",
messages=[{"role": "user", "content": "hello"}],
)
Streaming, tool calling, long context all work, because the interface is identical. Cursor, LangChain, LibreChat, n8n — same story.
It works with Claude Code too
Claude Code speaks Anthropic's format rather than OpenAI's, but the gateway translates between them, so you can run Claude Code's whole workflow on an open model:
bashexport ANTHROPIC_BASE_URL="[https://api.khidi.ai](https://api.khidi.ai)"
export ANTHROPIC_AUTH_TOKEN="sk-..."
claude --model kimi-k2.6
Same terminal workflow, a fraction of the cost. Basic usage is solid; some Claude-specific features can be hit or miss through translation, so test your exact flow.
What I won't oversell
The newest closed flagship is still ahead on the hardest problems — by a little, at a lot more money. Frontier research? Pay for the frontier. Normal engineering? You're overpaying.
Latency and reliability vary more with any hosted open-model service than with OpenAI's own stack. Streaming feels fine; non-streaming can be slower. Test your workload.
Open-model line-ups shift. Don't hardcode assumptions about what's available.
Try it on one project The models were never the blocker — the friction was. If cheap, capable inference behind a card-and-a-base-URL sounds useful, point one project at it and compare the output honestly. Worst case you confirm you really need the flagship. Best case you cut your biggest variable cost by an order of magnitude, with none of the setup that usually makes people not bother.
You can try it at khidi.ai — there's a free trial budget on sign-up, no card needed to start.