Model-agnostic, on purpose.
We don't take revenue share from upstream providers and we don't favor a brand. The recommendation you get from our team is the same one we'd make for ourselves, with the same trade-offs and the same uncertainty.
idclinks is a small, model-agnostic team of infrastructure engineers. We don't make the models, and we don't try to be a model lab. We build the boring layer that keeps the models you depend on reachable, predictable, and accountable.
The first wave of AI products was built on one provider, one model, one API. That worked when there was a clear leader. It doesn't work now — there are three or four frontier labs trading the top spot every quarter, plus open-weights flagships that keep closing the gap.
Teams that took the bet on a single provider are now spending engineering quarters writing adapters, hedging against quota cuts, and explaining unexpected bills to finance. We built idclinks for them: a single endpoint, a single schema, a single contract — across every model that's worth shipping.
We're independent on purpose. We don't have a model to sell you, so we have nothing to gain from routing your traffic to a particular brand. If the answer is to use the cheapest open-weights model, we'll tell you. If the answer is to pay 10× more for the frontier tier, we'll tell you that too.
Stated up front because they should be auditable from the outside, not buried in our internal handbook.
We don't take revenue share from upstream providers and we don't favor a brand. The recommendation you get from our team is the same one we'd make for ourselves, with the same trade-offs and the same uncertainty.
Infrastructure should disappear into the background. We optimize for predictable latency, deterministic error semantics, and routing decisions you can explain in one sentence — not for benchmark hero numbers.
Pricing in ranges. Response headers that tell you which region, which replica, which upstream. Traces you can export to your own observability stack. If we wouldn't want it as a customer, we don't build it that way.
We hire slowly and we ship slowly on purpose. The product is a contract — the model keeps working, the bill makes sense, the rate is the rate. That kind of contract requires patience, not headcount.
idclinks started as a routing layer behind another product, written because three different teams were re-implementing the same provider-failover logic in three different languages. The internal tool worked. The product did not.
We spun out the routing layer when other teams kept asking to use it. Six design- partners signed contracts in the first quarter — every one of them already running on two or more providers and tired of maintaining the seam.
Routed regions reached six worldwide. Dedicated capacity went into general availability. Open-weights flagships joined the catalog alongside the closed frontier models — the same schema, the same contract.
Forty-plus models in the catalog, four named tiers, and a public pricing page. Still independent. Still small. Still answering sales emails ourselves.
We don't gate conversations behind a multi-step form. Email the address below with a sentence or two about what you're building — we read every message.
Tell us your model mix, expected monthly tokens, region, and any compliance constraints. We'll come back with a trial key and a pricing sheet for your shape.
sales@idclinks.comSame address — sales reads it first and forwards anything technical to the on-call engineer. We don't run a separate support queue at our size, and we like it that way.
sales@idclinks.comWe share SOC 2 type II reports, sample DPAs, and architecture diagrams under NDA. Send the request and a short description of your review timeline.
sales@idclinks.com