Why OpenAI’s API Might Outlive OpenAI
A look at what happens when the protocol outlasts the product, and what we can learn from our dial-up past.
I’ve been tinkering with Kimi recently, and one of the things that feels…normal?...is that it didn’t ask me to install anything of its own. Instead, I just used a single import — from openai import OpenAI — and then overrode the base URL. That’s all it took. By my count, Moonshot’s K3 is the fifth major model family this year to launch with an OpenAI-compatible interface. This is probably where everybody is going.
In the State of Open Source AI report that we recently published at Mozilla, where I’m CTO, we have this graph that shows token share over time. I’m happy to report that the number of tokens being generated by the open weights models is growing. In June, 2025, 70% of OpenRouter token share was from US models from Google, OpenAI, and Anthropic. A year later? They are roughly 30%, with OpenAI sitting at just around 8% of weekly tokens.
Most of those tokens show up in a request/response pair that OpenAI designed. Not all of them, true. (OpenRouter will take an Anthropic-shaped request, too, and that’s how Claude Code talks to it.) But the default vocabulary — the one you get when you aren’t thinking about it — is OpenAI’s.
Everybody makes the Java analogy. Sun wrote the SDK and API for Java, defining how people called into the virtual machine. For those of you who don’t remember the history, Google reimplemented those APIs in Android, and Oracle sued. In 2021, the Supreme Court called it fair use, while assuming, rather than deciding, that the code was copyrightable at all. Fine. Java is the most famous analogy — if perhaps not the best one. That comes from a modem company in Norcross, Georgia.
For those of you who never had the joy of dealing with a modem, it was a device that connected your computer to the telephone line in your house. I’ll always remember my first one, a 2400 bps model, putting a busy signal up my parents’ phone line so I could dial into bulletin boards all around the NYC area. When you popped up your modem’s software, you would often see (and sometimes, if you were like me, type in) a series of AT commands — also known as the Hayes AT command set — to get the modem to do something. You would type “ATDT” and a phone number, and then the modem would dial. Every modem competitor copied it, because if your modem didn’t respond to the AT command set, then it couldn’t talk to any piece of modem software that was already written.
Stamped on the side of every modem you ever purchased was the phrase “Hayes-compatible.” And then that command set got formalized as an international standard. The cellular modem in your phone is running a descendant of that protocol right now.
Hayes filed for Chapter 11 in 1998, and was liquidated the following year. A former rival bought the brand.
The lesson? Setting the grammar, language, and protocol is often different from being paid.
Who’s Defining the Parameters?
Open the model catalog on OpenRouter, and every model has supported_parameters — basically a list of knobs that the gateway says a model will respond to. And if you look there, almost every model responds to the parameters that OpenAI defined: temperature, tools, tool choice, response format, etc. That doesn’t mean there aren’t their own custom fields, but it’s the difference between the main front pocket and a side one.
Now take a look at Kimi K3. It returns a reasoning_content field, where the model dumps its scratch work. But if you don’t replay the reasoning message on the next turn, Kimi won’t continue the conversation. If you hand it a tool result without that field, then you’re outside the documented format and the model will lose the thread.
There is a body that is attempting to standardize all this: Open Responses was started by OpenAI and is based on their Responses API as an attempt to enable a unified experience, to use their language. Hugging Face and Vercel have signed on to back this open inference standard. And they do have a reasoning field. Two of them, actually. One holds the raw scratch work, the way Kimi returns it. The other holds an encrypted blob you’re explicitly not supposed to open — the provider scrambles its reasoning, hands it to you, and trusts you to hand it back untouched on the next turn. The spec’s own word for it is “opaque.” So the container exists, and it exists in the hard version. Hugging Face’s launch demo even runs a Kimi model through it.
What doesn’t exist, however, is an agreement on the lifecycle: who’s required to preserve that item, whether a gateway can tell you a field is mandatory rather than merely available, and what happens when the client keeps it and the next provider throws it away. The open ecosystem is making up new primitives faster than anybody has agreed on how to use them.
I ran into a version of this last week, when I was benchmarking Kimi K3 against Claude Code. Overriding ANTHROPIC_BASE_URL to point at a non-Anthropic host had the side effect of silently turning off Tool Search in Claude Code (presumably because most proxies don’t forward the blocks it needs). Tool calling still worked! The tools, however, got loaded up front instead of discovered on demand. That one change moved the output tokens generated up around 20%. The thinking tokens? They moved up around 42%. Nothing errored, and nothing warned me. There is a flag to turn it back on, if you already know to look for it. The request was totally fine; it’s just that with those settings, the harness became a different harness.
This is not new. When modem vendors needed commands the AT set didn’t cover, they didn’t wait for permission either. They each just invented their own prefix. Hayes and USRobotics used &. Microcom used \. Sound familiar? Everybody bolted on their custom extensions.
That’s how this happens. One vendor ships something that works. Competitors clone it for compatibility. Then the clones diverge. Divergence gets expensive. And only then does a neutral body show up and try to formalize whatever everybody already had in common. For modems, that eventually became ITU-T V.250.
So…what to watch with Open Responses isn’t its charter — although, given who started it, it is notable that it says that no single vendor can occupy a majority of the maintainer seats. It’s the promotion path that they use. But if a lab shipped a new primitive, how long before the spec absorbs it? And has anything ever traveled the other direction?
The question is not which model wins. It is who owns the dependency that survives the model changing. “Hayes-compatible” has outlived Hayes by 27 years and counting.



