Launched this week
Hopscotch AI
500+ AI models available via a single API
192 followers
500+ AI models available via a single API
192 followers
🎁 PRODUCT HUNT EXCLUSIVE: The first 250 PH users to sign up get $50 in free model credits. Create your free account and redeem code HOPSCOTCH50OFF in the Billing tab. | 🚀 Access 500+ AI models from OpenAI, Anthropic, Google, and more through one API. Use multiple providers without managing separate integrations, accounts, or payments. Compare models on your prompts, configure fallbacks, and track usage and spend in one place. Pay provider rates with no platform fees or token markup.
Free Options
Launch Team
Customer.ioAutomate Messaging Everywhere — Startups Get 12 Months Free
Promoted
the crowded part of this space is routing, everyone claims automatic failover to the next provider when one is down or rate-limited. what I'd actually want to know before switching: when a request does fail over mid-stream, does the new model pick up with the same context and just continue, or does it restart the whole call, because that difference is what actually decides if users notice the switch happened.
@galdayan Good question. Today, if a stream has already started and then fails mid-stream, we restart the request on the fallback provider rather than trying to resume from the exact context. Seamless mid-stream continuation is something we’re actively thinking about.
Hey Gal fair point, and mid-stream failover is a very active feature we're looking to release shortly.
Currently most routers require a completely new restart when a stream fails, so the user sees the whole response start over. The way we're approaching it is:
buffering every token that's already been streamed to the user
if the provider drops, we send the original context plus the partial response to the fallback so it continues from that exact point instead of starting over
prompt caching on the fallback side so the handoff is fast and there's no long pause
failing over to the same model on a different provider first where possible
End result is the stream just keeps going and the user doesn't notice the switch. Will share more once it's live!
@jason_li1585 that's a much more concrete answer than "we restart the request" - buffering the streamed tokens plus forwarding the partial response as context is the actual fix, not just a fallback. prompt caching on the fallback side is a nice touch too since otherwise you'd eat the full latency penalty twice. following the Uniblock launch to see this live.