Skip to main content
Every Gloo AI inference endpoint belongs to one of three families. All three share the same model catalog, authentication, metering and rate limits. What differs is what runs around your request. Each family comes in both request shapes — the OpenAI-compatible Responses format and the Chat Completions format — so the family and the shape are independent choices.

​
Guarded endpoints

The recommended default, and where new integrations should start. A guarded request runs Gloo’s full safety and values pipeline: input guardrails, output moderation, values-aligned (tradition) responses, model_family selection and intelligent auto-routing across models.
  • Responses (POST /ai/v2/guarded/responses) — the recommended surface for new work.
  • Completions (POST /ai/v2/guarded/chat/completions) — fully supported, and the home of routing and model_family.

​
Direct endpoints

Direct endpoints send your request straight to the model you name. Gloo adds nothing between your prompt and the provider: no guardrails, no output moderation, no values-alignment, no routing. What you send is what the model sees; what the model returns is what you get. You can spot a direct endpoint by the /direct/ segment in its path. Use them when your application owns its own safety and prompting end to end — an agent framework with its own moderation, a backend that composes prompts itself, tooling that needs byte-faithful model behavior.
  • Direct Responses (POST /ai/v2/direct/responses) — for new work that owns its own safety; multimodal.
  • Direct Completions (POST /ai/v2/direct/chat/completions) — for existing Chat Completions tooling.

​
What runs, and what does not

Direct means direct about content, not a bypass of the platform: Still applies on every direct request:
  • Authentication (Bearer API key) and organization entitlement
  • Usage metering and billing
  • The Gloo model catalog — you address models by their gloo-* Model ID
  • Provider resiliency. Gloo serves the model you asked for, but not always from the same place: when the provider currently serving it is failing or unhealthy, your request fails over to another provider that serves the same model, and a stream cut mid-answer can be continued on a fallback provider. The model you receive is the model you asked for — resiliency changes who serves it, never what you get.
  • Platform rate limits
Deliberately not applied:
  • Input guardrails and output moderation
  • Values-alignment (tradition)
  • model_family selection and intelligent auto-routing — nothing picks a different model than the one you named (distinct from provider resiliency above, which only changes which provider serves that same model)
  • Gloo prompt augmentation — your messages go to the model verbatim
On direct endpoints, safety is your application’s responsibility. Nothing screens the input before the model sees it, and nothing reviews the output before your user does. If any part of your traffic needs screening, route it through the guarded Responses or Completions endpoints.

​
Grounded endpoints

Grounded endpoints retrieve relevant passages from content you have uploaded, inject them as context before generation, and tell you whether the answer was grounded in your sources.
  • Grounded Responses (POST /ai/v1/grounded/responses) — grounding in the Responses shape.
  • Grounded Completions (POST /ai/v2/grounded/chat/completions) — grounding on Completions V2, with citation metadata and tradition.

​
Which endpoint should I use?

When in doubt, start with the guarded Responses API. The guarded and direct Responses endpoints take the same request body, so moving between them later is a URL change.

​
Legacy endpoint aliases

The previous v2 paths remain available as aliases for existing integrations. New integrations should use the canonical paths above: The /ai/v1/grounded/responses endpoint is unchanged.