India Gets a 30B Open-Weight Model Built for Its Own Scripts

What shipped

• Gnani Artha, unveiled in New Delhi on 28 August 2026 by Bengaluru-based Gnani.ai, and launched by India's Vice-President C. P. Radhakrishnan. Gnani positions it as a "sovereign AI stack".
• Two components. Evon v3.3 is the model. Plexus is the agent orchestration platform. They are sold as a pair.
• Evon v3.3: 30 billion parameters, mixture-of-experts, roughly 3.5 billion active per token. Described in launch coverage as open-weight.
• Trained natively across more than 11 Indian languages — not English-first with an Indic adaptation layer bolted on afterwards.
• Gnani states Evon v3.3 consumes around 40% fewer tokens on Indian-language workloads than comparable models, and attributes that to rebuilding the tokeniser for Indian scripts. That is Gnani's claim, not an independently benchmarked result.
• Plexus is pitched at enterprises deploying agents across internal workflows, with customer service, document processing and business operations named as the opening use cases.
• Sources: the launch was reported by Inc42, and Gnani's own Artha page carries the vendor framing.

The reflex when a new Indian foundation model lands is to reach for the parameter count and file it against everything else on the shelf. Resist it. Thirty billion parameters with three and a half billion active per token puts Evon v3.3 in a size class that is now genuinely crowded — we compared a whole cohort of that shape in August's small open-weight models, and nothing in the announced numbers separates Evon from that pack on architecture alone. The capital story is crowded too: Indian foundation-model work has drawn serious money this year, including Sarvam's reported $350M round. Another 30B model, on its own, is not news.

What is potentially news is the tokeniser. Gnani did not claim a benchmark win. It claimed a 40% reduction in tokens consumed for the same Indian-language work, achieved by rebuilding the tokeniser for Indian scripts rather than inheriting one optimised for English. If that holds up outside the vendor's own harness, it is a cost lever that no amount of parameter tuning gives you, because it changes the denominator of every bill you receive and every latency budget you write. It is the one number in the announcement worth spending an afternoon testing.

Why the tokeniser is the number that matters

A tokeniser is the layer nobody in the room wants to talk about and everybody is paying for. It converts text into the integer sequence the model actually consumes. Its vocabulary and merge rules are learned from a training corpus, and if that corpus is overwhelmingly English, the merges it learns are the ones that make English compact. Common English words survive as single tokens. Devanagari, Tamil and Bengali get shredded into fragments — sometimes into individual bytes — because the tokeniser never saw enough of those scripts to learn that the sequences are worth keeping whole.

The metric for this is token fertility: tokens produced per unit of text. The higher the fertility, the more the tokeniser is fragmenting your language. And this is not a rounding error. Research published on 27 July 2026 — "The Tokenizer Tax", arXiv:2607.24276 — put numbers on it.

Sit with the Tamil row for a moment. On the Llama-3.1 tokeniser, English runs at about 1.24 tokens per word and Tamil at about 12.39. That is not a modelling problem, a quality problem or a prompt-engineering problem. It is an accounting problem, and it lands in three places at once.

The bill. Per-token pricing means a Tamil-speaking user costs you materially more than an English-speaking user for the same conversation. If your product serves a mixed audience, your unit economics vary by the language your customer happens to speak, which is an uncomfortable sentence to write and a worse one to discover in a board pack.

The clock. More tokens means more forward passes to say the same thing. Time-to-first-token and total generation time both stretch. On a voice or chat product where responsiveness is the entire experience, that penalty is felt by exactly the users you were trying to serve better.

The window. This is the one teams miss. If equivalent meaning consumes eight times the tokens, your effective context window shrinks by the same factor — the research measured it dropping to as little as 12% of what an English user gets. Your carefully tuned few-shot examples, your retrieved passages, your conversation history: all of it competes for a window that is quietly a fraction of the advertised size. Anyone who has built multilingual retrieval across Indian and European languages has hit this wall, usually while debugging why the same pipeline that works in English silently drops context in Tamil.

An Indic-native tokeniser attacks all three at once, which is why it is a more interesting claim than another point of benchmark headroom. It is also why the claim needs testing rather than repeating. The practical prompting consequences are covered in our guide to prompting for Indic languages and British English in one application, and the short version is that token budgets you set in English do not transfer.

Open-weight is not open source — read the licence

Launch coverage describes Evon v3.3 as open-weight. That is a specific and limited claim, and it is worth holding the line on the vocabulary because the industry has spent two years blurring it.

Open-weight means you can download the parameters and run them. Open source, in the sense the Open Source Initiative maintains, means you can use, modify and redistribute the artefact commercially without conditions attached to who you are or what you build with it. The distance between those two positions is where the interesting clauses live: redistribution rights, derivative naming, attribution obligations, acceptable-use restrictions, field-of-use carve-outs, and sometimes revenue or user-count thresholds above which the terms change entirely.

No specific licence name was detailed in the launch coverage we have seen, and we are not going to guess one. The honest position on 4 September 2026 is that the terms are unconfirmed. That is not an accusation — plenty of releases publish weights first and the licence text alongside them — but it does mean the diligence step is not optional. We have watched this exact fault line open before, most recently when Qwen3.8-Max shipped weights under terms that split the stack, and the pattern is consistent: teams build for three months on an assumption about the licence, then read it during a procurement questionnaire.

How to test the 40% claim on your own traffic

You do not need permission, a sales call or a proof-of-concept budget to evaluate a token-efficiency claim. A tokeniser is a small artefact that runs on a laptop. The whole exercise is an afternoon, and it produces a number denominated in your currency rather than the vendor's.

The method, in order:

1. Build a corpus from real traffic, bucketed by language. Pull a representative sample of production input — actual user utterances, not translated marketing copy — and split it into per-language files. The sample must reflect your real traffic mix, because a mix weighted evenly across languages will flatter or punish a tokeniser in ways that have nothing to do with your bill.

2. Tokenise the same corpus through both tokenisers. The candidate and the incumbent, over identical text. Same content, same order, no cherry-picking.

3. Compare tokens per word — and prefer a parallel corpus. The cleanest comparison uses the same meaning expressed in each language, so you are measuring the tokeniser rather than the verbosity of your users. Where whitespace word-splitting is unreliable for a script, fall back to tokens per character or tokens per utterance; the point is a consistent denominator, not a specific one.

4. Convert to money at your real traffic mix. Multiply total tokens per language bucket by your actual price per million, weight by each language's genuine share of volume, and compare the two totals. Do the same for output tokens, which are usually priced higher and are frequently forgotten in this exercise.

# Sketch, not a benchmark harness. Illustrative only — no numbers
# are produced here, because the only numbers that matter are yours.
from transformers import AutoTokenizer

CORPUS = {
    "en": "traffic/en.txt",     # one real utterance per line
    "hi": "traffic/hi.txt",
    "ta": "traffic/ta.txt",
}

CANDIDATES = {
    "incumbent":  "org/your-current-model",
    "challenger": "org/candidate-model",
}

def fertility(tokenizer, lines):
    tokens = sum(len(tokenizer.encode(x, add_special_tokens=False)) for x in lines)
    words  = sum(len(x.split()) for x in lines)
    chars  = sum(len(x) for x in lines)
    return {"tokens": tokens, "per_word": tokens / words, "per_char": tokens / chars}

for label, model_id in CANDIDATES.items():
    tok = AutoTokenizer.from_pretrained(model_id)
    for lang, path in CORPUS.items():
        with open(path, encoding="utf-8") as f:
            lines = [x.strip() for x in f if x.strip()]
        print(label, lang, fertility(tok, lines))

# Then, per language bucket:
#   cost = tokens / 1_000_000 * price_per_million
#   weight each bucket by its REAL share of your traffic, not an even split.
# Repeat for output tokens separately — they are usually priced higher.

Two things this test will not tell you. It will not tell you whether Evon v3.3 is good, only whether it is cheap per unit of meaning in your languages. And it will not capture serving-side reality — throughput, batching behaviour and memory residency on a 30B mixture-of-experts model with roughly 3.5B active per token are a separate exercise, and our vLLM production playbook is where that arithmetic lives. Token efficiency is necessary, not sufficient.

What "sovereign" does and does not buy you

"Sovereign AI stack" is a positioning term, and it is being used across the industry to mean several different things at once. Worth separating them.

What it plausibly does mean here: the model was trained in India, on Indian-language data, by an Indian company, and can be deployed in an environment the customer controls. For an enterprise or a public institution, that combination is genuinely useful. It answers supply-chain questions about who built the artefact, and deployment questions about where inference happens and who can see the prompts. Gnani's own framing — helping Indian organisations deploy AI while retaining control over sensitive data and the underlying technology — is a fair description of that value.

What it does not mean is a compliance exemption, and this is where procurement conversations regularly go sideways. On-premise or controlled deployment is a deployment property, not a legal one. Obligations under the Digital Personal Data Protection Act attach to how you process personal data, not to the nationality of your model vendor. Notice, consent, purpose limitation, retention and breach reporting apply identically whether inference runs in a Bengaluru rack or a foreign region.

It is also worth being precise about what the Act actually says on cross-border transfer, because the folklore has it backwards. Section 16 sets up a negative list: transfer outside India is permitted to any country except those the Central Government notifies as restricted. It is not a general bar, and on transfers the statute is more permissive than the GDPR, not less. What creates real residency pressure is everything stacked on top — sectoral mandates such as the Reserve Bank of India's payment-data directive, the additional duties that attach to a Significant Data Fiduciary, and, most often, client contracts that are stricter than any statute anyone is citing. The DPDP Rules commence in phases, with the substantive obligations arriving in May 2027, which makes this a planning deadline rather than a live emergency. We set out the sequencing in our DPDP Phase II compliance playbook.

Who this is genuinely for — and the UK read

Be honest about the shape of the buyer. Evon v3.3's token-efficiency pitch pays off for teams serving multilingual Indian users at volume, where a large share of input is non-English and the token bill is a line item somebody is already complaining about. Contact centres, government-facing service platforms, insurance and lending back-offices, and any conversational product with real Tier-2 and Tier-3 usage all fit. If your traffic is 95% English with a Hindi long tail, the tokeniser advantage is real but too small to justify a migration, and you should not let a good story talk you into one.

The UK read is not a courtesy paragraph. British teams building for diaspora-language users — Gujarati, Punjabi, Bengali, Tamil, Urdu across large and commercially significant communities — face precisely the same tokeniser economics, on the same scripts, with the same invisible context-window shrinkage. So do UK consultancies and software vendors selling into Indian enterprise clients, who inherit the language mix of the customer rather than the vendor. Neither group is served by treating this as an India-only story.

And the mechanism generalises past Indic scripts entirely. Morphologically rich European languages — Finnish, Hungarian, Turkish, Polish — take their own fertility penalty against English under the same tokenisers, for the same structural reason: the merge rules were learned from a corpus that under-represented them. A UK or EU team shipping a genuinely multilingual product should run the same tokeniser A/B on its own language mix regardless of whether an Indian model is anywhere near the shortlist. The lesson travels even if the model does not.

Where that leaves Artha: an interesting release with one claim worth testing and several facts still missing. Thirty billion parameters is unremarkable. Roughly 3.5 billion active per token is a sensible sparse design and nothing more. More than 11 Indian languages trained natively is a real differentiator against models that treat Indic as an afterthought. Gnani's claim of around 40% fewer tokens, if it survives contact with somebody else's corpus, is the sort of structural advantage that compounds every single day a product is live. Test the tokeniser, read the licence when it appears, and hold the word "sovereign" to what it actually delivers.