KT Token Factory promises 25% savings: 20 points are compression, 5 are routing

On October 30, Korean telecom KT opened Token Factory to enterprise customers: 73 models behind one contract, seven of them hosted on KT's domestic infrastructure, and an Auto Model Router that KT says can cut token usage by up to 25%. That number made me read the press coverage twice. When DigitalToday reported the launch briefing, Kim Joon-seok of KT's AI Agentic Lab gave the breakdown: roughly 20% comes from prompt compression and roughly 5% from routing to cheaper models. The router, the feature with the benchmark trophy, is the small slice.

What KT actually shipped

Token Factory is a model broker with a telecom billing system attached. At launch it lists 66 global models (GPT, Claude, Mistral, DeepSeek, xAI, Alibaba) plus seven domestically hosted ones, including KT's own Mi:dm K 3.0, Upstage's Solar Pro 4 and Motif 3. Through an OpenRouter partnership KT plans to pass 500 models by the end of the year. Every request lands in what KT calls a Token Detail Record, a direct borrow from the call detail records telcos have kept for decades, and the bill arrives in Korean won. A launch promotion takes 30% off the seven domestically hosted models until November 30.

The router looks at question type, difficulty, required quality and cost. The customer sets a cost versus quality preference instead of choosing a model, and a fallback switches to a designated model when a call fails. KT says the router ranked first overall on RouterArena, an open router comparison platform described in a 2025 paper. I could not find KT's entry or its score, so I treat the ranking as KT's claim. The MoneyToday coverage adds that the compression is tuned for Korean and removes "unnecessary wording" while keeping meaning.

Why routing is only five points

None of this surprises me. I have built routers (my autorouter notes) and the arithmetic is unforgiving. Routing saves money only on traffic where a cheap model is good enough and where the router can tell that in advance. In enterprise workloads the expensive calls are the long ones: RAG answers carrying 40k tokens of retrieved documents, agent loops that resend their whole tool history. Those are exactly the requests a difficulty classifier sends to the strong model. The requests you can safely downgrade were cheap to begin with.

There is also a units trap. Token usage down 25% does not mean the invoice drops 25%. Compression shrinks input tokens, which are usually the cheap side of a price sheet, while output tokens on frontier models cost several times more each. Routing changes the price per token, not the count. KT's headline folds both into a token number, and the customer pays in won.

Then the overhead. A classifier on every request adds latency and tokens of its own. A wrong downgrade costs a retry, often on the expensive model anyway, so a misrouted request costs more than one that was never routed. And 20% compression is the part I would test hardest. Compression that drops unnecessary wording can also drop the negation, the unit or the exception clause the answer depended on.

Routing saves money on the requests that were already cheap. Compression saves money by deleting words you hoped nobody needed.

How I would test it before signing

Replay your own traffic, not a leaderboard. Export two weeks of real requests with their outcomes, push them through the router at the cost and quality setting you would actually run in production, and score the answers with the evaluator you already trust. Track three numbers separately: the bill in currency, the quality delta per task type, and p95 latency. If a vendor reports only aggregate token savings, ask for the compression and routing split on your data, the same split KT's lab head gave reporters.

Test compression on its own. Turn routing off, leave compression on, and diff the answers on cases where detail matters: contract clauses, numeric answers, instructions that contain "do not". If compression costs two points of accuracy there, the 20% is no longer free.

Then look at where the downgraded traffic goes, weighted by cost. A router that moves 30% of requests to a small model has done little if those requests were 6% of spend. Tag every request with its routed model and its cost and plot the cost-weighted distribution, not the request count. That view is what made AT&T's 56% routing claim make sense to me, and it is the view KT does not publish.

Where the platform still earns its fee

I am skeptical of the percentage, not the product. For a Korean enterprise that wants Claude, DeepSeek and a domestic model, Token Factory replaces a contract and review per vendor with one contract billed in won, domestic hosting for the sovereign models, guardrails that screen personal data and a commitment not to store or train on customer data, which removes months of procurement work. When finance asks why the AI bill grew, a Token Detail Record per request answers what most teams cannot. The fallback alone justifies a gateway for many of them.

The routing value, though, lives in the policy you write, not in whose classifier runs it. Picture a support team whose traffic is mostly ticket tagging and field extraction. One rule covers it: classification, extraction and short summaries go to a small model, and anything with long context or tools stays on the strong one. That gets most teams I talk to their own five points. Review the split monthly, since a cheap prompt that gains a tool belongs on the strong model.

So here is the concrete move. Before you buy any auto-router on a percentage, ask for the decomposition. When the vendor's own engineers say four fifths of the savings come from compression, you can test compression on your own prompts in an afternoon, and then decide whether the remaining five points are worth a broker's margin.