AskShiva AI Gateway

One door for every model your app calls.

An OpenAI-compatible /v1 endpoint. Each app gets its own virtual key with a budget and a list of models it may call. Apps ask for a role such as askshiva-fast or askshiva-reason; the gateway picks the model behind it and falls back when one fails.

Early accessBy invitationLast updated

Your appmodel: "askshiva-smart"
The gateway/v1 · key · budget · allow-list
  • askshiva-fast
  • askshiva-smart
  • askshiva-reason
  • askshiva-tool
  • askshiva-vision
  • askshiva-indic
  • askshiva-embed
  • askshiva-image
  • askshiva-flash-pd
  • askshiva-kids
An app sends an ordinary OpenAI-style request with its own key. The gateway checks the key, its budget and its model list, sends the request to the model behind the alias, and moves down the alias’s fallback chain if that model fails.

What it is

The AskShiva AI Gateway is the single place where AskShiva’s apps reach AI models. It holds the provider keys, so an app needs only its own gateway key. It speaks the OpenAI HTTP format, so any OpenAI SDK works by changing the base URL and the key. It records the spend of every call against the key that made it.

It was built for our own products first. AskShiva’s apps now send their model calls through it, and each keeps its own direct path to a provider as a fallback. Outside teams can use it by invitation only.

What changes in your app

Three values. Everything else in your OpenAI-style code stays as it is.

python
- base_url = "https://api.provider.example/v1"
+ base_url = os.environ["ASKSHIVA_BASE_URL"]   # from your invitation
- api_key  = os.environ["PROVIDER_KEY"]
+ api_key  = os.environ["ASKSHIVA_API_KEY"]    # your app's virtual key
- model    = "some-provider-model-id"
+ model    = "askshiva-smart"                  # a role, not a model

Then follow the quickstart for a first call in curl, Python and JavaScript.

Concepts

  • Model aliases

    Ask for a role: fast, smart, reason, tool, vision, indic, embed, image. The model behind a role can change without an app release.

  • Virtual keys

    One key per app, with a 30-day budget, rate limits and a list of the models it may call. Provider keys stay inside the gateway.

  • Data classes

    Public, personal and children’s data each have their own aliases, and a key can only call the aliases of its class.

  • Fallbacks

    Most aliases have an ordered chain of models. A timeout moves on at once; children’s aliases never fall back to anything.

  • Endpoints and errors

    Chat, embeddings, images, speech, rerank and a model list, plus the error codes your app should handle.

  • Policy layer

    In development Signed short-lived product tokens and named tasks with cost ceilings, in front of the gateway.

Honest notes

  • Early access, by invitation. Not for sale. There is no public sign-up, no self-serve key and no service-level agreement.
  • Where it runs. On rented servers in the USA. The model providers behind the aliases process requests under their own terms. We do not publish which provider sits behind each alias, because that changes.
  • What is recorded. The spend ledger records the key, the model, token counts and cost of each call. It is configured not to store prompts or responses.
  • Outputs can be wrong. A gateway routes requests; it does not check answers. Validate model output in your app before you rely on it.

Live status

Gateway health
Unknown
Gateway stage
Early access
Policy layer
In development (staging)
Last checked
Not loaded yet

Read when the page loads, from the AskShiva status service. If the service cannot be reached the health shows “Unknown”. A health check only shows whether the gateway answers; it says nothing about any one model.