teamToken vs LiteLLM: when to run the proxy yourself and when not to
Start with the disclosure that shapes this whole page: teamToken runs on LiteLLM. It is our gateway underneath, and we are not going to argue that a library we depend on is the wrong choice. The real question is not which is better but whether you want to operate the thing yourself.
What you are actually choosing between
LiteLLM is software. You deploy it, point it at your own provider accounts, keep it updated, watch its database, and it gives you one OpenAI-shaped endpoint across a hundred providers with no markup on top, because there is no one in the middle to take one.
We are that same software, already running, with the provider accounts already opened and paid for. You get a key instead of a deployment. The markup pays for the operating, and that is the entire trade.
| LiteLLM, self-hosted | teamToken | |
|---|---|---|
| Who runs it | you | we do |
| Provider accounts | yours, opened separately | included |
| Markup on inference | none | yes, not published as a figure |
| Time to first call | a deployment | a top-up |
| Media generation | not part of the project | 51 models, per second and per image |
| Payment from Russia | you solve it yourself | card, SBP, crypto from $1 |
| Spend caps and analytics | configurable, yours to wire | per key, out of the box |
The one thing self-hosting cannot give you
Media generation. LiteLLM routes language models; video and image generation are outside what the project does. Ours sit on the same key, from $0.0067 a second of video and $0.02 an image, with prices on public pages rather than behind a login.
If your product needs both, self-hosting LiteLLM still leaves you shopping for a media API, opening a second account and reconciling a second invoice.
The other one: provider accounts
A self-hosted proxy is only as good as the keys you feed it. That means an account with each provider, each with its own billing, verification and regional rules. For teams outside the countries those providers serve directly, this is where self-hosting usually stops, and no amount of proxy configuration fixes it.
Switching either way
Because both speak the same dialect, moving costs one line in each direction. Point your client at us:
base_url = "https://api.teamtoken.store/v1"And if you later decide to run your own proxy, the same code points at your LiteLLM instance with no rewrite. We would rather say that plainly than pretend there is a lock-in here; there is not, and a claim to the contrary would be checked in five minutes.
Questions we get
/v1/images/generations and /v1/videos on the same key as text.When LiteLLM is the better call
If you already hold provider accounts, self-hosting is straightforwardly cheaper. You pay the providers directly and nobody takes a cut in between, which over a large volume is a number worth caring about.
If you need control, it is not close. A hundred-plus providers, your own routing rules, your own logs on your own machines, model configuration in a file you own. Anything with compliance requirements about where requests and logs live points the same way: run it yourself.
And the project is genuinely good. We know this better than most, because our gateway is built on it and has been for a while. If the operating side is not a problem for your team, the honest recommendation is to take the library and skip the middleman entirely.