Until this week the inference API was free. That was deliberate: we were tuning a scheduler that places language models across GPUs that have nothing in common except a CUDA driver, and we did not want to charge anyone while we measured how it behaved under real traffic. That phase is over. Inference is now billed, and the part worth writing about is not the price list. It is when the money moves.
Every request that completes on the network settles at that moment, on its own. The caller's balance goes down by what the request cost. The owner of the GPU that produced the answer gets 80% of it, credited to their earnings in the same database transaction. The platform keeps the rest. There is no end-of-month statement that tells you what you earned; you can refresh your balance after a single request and it has already moved.
This post is for two readers. If you own a graphics card with 24 GB of memory or more, particularly an RTX 5090 or an RTX PRO 6000, the first half is about what your card earns and why we want it. If you build on the API, the second half is about the free trial, the prices, and what changes for your key.
How a request turns into money
Here is the whole path, because the details are what make "real time" true rather than a marketing word.
- A request arrives at the API and the scheduler picks a GPU for it, based on what that node has been measured to sustain. We wrote about how that choice is made in Where Does Your Inference Actually Run.
- The model on that GPU streams the answer back. When the last token is out, the request is complete, and we know three things exactly: how many tokens went in, how many came out, and which node did the work.
- One SQL statement then does all of the accounting. It records the usage (tokens in, tokens out, cost at the model's list price), debits the caller's spendable balance, credits 80% of the amount to the node owner's earnings, and credits the remaining 20% to the platform's inference account. Four rows, one transaction. Either all of them land or none do.
That last property matters more than it sounds. Because the charge and the two credits are written together, the three amounts always sum to zero. We check it. Money that leaves a caller's account arrives, in full, split exactly as published, and nothing is ever "pending reconciliation".
Images go through the identical path. A generated image is a request like any other: it completes, it settles, the owner of the GPU that rendered it gets 80%.
Eight decimals, because tokens are small
A request on Qwen 3.8 27B that reads 46 tokens and writes 30 costs $0.00005652 at the current list price. The provider's share of that is $0.00004522. The first time we settled a request like this, our money columns held four decimals, and the database did what four decimals do: it rounded the charge up to a hundredth of a cent and the payout down to zero. Money left one account and arrived nowhere.
So balances and ledger rows now carry eight decimals, and the console shows every digit that carries information. Your balance reads $9.90 until a request touches it, and then it reads $9.89994348. At the lowest price on the platform, $0.04 per million tokens, a single token is still representable.
One line per day, every request underneath
If every request wrote a visible line to your transaction history, a busy key would produce thousands of entries a day, each a fraction of a cent. That is correct and unreadable. So the history groups inference into one line per day, per account: the number of requests, the tokens, the models, the total, and your balance after the last one. The per-request rows are all still there in the ledger; they are what proves the split adds up. If you want to see requests individually, the console's History tab lists them with tokens and latency.
For providers: what your card earns, and which cards we want
A node on ParalonCloud already earns on two tracks: USDC when it is rented, by the minute, and Season 0 points for staying online. This adds a third, and it is the one that does not wait for anybody to click "rent": as long as your node is verified, online, and hosting a model, the scheduler sends it inference requests, and each one that completes pays you the moment it does.
The split is the same one we use for rentals and have published since launch: 80% to the provider, always. Earnings accumulate in the same balance as rental income and are withdrawn the same way, as USDC on Solana, or converted one-to-one into platform credits. The details are in Payouts.
Why 24 GB is the floor, and why more is better
The model that carries most of the network's traffic is Qwen 3.8 27B, a 27-billion-parameter model with vision and tool calling, served with vLLM at 32k context. We run it in a 4-bit weight, 16-bit activation quantisation, which puts the weights at roughly 15 GB. That leaves the rest of the card for the KV cache, the memory that holds every conversation currently being answered.
On a 24 GB card such as the RTX 4090, the model fits and serves well, and a 4090 is genuinely welcome. But it is the card where the KV cache is tightest, which caps how many requests it can hold in flight at once. This is where the bigger cards separate:
- RTX 5090, 32 GB. Eight more gigabytes of KV cache than a 4090 on the same model, on memory that is markedly faster. More concurrent streams, longer prompts without eviction, and more room for the batch-friendly settings we only switch on for cards with headroom, CUDA graphs among them.
- RTX PRO 6000, 96 GB. Enough to hold the 27B model with a KV cache many times what a 24 GB card can carry, or to host a larger model altogether when we add one. This is the card that turns a single node into a serious slice of the network's capacity.
Since a provider is paid per completed request, the number of requests a card can complete per hour is what its earnings scale with, and that number is set by memory more than by anything else. A card with more VRAM holds more conversations at once; the scheduler notices, because it measures what each node actually sustains, and routes more work there. The same reasoning is why we asked for 5090s and RTX PRO 6000s in Two Ways Your GPU Earns Here for rentals. It applies with more force to inference.
The minimum for hosting Qwen 3.8 is 20 GB of allocatable VRAM, which in practice means a 24 GB card. Smaller cards still earn on the smaller models (a 3B and a 4B model are in the catalogue), on rentals, and on points. The full list of what a node needs is in Hardware Requirements.
What you do not have to do
You do not pick which requests you serve, and you do not set inference prices. The catalogue price is per model and is the same on every node; the scheduler routes each request to the node best placed to answer it. You also do not need to be available at a set time. A node that goes offline simply stops receiving requests, and starts again when it is back and verified.
Connecting a card takes one command. The steps are in Add a Node.
For API users: a trial, then pay per token
If you already have a key, nothing breaks. Every existing key is now a free key with a lifetime trial of 100,000 tokens, one such key per account. The same OpenAI-compatible endpoint, the same models, the same key string.
When the trial runs out, create a premium key in the Console. It bills per token from your credit balance at the model's list price, with higher rate limits, as many keys as you want, and it is the only key type that can generate images. Top up with USDC or USDT; credits never expire and there is no minimum beyond $1. Organisations with their own arrangement get a partner key type set up for their email domain; write to us.
Today's prices, per million tokens:
| Model | Input | Output | Notes |
|---|---|---|---|
| qwen3.8-27b | $0.12 | $1.70 | vision, tool calling, 32k context |
| qwen3-3b | $0.05 | $0.20 | 16k context |
| gemma3-4b | $0.04 | $0.09 | 8k context |
| z-image-turbo | $0.003 per image |
Your balance moves with every request, and the console's Usage tab shows what each key and each model has cost you, alongside the tokens. You see the same figures your balance moved by, because they come from the same ledger rows.
The API itself has not changed. The base URL, the bearer token, and the request shapes are documented in the Inference API pages, and the vision and tool-calling setup for coding agents is in Qwen 3.8 27B Is Live.
What this does not do yet
A few honest limits, so nobody is surprised.
- Trial requests do not pay out. A request on a free key draws on that key's 100k-token trial, not on credits, so there is nothing to split. The node that served it is not paid for it. Premium traffic pays; trial traffic is our cost of letting people try the API.
- You earn what is routed to you. Per-request pay means a node with no requests earns nothing from inference that hour. The scheduler spreads work by measured capacity, so a bigger, faster, more reliable card sees more of it, but we do not guarantee a volume.
- Withdrawals have a window. Settlement is instant; moving USDC to your wallet follows the monthly withdrawal window described in Payouts. Converting earnings to platform credits is immediate.
- The transaction history is daily, not per request. By design, as above. The per-request rows exist and are used for the accounting; they are not something you scroll.
Where to start
- Own a 24 GB card or better, especially an RTX 5090 or an RTX PRO 6000: add a node and it starts receiving requests once verified.
- Build on the API: your existing key already has its trial; when it runs out, create a premium key and top up.
- Want to see the accounting yourself: make one request on a premium key, then open Transactions. The line for today is already there.
