Hopscotch is a new product. We spent years solving one specific problem for a different kind of infrastructure, then realised that every team building with AI models runs into that same problem and has to solve it on their own.
The raise
In March we announced a $5.2M round led by SBI Ven Capital, taking the company to $7.5M raised in total. Alchemy, MoonPay, Hustle Fund, and AllianceDAO joined it, along with angels from Kraken, Uber, and CoinList. Decrypt has the full list.
Part of that went into Hopscotch.
What we already knew how to do
Our company, Uniblock, runs routing infrastructure. Not for models. A request arrives naming what it wants rather than which provider should serve it, and something has to pick one, notice when that provider is failing, tell apart a failure worth retrying from one that will fail the same way anywhere, move to another provider without the caller writing that code, and make every provider's response look the same from the outside.
That engine has been in production for years.
Why we pointed it somewhere new
We were not looking for a second market. We noticed we already had the answer to something a lot of people were asking about.
A team building with models is usually talking to several providers at once, each with an API that is close to the others without being the same. Those providers rate-limit, they run out of capacity in the middle of a busy hour, and they return errors that mean very different things: a 429 will often clear if you wait a moment, while a malformed request will fail the same way on every provider you send it to. They also charge different amounts for the same open weights. So the team ends up writing its own provider selection, its own retry logic, and its own fallback chain, then maintaining all three alongside the product it actually set out to build.
We had built that layer once already. Hopscotch is the version of it we built for models.
What it actually does
Hopscotch answers on a single base URL, in the OpenAI chat completions shape, so pointing an existing client at it is usually a one-line change rather than a migration. There are more than 150 models behind it to start with, and we are still adding.
Cost is something you choose rather than something that happens to you. Send hopscotch/auto with a cost tier, low, balanced, or high, and auto picks inside the band you named. Name a model and that model runs. Nothing quietly substitutes something cheaper while you are not looking.
Failover is classified rather than blind. A transient error, a capacity error, a malformed request, and our own adapter failing on a well-formed response are four different situations that call for four different responses, and retrying the ones that cannot succeed only bills you twice for the same failure. The dashboard shows every attempt behind a request and the class it was given.
You pay list price on one bill, whichever lab served the request.
Who it is for
Anyone who calls models is in scope. That includes a company standardising what its teams spend and which models they are allowed to reach, and it includes one person with a side project who would rather not maintain four SDKs and a fallback chain of their own.
It is the same product in both cases. Spend caps, roles, and keys live in the product rather than behind a plan tier, so the difference between those two is how you configure it rather than what you are allowed to buy.
Where this goes
The gateway is live. Pointing a client at it takes one line, which the unified API page walks through, and a key from the dashboard is how you start.