Get in touch
Work location
B-810/811, World Trade Tower (WTT), Makarba, Sarkhej Gandhinagar Highway, Ahmedabad,
Gujarat, India, 380015
Social link
Wiring a product to call GPT-4o is an afternoon’s work. Making that call survive a slow provider day, an expensive week, or the hour someone needs an exact cost number is the actual job, handled without the product knowing or caring which model answered.
SupportGenie was built for a SaaS support team running customer chat on OpenAI. It’s the backend layer between the support product and whichever model is answering: OpenAI by default, Claude the moment OpenAI looks degraded. It streams every response and keeps the conversation’s memory intact through the switch, across 24,532 conversations this week.
.jpg)
A support integration wired to a single provider is one outage or one price change away from being offline or over budget, and switching providers manually mid-incident means losing conversation context exactly when things are already going wrong.
A provider-agnostic gateway streams every response in real time, detects when the primary is degraded, and fails over automatically without dropping context, logging cost per provider so nobody finds out about a price spike from the invoice.
.png)
Every request goes through a gateway that picks a provider based on live health and cost, not a choice hard-coded at launch. The part that’s easy to get wrong is the failover itself: if a conversation three messages deep suddenly routes to a different model, the customer should never be able to tell. SupportGenie carries context across the switch, so a customer asking about order #12345 gets a coherent reply whether message four came from GPT-4o or Claude. Every exchange is logged with its token count and provider, keeping a $0.042-per-1K-token blended cost a known number.
Four components sit between the chat window and the model providers. The product only ever talks to the gateway, so routing, failover and cost tracking can change underneath it without touching the support experience.
Receives every chat request and holds the conversation’s context across the session, regardless of which model answers.
.svg)
Picks OpenAI or Claude per request based on live latency, health, and cost signals
Detects a degraded primary mid-conversation and switches without the user noticing or losing history.
Tracks tokens and spend per conversation and per provider, feeding the number ops actually checks.
A provider switch can happen on message four of a conversation without the earlier messages being lost.
Responses stream token by token the same way whether OpenAI or Claude is answering.
Spend is tracked by provider, not just in aggregate, so a price change on one side shows up immediately.
The router reacts to live latency and error rates rather than a fixed schedule or manual toggle.
Provider credentials live in one place instead of being copied into every service that needs to call out.
Measured over a 30-day window against real traffic, not a synthetic test.
The aim was a support chat that keeps working whatever happens upstream. Here is how SupportGenie differs from a direct, single-provider integration.
Outages, rate limits, latency spikes and price changes: the specific failure modes that had already hit similar integrations.
Started with the request and response layer both providers would sit behind, before writing any routing logic.
Health-based provider selection came first; failover without losing context came once routing was proven stable.
Token and spend logging went in alongside the routing logic, not after someone asked for a cost report.
Killed the primary provider mid-conversation repeatedly until failover held up without manual intervention.
An automatic switch still needs someone to understand it at 2am, including what’s safe to ignore.
.jpg)
