Most LLM providers share the same checkout page: email, credit card, billing address, sometimes a KYC review. For a team that already holds Bitcoin, that page is the bottleneck — not the model.
This post walks through the workflow when the provider accepts Bitcoin directly: how a top-up becomes API calls, how search factors into the bill, and where the gotchas are.
The usual checkout
A typical LLM API signup looks like this:
- Register an account
- Add a credit card
- Wait for verification (minutes to days)
- Get an API key
- Start paying per token
If you want web search on top, the list often grows: a Tavily account, a second API key, a second billing page, a separate usage dashboard. With a provider that accepts Bitcoin, none of that exists — and there is no minimum top-up.
The Bitcoin workflow
With a provider that takes Bitcoin, the flow is different:
Hold BTC → Send to deposit address → Credits appear → API key works
There is no card. There is no KYC review. There is no separate search subscription.
Concretely, using the same OpenAI-compatible SDK as every other provider:
from openai import OpenAI
# Same SDK, same request shape
client = OpenAI(
api_key="your-easyrouterai-key",
base_url="https://easyrouterai.com/v1"
)
# Search is on by default — no separate Tavily key, no second bill
response = client.chat.completions.create(
model="deepseek-v4-flash",
messages=[{"role": "user", "content": "What changed in EU AI regulation this week?"}]
)
print(response.choices[0].message.content)
The key point: one provider, one balance, one API key. Search is included in the call, not metered as a separate service.
What the balance actually covers
| Item | Billed as |
|---|---|
| Input tokens | Per-token, by model |
| Output tokens | Per-token, by model |
| Web search | Included (always on, no separate meter) |
| Model switching | Free — change one string |
Compare that to the card-based alternative:
| Item | Separate bill? |
|---|---|
| Model tokens | Yes (provider A) |
| Web search | Yes (provider B — Tavily, Bing, etc.) |
| Gateway | Sometimes (provider C) |
Three invoices for one request. With Bitcoin, there is one balance.
The workflow, step by step
1. Create an account
Email and password. No card, no billing address.
2. Send Bitcoin to the deposit address
The provider shows a single Bitcoin deposit address. Send BTC on the network it specifies only — a wrong-network transfer is the most common way to lose funds. For Bitcoin, this is usually the Bitcoin mainnet.
3. Send the top-up
Send Bitcoin to the deposit address. The dashboard shows the transaction as pending until it has enough confirmations.
4. Credits land
Once confirmed, the balance appears in the dashboard. It is denominated in the provider’s internal credit unit, not in Bitcoin.
5. Generate an API key
One key. It works across all models and across the search layer. There is no per-service key.
6. Call the API
Same OpenAI SDK, same chat.completions.create. No extra headers for billing.
7. Monitor usage
The dashboard shows credits consumed per request: input tokens, output tokens, model used. Search does not appear as a line item because it is bundled.
Gotchas
Wrong network. A Bitcoin deposit on the wrong network is the most common way to lose funds. Send only on the network the provider specifies — for Bitcoin, that is usually the Bitcoin mainnet.
No refunds. Crypto top-ups are generally non-refundable. Start with a small amount until you trust the usage numbers.
Search is always on. If your use case never needs web context, you are still paying the bundled rate. That is the trade-off for not running a separate search service.
Balance ≠ Bitcoin. Your credit balance fluctuates with model pricing. Treat it like prepaid compute, not a bank account.
When this workflow fits
- Your team already holds Bitcoin
- You want to avoid card-based KYC and verification delays
- You need search without a second provider account
- You build in a jurisdiction where card payments are awkward
- You prefer prepaid usage over monthly invoicing
When it does not fit
- You need a formal invoice for accounting — most crypto-only providers do not issue one automatically
- You want enterprise SLA or dedicated support — that usually needs a contract, which means KYC anyway
- You need usage exported to a corporate finance system — check the dashboard’s export options first
FAQ
Which cryptocurrencies are accepted?
Bitcoin (BTC) on the network the provider lists in the dashboard. No minimum top-up required.
Is there a KYC requirement?
For standard API usage with a Bitcoin top-up, generally no. Higher-volume contract tiers may require verification.
Can I pay with a credit card instead?
Yes, the provider usually also accepts a card on file. The workflow above is the crypto-specific path.
Is search really included?
Yes. Search is always on by design, so there is no separate search meter or second API key.
What happens when the balance runs out?
Requests return an insufficient-balance error. Top up again and they resume — no key rotation needed.
How is usage priced?
Per input and output token, by model. Search is bundled. There is no separate search fee. Check the provider’s pricing page for current rates.
Can I export usage data?
The dashboard typically provides a per-request log and a downloadable summary. Exact format depends on the provider.
What this enables
A team can go from “we have Bitcoin” to “we have a working search-enabled LLM call” in under ten minutes, with no card issuer and no verification queue in between.
That is the whole point of paying in Bitcoin: remove the checkout page from the critical path.
Related
- How to Add Web Search to Any OpenAI-Compatible API
- Why “Model From China” ≠ “Search Results From China”
- Tavily Without a Second Bill