Business applications
Document question-answering, summarisation, drafting and internal tools. Wire it into systems you already run through an API your team most likely already knows.
Customized open models,
tuned for real work.
Business applications, chatbots, student projects and coding tasks — one OpenAI-compatible API, served from NVIDIA accelerators in Amaravati, India.
tokenkey.py
from openai import OpenAI
client = OpenAI(
base_url="https://tokenkey.in/v1",
api_key="tk_live_...",
)
client.chat.completions.create(
model="tk-auto",
messages=[{"role": "user", "content": "hello"}],
)What people use it for
One API across the work an institution actually does.
Chatbots and assistants
Support desks, campus helplines, internal knowledge assistants. Responses stream token by token over your own network rather than a transatlantic round trip.
Student work
Tutoring, explanation and research help at classroom scale. Prompts stay in India and are never stored, so coursework does not become somebody else's training data.
Coding tasks
Completion, review and edits across files, routed to a model tuned for code rather than a general one asked to cope with it.
Models
Different work wants different models.
Ask for tk-auto and the gateway chooses. Name a model and it honours that, verbatim.
tk-auto
Router
Picks the tier for each request before generating, and records which one served it and why.
tk-base
Fast
Short, high-volume requests where responsiveness matters more than depth.
tk-32b
Flagship
Multi-step reasoning and longer context — the questions worth the extra compute.
tk-coder
Code
Generation, review and repository-scale edits.
01
Classify before generating
The tier is chosen before a single token is produced. The rejected alternative — letting a small model attempt everything and escalate when it judges itself to have failed — pays both models' latency on the hardest requests, and small models are poorly calibrated about their own competence.
02
Serve from the right tier
A fast tier for short work, a flagship tier for reasoning, a coding tier for repository-scale edits. Naming a model explicitly always overrides the router.
03
Account for every token
Counts, time-to-first-token and the routing decision are recorded per request — including when a client disconnects mid-stream, so abandoned work is not silently free.
Where it runs
NVIDIA accelerators in Amaravati, India.
Andhra Pradesh is building Amaravati as the country's AI capital. Your models run there — on hardware you can point at, under the same laws as the people using it.
Hardware in Amaravati
NVIDIA L40S accelerators in a rack in the Amaravati region of Andhra Pradesh — not a region name in a cloud console, but a machine with an address you can visit.
Your data stays in India
Inference runs on that hardware and account email goes through an Indian relay. Your text is not forwarded to a model provider abroad, because there is no provider in the path — the model is on the rack.
Content is not stored
Usage records hold token counts, latency and the routing decision — never the text. Retention is off by default, and a test asserts it by sending a marker string through and scanning every table for it.
Drop-in compatible, no lock-in
Point any OpenAI client at a new base URL. No SDK to adopt and no rewrite — which also means the same code moves back off us just as easily.
On benchmarks
We do not publish evaluation figures we have not measured. Once the pilot is serving real traffic on real hardware, throughput, time-to-first-token and routing accuracy will be published together with the methodology and the hardware they were measured on — because a number without those is not worth reading.
Start sending requests.
Create an account, get a key, point your client at it. New accounts are reviewed before access is granted.