Studio

The Studio is the web UI built into the paddock server binary. It serves from the same host and port as the API, so once the server is running there is nothing extra to install or configure.

Opening the Studio

Start the server and open its address in a browser. With the default configuration that is:

paddock --model ~/paddock/models/your-model.gguf
# then open http://localhost:11540

The UI is embedded in the server binary and served as the fallback for any path that is not an API route. It is a single-page app with real URLs, so deep links like /chat or /settings survive a refresh.

Server-Side Storage

Conversations, saved prompts, MCP server configs, and app settings live in an embedded SQLite database on the server at ~/paddock/paddock.db, not in the browser. Chats survive a cache clear, and any browser pointed at the same server sees the same history. Attachment bytes are stored server-side too and streamed back on demand.

Settings has a one-click export that downloads a sanitized copy of the database as a SQLite file. Stored API keys and MCP credentials are stripped from the export.

Chat

Chat streams over the server's OpenAI Responses API (/v1/responses), the same endpoint external clients use.

• Reasoning. Thinking models stream their reasoning into a collapsible fold that shows how long the model thought. The control adapts to the loaded model: gpt-oss takes a low/medium/high effort setting, Qwen 3.5 takes an on/off thinking toggle.
• Rendering. Replies render as Markdown with syntax-highlighted code blocks, KaTeX math, and Mermaid diagrams.
• Turn control. Stop a reply mid-stream, regenerate the last answer, or continue a reply that hit the length cap from exactly where it stopped.
• System prompts. Each chat has its own system prompt, edited in a panel that can load a preset from the saved-prompt library or save the current text as a new preset. The library itself is managed on the Prompts page.
• Context handling. A meter shows how much of the context window the conversation uses. When a chat outgrows the window, older messages are summarized in the background so the model keeps the thread; turn that off in Settings to drop the oldest messages instead.
• History. The sidebar searches chats by title and supports pin, rename, delete, and multi-select delete. Titles are set automatically from the first message.

Attachments

Images can be attached when the loaded model supports vision; the server advertises the capability, and the composer warns when the active model cannot see what you attach. PDF attachments are rasterized to page images on the server through pdfium, so they follow the same vision path. PDF support requires pdfium_lib in the server config, and the UI shows the per-document page cap.

Run Details

Every answer records exactly what produced it: the model, the system prompt, the sampling parameters, the enabled tools, and the GPU it ran on. Expanding a turn's run details shows time to first token, tokens per second, reasoning time and tokens, and the peak GPU load sampled during the turn. Regenerate a reply under different settings and the two turns keep their own records, so you can compare runs on facts instead of impressions. For engine-versus-engine comparisons, see Benchmarking.

Models

The Models page combines the curated download catalog with what is already on the machine.

• Catalog. Models are grouped by role (chat and vision, embeddings, rerankers) with a spec sheet per model: quantization, parameter count, context length, license, and vendor homepage.
• Downloads. One click pulls a model to the server's models folder with live progress. The page shows the folder location and free disk space, and refuses a download that will not fit.
• Will it fit. Each model gets a VRAM estimate checked against the detected GPU, marked as fits, tight, or too big.
• Local files. GGUF files you place in the models folder yourself are listed alongside the catalog.

The served model is chosen at startup with --model; the page tells you which downloaded model is currently loaded.

Web Search

Chat can search the web through a provider you bring your own key for: Exa or Tavily. Pick the provider and paste the key in Settings; the key is stored write-only on the server and never sent back to the browser. Each chat has a globe toggle, off by default, that lets the model issue searches for that conversation. Search calls appear in the thread as cards showing the query and the sources the provider returned, and Settings has a test button to verify the key works.

MCP Tools

The MCP page registers Model Context Protocol servers the model can call as tools.

• Transports. Local servers over stdio (command, arguments, environment) and remote servers over HTTP (URL, headers), with OAuth 2.1 sign-in for remote servers that require it. Tokens and secrets stay on the server.
• Management. Enable or disable each server, test the connection, and browse the tools it exposes.
• Approval. A per-server "require approval" mode routes every tool call through an approve or deny prompt in the chat thread before it runs.
• Per-chat toggle. Each chat has one tools switch; on lets the model use any enabled server, off gives a tool-free chat.

Tool execution happens server-side, so API clients get the same tools through /v1/responses, not just the Studio. See the MCP page for the API side.

GPU Telemetry

A live hardware dock streams GPU telemetry over a WebSocket: utilization, VRAM used and total, temperature, power draw against the limit, clocks, and fan speed, alongside engine counters such as current tokens per second, prefill or decode phase, and KV cache usage. Telemetry is sampled through NVML and degrades gracefully on machines without an NVIDIA GPU.

Settings