ReadyServer LLM API Bundles No-Cost Inference Into Every VPS. The Catch Is the Queue
The Singapore host ships an OpenAI-compatible endpoint with every server, with no keys and no token bill. Its fair-share model is generous, best-effort, and silent on what happens to the data.
Ready Server, a Singapore virtual-private-server host, has launched the ReadyServer LLM API, an OpenAI-compatible inference service included with every ReadyServer VPS at no additional cost. There are no API keys to create and no per-token billing. The service runs two open-weight Qwen models, served with vLLM, and is reachable only from inside Ready Server’s private network rather than from the public internet. The company says the launch responds to a cost problem: as applications move from simple chat prompts to autonomous agents, inference bills climb, and Gartner projects that AI inference costs per agentic workflow will rise more than fivefold through 2028.
The offer is unusual, and the detail is where it gets interesting. Bundling no-cost inference into a hosting plan is a commercial bet, and Ready Server is explicit that the capacity is shared and the service is best-effort: when it is busy, requests are queued, and customers who have used fewer tokens go first. That design is what makes the price possible. It also defines what the API is and is not good for, and it leaves open a question the release does not answer: what happens to the prompts once they reach Ready Server’s servers.
What Ready Server launched
The ReadyServer LLM API is an inference endpoint that follows the OpenAI API format, so most OpenAI clients work once the base URL changes. It also exposes an Anthropic Messages API-compatible endpoint, so tools built for Claude’s software development kits can point at the same models. At launch it serves two models: qwen3.6-27b, which answers directly and takes a 131,072-token context, and qwen3.8-27b, a reasoning model with a 262,144-token context that thinks before it answers, with adjustable reasoning effort. Both accept text and images and support tool calling and structured JSON output. Chat completions, legacy text completions and the models list get support; embeddings are not, and the OpenAI Responses API is in preview.
The network controls the access rather than a key doing it. The endpoint resolves to a private address and is reachable only from a ReadyServer VPS, so there is nothing to create, rotate or leak. Requests travel from the customer’s server to Ready Server’s inference servers over the company’s private network rather than the public internet. It is available now to all ReadyServer VPS customers at no extra cost, alongside the host’s existing per-hour point-based billing, unmetered bandwidth and data centres in Singapore, Hong Kong and Tokyo.
Why no-cost inference is possible
The economics of giving away GPU inference are the first thing to examine. Running a 27-billion-parameter model in FP8 requires real accelerator capacity, and managed providers charge for it per token precisely because it costs money. Ready Server’s answer is that it does not meter usage at all: instead, all customers share a pool of inference capacity, and a fair-share policy decides who is served when. The API is a feature of the VPS rather than a product with its own bill, so the cost is carried by the hosting plan and absorbed by the assumption that most customers will use it lightly and intermittently.
That is a coherent model for its target user: a developer or small agency running periodic jobs, a chatbot, or a retrieval pipeline next to the application it already hosts, where a modest and unpredictable amount of inference is enough. It is not a model built for guaranteed throughput, and Ready Server does not pretend otherwise.
Gartner’s framing sharpens the point. In its August 2026 forecast, the firm described an inference paradox: token prices are falling, but the total cost of AI is rising, because agentic workflows consume far more, and more expensive, tokens than chatbots. Gartner’s own advice for high-cost agentic tasks is to run them on open-weight models whose serving capacity you control, which it estimates can cut much of the remaining agentic bill. Ready Server’s offer sits inside that logic, with one difference: the customer controls neither the models nor the capacity, only the access.
The fair-share trade-off
The fair-use policy is unusually frank, and it is the most important document in the launch. When the service is busy, requests are queued, and customers who have used fewer tokens are served first. The policy tells users to set a maximum token limit, to stream responses, to limit parallel requests, to cache results, and not to retry requests that are merely slow, because retries add to the queue. It prohibits reselling access, exposing the endpoint through a public proxy, and running load tests or benchmarks designed to saturate the service. Repeated or serious misuse can lead to suspension.
Read together, those rules describe a best-effort service with no throughput guarantee and no service-level agreement. That is a reasonable design for the use cases named, but it rules out the ones where latency is the point. A customer-support bot that must answer in under a second, or an agent that fans out to hundreds of calls in a burst, cannot rely on a queue that deprioritises heavy users.
The trade-off is explicit: you pay nothing per token, and in exchange you accept that someone else may be served first. For a team weighing this against a metered API, that is the decision, and it is a good one only if the workload tolerates waiting. None of that is a flaw; it is a design. The question for a buyer is simply whether the job can wait. A nightly batch job or an internal tool can. Anything a user is sitting in front of usually cannot.
Private network is not the same as private data
The launch leans on the word private, and it is worth separating two things it can mean. What Ready Server documents is private transit: requests do not cross the public internet, and the endpoint is not reachable from outside its network. That is a genuine and useful property, and it reduces exposure compared with calling a public API over the open internet.
It is not the same as private data handling. The prompts still reach Ready Server’s servers, so the questions that matter for sensitive workloads are about what happens there: whether inputs and outputs are logged, how long they are retained, whether they are used for any other purpose, and where the inference servers and their storage sit. The release does not address any of this, and the documentation points to a separate page on data handling rather than stating the terms in the announcement. For a developer considering the service for anything confidential, those answers are the ones to obtain in writing before the word private does any work.
The alternatives
The inference market Ready Server is entering is crowded and cheap. Managed per-token providers such as Together AI, Fireworks, Groq and DeepInfra serve the same class of open-weight models, usually with published prices, latency figures and support; some offer free tiers. Self-hosting with vLLM on a rented GPU gives full control and predictable cost but bills for idle hardware. Aggregators such as OpenRouter route across many providers from one key.
Providers’ published prices show how affordable managed AI has become: they serve comparable open-weight models for fractions of a cent to a few dollars per million tokens, and several offer free tiers. Ready Server does not compete on raw performance or price per token; instead, it offers teams already using its VPS zero marginal cost and eliminates the need to manage API keys. The market guidance is instructive: managed APIs are usually the cheaper and simpler choice below a few hundred million tokens a month, while self-hosting pays off only at high, sustained volume with engineering staff.
Ready Server targets the band below that, where a metered bill is unwelcome but a dedicated GPU is overkill, and offers a third option: someone else’s capacity, shared. For a team already paying for a ReadyServer VPS, the marginal decision is easy, because the endpoint is simply there; the sensible move is to test it against a metered provider on the workloads that can wait, and keep the metered provider for the ones that cannot.
What buyers should ask
For a team considering it, the questions are specific. What is the API’s actual throughput and availability, and is any of it having a commitment? What are the data-handling terms for prompts and outputs, and can they be provided in writing? How does it calculate fair-share priority, and how does the service behave under sustaining load? Which models will add, and under what licences? Is there any path to dedicated or guaranteed capacity if the workload grows? And what is the VPS itself costing, since the inference is bundling into that price rather than free in absolute terms?
What it signals
The launch is a small but telling bet on where inference costs are heading. Gartner argues that although token prices are falling, AI’s total cost is rising because agents consume far more tokens than chatbots. It recommends running high-cost agentic tasks on open-weight models whose serving capacity enterprises control. Ready Server is selling a version of that idea without the ownership: open-weight models, served on capacity you share rather than own. It is a sensible offer for its niche. Whether it holds depends on two things the announcement leaves open, how the shared capacity behaves under load and what happens to the data, and both are answerable in a conversation rather than a press release.