Serverless Inference

Serverless inference offers pay-per-request pricing with no idle compute cost, the right choice for low-volume or spiky traffic where reserving GPU replicas would be wasteful. The endpoints are OpenAI-compatible. Point any OpenAI client at the base URL below, swap in a Lyceum API key and a model name, and everything else, streaming, tool calling, usage accounting, works the same.

Try it

Enter a key and pick a model to send a real request from this page. It runs the same auth, credit and model checks as any client, so a green result means your key is valid, your org has credit, and the model ID resolves.

This sends one real chat completion and bills it to your org, the same as any other request. It is a few tokens.

Endpoint and authentication

The base URL for serverless inference is:

https://api.lyceum.technology/openai/v1

Authenticate with your Lyceum API key (lk_...) as a Bearer token. Most SDKs append the path for you, so you pass only the base URL above.

Method	Path	Purpose
`POST`	`/chat/completions`	Chat completions (streaming and non-streaming)
`POST`	`/embeddings`	Text embeddings
`GET`	`/models`	List the models currently available

There is no legacy text /completions endpoint. All text generation goes through /chat/completions using the messages format.

Quickstart

Python
curl

from openai import OpenAI

client = OpenAI(
    api_key="lk_...",
    base_url="https://api.lyceum.technology/openai/v1",
)

resp = client.chat.completions.create(
    model="z-ai/glm-5.2",
    messages=[{"role": "user", "content": "Explain prompt caching in one sentence."}],
)
print(resp.choices[0].message.content)

curl https://api.lyceum.technology/openai/v1/chat/completions \
  -H "Authorization: Bearer lk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "z-ai/glm-5.2",
    "messages": [{"role": "user", "content": "Explain prompt caching in one sentence."}]
  }'

Model IDs

GET /models is the authoritative list of IDs the serverless API accepts, and it reflects what is served right now. It also contains the -instant variants (same model, reasoning switched off, see Reasoning models) and the lyceum/simple, lyceum/complex and lyceum/reasoning routing aliases. Prices and context windows per model are on the models page.

Model ID	Model
`deepseek/deepseek-v4-pro-0813`	DeepSeek V4 Pro 0813
`deepseek/deepseek-v4-flash-0731`	DeepSeek V4 Flash
`deepseek/deepseek-v4.1-flash`	DeepSeek V4.1 Flash
`moonshotai/kimi-k3`	Kimi K3
`moonshotai/kimi-k2.6`	Kimi K2.6
`moonshotai/kimi-k2.7-code`	Kimi K2.7 Code
`z-ai/glm-5.3`, `z-ai/glm-5.3-instant`	GLM-5.3
`z-ai/glm-5.3-flash`, `z-ai/glm-5.3-flash-instant`	GLM-5.3 Flash
`z-ai/glm-5.2`, `z-ai/glm-5.2-instant`	GLM-5.2
`z-ai/glm-5.1`	GLM-5.1
`minimax/minimax-m3`	MiniMax M3
`minimax/minimax-m2.5`	MiniMax M2.5
`qwen/qwen3.8-2.4t-a95b`	Qwen3.8 2.4T A95B
`qwen/qwen3.8-27b`, `qwen/qwen3.8-27b-instant`	Qwen3.8 27B
`qwen/qwen3.8-flash-next`, `qwen/qwen3.8-flash-next-instant`	Qwen3.8 Flash Next
`qwen/qwen3.5-9b`	Qwen3.5 9B
`qwen/qwen3-235b-a22b-instruct-2507`	Qwen3 235B A22B Instruct
`qwen/qwen3-embedding-8b`	Qwen3 Embedding 8B (embeddings endpoint only)

A model ID that is listed but has no backend available at the moment answers 404 model not found, the same as an unknown ID. Poll GET /models or retry with backoff before treating it as permanent.

Streaming

Set stream: true to receive tokens as they are generated. This is the recommended mode for anything user-facing or long-form, it lowers time-to-first-token and keeps the connection active for the full generation.

stream = client.chat.completions.create(
    model="z-ai/glm-5.2",
    messages=[{"role": "user", "content": "Write a short story."}],
    stream=True,
)
for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

Timeouts and long-running requests

The platform allows a single request up to 300 seconds of generation time. Large context windows or long outputs on a non-streaming call can genuinely take minutes, so the most common source of “cut off” errors is a client-side timeout that fires before the response finishes, not the server.

For long outputs, stream the response. Streaming keeps data flowing over the connection, which avoids idle/read timeouts and gives you tokens as they arrive instead of waiting for the whole completion.

If you must run non-streaming for long generations, raise your client’s read timeout:

client = OpenAI(
    api_key="lk_...",
    base_url="https://api.lyceum.technology/openai/v1",
    timeout=600.0,  # seconds; default in most SDKs is 600, but some frameworks set it lower
)

Some frameworks (for example litellm) apply a separate stream inactivity timeout that aborts a stream if no new token arrives within a fixed window. Under heavy load, time-to-first-token can spike, so if you stream through such a framework, raise its inactivity timeout as well as the overall request timeout.

Request limits

Limit	Value
`max_tokens` / `max_completion_tokens`	At most 65,536 per request. Larger values are rejected with `400 field 'max_tokens' must not exceed 65536`.
Generation time	300 seconds per request, see above.
Context window	Model-specific, listed per model on the models page. A prompt that exceeds it is rejected by the backend with `400 inference request rejected`.

Function calling and tools

All chat models support function / tool calling using the standard OpenAI tools parameter: automatic tool calls, parallel calls and tool-result round-trips work on every model. tool_choice is forwarded to the backend, but not every model enforces it, see the warning below.

resp = client.chat.completions.create(
    model="z-ai/glm-5.2",
    messages=[{"role": "user", "content": "What is the weather in Berlin?"}],
    tools=[{
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get the current weather for a city",
            "parameters": {
                "type": "object",
                "properties": {"city": {"type": "string"}},
                "required": ["city"],
            },
        },
    }],
    tool_choice="auto",
)
print(resp.choices[0].message.tool_calls)

tool_choice: "required" and a named function ({"type": "function", "function": {"name": "..."}}) are currently not enforced on deepseek/deepseek-v4-pro-0813, deepseek/deepseek-v4-flash-0731 and z-ai/glm-5.3. These models can answer in plain text with no tool_calls while still reporting finish_reason: "tool_calls". In checks on 17 September 2026, tool_choice: "required" was also not enforced on deepseek/deepseek-v4.1-flash and z-ai/glm-5.2, and only some of the time on moonshotai/kimi-k2.6 and qwen/qwen3-235b-a22b-instruct-2507. moonshotai/kimi-k3, z-ai/glm-5.3-flash, minimax/minimax-m3 and qwen/qwen3.8-27b honour both forms. If your application depends on a forced tool call, check message.tool_calls and fall back when it is empty.

A small number of models prefer to answer in text rather than call a tool when tool_choice is left on "auto". On models that enforce tool_choice, set it to "required" to force a call.

Prompt caching

Prompt caching is automatic, there is nothing to enable. When consecutive requests share an identical leading prefix (for example a fixed system prompt or a large shared context), the cached portion is reused and billed at a reduced input rate. To benefit, keep the stable part of your prompt at the front and vary only the tail (the user’s latest message). Caching is best-effort, a request may or may not hit a warm cache depending on recent traffic. Cache hits are reported in the usage object:

resp = client.chat.completions.create(model="z-ai/glm-5.2", messages=[...])
print(resp.usage.prompt_tokens)                        # total input tokens
print(resp.usage.prompt_tokens_details.cached_tokens)  # portion served from cache

prompt_tokens_details is absent entirely on a cache miss rather than reporting zero, so read it defensively:

details = resp.usage.prompt_tokens_details
cached = details.cached_tokens if details else 0

Reasoning models

Several serverless models produce an explicit reasoning trace before the final answer. The trace counts toward output tokens, so set max_tokens high enough to cover both the reasoning and the visible answer. Otherwise the whole budget can be spent on reasoning and content comes back empty or truncated.

Most models return the trace in message.reasoning_content. Some backends use message.reasoning instead (observed on z-ai/glm-5.3 and, depending on the serving path, deepseek/deepseek-v4-flash-0731). Read both fields.

Controlling reasoning

The simplest switch is the top-level OpenAI parameter reasoning_effort, which Lyceum forwards to the model backend. reasoning_effort: "none" turns reasoning off on every model that supports switching. chat_template_kwargs is forwarded unchanged as well, for clients that prefer the chat-template switch; the kwarg key differs by model family (DeepSeek and Kimi: thinking, GLM and Qwen3.8: enable_thinking).

Model	Reasoning by default	How to change it
`deepseek/deepseek-v4-pro-0813`	On	Disable: `reasoning_effort: "none"` or `chat_template_kwargs: {"thinking": false}`
`deepseek/deepseek-v4-flash-0731`	On	Disable: `reasoning_effort: "none"` or `chat_template_kwargs: {"thinking": false}`
`deepseek/deepseek-v4.1-flash`	On	Disable: `reasoning_effort: "none"`
`moonshotai/kimi-k3`	On	Disable: `reasoning_effort: "none"` or `chat_template_kwargs: {"thinking": false}`
`moonshotai/kimi-k2.6`	On	Disable: `reasoning_effort: "none"` (`chat_template_kwargs: {"thinking": false}` is ignored)
`moonshotai/kimi-k2.7-code`	On	Always on: `chat_template_kwargs: {"thinking": false}` moves the reasoning into `content`, and `reasoning_effort: "none"` is ignored
`z-ai/glm-5.2`	On	Disable: `reasoning_effort: "none"`, `chat_template_kwargs: {"enable_thinking": false}`, or use `z-ai/glm-5.2-instant`
`z-ai/glm-5.3`	On	Leave on: `reasoning_effort: "none"`, `chat_template_kwargs: {"enable_thinking": false}` and `z-ai/glm-5.3-instant` currently move the reasoning into `content`, ending in a literal `</think>`
`z-ai/glm-5.3-flash`	On	Leave on: `reasoning_effort: "none"`, `chat_template_kwargs: {"enable_thinking": false}` and `z-ai/glm-5.3-flash-instant` currently move the reasoning into `content`
`qwen/qwen3.8-27b`	On	Disable: `reasoning_effort: "none"`, `chat_template_kwargs: {"enable_thinking": false}`, or use `qwen/qwen3.8-27b-instant`
`qwen/qwen3.8-flash-next`	On	Disable: `reasoning_effort: "none"`, `chat_template_kwargs: {"enable_thinking": false}`, or use `qwen/qwen3.8-flash-next-instant`
`minimax/minimax-m3`	On	Always on, cannot be disabled (`reasoning_effort: "none"` is accepted but ignored)
`qwen/qwen3.5-9b`	On	Disable: `reasoning_effort: "none"` (`chat_template_kwargs` thinking flags are ignored)
`qwen/qwen3.8-2.4t-a95b`	On	Always on, cannot be disabled (`{"thinking": false}` is accepted but ignored)

Example, disabling reasoning on a model that defaults to on:

resp = client.chat.completions.create(
    model="deepseek/deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "Summarise this in one sentence: ..."}],
    reasoning_effort="none",
)

reasoning_effort levels other than "none" are forwarded to the model verbatim and are not reliably graded. Treat reasoning as on/off, not a depth dial.
Accepted values differ per model. moonshotai/kimi-k3 accepts low, medium, high, max and none. qwen/qwen3.8-27b and qwen/qwen3.8-flash-next accept none, low, medium and xhigh, and reject high, max and minimal with 400 inference request rejected.
Top-level enable_thinking is not honored. Use reasoning_effort or chat_template_kwargs.

Instant variants

Clients that cap max_tokens and don’t render reasoning_content (GitHub Copilot, Cursor and similar BYOK setups) can end up with an empty visible answer because the whole budget goes into reasoning. For clients that cannot pass request parameters, use the -instant model IDs: z-ai/glm-5.2-instant, qwen/qwen3.8-27b-instant and qwen/qwen3.8-flash-next-instant. Same model, same pricing, answers directly without a reasoning phase. They are listed in GET /models. z-ai/glm-5.3-instant and z-ai/glm-5.3-flash-instant are listed too, but currently write their reasoning into content, so avoid them in these clients.

Image and PDF input

Some models accept images alongside text. Send them as OpenAI-style content parts: the content of a user message becomes an array with a text part and one image_url part per file. The URL can be a public https:// URL or an inline base64 data URL.

import base64

def data_url(path: str, mime: str) -> str:
    with open(path, "rb") as f:
        return f"data:{mime};base64,{base64.b64encode(f.read()).decode()}"

resp = client.chat.completions.create(
    model="moonshotai/kimi-k3",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "What is in this image?"},
            {"type": "image_url", "image_url": {"url": data_url("photo.jpg", "image/jpeg")}},
        ],
    }],
)
print(resp.choices[0].message.content)

Text-only turns can keep using a plain string for content. Images count towards the request body limit, so downscale large photos before encoding them. The dashboard playground caps the longest edge at 1568 px, which is plenty for every model listed here.

Which models accept images

Verified on 15 September 2026 against the live endpoint, with two distinct synthetic test images sent to every chat model across three sweeps. “Yes” means the model described both images correctly every time.

Model	Image input	Notes
`deepseek/deepseek-v4.1-flash`	Not currently	Image requests returned `502` on 17 September 2026 (3 of 3)
`moonshotai/kimi-k3`	Yes
`moonshotai/kimi-k2.7-code`	Yes	Also reads PDFs, see below
`moonshotai/kimi-k2.6`	Yes	Also reads PDFs, see below
`z-ai/glm-5.3-flash`	Yes	Leave reasoning on for image requests: with `reasoning_effort: "none"` the model writes its reasoning into `content` before the answer
`qwen/qwen3.8-flash-next`	Yes
`qwen/qwen3.8-27b`	Yes
`qwen/qwen3.5-9b`	Yes
`minimax/minimax-m3`	Yes	An earlier check saw it misname colours in half of the attempts; the September sweep was 6 of 6 correct. Verify on your own inputs before relying on it
`z-ai/glm-5.1`, `z-ai/glm-5.2`, `z-ai/glm-5.2-instant`	No	The request succeeds but the image is ignored. The model answers that no image was attached, or returns empty content
`z-ai/glm-5.3`, `deepseek/deepseek-v4-pro-0813`, `deepseek/deepseek-v4-flash-0731`, `qwen/qwen3.8-2.4t-a95b`, `qwen/qwen3-235b-a22b-instruct-2507`	No	Rejected with `400 inference request rejected`
`minimax/minimax-m2.5`	No	Text requests succeed, image requests fail with `502` or `429`

The dashboard playground shows a Vision chip on every model in the “Yes” rows and lets you attach, drag and drop, or paste images. Click any sent message there to get the exact request.

PDF input

moonshotai/kimi-k2.7-code and moonshotai/kimi-k2.6 also read PDFs. Send the PDF exactly like an image, as an image_url part whose URL is a data:application/pdf;base64,... data URL:

resp = client.chat.completions.create(
    model="moonshotai/kimi-k2.6",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "Summarise this document."},
            {"type": "image_url", "image_url": {"url": data_url("report.pdf", "application/pdf")}},
        ],
    }],
)

Every other model rejects a PDF part with 400 inference request rejected, including models that accept images.
The OpenAI {"type": "file", "file": {...}} content part is not supported by any backend and is rejected with 400.
Expect PDF requests to take longer than image requests; in our checks a one-page PDF took 10 to 17 seconds on the Kimi K2 models.

The playground shows a PDF chip on these two models and accepts PDFs in the attach dialog and drop zone.

Embeddings

Text embeddings use the same base URL and key:

emb = client.embeddings.create(
    model="Qwen/Qwen3-Embedding-8B",
    input="text to embed",
)
print(len(emb.data[0].embedding))

Error handling

All errors use the OpenAI-compatible shape with error.message, error.type and, where it applies, error.param:

{ "error": { "message": "model not found", "type": "not_found_error", "param": "model" } }

Lyceum does not pass upstream error text through. Errors coming from a model backend are mapped to a small set of stable messages, so match on error.message and the HTTP status:

Status	`error.message`	Meaning	What to do
400	`field 'max_tokens' must not exceed 65536`	Request validation by Lyceum	Fix the request
400 / 409 / 413 / 422	`inference request rejected`	The model backend rejected the request. Typical causes: a `reasoning_effort` value the model does not accept, an image sent to a text-only model, a prompt larger than the context window. The status code is the backend’s.	Fix the request, don’t retry unchanged
401	`not authenticated`	Invalid or missing API key	Check the key
404	`model not found`	Unknown model ID, or no backend currently serves this ID	Check `GET /models`, retry with backoff
429	`inference capacity exhausted`	Lyceum’s capacity control: no free slot for this model right now	Retry with backoff
429	`inference service temporarily rate limited`	The model backend returned 429	Retry with backoff
502	`inference service temporarily unavailable`	The model backend failed (5xx or connection error)	Retry with backoff
503	`service temporarily unavailable`	The selected backend is temporarily unavailable	Retry with backoff
504	`request timed out`	Generation exceeded the 300-second limit	Stream, or shorten the request

The same shapes are used for errors that occur mid-stream. Retry on 429, 502, 503 and 504 with backoff; treat 4xx rejections as permanent for that request.

Support references

Every response carries the headers x-cloud-trace-context and traceparent. Both contain the same 32-character trace ID (the first segment of either header). Quote that trace ID together with the timestamp in UTC when you contact support about a specific request.

Serverless vs dedicated

Use case	Pick
Low-volume or spiky traffic, pay-per-request, no infra to manage	Serverless (this page)
Steady production traffic, predictable latency, your own model	Dedicated Inference

Models and pricing

Model IDs, context windows and per-token prices for every serverless model.

Getting started

Serverless

Instances

Inference

Coding agents

Workloads

Observability

Tools

Configuration

Account

Try it

Endpoint and authentication

Quickstart

Model IDs

Streaming

Timeouts and long-running requests

Request limits

Function calling and tools

Prompt caching

Reasoning models

Controlling reasoning

Instant variants

Image and PDF input

Which models accept images

PDF input

Embeddings

Error handling

Support references

Serverless vs dedicated

Models and pricing

​Try it

​Endpoint and authentication

​Quickstart

​Model IDs

​Streaming

​Timeouts and long-running requests

​Request limits

​Function calling and tools

​Prompt caching

​Reasoning models

​Controlling reasoning

​Instant variants

​Image and PDF input

​Which models accept images

​PDF input

​Embeddings

​Error handling

​Support references

​Serverless vs dedicated

Models and pricing

Try it

Endpoint and authentication

Quickstart

Model IDs

Streaming

Timeouts and long-running requests

Request limits

Function calling and tools

Prompt caching

Reasoning models

Controlling reasoning

Instant variants

Image and PDF input

Which models accept images

PDF input

Embeddings

Error handling

Support references

Serverless vs dedicated