Rust AI API client (India)

Rust crates like async-openai were built around a configurable API base rather than a hardcoded host, precisely so they can target any server that speaks the OpenAI chat-completions protocol. unoblox is that protocol, served from India and billed in rupees, which means a Rust service that already uses async-openai needs a configuration change, not a rewrite.

Configuring the client

use async_openai::{config::OpenAIConfig, Client};
use async_openai::types::{CreateChatCompletionRequestArgs, ChatCompletionRequestUserMessageArgs};

let config = OpenAIConfig::new()
    .with_api_base("https://api.unoblox.ai/v1")
    .with_api_key("ub-gw-xxxxxxxxxxxxxxxxxxxxxxxxxxxx");

let client = Client::with_config(config);

let request = CreateChatCompletionRequestArgs::default()
    .model("qwen/qwen3-235b-a22b-instruct-2507")
    .messages([ChatCompletionRequestUserMessageArgs::default()
        .content("Draft a one-line changelog entry.")
        .build()?
        .into()])
    .build()?;

let response = client.chat().create(request).await?;

Everything downstream — the async call, the response struct, error handling — stays exactly as async-openai's own documentation describes it.

Model choice for latency-sensitive Rust services

Rust is frequently chosen for services where tail latency and throughput matter, which makes the smaller/cheaper models attractive defaults with a larger model reserved for harder requests:

Model id	₹ / 1M input	₹ / 1M output
deepseek-ai/deepseek-v4-flash	₹9.07	₹18.14
google/gemma-4-31b-it	₹13.10	₹38.30
meta-llama/llama-4-scout-17b-16e-instruct	₹10.08	₹30.24
openai/gpt-4.1	₹201.60	₹806.40

Anything outside this table — o3, o4-mini, Nemotron, Mistral Small and the rest of the catalog — should be priced by checking its live rate at /models, not by assuming it matches a neighbouring row.

Async streaming and concurrency

async-openai's streaming response type works unchanged against unoblox's SSE output, so a tokio-based service can .await a streaming chat completion the same way it would against any OpenAI-compatible host. Because billing is per token rather than per request, running many concurrent low-latency requests from a Rust service doesn't carry a different cost model than fewer, larger ones — the token count is what's metered.

Where the key lives

Treat the ub-gw-… key as you would any other service credential: load it from your secrets manager or environment configuration at startup and pass it into OpenAIConfig::with_api_key once, rather than constructing a new client per request.

The billing difference

The wire protocol is identical to OpenAI's; the invoice is not. unoblox settles in rupees on a monthly GST invoice issued by an Indian entity, so the spend is input-tax-credit claimable and doesn't depend on a company having an international card on file.

Frequently asked questions

Does async-openai need a patch to work with unoblox? No — with_api_base and with_api_key on OpenAIConfig are sufficient.

Will streaming responses parse correctly? Yes, the streamed chunks follow the same shape async-openai already parses for OpenAI-compatible hosts.

Can I call multiple models from one Rust binary? Yes — the model is a field on the request, not the client, so one Client can serve many models.

Is there a no-cost model for integration testing? Yes — qwen/qwen3-1.7b is listed at ₹0.

How do I estimate cost for a high-throughput service? Multiply your expected input and output tokens per request by the model's listed ₹ rate per 1M tokens — see /models for any model not priced above.

What does the invoice look like? A monthly GST invoice from an Indian entity, in rupees, with input tax credit claimable.

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