The LLM API catalog: fifteen open-weight chat models on one OpenAI-compatible endpoint
An LLM API is a metered HTTP service that serves a large language model. Your application sends messages, the model returns generated text, and the host bills by the token. This page is that product's catalog on this platform. It covers fifteen open-weight chat models from ten publishers behind one OpenAI-compatible endpoint. All are billed per token out of a prepaid wallet. Each has a model page that carries the details that decide a purchase, from thinking control to the exact context window.
Last verified: 2026-09-25
Two things this page deliberately does not carry. It carries no prices. Rates render on the pricing page from the platform's own model data, the same source the metering reads, so a number here could only drift. And it carries no per-model spec tables: the catalog listing and the model pages own those. What follows is the map.
What an LLM API is
Concretely, a chat model API receives a request with a model id and a messages array. It returns a completion. The industry has largely settled on one request shape for this, the OpenAI chat-completions format. Most vendors and the major local runtimes expose servers compatible with it. That convergence is why an integration written against one host usually moves to another by changing a base URL and a model id. It is also the shape this platform's chat endpoint speaks: the standard fields, standard tool-calling shapes, streaming and non-streaming, and a Bearer key for auth.
Metering is the other half of the product. A call bills three kinds of tokens at their own rates. Input tokens are what you send. Cached input tokens are prefixes the platform has seen before, billed below fresh input. Output tokens are what the model writes. Every response reports the call's own charge in its usage object, so cost is visible per request rather than per invoice. The OpenAI-compatible API guide, named in the guides block below, walks the base-URL swap in detail.
The catalog: fifteen models from ten publishers
The families, in plain words.
Qwen, two lanes. The dense Qwen 3.8 27B is a vision-language model. Per its official card, it reads images and video, writes text, and ships with thinking on by default and controllable per request. The sparse Qwen3.6-35B-A3B is the throughput lane. It is a mixture-of-experts build tuned for agentic coding and repository-scale reasoning, also under Apache 2.0.
MiniMax M2.7. A large sparse mixture built for endurance: long coding sessions, long tool-calling chains, instruction stability over many turns. Its license stands apart in this catalog. Per the repository, the weights are free for non-commercial use under MIT-style terms. Commercial use needs MiniMax's prior written authorization.
Muse Glimmer 30B. Meta Superintelligence Lab's open agentic model. The card trains failure recovery directly into the model. When a tool call fails or returns something unexpected, it diagnoses and retries rather than halting. That is the behavior an always-on agent needs. It reads images alongside text.
Ornith 1.5, two scales. A self-improvement family. Per the release post, the model generated its own training tasks and scaffolds. It improved through reinforcement learning on its own attempts. The lineage is built from Qwen3.5 and Gemma 4. The 35B mixture and the 9B dense build are both MIT-licensed. The 9B is small enough for a single consumer card.
The September four. GLM 5.3 Flash from Z.ai is a 320 billion parameter mixture with 18 billion active per token. It takes text, images, and video into the same context. Z.ai's documentation is explicit that its thinking is forced and cannot be disabled. DeepSeek V4 Flash 0731 and DeepSeek V4 Pro are the open-weight general-availability snapshots of DeepSeek's flash and pro tiers. Per the official change log, the publisher retired the V4 Flash generation from its first-party API on September 10, 2026. It reroutes the pro name from September 14. The public weights stay public. Gemma 4 31B is Google DeepMind's dense Apache 2.0 reasoning model. It takes text and image input and has a configurable thinking mode. All four landed as serving rows on September 11, 2026, and their pricing went live with them.
Two flagships joined the list on September 25, 2026. GLM 5.3 is Z.ai's flagship itself, the big sibling of the Flash build above; DeepSeek V4.1 Flash is the successor snapshot to the 0731 lane. Both are live and both render on the public list.
The Jev decision trio. Jev fast, Jev causal, and Jev batch are decision models: choices in, scores out, on the same chat completions route as the rest of this catalog. They are live as of September 25, 2026. The classification page carries what the family is for.
Availability, stated plainly. The catalog listing on this page renders each row's current state from the platform's own model data. Every row here is live. The shared endpoint carries fifteen rows, including the two robot reasoning entries that listed on October 6. The two self-hosted Ornith lanes complete the set. Every model page states its own state exactly, and that page is the place to check before committing a workload.
Choosing by job
- Deep agentic coding and terminal work. The dense Qwen 3.8 27B and MiniMax M2.7 are the built-for-it pair in the serving set, and the DeepSeek lanes, which landed as serving rows on September 11, 2026, target the same work.
- Fast, low-cost generation at volume. The sparse routes: Qwen3.6-35B-A3B with the flash tier, GLM 5.3 Flash and DeepSeek V4 Flash 0731, all serving today.
- Agents that must survive their own mistakes. Muse Glimmer 30B, for the failure-recovery training above.
- Long-context reading. Windows in this catalog run from 100,000 tokens to the million-token class; each model page carries the exact number that governs its lane and who measured it.
- Small, contained work on small budgets. Ornith 1.5 9B: quick answers to bounded problems, cheap to meter, and the same weights run on a home machine.
- Image input. Qwen 3.8 27B, Muse Glimmer 30B, Gemma 4 31B, and GLM 5.3 Flash carry it in the serving set.
Thinking control: three patterns in one catalog
Most models in this catalog reason before they answer. How you control that differs by family in ways that affect both quality and cost.
- A per-request knob. Several lanes take a
reasoning_effortparameter with graded values. The values run from a setting that skips the reasoning pass to settings that lean into it. Send the knob and the platform translates it to whatever the model actually reads. Sending the model's native spelling yourself returns a named parameter error. - A phrase in the system prompt. Muse Glimmer's card defines its official control as a line in the system prompt. It is
Reasoning strength:with a level, not a request field. Because it is ordinary prompt text, every host that hands system messages to the model honors it. - Always on. MiniMax M2.7 takes no thinking switch on this platform's contract, and GLM 5.3 Flash's forced thinking is documented above.
The cost connection: reasoning tokens are output tokens. A model that thinks at maximum depth by default spends output budget before the answer starts. That is why the knob, when a lane has one, is also a cost control. Each model page documents its own control exactly.
What a call costs here
No numbers on this page; the mechanism is the content. Every call meters input, cached input, and output tokens at the platform's rates and returns the charge in the response. A workload's cost is observable as it runs. The spend limit is structural. Calls draw from a prepaid wallet, and a call that arrives after the balance is gone is refused instead of going into debt. There are no trial credits to expire. A refill is what restarts the meter. Keys are revocation boundaries: an exposed key is disabled on its own, without touching the rest. Current rates for every serving row sit on the pricing page. How to avoid API bill shock, one of the guides named below, covers the habits that keep a metered workload predictable.
Running the weights yourself
Every model here is open-weight. The honest page has to include the local option. The licenses mostly encourage it. Most of these families ship under Apache 2.0 or MIT. The MiniMax license terms above are the one commercial-use checkpoint. The real constraints are hardware and time. A 9B dense model runs on a single consumer card. A 30B dense model wants the high-memory class. The large mixtures want either serious VRAM or aggressive quantization, at real quality cost on some families.
Run the weights locally when the machine exists and traffic is steady enough to justify the hardware. Run them locally when the data cannot leave machines you govern, or fine-tuning is the goal. Use a hosted lane when calls arrive in bursts or only now and then. Use it when the thought of owning runtime pins and quant picks is worse than a meter, or when the metering, the wallet stop, and key revocation are the point. The guide Ornith 1.5 locally (Ollama/GGUF) vs the hosted API, linked in the guides block, works one family's math end to end.
Getting started
- Get access through the invite flow on the console. The platform is in invite-only beta; once the invite lands, the wallet and API keys are managed on the console.
- Create an API key. A key is its own revocation boundary, so splitting projects across keys keeps a leak contained to one of them.
- Pick a lane and make the first call. Open the model page for the job you have in mind and copy its curl tab; the examples run as written with your key exported. The models index maps the whole platform, including the speech, embedding, rerank, parsing, and image generation lanes beyond this page.