How to reduce LLM costs in India

How to reduce LLM costs in India — 8 proven tactics

Building with LLMs and spending too much? Here are 8 tactics to cut your ₹ invoice without sacrificing output quality.

Tactic 1: Optimize prompts (20–30% savings)

Shorter, clearer prompts mean fewer input tokens. Since input is cheaper than output per token, this is usually your easiest first lever, not your biggest one.

Before (verbose, ~150 tokens):

You are a customer support agent with 10 years of experience in
technology products. You have been trained to be empathetic, patient,
and solution-focused. Please read the following customer question and
provide a helpful, detailed response that addresses their concern...

After (concise, ~20 tokens):

Support response to customer:

Savings: ~130 fewer input tokens per request. At 100K requests/day, that's roughly ₹3K–₹30K/month saved depending on which model you're running — more on expensive models, less on cheap ones.

Tactic 2: Use the cheapest capable model (50–95% savings)

Model choice dominates cost more than any prompt trick.

Model	₹/1M input	Use case	Best if
Qwen3.8-27B	₹0	Testing, low-volume	80%+ accuracy is enough
Qwen3 235B-A22B	₹9.11	General production	Balanced quality/cost
Llama 4 Scout	₹10.12	Classification, tagging	Speed + cost over nuance
Claude Sonnet	₹202.46	Reasoning, coding	You need top-tier accuracy
GPT-4o	₹253.07	Multimodal, complex	Vision or edge cases

Example: a classification task (sentiment, intent, category) usually works fine on Qwen3.8-27B (₹0). At 10M monthly tokens, that's ₹0 versus ₹2,025 on Claude Sonnet (10 × ₹202.46) — pure savings if accuracy holds up on your data.

Recommendation: start on Qwen3.8-27B. If accuracy isn't acceptable, step up to Llama Scout, then Qwen3 235B. Most production classification and extraction tasks never need to go further.

Tactic 3: Cache repeated context (up to ~80% off the repeated part)

If your prompt repeats the same large block of context (a handbook, a system prompt, a reference document) on every call, keep that block at the very start of the prompt and byte-identical on every call. On models whose page lists a Cached input price, the provider serves the repeated prefix from its prompt cache and those tokens are billed at the cached rate; usage.prompt_tokens_details.cached_tokens shows how many were.

response = client.chat.completions.create(
    model="deepseek-ai/deepseek-v4-flash",
    messages=[
        # identical on every call -> served from the provider's prompt cache on repeats
        {"role": "system", "content": "You are a support bot.\n\n" + COMPANY_HANDBOOK},  # 5,000 tokens
        {"role": "user", "content": "What is our refund policy?"},
    ],
)
print(response.usage.prompt_tokens_details.cached_tokens)

Worked example — 1,000 queries/day on DeepSeek V4 Flash, each with the same 5,000-token handbook + a 200-token question (rates at the time of writing: ₹9.11 per 1M input tokens, ₹1.82 per 1M cached input tokens):

• Without caching: 30,000 queries/month × 5,200 tokens = 156M input tokens × ₹9.11/M = ₹1,421.16/month.
• With caching (handbook served from the cache on repeat calls): 150M cached tokens × ₹1.82/M + 6M uncached tokens × ₹9.11/M = ₹327.66/month.
• Savings: ₹1,093.50/month (≈77%). The current rates are on each model page.

Caching applies only where a model page lists a Cached input price. Claude models on unoblox do not offer cached-input pricing yet.

Tactic 4: Batch requests (latency savings, not token savings)

Processing 10 requests individually versus 1 batch request costs the same in tokens, but:

• 10 separate API calls mean 10× the network/latency overhead.
• 1 batched call means a single round trip.

For large jobs (summarizing 1,000 documents), batch 50–100 per request where the API supports it. Same ₹ spend, faster wall-clock time.

Tactic 5: Summarize long documents before deep analysis (meaningful savings on long inputs)

If you're analyzing a long document, don't feed the whole thing into an expensive reasoning pass — summarize first, then analyze the summary.

Before: send all 10,000 input tokens directly to GPT-5, get a 2,000-token output. (10,000/1,000,000 × ₹126.53) + (2,000/1,000,000 × ₹1,012.28) = ₹1.27 + ₹2.02 = ₹3.29 per document.

After: summarize to 1,000 tokens with a cheap model first, then analyze the summary (1,000 input + 500 output on GPT-5): (1,000/1,000,000 × ₹126.53) + (500/1,000,000 × ₹1,012.28) = ₹0.13 + ₹0.51 = ₹0.63 per document, plus a small summarization cost on the cheap model.

Even accounting for the summarization pass, this comes out meaningfully cheaper per document once you're processing volume — and the savings compound because the expensive model now sees far fewer tokens.

Tactic 6: Stream and stop early (5–10% savings)

When streaming responses, stop reading as soon as you have what you need. You're only billed for tokens the model actually generates, so cutting a stream short before the model rambles on saves real output cost.

with client.messages.stream(...) as stream:
    for text in stream.text_stream:
        if "Answer:" in text:
            break  # Stop early, save tokens

Tactic 7: Validate client-side before calling the API (10–20% savings)

If a meaningful share of requests are malformed, empty, or spam, filter them before they reach the model.

if len(user_message) < 10:
    return "Message too short"
if contains_sql_injection(user_message):
    return "Invalid input"
client.chat.completions.create(...)  # Only valid requests reach the API

Tactic 8: Set a hard spend ceiling per key

Even with every optimization above, a bug (a retry loop, an unbounded batch job) can spike your bill overnight. Set max_spend_monthly on each API key — requests past the cap return a clear error instead of silently continuing to bill, so a runaway script costs you an alert, not a surprise invoice.

Putting it together: a single-lever example

Before: a support chatbot sending 50M input tokens/month through Claude Sonnet (₹202.46/M) costs 50 × ₹202.46 = ₹10,123.00/month.

After: the same 50M tokens/month, routed to Qwen3 235B (₹9.11/M) for the routine share of traffic, costs 50 × ₹9.11 = ₹455.50/month.

Savings from the model-switch lever alone: ₹9,667.50/month (≈96%) — before even layering on prompt optimization or caching.

Frequently asked questions

Will optimizing prompts hurt output quality? Usually not — shorter, clearer prompts often improve quality by removing noise, not just cost.

Which tactic has the biggest ROI? Model selection (Tactic 2). Moving routine tasks from Claude Sonnet to Qwen3 235B cuts the input rate by roughly 95% before you touch anything else.

Can I use prompt caching with every model? Caching support varies by model — cached-input pricing applies only where the model page lists a Cached input price (Claude models on unoblox do not have one yet).

Should I validate all user input before calling the API? Yes, as a habit — client-side validation is nearly free and avoids paying for calls that were never going to produce a useful response.

What if I genuinely need the most capable model for a task? Use it for that task specifically. For most workloads, only 10–20% of requests actually need frontier-model quality — route the rest to a cheaper model.

How often should I re-check my model choices? Whenever your monthly volume grows meaningfully, or after a pricing update — the cheapest-capable-model tradeoff shifts as both your traffic and rates change.

Can I set a hard limit so a bug never surprises me with a huge bill? Yes — max_spend_monthly on the API key returns an error once you hit the cap instead of continuing to bill.

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