Mercury CLI · Providers and sign-in

Mercury routes a session’s model to the provider that owns its identifier. Each provider has its own API, credentials and refusals.

Provider access

OpenAI: A ChatGPT subscription sign-in or an API key.
Anthropic: One Anthropic row on /logins (in the chat card and on the first-run sign-in screen alike) with Anthropic Console (browser sign-in, which mints an API key, awaits its save and never reuses a closed flow) and an Anthropic API key for usage-based billing (masked paste, checked against GET /v1/models?limit=1 before saving, prompting for the workspace ID from Console → Settings → Workspaces when the key is organisation-scoped so every Messages, token-counting and catalogue request carries anthropic-workspace-id, and reporting a refused key in the field without storing it). Switching between saved Anthropic account slots ([s]) applies to new requests only: a turn or crewmate in flight keeps the credential it started with and recovers by re-resolving without failing on a 401.
OpenRouter: One credential for the whole catalogue, by OAuth or an API key. The OpenRouter routing policy row in /config chooses strict, balanced or open routing; balanced is on from the start, with data collection denied, every request parameter required, fallbacks on and zero data retention off. The routing.openrouter.* settings hold the same choices.
Google: Sign in with Google to use your account’s plan quota, or use an API key or your own OAuth client through six guided steps to bill a Google Cloud project. The key resolver takes GOOGLE_API_KEY before GEMINI_API_KEY.
Hugging Face: A device-code sign-in (/logins huggingface, requesting openid profile inference-api write-endpoints for identity, Inference Providers calls and Inference Endpoints management) or a stored Hub token (HF_TOKEN takes precedence).
Moonshot: A device-code sign-in or an API key.
Z.AI: A GLM Coding Plan subscription key or a general pay-as-you-go API key, through /logins zai or ZAI_API_KEY. A key stored through /logins zai carries the plan it was checked under; a key supplied through ZAI_API_KEY or a key command uses the plan ZAI_KEY_PLAN names (coding or general), and when ZAI_KEY_PLAN is unset Mercury learns the plan once per process from the key’s models list (checking the general base https://api.z.ai/api/paas/v4 first, then the GLM Coding Plan base https://api.z.ai/api/coding/paas/v4) and corrects it if a chat refusal names the other plan.
DeepSeek: An API key from the DeepSeek platform, through /logins deepseek or DEEPSEEK_API_KEY.
xAI: A Grok subscription sign-in (SuperGrok or X Premium), or an API key, through /logins xai. XAI_API_KEY and XAI_MANAGEMENT_API_KEY pin the keys from the environment, and /logins xai adds the management key after the inference key.
Meta: Sign in with Meta (a Muse Code subscription, a device code in your browser) or a pay-as-you-go Model API key, through /logins meta, /logins muse, MODEL_API_KEY or META_API_KEY. Sign in with Meta exchanges the device code against Meta’s OIDC endpoints (auth.meta.com/oidc/device/authorization/ and /oidc/device/token/) under Muse Code’s public client id, sends the resulting account token once to api.meta.ai/muse-code/key to mint the subscription’s API key (and on bounded /usage reads for the plan’s tier and usage windows), and sends only the minted key on every model request to api.meta.ai/v1. A pasted Model API key or MODEL_API_KEY / META_API_KEY bills pay-as-you-go.
Mistral: An API key, through /logins mistral or MISTRAL_API_KEY. The picker lists the account’s own models (with recorded rows including mistral-large-4, mistral-medium-3-5, mistral-small-2603, mistral-large-2512, the three Ministral 3 sizes, codestral-2508, and Z.ai zai-glm-5-3 and zai-glm-5-3-flash at 1M-token context with low, high and max effort on zai-glm-5-3), and an Admin API key added beside the key (/logins mistral after the inference key, or MISTRAL_ADMIN_API_KEY) turns on the organisation usage meter.
Nous Portal: Sign in with your Nous Portal account (an OAuth device-code approval in your browser) or paste an API key made at portal.nousresearch.com, through /logins nous or NOUS_API_KEY, for the Portal’s model gateway, which serves models from several companies under the Portal’s own identifiers (nous/<vendor>/<model>). /usage shows the Portal’s plan and usable credits, and /accounts shows and removes the sign-in or stored key.
OpenCode Zen: An API key from opencode.ai/console, through /logins zen (opencode) or OPENCODE_API_KEY. The gateway’s models run as zen/<id> across its chat-completions shape (including Mistral Large 4 with a 524,288-token window) and its Responses shape (including GPT, Grok, Muse Spark and Muse Wonder rows), and /usage shows the session’s spend and an OpenCode Go plan’s windows.
MiniMax: An API key (a pay-as-you-go Open Platform key or an M Plan Subscription Key) through /logins minimax or MINIMAX_API_KEY, checked on GET /v1/models before it is stored. Runs M-series text models (MiniMax-M3, MiniMax-M3.1-Flash with 1M-token context, image input, $0.15 input / $0.015 cached / $0.60 output per million tokens and tunable low through max effort, MiniMax-M3.1-Flash-Preview on the M Plan, and MiniMax-M2.7; bare word minimax) with reasoning_split: true and per-model thinking controls; /usage shows session spend and, for an M Plan key, the plan’s 5-hour and weekly windows per model. A pay-as-you-go Open Platform key stored through /logins minimax also serves named videoProvider.<name> generators (kind set to minimax, model set to MiniMax-H3 or MiniMax-H3-Max, optional baseUrl defaulting to api.minimax.io over HTTPS) configured in user or project settings for the Video tool.
Together AI: An API key through /logins together, TOGETHER_API_KEY or TOGETHER_AI_API_KEY, checked on GET /v1/models before it is stored. Serves a live catalogue of open-weights chat models under together/<org>/<model> (bare word together) with prompt_cache_key session affinity, model-specific reasoning controls, and recorded vision flags and prices (including GLM 5.3 Flash, DeepSeek V4.1 Flash, DeepSeek V4.1 Flash 1017, Qwen3.8 2.4T, Qwen3.8 Flash, Qwen3.7 Max, Qwen3.7 Plus, Qwen3.6 Plus, Qwen3.5 9B, Qwen3.5 397B-A17B, MiniMax M3.1 Flash, Muse Spark Open 816B, Muse Glimmer 30B, Inkling, Ternary Bonsai 27B and Tev1 4B Experimental).
Cohere: An API key through /logins cohere, COHERE_API_KEY or CO_API_KEY, checked on GET /compatibility/v1/models before it is stored. Runs Command, North and Aya chat models (command-*, north-*, c4ai-aya-*, tiny-aya-*; bare word cohere) with structured JSON output and reasoning_effort (high or none) on reasoning rows.
Groq: An API key from console.groq.com/keys, through /logins groq or GROQ_API_KEY. Live text models use qualified ids such as groq/openai/gpt-oss-120b (bare word groq), with per-model reasoning format and effort and observed rate limits in /usage.
Cerebras: An API key from cloud.cerebras.ai, through /logins cerebras or CEREBRAS_API_KEY. Live text models use qualified ids such as cerebras/gpt-oss-120b (bare word cerebras), with reasoning effort and a stable conversation cache key.
Fireworks AI: An API key from app.fireworks.ai/api-keys, through /logins fireworks or FIREWORKS_API_KEY. Live text models use qualified fireworks/<model-id> resource ids (including short aliases such as fireworks/kimi-k3, fireworks/accounts/fireworks/models/minimax-m3p1-flash with 1,040,000 context and image input, muse-spark-open, deepseek-v4p1-flash-1017, and the image-capable Fire Pass router fireworks/kimi-fast-latest; bare word fireworks), with top-level reasoning effort, session-affinity prompt caching and observed TPM limits in /usage.
Melious AI: An API key from melious.ai/account/api/keys (with inference.models and inference.chat scopes), through /logins melious or MELIOUS_API_KEY. Live chat models run as melious/<model-id>, including :speed, :price, :eco and :batch routing variants (balanced by default), with reasoning effort (including max) and EUR request costs and limits in /usage.
OrcaRouter: A device-code sign-in or an API key from orcarouter.ai/console/token, through /logins orcarouter or ORCAROUTER_API_KEY. Models run as orcarouter/<vendor>/<model> or orcarouter/<alias> (and named routers as orcarouter/orcarouter/<name>, including orcarouter/orcarouter/auto), with reasoning effort, session affinity and per-request cost reporting in /usage.
Qwen: A QwenCloud API key (qwencloud.com: Token Plan or pay-as-you-go) or an Alibaba Cloud Model Studio API key (modelstudio.alibabacloud.com: pay-as-you-go, Token Plan or Coding Plan), connected through /logins qwen or DASHSCOPE_API_KEY. Each key is checked on its own endpoint before it is stored: a key beginning sk-sp- probes the QwenCloud Token Plan endpoint (token-plan.maas.qwencloudapi.com/compatible-mode/v1) and the Model Studio Coding Plan endpoints (coding-intl.dashscope.aliyuncs.com/v1, then coding.dashscope.aliyuncs.com/v1), while any other key probes the QwenCloud pay-as-you-go endpoint (maas.qwencloudapi.com/compatible-mode/v1) and the Model Studio regional and Token Plan endpoints (International Singapore, China Beijing, China Hong Kong, and the Token Plan in Singapore and Beijing; DASHSCOPE_BASE_URL pins an endpoint directly and DASHSCOPE_WORKSPACE_ID adds workspace-dedicated domains). Qwen’s status and /model rows name the console a key belongs to (QwenCloud or Model Studio) from the endpoint that accepted it, or both while none has. A plan key lists the plan’s documented models with Qwen3.8 Max first and the plan’s Auto row (qwen-auto, sent as auto), and a pay-as-you-go endpoint merges its live text model list with dated pins (sending a pinned id absent from the live list for the bound endpoint’s console to decide). The family word qwen runs Qwen3.8 Max wherever it is a row, and requests send enable_thinking, preserve_thinking, reasoning_effort (low, medium, xhigh) on the Qwen3.8 rows, or thinking_budget from models.<id>.thinkingBudget.
Local servers: No sign-in. A discovered server, such as Ollama, LM Studio, vLLM or llama.cpp, is served at each model’s own base URL, or with an optional key in MERCURY_LOCAL_API_KEY.
Custom endpoints: Configured under compatProvider.<name> in user, launch or managed-policy settings (baseUrl, label, keyCommand, models, headers, sessionAffinityHeader, and dialect: chat-completions, responses, ollama, lmstudio, vllm, sglang or llamacpp), or registered through /llmhost and mercury host (compat/pod-<id>/<model>, compat/box-<name>/<model> or compat/<name>/<model>). /logins compat/<name> stores a key for that endpoint alone, MERCURY_COMPAT_<NAME>_API_KEY overrides it from the environment, and models run as compat/<name>/<id> (a single default endpoint uses compat/<id> and honours MERCURY_COMPAT_API_KEY, MERCURY_COMPAT_BASE_URL, MERCURY_COMPAT_LABEL and MERCURY_COMPAT_MODELS). Custom compat/ endpoints using the responses dialect send the session’s prompt_cache_key in /v1/responses requests. Keyless named endpoints (compat/<name>/<model>) work as the default model for new and /clear sessions.

A claude.ai or ChatGPT sign-in is checked once when Mercury opens and whenever /health runs: a sign-in past its expiry is renewed through its refresh grant, and one the provider refuses shows as <Family> sign-in expired on the boot screen's Logins row and in /health before a first prompt is sent. A prompt that still meets an expired sign-in is not lost: the error line paints, its words come back to the composer, and they are sent again on their own once /logins lands a credential (or /model moves the session to a signed-in family) while the composer holds them unchanged.

Local model servers

/localsetup pulls a GGUF from Hugging Face into the Bank, starts a GGUF already in the Bank, or sets up Ollama and connects to running servers, with nothing pre-chosen (Esc keeps your current model and stops only a server the dialog started):

Hugging Face (/localsetup → Hugging Face, or /localsetup author/model-GGUF directly): Lists each complete GGUF quantisation (split GGUF files grouped as one choice) with its download size and projected memory for the largest fitting 32k, 64k, 128k or 256k window (never above the model’s trained maximum, calculated from the GGUF header’s attention geometry and any mmproj vision projector weights; a file without enough header information cannot be started here). After you choose the quantisation and any mmproj projector, /localsetup asks before downloading into the Bank (~/mercury-model-bank when no Bank folder is configured yet), resumes interrupted downloads, checks file sizes and SHA-256 hashes against the repository manifest (using your /logins huggingface sign-in for gated repositories), shows the llama-server command and memory requirement (using Mercury’s locally built llama.cpp engine when present, then llama-server on PATH or Homebrew, and passing --spec-type draft-mtp when the model carries NextN/MTP tensors), checks available memory before loading, starts llama-server on 127.0.0.1:8080 as the local-gguf project service, selects local/<GGUF filename without .gguf> and checks a short reply.
Bank (/localsetup → Bank): Lists GGUF models registered by Bank downloads, hashes the files again before starting, and runs the same llama-server setup without downloading. /llmhost shares the same Bank.
Ollama or a running server (/localsetup → Ollama / running server): Discovers Ollama, LM Studio, vLLM or llama.cpp, finds or installs and starts Ollama when needed, lists the server’s existing models alongside the Qwen 3.5 family and the MoE coding tag qwen3.6:35b-a3b-coding sized against your machine’s memory (on a Linux or Windows machine with a discrete graphics card reading the card’s own memory from nvidia-smi, rocm-smi or Ollama’s Windows server.log, and asking which model to use when LM Studio, vLLM or llama.cpp lists more than one), pulls the chosen model with live progress, sets its window from cache geometry and available memory, selects it and checks a reply.

MERCURY_LOCAL_PROBE_TARGETS controls discovery (none disables it; without a custom probe list, Mercury remembers servers started by the GGUF dialog). Wherever local models are named and no local server answers, the same setup option appears: the model picker’s LOCAL section (where s opens the dialog), the home screen, the /config Local row and the /usage local block. Selecting the last row on the first-run sign-in screen opens the model picker on the home screen when a local server has a model. The server runs on after Mercury exits.

A Local Server page under /config shows the server’s settings (models kept loaded, parallel slots, keep-alive, context length) beside what it is running with and how it was launched; the values live under local.server in settings. A change is applied only after a review of the exact lines and the restart, and a choice that would not fit the machine is refused with the memory figures.

On a machine with less than 16 GiB of memory, a manually selected local window that fits but leaves little memory gets a warning and a smaller-window suggestion. The warning applies when less than a tenth of usable memory, or less than 1 GiB, would remain. Auto still chooses the largest window that fits.

Mercury waits for a local model while its server answers. The status row says when the first byte is expected, from the model’s size and the measured pace, extends the wait while the server still answers, says when the server has stopped answering, and a request is capped at two hours. Switching to a local Ollama model loads it and ingests its prompt before your first word and keeps it warm across a pause. An already loaded model is reused when its served window fits the chosen setting; changing that window can require a reload. A request to a local model carries only the tools the model needs; the rest stay a search away. When a local model writes a tool call as text markup (<tool_call>, <arg_key>/<arg_value>, call:name{…} or [TOOL_CALLS]name[ARGS]{…}), Mercury runs the tool while leaving partial, malformed or quoted shapes as text, and preserves the local server’s prompt cache across tool steps. When a local model’s server declares no native tool support, Mercury renders the tool catalogue into the system text as JSON, reads <tool_call> blocks holding {name, arguments} through the local markup readers, and returns results as <tool_result> blocks.

Run or connect a model: `/llmhost` and `mercury host`

Open /llmhost in the foreground chat. Its popup opens on Which model? with 32 shipped models across 78 recipes (assets/host/recipes.json version 2, with 32 weight manifests in assets/host/weights.json), a live Hugging Face search line (model name, e.g. deepseek, qwen, glm), and mouse-wheel scrolling that moves the selected popup row one notch at a time while keeping the chat behind it still. /model also includes searchable run it → /llmhost actions (run it on this Mac → when a model fits a local Mac) that open the chosen model’s screen directly, and opening /model or /llmhost on a read-only configuration directory ignores EACCES, EPERM and EROFS when creating the host state directory so the picker opens cleanly.

On Which model?, Machines I'm paying for and Vendor keys sit at the top above MODELS. The cursor opens on the cheapest in-stock model (or a running or local-fitting model when one exists), and MODELS sorts rows by where they can run right now: already running on your machine, fits one of your saved computers, in stock at the lowest hourly price across connected providers, then out of stock or unconnected, followed by lowest hourly price and model name. Below MODELS, Which model? includes My computers, Bank · your weights, Refresh stock and prices, and More options → (Rent a GPU (Runpod, Vast.ai, Lambda, Hugging Face, Hyperstack, Verda, DigitalOcean), A box I can reach by SSH, A server that's already running, One of my computers, Bank · your weights, and Private recipes · none · choose a file →). Selecting Private recipes from More options → or a private model screen opens Which private recipes file? (Private recipes · <path> · <N> rows · replaces the shipped list): enter an absolute path (using the saved path in <config>/host/recipes-file.json, MERCURY_HOST_RECIPES_FILE or <config>/host/private-recipes.json in that precedence order), validate the JSON and recipe fields, preview the models before Use this file, and save the choice in <config>/host/recipes-file.json so Which model? refreshes immediately with private tags. Every connection path reads the served models and context windows, checks a reply, and registers the provider for /model and /logins.

Typing on Which model? filters the MODELS list immediately, and after 3 characters and 450 ms queries Hugging Face (pipeline_tag=text-generation, sort=downloads, up to 20 results under HUGGING FACE · <N> results, showing the repository, parameter count, format, download count, licence, and restricted status in words). Selecting a Hugging Face row reads its paginated file tree at one revision and config.json (proactively refreshing an expired /logins huggingface OAuth token and retrying Hub requests once on HTTP 401, or using HF_TOKEN), checks GGUF shard headers via HTTP range requests against the 163 architectures, 314 tensor names and 35 supported ggml tensor types of the prebuilt llama.cpp engine (assets/host/llamacpp-engine.json at llama.cpp 184f6536, which also records the container image digest and CUDA architectures 100;103;120) along with tensor dimensions (up to 4), multi-shard split.count, split.no and split.tensors.count consistency and duplicate tensor names, and checks safetensors quant_method values against vLLM’s supported quantisations (refusing unknown GGUF architectures, tensor families or tensor types, invalid shard splits, EXL2/EXL3, and unsupported quantisations before any rental or watch). It then derives an in-session recipe: llama.cpp for complete GGUF quant shard sets (preferring Q4_K_M or the 4-bit family, 4 parallel slots, retaining the repository’s declared context window) or vLLM for safetensors (vllm/vllm-openai:v0.32.0, CUDA 13.0, --max-model-len from config.max_position_embeddings), sized with a 1.2× memory margin across 1, 2, 4 or 8 GPUs (H100 80 GB, H200 141 GB, B200 180 GB, B300 288 GB).

Selecting a shipped or derived model opens its screen with the selected values and actions:

QUALITY: The recipe’s quantization or precision variants (such as 4-bit GGUF, NVFP4, FP8, MXFP8 or BF16), the required GPU count and memory, the lowest current hourly price, and the context window (Choose quality → switches variants).
CONVERSATIONS × CONTEXT: How the GPU-memory token budget splits across parallel conversations (for example 4 conversations × 131,072 tokens).
THINKING: The default reasoning level, which you can adjust per request at any time with /effort.
WEIGHTS: The download size from Hugging Face, local bank status (banked ✓ on <folder> or not banked), kept Runpod or Vast.ai volume readiness, and saved first-boot upload settings.

Below those four lines are the actions: switch to a machine already running at no extra cost, rent an in-stock GPU across all seven providers (Runpod, Vast.ai, Lambda, Hugging Face, Hyperstack, Verda and DigitalOcean) sorted cheapest first (with datacenter, community host or host tags on Vast.ai rows and confirmations, sorting Vast.ai machines with recorded tunnel link drops under <config>/host/reliability/ below unaffected machines while keeping them selectable), start on a fitting computer you own, open the Bank screen, Watch stock or No stock · watch, Replace key / Remove key controls for connected API-key providers (Sign out with /logins huggingface for Hugging Face), Connect <vendor> → rows for unconfigured providers, Choose quality →, and Private recipes.

The Bank screen (`Bank · your weights`) and kept weights volumes

Open Bank · your weights from Which model?, More options → or a model screen without needing a GPU provider key until mirroring or deleting a volume. Mercury discovers or asks for a bank folder (<config>/host/bank.json, ~/mercury-model-bank, ~/models, /Volumes/*/mercury-model-bank, /mnt/*/mercury-model-bank, plus Change folder on the Bank screen), recognises existing folders by the model identity in SHA256SUMS or config.json, loads <config>/host/private-recipes.json automatically across terminals, keeps banked Hugging Face models in the Bank table across sessions, and stores each model in <bank>/<namespace>--<repo> with a SHA256SUMS manifest. The Bank summary line shows the folder path, free space, banked model count and size, and any kept volumes’ monthly rate, above a five-column table (MODEL, SIZE, BANKED, CHECK and VOLUME, where CHECK shows failed · v when a file check failed and Enter opens the path, error and volume detail).

Five single-key actions fit on one line on the Bank table and on a model screen (b bank or b bank again when banked, v verify, m mirror, d drop, k keep safe; pressing b, v, m, d or k on a model screen works before moving the selection cursor):

b (bank): Downloads the model’s weights in the background (hf download with HF_TOKEN when signed in so restricted repositories download) and checks hashes against SHA256SUMS at $0.00.
v (verify): Re-checks every file on disk against SHA256SUMS and any manifest digests at $0.00.
m (mirror): Mirrors a shipped, derived or banked private recipe’s manifest onto a Runpod network volume ($0.07/GB/month up to 1,000 GB, $0.05/GB/month above, with Prepare now via the cheapest single-node pod in stock or At the next rental), a Runpod global volume ($0.09/GB/month + IOPS), or a machine-bound Vast.ai volume (Vast.ai volume · keep on one Vast.ai machine · per GB-month at the machine's rate). A Vast.ai volume is prepared via the cheapest fitting instance on that machine, mounted at /workspace/mercury-weights with SGLang, DeepGEMM, FlashInfer, TorchInductor, Triton, CUDA and vLLM kernel caches stored on the volume so compiled kernels can be reused on later boots, and listed under Machines I'm paying for with d delete and w watch for that machine (w refreshes price and waits specifically for the machine that holds the volume).
d (drop): Deletes the kept Runpod or Vast.ai weights volume after confirmation while leaving your local bank untouched.
k (keep safe): Copies and checks a banked model (including config and tokenizer files) onto another mounted drive, mirrors it to a volume, or saves a first-boot upload of your local bank to Vast.ai and Lambda rentals at your measured upload speed.

When you rent a model with a kept Runpod or Vast.ai volume, warm startup checks file sizes, modification times, the first and last 64 MB, and eight seeded 1 MB samples per large file against SAMPLES.json in a few seconds (with Verify fully for a full SHA-256 check on demand) and starts the engine without re-downloading weights. Volumes show their monthly storage billing even when no instance is running and prompt whether to keep or delete the volume when you terminate an attached rental.

Rent a GPU across Runpod, Vast.ai, Lambda, Hugging Face, Hyperstack, Verda and DigitalOcean

Connect a GPU provider from a model screen, Vendor keys on Which model?, or More options → → Rent a GPU: paste a Runpod (console.runpod.io/user/credentials), Vast.ai, Lambda, Hyperstack or DigitalOcean API key, or Verda Client ID:Client Secret, into the masked field (checked against the provider’s instance list and saved in Mercury’s 0600 credential store, with Replace key / Remove key controls on the model screen), or use your saved /logins huggingface sign-in (openid profile inference-api write-endpoints) for Hugging Face Inference Endpoints (Sign out with /logins huggingface on the model screen). Hugging Face Inference Endpoints creates a private, single-replica endpoint on fitting hardware at the live catalogue’s hourly price that reaches READY over HTTPS without SSH, supports pause, resume and confirmed deletion, names the required Inference Endpoints token permission and settings URL on HTTP 403, and shows the rate-limit reset time and /logins huggingface remedy on HTTP 429. Hyperstack registers Mercury’s SSH public key in the selected environment, bills per minute including a public IP charge, and uses local /workspace storage deleted on termination; Verda and DigitalOcean register the SSH key on the account; Verda prepays 10-minute compute increments with unused time refunded and charges separately for its root disk (permanently deleted and confirmed absent on termination); DigitalOcean bills per second with a 5-minute minimum, includes local disk, and lists on-demand H100 and H200 sizes; powering off these instances does not end compute billing.
Choose a model and GPU shape. Mercury reads live stock and hourly prices for every GPU and node in the recipe across the 78 shipped recipes and 32 models in assets/host/recipes.json (version 2): GLM-5.3-Flash, Nemotron 3.5 Super VL 120B (including NVFP4 on 1× RTX PRO 6000), Qwen3.8-27B, DeepSeek-V4.1-Flash-1017 (with --chunked-prefill-size set to 2048 on 4× B200 with --mem-fraction-static 0.78, 4096 on 4× B300 and 4× GB300, and kvBytesPerToken of 11,624 bytes/token for 1M-token context), GLM-5.3 (FP8 and BF16), Kimi K3, Qwen3.8-2.4T-A95B (FP8 and NVFP4), DeepSeek V4 Pro, MiMo-V2.6-Pro-RL, Mistral Large 3 675B, and the 45 frontier open-weights recipes (Beam 1.0 501B-A23B in FP8 and NVFP4, Hy4-preview 770B in MXFP8 and BF16 with --context-length 262144, Step 5 Preview 604B-A27B, MiniMax-M3 427B-A23B in MXFP8 and BF16, Inkling 975B and Inkling-Small 266B in NVFP4, Nemotron 3 Ultra 550B-A55B in NVFP4 and BF16, LongCat-2.0 1.8T, Ling-3.1-flash 572B, Qwen3.8-Flash-Next 180B-A6B, MiMo-V2.6-Flash-RL 309B-A15B, gpt-oss-120b on 1× H100 or 1× H200 with vllm/vllm-openai:v0.32.0, and Gemma 4 31B), each with its vendor launch flags, tool-call parser, context window, reasoning effort levels, licence summary and file manifest. Trillion-parameter recipes include multi-node Runpod Instant Clusters and display total hourly compute, per-node disk allocations, weight download sizes, estimated download times at 0.5 to 1 GB/s per node, and model-licence disclosures.
Choose Tune on the rental confirmation screen (optional) to adjust quantization, conversations × context splits against the visible GPU-memory budget (12 GB per GPU engine reserve plus KV cache bytes per token), and default thinking level before confirming a rental.
Confirm the hourly price and weights source. Nothing is rented until you select the confirmation row and press Enter. Confirmation states the model, GPU shape, hourly rate, weights source, Tune summary, storage terms (Runpod disk storage is named per GB-month, and multi-node Runpod cluster confirmations omit the single-pod Stop storage sentence), deletion consequences and SSH-key notices. Selecting Weights on Confirm the hourly price (or a stock-watch confirmation) lets you choose Hugging Face, a Private repository (checking shard paths, byte sizes and SHA-256 digests against the recipe manifest and downloading on the rented machine with your /logins huggingface sign-in before removing the token file), This computer’s Bank (uploading your local bank over SSH while compute bills during the transfer), or a Kept volume on Runpod or Vast.ai (with unavailable choices stating what action is needed). If a vendor refuses placement (HTTP 400 or 410), Mercury returns to the GPU shape list and reports that no pod or cluster was created and nothing bills (<vendor> could not place <shape> · $<rate>/hr · no <pod|cluster> was created · nothing bills). If a selected Vast.ai machine is taken before creation (no_such_ask), Mercury refreshes stock and presents the next machine behind a new price confirmation (staying on the volume’s machine when a Vast.ai volume is attached), and a Vast.ai SSH-key failure before creation reports that no instance was created and nothing bills (reading Vast.ai’s SSH-key list in both bare and wrapped array shapes). Both shipped llama.cpp GGUF recipes (GLM-5.3-Flash with mmproj-F16.gguf and Nemotron 3.5 Super VL 120B with mmproj-BF16.gguf) download and check their vision projector alongside the model shards and pass --mmproj to llama-server on the updated prebuilt CUDA 13 llama.cpp image (built at llama.cpp 184f6536), skipping source compilation during pod setup and enabling image prompts and the Computer tool on rented and SSH-hosted GGUF servers.
Background preparation, cross-provider stock watches, setup pauses and the two-hour sweep. A detached background worker creates or registers the SSH key, provisions the instance, cluster or endpoint, prepares the chosen Weights source (downloading weights on the machine · <X> of <Y> GB), starts the engine on remote loopback, opens a local SSH tunnel, registers compat/pod-<id>/<model>, checks a reply, and when ready switches the live session that started the rental to compat/pod-<id>/<model> (keeping your saved default model in user settings unchanged and recording the session’s previous model so Terminate or the two-hour idle sweep restores it) while /llmhost can be closed with Esc (retaining the selected recipe row, its weight manifest, the chosen Weights source and a private reference to your foreground Hugging Face token or relative-path credential command across processes, and keeping background host notices saved across a restart until consumed, where a host notice paints its row without starting a model turn). Watch stock polls every connected provider (Runpod, Vast.ai, Lambda, Hugging Face, Hyperstack, Verda and DigitalOcean) every 5 seconds for up to 12 hours ($0.00 billed while watching under Machines I’m paying for, with a Cancel action) and rents the first fitting shape at or below your hourly ceiling. Transient vendor read errors (HTTP 429, 5xx and network timeouts) during setup and reads after manual Stop, Terminate and weights-disk deletion retry for up to 4 minutes with exponential backoff and live retry status on the row before pausing. No setup or runtime check ever terminates a rented machine on its own: when a rental or Runpod cluster hits an engine exit or out-of-memory error while loading weights (reading the engine’s own first non-warning error line from the current MERCURY_STEP starting engine mark onward and any unused-tensor count from the full engine.log, never treating [W...], *Warning, WARN or WARNING lines as engine death), 10 minutes of engine log silence past the setup budget (applying the 10-minute log-progress grace only after the engine prints new log lines), a weight download stall under 1 GB in 10 minutes or past the download deadline, SSH key refusals past the setup deadline (on a running Vast.ai instance that refuses SSH through the deadline, Mercury first attaches its SSH public key to the instance and retries for up to 4 minutes before pausing), five failed tunnel reconnects after setup (recorded under <config>/host/reliability/), or a cluster node fault (with cluster placement reads carrying their own retry budget past the placement window so an unplaced cluster reports did not bring all <N> nodes up with SSH within <M> min), Mercury pauses the record with the machine running, closes the local tunnel, and posts one notice naming the cause, the machine, the hourly rate still billing, and Resume or Terminate in /llmhost. When a running rental’s engine exits after setup, Mercury reads the engine’s startup token plan and last prefill or decode batch from engine.log, pauses the rental with the machine up and weights on disk, and answers chat requests immediately with the context tokens held versus the recipe budget and the Resume or Tune remedy; on Resume setup, Mercury reopens the tunnel on the same local port and reuses a still-answering engine (or restarts from the weights already on disk) without re-downloading weights. A background sweep every 5 minutes automatically terminates a rental only after 2 hours with no completed model request (or Tune reload) or 2 hours in an unanswered pause, confirms its absence from the vendor’s instance list, removes the /model entry, restores the renting session’s previous model, and leaves any kept weights volume untouched while naming its monthly charge.

Manage, Tune in place, Stop or Terminate a rental

Open /llmhost → Machines I’m paying for to inspect live rentals, clusters, Runpod and Vast.ai volumes and active stock watches across all connected providers. Machines I’m paying for counts live vendor instances only (including starting, booting, error and terminating instances in spend estimates), names each provider’s answer (none, no instances, no endpoints or unread), and labels each row by its vendor (Runpod pod, Vast.ai instance, Lambda instance, HF endpoint, Hyperstack instance, Verda instance or DigitalOcean instance, with each row’s state, hourly rate and spend estimate). On a machine’s controls screen, the header shows the hourly rate, live elapsed time since placement and spend so far ($<rate>/hr · <elapsed> elapsed · ~$<spend> so far + storage). Vendor read errors collapse to one summary line at the top of a screen (with details on Enter): an HTTP 401 or HTTP 403 on Runpod or Vast.ai halts only the failed read operation (volumes, stock or machines) so a refused weights-disk read keeps your running machines listed (weights disks unread; storage may still bill), while Hugging Face halts all reads for that token until the credential changes. Vast.ai instance listing uses /api/v1/instances/ with full pagination (and reports an update notice on HTTP 410), Runpod and Vast.ai refuse an incomplete or truncated instance page before claiming an instance is terminated, Lambda walks paginated instance lists past 50 instances, and Runpod log tails decode Server-Sent Events log lines and surface HTTP 422 validation fields:

Tune (Runpod single-node llama.cpp pods): Recognises the prebuilt llama-server binary, adjusts conversations × context or default thinking, and reloads the running llama-server in place without re-downloading weights, with automatic rollback to the previous launch script if the reload fails.
Stop / Pause: Releases GPU compute on Runpod and Vast.ai pods (storage continues to bill while stopped) or pauses a Hugging Face Inference Endpoint (with Resume to start it again; Lambda instances and Runpod clusters have no Stop operation and bill until termination).
Terminate: Deletes the pod, cluster, instance or endpoint after confirmation, confirms its absence from the vendor’s instance list, reports the compute spend (~$<spend> + storage), restores the renting session to its previous model, and removes its model registration from /model even when the local pod record is missing (and opening /llmhost cleans up endpoints whose pods have ended).
Logs and Resume setup: Read the engine or vendor log tail (holding the Logs page with a frozen clock until Esc returns to the machine controls) or restart a stalled setup job.

Multi-node clusters and in-place Tune reloads are Runpod-only; kept weights volumes exist on Runpod and Vast.ai; selecting a Runpod-only option for Vast.ai or Lambda explains that boundary without making a request.

Own-computer model servers: `My computers` and `mercury host`

Open /llmhost → My computers (or More options → → One of my computers), or run mercury host from the command line:

mercury host status [box]
mercury host recipes [box]
mercury host add <name> --ssh <host> --os darwin|linux|windows [--user <user>] [--port <port>] [--key <path>]
mercury host start <box|this-computer> <recipe> (--bank <folder> | --download <folder>) [--yes]
mercury host stop <box>
mercury host restart <box>
mercury host logs <box>
mercury host uninstall <box>

Mercury checks this computer or a saved SSH computer across macOS, Linux and Windows, picks an Ollama or GGUF recipe that fits its memory, checks any local weight bank against SHA256SUMS before startup (supporting both sharded and complete single-file GGUF or safetensors banks on mercury host start --bank and SSH boxes, or confirming a download), prints each setup phase as it begins (verifying the bank, installing Ollama or building llama.cpp, downloading weights, installing the login service, pulling the model and waiting for the engine to load) on the terminal and the /llmhost computer screen, installs and starts a user login service (launchd on macOS, systemd --user on Linux, Windows Scheduled Task on Windows) bound to loopback, opens a persistent SSH forwarder for remote computers, and registers compat/box-<name>/<model> for every session sharing the configuration home. The computer screen and mercury host status show the engine, model, reported busy slots and last measured token rate. Stopping the service keeps the model row visible in /model as box <name> · engine stopped (/llmhost starts it) without prompting for an API key, and uninstall removes Mercury’s service definition without deleting downloaded weights.

SSH computers, running servers, `/effort` and streaming

Under More options → → A box I can reach by SSH, enter a host and user or an SSH config alias; Mercury runs nvidia-smi over SSH, lists recipes that fit the detected GPUs, checks a local weight folder (including any required mmproj vision projector) or downloads from Hugging Face into /workspace after confirmation, binds the engine to remote loopback and opens a local SSH tunnel. Under More options → → A server that's already running, enter an OpenAI-compatible API base (a bare server address gets /v1 appended), confirm or pick the server dialect (SGLang, vLLM, llama.cpp, Ollama, LM Studio, chat completions or Responses; SGLang discovery reads GET /model_info before falling back to /get_model_info, and llama.cpp router-mode servers receive ?model= on /props, /slots and /metrics), enter an optional masked key (stored in Mercury’s credential store, never in a settings file), pick a model showing its served window, and run the reply check to register compat/<name>/<model> (default compat/llmhost/<model>).

Endpoints are saved under compatProvider.<name> in user settings with their API base, label, dialect, sessionAffinityHeader: "x-session-id" on SGLang, and models["compat/<name>/<model>"].contextWindow and supported efforts (an explicit per-model contextWindow in settings takes precedence over the server’s reported window):

Reasoning and /effort: /effort lists and sends each model’s supported reasoning levels (low, high, max on GLM-5.3, GLM-5.3-Flash, DeepSeek V4.1/V4 Pro and Kimi K3; low, medium, xhigh on Qwen3.8; named thinking values from /api/show on Ollama, with cold Ollama launches reading the model’s capability catalogue before the first request so the first turn sends your chosen /effort), sending chat_template_kwargs.reasoning_effort on llama.cpp and top-level reasoning_effort on vLLM, SGLang, Ollama and Kimi K3. SGLang requests also send chat_template_kwargs.thinking (true when session thinking is on, false when off) alongside chat_template_kwargs.clear_thinking: false so models such as DeepSeek-V4.1-Flash reason by default when no /effort is set and honour thinking off, and SGLang, vLLM, llama.cpp and Kimi K3 conversations preserve assistant reasoning_content across tool turns and continuations. If a server rejects a reasoning parameter or value, Mercury keeps your selected /effort and thinking and reports the server remedy instead of retrying at default effort.
Vision projectors, tool schemas and engine refusals: A llama.cpp server running without a vision projector reports that --mmproj is missing instead of marking the model text-only, and sending an image to a text-only or projector-less endpoint displays a notice naming the remedy. The Computer tool sends a flat one-level sequence step schema so llama.cpp accepts all 75 tool schemas without $ref errors, and an incompatible custom or MCP tool schema on llama.cpp refuses the request before dispatch without removing any tool from the roster. When llama.cpp, vLLM, SGLang, Ollama or LM Studio returns an HTTP 4xx/5xx refusal, Mercury names the cause and the server flag to fix it.
Slot affinity, prefix cache, prefill speed and live stream status: On llama.cpp servers reporting multiple slots in GET /props, sessions coordinate distinct id_slot assignments across Mercury processes sharing a config home (with cache_prompt: true, keeping their slot through context compaction and crewmate turns), and shipped recipes enable llama.cpp prompt caching, vLLM prefix caching and SGLang cache reporting. During prompt ingestion and streaming on self-hosted, OpenAI-compatible and Gemini endpoints, Mercury uses llama.cpp and SGLang /metrics prefill speeds to extend the first-byte allowance and polls server liveness instead of timing out after 30 seconds, the turn spinner shows its verb, elapsed time, ↓ token count, ~<N> tok/s output rate and retry or reconnect count, and the context compaction row shows compacting context, ↓ ~<tokens>, the progress bar and elapsed time (while context compaction retries keep your selected thinking and /effort settings).
Unreachable custom endpoints, session fallback and headless/SDK parity: Keyless endpoints retry in place without opening an unrelated sign-in screen, unreachable custom endpoints show Retry this server → and Remove this endpoint → in /model, /clear or session resume when the previous chat’s model cannot be reached starts the fresh chat on the default model with a one-line notice naming the unreachable model and /model (and unavailable compat model refusals point to /llmhost and /model), custom compat/ endpoints using the responses dialect send the session’s prompt_cache_key in /v1/responses requests, and mercury run --model local|compat|huggingface and both SDKs (sdk/ and sdk-py/) resolve those family names against your configured endpoints and retain a recorded compat/<endpoint>/<model> across cold and warm session resume.

Run /logins, select a provider from the list, and sign in in your browser or paste an API key.

Mercury records when the credential landed in the sign-in ledger and can start sessions on that provider’s usable models. The receipt names the account that signed in, the transcript’s sign-in line reads Login successful with the account after it, and the Logins card and the home screen’s chip show it at once. Setting view.accountIdentity to false takes every address, username and key tail off the screens for a recording and leaves the account word; the Logins screen, /accounts and the health report still name the account.

/logins opens the same card the first run shows, and the key-entry cards name where to obtain each key. Pasting a wrong API key or denied device code at /logins is refused at the door before anything is stored, showing the service’s own words: Anthropic (checked on GET /v1/models?limit=1 and prompting for a workspace ID when the key is organisation-scoped), OpenAI’s device-code sign-in (posting under /api/accounts/deviceauth/, treating deviceauth_authorization_pending as pending, honouring slow_down, and failing on the first poll when denied or expired), xAI (HTTP 400 Incorrect API key provided), Gemini (HTTP 400 API_KEY_INVALID, keeping any key stored before and reporting auth-invalid), OpenRouter (checked on authenticated GET /api/v1/key), MiniMax (base_resp 1004 and 2049 on /v1/token_plan/remains), Z.AI (checked on the selected plan’s models list before storing), Qwen (checked on the QwenCloud or Model Studio endpoints before storing), Mistral, OpenCode Zen, Together AI and Cohere. When a stored sign-in or API key has lapsed or been refused by the service, /logins, mercury auth list, mercury auth status, mercury auth status <family> and /health read one refusal record and print the same status, timestamp, service message and reconnect command (<credential> refused (HTTP <status>: <message>) at <timestamp> · /logins <family> reconnects, or update <ENV_VAR> for an environment-pinned key) until you reconnect. From the command line, mercury auth login [<family>], mercury auth list, mercury auth status [<family>], mercury auth logout [<family>] and mercury auth mint manage authentication across all 22 provider families, and mercury models [--json] prints the models the signed-in accounts reach. In settings, credentials.keyCommand supplies an Anthropic API key from a shell command, and credentials.keyCommands.<family> maps any provider family (openai, openrouter, orcarouter, gemini, moonshot, deepseek, xai, meta, mistral, nous, zen, minimax, together, cohere, groq, melious, cerebras, fireworks, qwen, huggingface, local, zai, anthropic, or compat/<name>) to a shell command supplying its API key (10-second timeout, cached for the process, 30-second failure backoff, invalidated on HTTP 401 with one retry, and gated on workspace trust when defined in project settings). A sign-in row on the Session Concourse or in a model picker opens Logins on that row’s family, and Esc returns to the picker that opened it.

The Gemini card offers Sign in with Google for your account’s plan quota, an API key (opening the AI Studio key page and taking the key by one paste), or your own OAuth client; the last two use Google Cloud project billing.

To connect your own OAuth client:

Create a Google Cloud project.
Enable the Gemini API on it.
Set up the consent screen for testing, with your own Google address as a test user.
Create an OAuth client for a desktop app.
Paste the client id. It is kept, so the next sign-in starts at the last step.
Sign in to your Google account in the browser, past the unverified-app screen.

When sign-in is refused, the card returns to the step that needs attention. Both your own OAuth client and Gemini API-key sessions use Google’s native generation endpoint and preserve signed response parts between tool calls and when resuming (when a reply’s signature arrives after the answer text, the blocks settle as the thinking block followed by the text block so the stop reason lands on the answer). The latest sign-in action is the active Gemini source; /logins and /usage name any stored source that is not active, and Enter on its row makes it active without re-entering it. Google refusals display Google’s reason. If Google reports that it is busy, Mercury retries with the same increasing delay used for other providers; see Credential changes and refusals.

Inspect provider accounts

Run /accounts to see every connected account and API key across all providers. Each provider header carries the provider’s name, and the rows beneath it list each sign-in with its kind, identity and masked key tail, without showing secret values. You can keep up to two saved Anthropic accounts and two saved OpenAI accounts at once (environment-variable keys do not count toward that limit), while a provider with no limit shows how many sign-ins it holds beside its name.

An environment-pinned key takes precedence for the process and cannot be edited in /accounts. Removing a slot routes to the store that owns it. Sign in once per company and keep different providers connected at the same time; the accounts board shows which sign-in each session uses.

Session defaults

The default provider is the provider of the most recent sign-in. A fresh, unpinned session starts on that provider’s newest model the credential can use. The default skips a gated row, and a provider with no usable row falls through to the next most recent sign-in.

/model: Says which model was picked and why; /model default clears the saved choice.
/defaultprovider: Makes a provider the most recent sign-in by your choice, as an entry in the same ledger.
MERCURY_MODEL: Pins a model ahead of the computed default.

With no sign-in anywhere there is no default: the home screen and /model say so and point at /logins.

Credential changes and refusals

A sign-in or a removal tells every runner the daemon hosts to read the account again. A usage-limit verdict is trusted only for the account that observed it and reads as unknown once the signed-in account is another. The verdict lapses at the reset the reply named, or after a bounded span when it named none. An expired sign-in is reported as an expired sign-in, and the notice names the sign-in command, /logins anthropic for the Anthropic provider. An unrecognised 4xx response from Anthropic shows the HTTP status and the provider’s own sentence on the transcript row while keeping the raw JSON envelope in the debug log.

A subscription that reports a usage window gets two warnings as it fills, at 80 and 90 percent, as words in the chat; the provider’s own refusal stays the only mechanical stop. The model is told the same only when the engine.usageNotice setting is on; until you turn it on, the meters and the warning stay yours alone. A nearby spending limit appears in the same notice.

On the Anthropic connection, an authentication refusal skips the retry backoff. Mercury attempts credential recovery once when the active sign-in or key helper can refresh the credential. A changed credential gets one immediate retry. A failed refresh, an unchanged credential or another authentication refusal ends the request. The blocker names the account when known and the sign-in command, or the environment variable or helper that supplied the rejected credential.

An expired OpenRouter OAuth key leaves a valid stored API key in force: model calls and the credits read use the stored key, and the failed key is named. Refusals show OpenRouter’s own message, or the HTTP status when no body is returned. A refusal is called expired only when the provider says it is.

When a provider answers that it is busy, Mercury sends the request again on a growing wait for about a minute before the red error. The first thirty seconds stay quiet, then a retry line shows the wait and the count, and the red line, when it comes, says how many retries it took and how long. An answer that arrives inside the wait has one calm line above it naming the provider, and Esc ends the wait at once. A rate limit that names its own wait follows the same schedule, using that wait in place of the step. If a provider stays overloaded after a minute of retries, any running crewmate pauses and probes after 30 seconds, every minute for ten minutes, and then every five minutes for up to one hour, resuming automatically when the provider answers. On an API key the refusal shows only once the retries are spent, and it proposes the fallback model when one was named. A network outage on any provider takes its own bounded reconnect steps outside the retry budget, counts as no fault, and the status row says it is reconnecting; MERCURY_RECONNECT_BUDGET_MINUTES bounds the wait.

When a usage window closes and you confirm a handoff card to another signed-in provider, the session runs on that backup provider until your original provider’s usage window is observed to reset. One amber sentence above the composer says so for two minutes after the switch, and again whenever the facts it states change, with /model as the way back; MERCURY_FAILOVER_LINE_MS sets that window in milliseconds. The strip’s model segment keeps a short amber mark beside the served model while the session runs on the backup provider. In settings, engine.backups (or --backup-model <id> on the command line, which heads the list) names an ordered list of backup engines: when the active engine’s provider is overloaded past the retry ladder, unreachable, refusing its sign-in after a refresh, or no longer serving the model, the turn hops to the first backup engine, then the next, each tried once per turn, and states the hop in one line.

On hosted providers, the wait for the first response byte is sized to the prompt and named in the notice. A connection that sends headers and then goes silent is retried without cutting off a model that is still thinking. A reply cut mid-stream is retried. On the Anthropic connection, Mercury shows a stream-cut notice and reissues the reply once on a fresh connection. Hosted requests use HTTP/1.1 by default; on the OpenAI API-key road, setting routing.openai.transport to websocket keeps one WebSocket connection per conversation that sends only the new input against the previous response and falls back to HTTP on any connection or stream fault before the response begins.

New OpenAI sessions can reuse the provider’s cached tools and system prompt shared with other sessions in the same project. Moonshot’s K3-series models (kimi-k3.1-pro, kimi-k3.1-pro-highspeed, kimi-k3, k3.1-pro, k3.1-pro-highspeed, k3, k3-256k) and kimi-for-coding, DeepSeek deepseek-flash, and self-hosted compat/ endpoints (vllm, sglang, llamacpp, ollama, lmstudio and rented pod- endpoints) defer tools at the end of messages: a request carries the tools it needs, and admitting another tool appends its definition as a system row so the initial tools array and cached prompt prefix stay unchanged.

A provider whose credential does not resolve refuses with text that names where to sign in or store a key. An undiscovered local model refuses with the probe route. A routed request stays on its provider. When a provider reaches its usage window, crewmates targeting that capped provider are also refused instead of failing over to another provider, while crewmates targeting other signed-in providers can still run. A refused API-key creation shows the provider’s own sentence. On Z.AI, glm-5.3-flash, glm-5.3-flashx and the glm-4.6v and glm-4.5v rows accept images, while a conversation that carries an image reaches a text-only GLM model as an [image] note, and Z.AI’s wording for an image it refuses is understood so the next request goes out without the image.

Read plan usage

Every provider’s usage block names its account beneath the title, on the vitals rail and in /usage. When the session model runs on a rented GPU (compat/pod-<id>/<model>), /usage shows the rental’s machine identity, hourly rate, elapsed time since placement and compute spend so far ($<rate>/hr · <elapsed> elapsed, $<spend> so far + storage). The vitals rail’s Anthropic usage rows update from the session’s own replies as you work, the plan tier is re-read when usage is read, and when an HTTP 429 closes a per-model usage window, /usage, the vitals rail and mercury usage display that window’s name, reset time and bound model alongside the account figures and clear it once its reset passes. Moonshot plans, MiniMax M Plan keys and Z.AI Coding Plan keys show their usage windows and resets. Z.AI and MiniMax M Plan keys show five-hour and weekly windows; a pay-as-you-go key says it has no usage endpoint to read. A Gemini API key or your own OAuth client gets no usage, quota or credit figure from Google, so /usage says so in one line beside this session’s token totals (and any model on the Gemini slot for which Google reports no quota reads <model>: no quota reported for this model · used this session); for your own OAuth client it names the Cloud console’s Quotas page for the Generative Language API or Google AI Studio. An expired sign-in is refreshed when usage is read, and the OpenAI card and popup use the same reading. From the shell, mercury usage and mercury usage --json print the same reading without opening a chat, and mercury usage --history (--days <N>, --project, --json) reports local input tokens, output tokens, cache-hit rate, estimated USD and unpriced turns across saved transcripts grouped by UTC day, model and project without contacting providers (see Automation).

Every sign-in has a credits line beside its usage meter. Where the provider reports a balance, the line shows that figure and when it was read. Where it does not, Mercury says so, and session spend appears as its own figure. A Kimi sign-in shows its Extra Usage balance beside its plan windows. An OpenRouter key shows its remaining credit under the key cap, and below a $10 floor /usage names the remaining amount and the credits page. A window that reads reached says what carries the requests from there in the provider’s own words: an Anthropic subscription on extra usage names its figure, a ChatGPT sign-in says how many credits are left, and a provider that states nothing about it is named as not stating it.

A Grok subscription shows its included weekly pool and purchased credits. For an xAI API key, an optional management key entered through /logins xai adds the team’s prepaid balance, billing-cycle usage and any postpaid limit. Those are team figures, and this session’s spend appears separately; the inference key works without a management key.

Jev can use a TypeSafe key configured through /jev, or OpenRouter access enabled with /jev or on (an OpenRouter HTTP 401 on a Jev request records the sign-in refusal so it shows in /logins). Each connection has its own key, spend meter and cap, /jev shows which is active, and /usage shows the evaluator row only when the config home holds an evaluator key or a call was made in the session.

Models and effort · Web search · Quickstart · Saturn scheduling