AI infrastructure
SilkLLM
One API key for every model, with the billing solved
- Role
- Creator and lead developer
- Built with
- Python
- FastAPI
- React
- TypeScript
- PostgreSQL
- Redis
- Celery
- LiteLLM
- Stripe
- Paystack
- Docker
A unified gateway to five language model providers. One endpoint, one key, one prepaid balance. Requests route to whichever model is asked for or is cheapest and healthy, and the real cost of the call is metered against the balance as it happens.
01
Why it exists
Working across model providers means an account, a key, a billing relationship, and a client library for each one, and no single view of what any of it costs. Switching providers, or falling back when one is failing, becomes a code change rather than a configuration.
The harder half is money. Reselling model access means metering a cost that is only known after the call returns, in fractions of a cent, without ever letting a balance go negative.
02
What was built
The gateway itself over five providers, with fallback chains, streaming, and per-model routing weights.
A billing system with two payment rails, one for cards internationally and one for local currency, a full ledger, and a balance that is authoritative rather than eventually consistent.
Per-key spend caps, alert thresholds, model and provider allowlists, per-minute rate ceilings, and shared budget pools for teams.
An admin console that watches provider balances and sends alerts before an upstream account runs dry, driven by a scheduled monitor rather than by a failed customer request.
Python and JavaScript client libraries, and a landing site and dashboards in React. The Python one is published on PyPI as silkllm, so reaching five providers is one install and one key.
03
Architecture
The generation path is deliberately boring and deterministic. A router resolves the model with no AI in the decision: an explicit model wins, then the named provider's highest weighted model, then the cheapest healthy one, and a model counts only if both it and its provider are enabled.
Then a pre-flight balance check against a conservative estimate, the provider call with a fallback chain behind it, and finally the cost deduction and the ledger write, in that order, so nothing is charged for a call that never happened.
Per-key controls sit in front of all of it and run before any provider is contacted: rate, scope, shared pool, key cap, then balance. Spend limits are allocations rather than advisory ceilings, so the sum of every capped key and shared budget cannot exceed the account balance. The same dollar cannot be promised twice.
04
My contribution
Creator and lead developer. The gateway, the router, the metering and ledger, the billing integrations, the admin monitoring, the dashboards, and both client libraries.
05
Engineering challenges
Concurrent spending against one balance. The deduction is conditional in the database rather than read then written in the application, so two requests arriving together cannot both pass a check that only one of them should.
Charging for streaming, where the total is not known until the stream ends.
Keeping the caller's error useful when a provider fails, which meant normalising five vendors' failure modes into one error type rather than forwarding whatever came back.
06
Result and impact
Live at getsilkllm.com, with the client library published on PyPI as silkllm and a JavaScript package alongside it.
07