API Behavior

This page documents how the built-in OpenAI-compatible API behaves at runtime: what routes exist, how streaming works, and why requests are queued instead of running in parallel.

Routes

IntenseRP currently exposes three OpenAI-style endpoints:

If API Keys are enabled, both routes require:

Authorization: Bearer YOUR_KEY

Dry Run Mode

Settings -> API Server -> Dry Run -> Dry Run Mode starts the API server without launching a provider browser. The display window opens immediately and waits for an incoming request.

When a chat or text completion request arrives, IntenseRP captures the raw JSON body, renders the formatted prompt through the same formatting pipeline used for real provider sends, updates the display, and returns HTTP 418 I'm a teapot. No request is queued and no provider page is touched.

Dry Run Mode applies only when services start. If a browser is already running, stop services and start again with Dry Run Mode enabled.

All parallel runtime paths are skipped in this mode, meaning you can't submit multiple requests simultaneously, and each new captured request simply replaces the previous one in the display.

Models and what they mean

The API reports provider-specific "model" IDs, but they are best thought of as behavior presets.

In normal single-provider mode, GET /v1/models follows the currently selected provider by default.

If Settings -> API Server -> Model IDs -> Use Universal Model Names is enabled, single-provider mode shows these instead:

Provider-prefixed behavior IDs still continue to work either way. Providers in Parallel still rejects intenserp-*, but it can expose UMM real-model IDs when this setting is enabled.

For GLM Chat, Google AI Studio, QwenLM, Perplexity, HuggingChat, and Xiaomi MiMo, Universal Model Names also exposes real model IDs in /v1/models. They are lowercase, with spaces and dots converted to -, and they keep the normal -auto, -reasoner, and -chat suffixes. For example, GLM-5.1 appears as glm-5-1-auto, glm-5-1-reasoner, and glm-5-1-chat.

In Providers in Parallel, only conflicting real-model IDs get provider prefixes so they can route to the right browser. For example, Google AI Studio's Gemini 3.1 Pro can appear as aistudio-gemini-3-1-pro-reasoner if another active provider also exposes gemini-3-1-pro-reasoner.

The intenserp-* IDs use the model selected in Settings. A real-model ID overrides the provider's UI model for that request, then applies the suffix behavior on top.

DeepSeek

These map to DeepSeek UI toggles:

GLM Chat

These map to GLM UI toggles:

Moonshot

Moonshot model IDs are behavior presets:

QwenLM

QwenLM model IDs are behavior presets:

Perplexity

Perplexity model IDs are behavior presets:

HuggingChat

HuggingChat model IDs are behavior presets:

HuggingChat can also accept HuggingChat-only request fields such as inference_provider, huggingchat_inference_provider, and huggingchat_thinking_effort.

Google AI Studio

Google AI Studio model IDs are also behavior presets:

Xiaomi MiMo

MiMo model IDs are behavior presets:

MiMo's web UI does not expose a thinking toggle; these modes control whether IntenseRP forwards or filters MiMo's streamed <think> text.

Request reasoning_effort

If Settings -> API Server -> Request Controls -> Accept API Reasoning Effort is enabled (it is off by default), IntenseRP also accepts OpenAI-style per-request reasoning effort fields:

{
  "model": "aistudio-auto",
  "reasoning_effort": "medium"
}

Nested reasoning.effort is accepted too, for clients that use that shape:

{
  "model": "aistudio-auto",
  "reasoning": { "effort": "medium" }
}

Top-level reasoning_effort wins if both are present.

When this compatibility setting is enabled, Reasoning Effort Providers controls where it applies. For selected providers, the resolved effort takes priority over the reasoning part of the model ID for that request. Providers left unchecked ignore the request field and keep using the model ID suffix, Provider Behavior settings, or loadout values.

For most providers, effort values are simplified into the existing reasoning toggle:

For Google AI Studio, explicit efforts are mapped to Thinking Level instead: minimum/minimal -> Minimal, low -> Low, medium -> Medium, and high/max/xhigh -> High. If no effort is sent, IntenseRP still treats that as chat/off mode because clients like SillyTavern use "Auto" by omitting the field.

For GLM-5.2, enabled efforts also select the Deep Think effort menu: medium/high -> High, and max/xhigh -> Max. Disabled and low-effort values still force Deep Think off.

Request flow (high level)

At a high level, a request goes through these layers:

1. Client calls POST /v1/chat/completions or POST /v1/completions
2. IntenseRP enqueues the request (FIFO)
3. A queue worker dequeues the request
4. The driver either formats chat messages or forwards a raw text-completion prompt, then drives the selected provider UI and intercepts its network stream
5. IntenseRP forwards the stream to the client (or accumulates it and returns a single JSON response)

sequenceDiagram
    participant C as Client
    participant A as IntenseRP API (FastAPI)
    participant Q as Request Queue
    participant D as Provider Driver (Playwright)
    participant DS as Provider Backend

    C->>A: POST /v1/chat/completions or /v1/completions
    A->>Q: enqueue (request)
    Q->>D: worker dequeues request
    D->>DS: proxied stream of provider request
    DS-->>D: SSE chunks
    D-->>A: OpenAI-style chunk(s)
    A-->>C: SSE (stream=true) or JSON (stream=false)

Concurrency and queueing

By default, IntenseRP processes one generation at a time.

• Incoming requests are put into an internal queue.
• A single worker pulls from that queue and calls the driver.
• Requests are handled in order (first in, first out).

What this means in practice:

• If multiple clients send requests at once, later requests will wait.
• If your client retries aggressively, you may unintentionally build up a queue.

Request Queue Preview (UI)

If you want to see the queue without guessing (or digging through logs), IntenseRP can show an optional panel in the main window.

Settings → Interface → Main Window → Show the Request Queue Panel

Once enabled, it shows the request currently being processed (if any), plus any waiting requests.

Each entry includes a short request ID (useful when matching things up with logs), when it was added, request type, message count or prompt length, model, streaming mode, and the API key name (if you have API keys enabled).

You can drag the divider to resize it if you don't like the default width.

At the bottom of the panel, there are 2 queue controls:

• Stop (square) - aborts the currently active request and disconnects the client
• Clear Queue (trash) - cancels all queued requests after the current one

Streaming (stream: true)

When you set stream: true, the API responds with Content-Type: text/event-stream and yields OpenAI-style SSE data: frames:

{
  "id": "chatcmpl-custom",
  "object": "chat.completion.chunk",
  "created": 1730000000,
  "model": "deepseek-auto",
  "choices": [
    { "index": 0, "delta": { "content": "Hello" }, "finish_reason": null }
  ]
}

The stream ends with:

data: [DONE]

Text completions stream shape

For POST /v1/completions, IntenseRP still streams over SSE, but the payload uses the legacy completions shape:

{
  "id": "cmpl-custom",
  "object": "text_completion",
  "created": 1730000000,
  "model": "deepseek-auto",
  "choices": [
    { "text": "Hello", "index": 0, "logprobs": null, "finish_reason": null }
  ]
}

Disconnect behavior

If a streaming client disconnects, IntenseRP will:

1. Mark the request as aborted
2. Stop forwarding chunks
3. Ask the driver to stop the generation in the active provider UI

Non-streaming (stream: false)

When you set stream: false, the server still generates via streaming internally, but it accumulates all delta.content pieces into one final response:

• choices[0].message.content is the concatenated text
• usage GLM Chat, QwenLM, and Xiaomi MiMo can populate it when Count Tokens is enabled in the provider Behavior settings

Text Completions (POST /v1/completions)

This route is the old prompt-based API shape. Instead of sending a chat transcript, you send one raw prompt, and IntenseRP forwards that prompt as-is after stripping recognized macros.

Right now, IntenseRP supports one prompt per request on this route. If a client sends multiple prompts in one /v1/completions call, the request is rejected instead of trying to fan out multiple browser generations at once.

That means the usual chat-only formatting layers are skipped here on purpose:

• No chat templates
• No injection block
• No name scanning / name substitution
• No system-message splitting tricks

On Google AI Studio specifically, this also means IntenseRP will not try to use the separate System Instructions field for text completions, even if you normally have that feature enabled for chat requests.

Errors and status codes

Common status codes:

For debugging, the fastest path is usually:

• Enable the console and/or logfiles
• Reproduce once
• Inspect the last warnings/errors

Console & Logging

Related pages

Back to Advanced

Advanced