Choosing a model from the Lyceum model library: what to compare

Choose a model in five steps: match task and input, filter by context window, price your traffic, test your prompts, then pin the ID.

Which model in the library should I use for my feature, and what will it cost me? It comes up when a product team leaves a closed API. It also comes up when a new model lands and the old choice needs a second look. This guide shows how to choose an open model, meaning a model whose trained weights are published. It then points you to the deeper pages per model family.

Lyceum is a sovereign European AI inference provider for open-source models. Teams call models such as Kimi, GLM, DeepSeek and Qwen through one OpenAI-compatible API, billed per token, on GPUs in European data centres. OpenAI-compatible means your existing OpenAI client works once you change the base URL, the API key and the model name. Our serverless models, the ones you call per token without running a server, run in Paris and Finland. Prompts and outputs are processed, not stored, and never used for training.

Why look at open models now? Epoch AI finds that since January 2026, the most capable open-weight models have lagged frontier closed models by an average of four months. So a shortlist of open models is a real option for a product feature.

Step 1: Match models to your task and input

The task decides your shortlist before price does. Our models page lists every model with its API ID, prices, context window and processing region. Its table also shows what each model is best for and which input it accepts: text only, or text and images.

Our running example is a hypothetical document Q&A feature. Users upload a contract and ask questions about it. The feature sends text only, needs long inputs and short answers, and runs about 20,000 requests a day.

Read the "best for" column against that task:

• Coding and agents: GLM-5.3 (text only) and Kimi K3 (text and images).
• Long documents: MiniMax M3 (text and images).
• General work: Qwen3.8 27B (text and images).
• Fast, low-cost requests: GLM-5.3 Flash (text and images).

Search and retrieval is a different job. An embedding model turns text into numbers so you can find similar passages. For that step, use Qwen3 Embedding 8B, priced at $0.02 per 1M input tokens. Keep it out of the chat-model comparison.

Step 2: Filter the library by context window

The context window is the most tokens one request can hold, prompt and answer together. A token is the unit a model reads and writes, billed per million. If your longest request does not fit, the model is out, whatever it costs.

Our example sends 6,000 input tokens and gets 400 back, so every candidate fits. The difference shows up with whole contracts or long chat histories. MiniMax M3, GLM-5.3, GLM-5.3 Flash and Kimi K3 list a 1M-token context window on our models page. Qwen3.8 27B lists 256K, and Qwen3 Embedding 8B lists 32K.

Measure your longest real request, not the average one. Then keep a margin for the answer, because the answer counts toward the same window.

Step 3: Price each model on your own token mix

Model cost depends on three prices, not one. Our models page lists, per 1M tokens, an input price, a cached input price and an output price. Cached input is the repeated start of a prompt that we bill at a lower rate.

Caching works on an identical start. On GLM-5.3, when requests share an identical start, the cached part is billed at $0.26 per 1M tokens instead of $1.40. Keep the stable part of your prompt at the front. A cache hit means we still hold that start in memory, and it is best effort: likely, but not guaranteed. So plan with a range.

In the Q&A example, 5,000 of the 6,000 input tokens are the same instructions and contract text on every question about one contract. The first question on each contract cannot hit the cache and pays the full input price. We assume users ask many questions per contract and count every request as a cache hit, which is a best case. The daily cost of one model is:

uncached input tokens = input tokens - cached input tokens

daily cost = requests x (uncached input tokens x input price
                        + cached input tokens x cached price
                        + output tokens x output price) / 1,000,000

For GLM-5.3 Flash with caching, one request costs 1,000 x $0.20 + 5,000 x $0.05 + 400 x $0.50, divided by 1,000,000. That is $0.00065, and 20,000 requests make $13.00 a day. Without caching it is 6,000 x $0.20 + 400 x $0.50, so $0.0014 per request and $28.00 a day.

Here is the same calculation as a script you can rerun with your own counts:

PRICES = {  # USD per 1M tokens: input, cached input, output (models page, 26 Oct 2026)
    "z-ai/glm-5.3-flash": (0.20, 0.05, 0.50),
    "minimax/minimax-m3": (0.40, 0.10, 2.00),
    "qwen/qwen3.8-27b": (0.40, 0.10, 2.40),
    "z-ai/glm-5.3": (1.40, 0.26, 4.40),
    "moonshotai/kimi-k3": (3.00, 0.75, 15.00),
}
requests, input_tokens, cached_tokens, output_tokens = 20_000, 6_000, 5_000, 400

for model, (inp, cached, out) in PRICES.items():
    no_cache = requests * (input_tokens * inp + output_tokens * out) / 1e6
    with_cache = requests * ((input_tokens - cached_tokens) * inp
                             + cached_tokens * cached + output_tokens * out) / 1e6
    print(f"{model}: ${no_cache:.2f} without cache, ${with_cache:.2f} with cache")

Calculated example, with hypothetical traffic and list prices read from our models page on 26 October 2026:

In this calculated example, caching the repeated start cuts the daily bill by 45 to 56 percent across the five models. The input share dominates here because each request reads 6,000 tokens and writes 400. A chat feature with long answers would shift the weight to the output price.

The example leaves out answer quality, speed and how often the cache actually hits. It also leaves out the extra output tokens a model writes when it thinks before answering, which we bill like any output. Check your real share in the dashboard: Inference → Serverless → Usage shows input, output and cached tokens per model, member and API key.

A reasoning phase is thinking text some models write before the answer. It can help on hard questions, and it adds output tokens you pay for. Our Instant variants answer without a reasoning phase.

GLM-5.3 Instant is GLM-5.3 without a separate reasoning phase, at the same price. One limit applies today: its answer still starts with a short piece of reasoning text that ends with a `</think>` tag. Drop everything up to and including that tag in your code, or use GLM-5.3 with reasoning on. We are fixing it.

Step 4: Test your shortlist on your own prompts

Collect a fixed set of your own prompts and write a pass rule for each, for example "quotes the right clause". Run your two or three cheapest candidates on the set. Divide each model's cost by the number of answers that pass, and compare that figure, not the price per token. Our guide on switching to open models sets out the test order.

Step 5: Pin the model ID, then check licence and region

Pin the model ID once you choose. Retired models are no longer served: requests to their IDs return `404 model not found`. Our models page names a replacement for each retired model, so check it before each release.

A routing alias is a model ID that sends your requests to a model we choose, and we bill each request as that model. We can change the model behind an alias. Today, Lyceum Router sends every request to MiniMax M3. Two more aliases split by request type: Lyceum Simple takes light requests, and Lyceum Reasoning takes requests that need reasoning.

Use an alias when you do not want to choose and can accept that the model behind it may change. Use a fixed model ID when you need repeatable results, for example in an evaluation or a regulated workflow.

Licences differ per model, and they decide what you may ship. Kimi K3 is published under the Kimi K3 License, and GLM-5.3 Flash under MIT. Hugging Face asks you to seek out and respect a project's license before using it. Read the licence of the exact model you pick on its model card or its licence file.

Region matters as much when your customers ask where prompts go. The GLM-5.3 page says it plainly: check the model's processing region before sending data. Read the region on the page of each model you shortlist.

For the next step, read by model family:

1. Where to run Qwen models in Europe
2. Where to run DeepSeek in Europe
3. Where to run Kimi models in Europe

What changed in the library over time is in our model roster and price changes.

If your feature reads long text and writes short answers, start with the lowest-priced model that fits your context and input. Cache the start of every prompt. Create an API key in the dashboard and run your shortlist on your own prompts.