Ruby AI API client (India)

Ruby never got an official first-party OpenAI SDK, but the community filled the gap with gems like ruby-openai that treat the base URL as configuration, not a hardcoded constant. That single design choice is what lets a Rails app or a Sidekiq worker call unoblox — India's rupee-billed, OpenAI-compatible gateway — without touching a line of application code beyond the client setup.

Configure the client

require "openai"

client = OpenAI::Client.new(
  access_token: "ub-gw-xxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  uri_base: "https://api.unoblox.ai/v1"
)

response = client.chat(
  parameters: {
    model: "deepseek-ai/deepseek-v4-flash",
    messages: [{ role: "user", content: "Summarise this support ticket in two lines." }]
  }
)

puts response.dig("choices", 0, "message", "content")

That's the entire migration for most Ruby codebases: one uri_base, one key, and the rest of your chat, embeddings and (where supported by your gem version) tool-calling code keeps its existing shape.

Picking a model for a Ruby service

Model id	₹ / 1M input	₹ / 1M output
deepseek-ai/deepseek-v4-flash	₹9.07	₹18.14
meta-llama/llama-4-scout-17b-16e-instruct	₹10.08	₹30.24
openai/gpt-5-mini	₹25.20	₹201.60
qwen/qwen3-1.7b (free)	₹0.00	₹0.00

For models outside this table — Claude, Nemotron, Mistral Small, GPT-5 nano and others in the catalog — read the live ₹ rate on /models before you bake a number into a billing estimate.

Background jobs and streaming

Most Ruby AI workloads live inside a Sidekiq or ActiveJob worker rather than a request/response cycle, and that's where per-token ₹ pricing is easiest to reason about: a nightly job that processes a known number of records has a known, computable token bill. ruby-openai also supports a stream: proc for token-by-token output if you're building a live chat surface with Action Cable rather than a batch job — the SSE format from unoblox matches what the gem already expects from OpenAI's own host.

Keeping keys scoped

Because unoblox keys are simple bearer tokens (ub-gw-…), it's straightforward to mint one key per Rails environment or per background-job queue and track spend separately in the account dashboard, rather than sharing one key across staging and production.

What changes on the invoice

The request and response bodies are identical to what ruby-openai already sends to OpenAI's own host. What's different is that unoblox settles in rupees on a monthly GST invoice from an Indian entity — input tax credit claimable, no international card, no separate FX line anywhere on the bill.

Frequently asked questions

Do I need a fork or patch of ruby-openai? No — the published gem's uri_base and access_token options are all that's required.

Does streaming work the same way? Yes, the gem's stream: proc receives the same incremental chunks it would from any OpenAI-compatible host.

Can I run multiple models from one Ruby app? Yes — pass a different model string per client.chat call; there's no per-client model lock-in.

Is there a way to test integration without spending anything? Yes — qwen/qwen3-1.7b is listed at ₹0, so you can validate your Ruby integration before pointing production traffic at a paid model.

How are rate limits handled? Limits are per key, visible in the account dashboard — mint separate keys per environment if you need independent limits.

How is this billed to my company? A monthly GST invoice from an Indian entity, in rupees, with input tax credit claimable.

Get started in rupees → https://unoblox.ai/sign-in