The singularity is already here, just in pieces.

01 · Where we are

Everything in this field arrives on its own. New weights land every few weeks and each release carries its own keys, its own billing, and its own setup. When Kimi came out, everyone was talking about it and almost nobody had actually run it, because running it meant starting an account and wiring up one more thing.

The same separation runs underneath. Every request has to execute on somebody's hardware, and there are dozens of providers now with different prices, different speeds, and different reliability, none of which your code knows about. The tools people work in are just as separate: two engineers on the same team, one in Claude Code and one in Cursor, have almost no shared ground.

So the capability is already here and it is scattered. The work of holding it together lands on the person trying to get something done, which is why most people pick one corner of it and stay there.

02 · Where this is going

Capability per parameter keeps improving at a steady rate, and distillation keeps compressing large models into much smaller ones at a fraction of the cost, power, and latency.

Local models trail the frontier by roughly seven to nine months, and that distance has held while both lines climbed. Follow the same curves and frontier-level intelligence runs on a laptop about a year after it ships in a data centre.

The second thing those curves say is that the scattering gets worse. Models are splitting into fine-tuned, hyperspecialized variants, so a capable machine ends up holding many small models instead of one large download. Providers are specializing in parallel, trading latency for cost or building their own silicon and number formats.

03 · How we got here

We started at the bottom of the stack and wrote an inference engine. After two months of kernel work it ran ahead of llama.cpp and MLX on decode, prefill, and time to first token on the same hardware. Everyone who saw it said the same two things: it was fast, and a local model on its own still could not carry the hardest fifth of their work.

That is what pushed us to the router. If a local model handles most requests well and a frontier model is only needed for the hardest ones, the useful thing to build is the layer that tells them apart and sends each request to the right place: which model, which provider, which machine. The engine work still ships underneath it, which is why running a model locally is a real option in the routing table rather than a checkbox.

04 · Where we fit

Your code keeps calling the same OpenAI-compatible or Anthropic-compatible endpoint it already calls. Name a model id and that is what serves, or the request is refused. Ask a saved route, a reach preset, or Palm, and the router picks where the request runs: the cheapest path, the fastest response, the most reliable provider, or your own machine.

Using Conifer, you can try Kimi without opening an account with Moonshot. When you ask a route, the router can fetch a local model you would not have downloaded yourself, and price and uptime become inputs to that decision rather than a commitment you made months ago. Name a model and none of that substitution happens. All of it works inside the environment you already have, because the endpoint is the only thing your setup needs to know about.

That is what an inference gateway is. Many models, many providers, and many machines on one side, one endpoint on the other, and the routing in between doing the part that used to be your job. As the field keeps splitting, the number of things worth reaching grows and the amount you have to manage stays where it is.