Available Providers
QueryMT ships with 15 providers split across two types: WASM (API-based, cloud services) and Native (local inference, runs models on your hardware). This page covers how to configure each type, how to pick the right build variant for your hardware, and provides copy-pasteable configuration recipes.
Provider Repository (repo.query.mt)
QueryMT maintains an always-up-to-date provider repository at https://repo.query.mt.
latest.json— updated on every push tomain(default)stable.json— updated on every tagged release
If no providers config exists at ~/.qmt/providers.toml (or .json / .yaml), QueryMT automatically fetches latest.json and caches it to ~/.qmt/providers.json on first run.
Override the source URL:
Note
The provider repository currently covers WASM providers only. Native providers must be configured manually in your providers config.
WASM Providers (API-based)
WASM providers call remote APIs. They are sandboxed WebAssembly modules that run on any platform and require no local hardware beyond an internet connection. All 12 WASM providers are listed in the provider repository, so you don't need to configure them manually unless you want to pin a version or customise settings.
| Name | Description | API Key Env Var |
|---|---|---|
anthropic |
Anthropic Claude models | ANTHROPIC_API_KEY |
openai |
OpenAI GPT / o-series models | OPENAI_API_KEY |
codex |
OpenAI Codex / coding-optimised models | OPENAI_API_KEY |
google |
Google Gemini models | GEMINI_API_KEY |
mistral |
Mistral AI models | MISTRAL_API_KEY |
groq |
Groq-hosted models (OpenAI-compatible) | GROQ_API_KEY |
ollama |
Ollama local server (OpenAI-compatible) | — |
openrouter |
OpenRouter multi-provider gateway | OPENROUTER_API_KEY |
alibaba |
Alibaba Cloud Qwen models (OpenAI-compatible) | DASHSCOPE_API_KEY |
moonshot |
Moonshot AI Kimi models (OpenAI-compatible) | MOONSHOT_API_KEY |
kimi-code |
Kimi Code specialised coding model | MOONSHOT_API_KEY |
xai |
xAI Grok models (OpenAI-compatible) | XAI_API_KEY |
Minimal WASM configuration
You only need to specify a provider if you want to override defaults or pin a version. Most users can skip this entirely.
Native Providers (local inference)
Native providers run LLMs locally on your machine. They are distributed as platform-specific shared libraries (.so / .dylib / .dll) packaged into OCI images. Unlike WASM providers, QueryMT resolves native providers at download time by inspecting the OCI image index for a manifest that matches your OS and architecture. If a match is found, the native library is downloaded; if not, QueryMT falls back to the WASM variant if one exists.
There are three native providers:
| Name | Underlying engine | Description |
|---|---|---|
llama-cpp |
llama.cpp | GGUF models, vision support, broad hardware compatibility |
izwi |
izwi-core | Efficient local inference with Flash Attention |
mrs |
mistral.rs | High-performance inference for Mistral and compatible architectures |
Native providers must be configured manually
Native providers are not included in the repo.query.mt provider repository. You must add them to your ~/.qmt/providers.toml explicitly.
Feature tags
Each native provider is published with multiple OCI tags corresponding to different hardware backends. The tag you specify in path controls which binary is downloaded.
| Tag suffix | Hardware | Availability |
|---|---|---|
latest / latest-default |
CPU only | Linux (x86_64, arm64), macOS (x86_64, arm64), Windows (x86_64) |
latest-metal |
macOS Metal GPU | macOS (x86_64, arm64) |
latest-accelerate |
macOS Accelerate framework | macOS (x86_64, arm64) — izwi, mrs only |
latest-vulkan |
Vulkan GPU | Linux (x86_64, arm64), Windows (x86_64) — llama-cpp only |
latest-cuda12.8 |
NVIDIA CUDA 12.8 | Linux (x86_64, arm64), Windows (x86_64) — llama-cpp only |
latest-rocm7.2 |
AMD ROCm 7.2 | Linux x86_64 only - llama-cpp only; GPU runtime validation pending |
latest-cuda12.8-sm80 |
NVIDIA CUDA SM 80 | Linux x86_64 — izwi, mrs only |
latest-cuda12.8-sm86 |
NVIDIA CUDA SM 86 | Linux x86_64 — izwi, mrs only |
latest-cuda12.8-sm87 |
NVIDIA CUDA SM 87 (Jetson Orin) | Linux arm64 — izwi, mrs only |
latest-cuda12.8-sm89 |
NVIDIA CUDA SM 89 | Linux x86_64 — izwi, mrs only |
latest-cuda12.8-sm120 |
NVIDIA CUDA SM 120 | Linux x86_64 — izwi, mrs only |
Version-pinned variants follow the same pattern with the crate version prepended: 0.1.0-metal, 0.1.0-cuda12.8-sm89, etc.
llama-cpp CUDA vs. izwi/mrs CUDA
llama-cpp uses a single combined cuda12.8 build that covers all NVIDIA GPUs via JIT compilation at runtime — no SM selection needed. izwi and mrs compile Flash Attention kernels ahead of time, which requires a specific SM architecture to be selected at build time.
NVIDIA GPU to SM architecture
Use this table to find the correct cuda12.8-smXX suffix for your GPU.
| GPU | Architecture | SM | Tag suffix |
|---|---|---|---|
| RTX 3050 / 3060 / 3070 / 3080 / 3090 | Ampere | 86 | cuda12.8-sm86 |
| RTX 3050 Ti (laptop) | Ampere | 86 | cuda12.8-sm86 |
| A10 / A40 | Ampere | 86 | cuda12.8-sm86 |
| A30 / A100 | Ampere | 80 | cuda12.8-sm80 |
| RTX 4060 / 4070 / 4070 Ti / 4080 / 4090 | Ada Lovelace | 89 | cuda12.8-sm89 |
| RTX 4060 Ti / 4070 Super / 4080 Super | Ada Lovelace | 89 | cuda12.8-sm89 |
| L4 / L40 / L40S | Ada Lovelace | 89 | cuda12.8-sm89 |
| RTX 5070 / 5070 Ti / 5080 / 5090 | Blackwell | 120 | cuda12.8-sm120 |
| B100 / B200 / GB200 | Blackwell | 120 | cuda12.8-sm120 |
| Jetson AGX Orin / Orin NX / Orin Nano | Ampere (aarch64) | 87 | cuda12.8-sm87 |
Not sure which SM your GPU is?
Run nvidia-smi --query-gpu=compute_cap --format=csv,noheader to print your GPU's compute capability (e.g. 8.9 = SM 89).
AMD ROCm compatibility
The llama-cpp latest-rocm7.2 variant is built on Ubuntu 24.04 with ROCm 7.2.1, matching llama.cpp's Linux ROCm Docker build. One binary contains all of the upstream build's GPU targets; no per-GPU tag is needed:
| GPU family | Compiled targets |
|---|---|
| Instinct (CDNA) | gfx908, gfx90a, gfx942 |
| RDNA 2 | gfx1030 |
| RDNA 3 | gfx1100, gfx1101, gfx1102 |
| Ryzen APUs (RDNA 3.5) | gfx1150, gfx1151 |
| RDNA 4 | gfx1200, gfx1201 |
Initial ROCm release: GPU runtime validation pending
CI compiles the provider and checks ROCm linkage without an AMD GPU. Actual inference, performance, and model/backend combinations have not yet been validated on AMD hardware. The targets listed here describe compiled coverage, not a tested hardware support guarantee.
The OCI artifact contains the provider library only, not ROCm or GPU drivers. Use Ubuntu 24.04 or a compatible environment with the ROCm 7.2.1 HIP runtime, hipBLAS, and rocBLAS (including its GPU kernel data) installed. Follow AMD's ROCm 7.2.1 installation instructions and check the GPU/driver requirements for your hardware. The dynamic linker must be able to resolve libamdhip64.so, libhipblas.so, librocblas.so, and their dependencies. Nonstandard installations, including NixOS, require an environment providing those libraries; the downloaded artifact is not self-contained.
The process also needs permission to access the AMD GPU (/dev/kfd and the appropriate /dev/dri render node). GPUs outside the compiled list can use latest-vulkan or a source build with a custom target list. This initial ROCm variant is not published for Windows or Linux arm64.
Choosing a feature tag
Provider reference
anthropic
Claude models through the Anthropic Messages API. Requests are shaped per model, so the same session settings are valid on every Claude generation.
Model classes and "auto" effort
The model ID (including Bedrock, Vertex and router forms such as us.anthropic.claude-opus-4-7-v1:0, claude-sonnet-4-6@20260101 or anthropic/claude-sonnet-5-5) is parsed into family and version and falls into one class:
| Class | Models | "auto" (no effort set) | Explicit effort (low, medium, high, max) |
|---|---|---|---|
| Default-on adaptive | Claude 5 or later, Fable, Mythos (including Mythos Preview) | No thinking, no effort: the API defaults apply |
thinking: {type: "adaptive"} + output_config.effort |
| Opt-in adaptive | Opus and Sonnet 4.6 to 4.8 | thinking: {type: "adaptive"} |
thinking: {type: "adaptive"} + output_config.effort |
| Budget | Everything older, and IDs that can't be parsed | No thinking |
thinking: {type: "enabled", budget_tokens} |
Behaviour change for Opus 4.6-4.8 and Sonnet 4.6
"auto" now turns adaptive thinking on for these models. This raises cost and latency, and responses may contain thinking blocks. There is no "off" reasoning level yet.
\"auto\" on Claude 5.x does not bound thinking
Default-on models keep their API default effort (high on most models), and nothing in the request limits how much they think. The documented controls are max_tokens and effort. Thinking spend is reported as reasoning_tokens in usage so it is visible, but it is not capped by this provider.
Effort and budget fitting
On adaptive models the effort is sent unchanged as output_config.effort. On budget models the budget is reasoning_budget_tokens when configured, otherwise a default per effort (low 1,024, medium 8,000, high 16,000, max 31,999). It is then fitted to the request: at least 1,024 and at most half of max_tokens. When max_tokens is below 2,048 thinking is omitted. Budget models never receive output_config.
Sampling parameters
- On Opus 4.7 or later and on every Claude 5 or later, Fable or Mythos model,
temperature,top_pandtop_kare never sent. - On other models, whenever thinking is sent,
temperatureandtop_kare omitted andtop_pis sent only if it is between 0.95 and 1. - Otherwise the configured values are sent.
Each dropped value is logged at debug level.
Forced tool choice
A forced tool_choice is any or a named tool.
- Budget models: thinking is dropped from that request.
- Opus 5.5 or later, Sonnet 5.5 or later, Fable 5.1 or later, Mythos 5.1 or later: the API rejects forced tool choice, so the request fails locally with an invalid-request error.
- Other adaptive models: sent unchanged.
Thinking replay, usage and stop reasons
Each thinking block becomes its own reasoning item with its own signature. Signed blocks are replayed unchanged, even when their text is empty (the default display: "omitted" on Opus 4.7+ and Claude 5). redacted_thinking blocks are kept and replayed with their opaque data. output_tokens_details.thinking_tokens is reported as reasoning_tokens and subtracted from the inclusive output_tokens, so ordinary output and reasoning never overlap. Streaming usage ends with the final message_delta values: the provisional output count in message_start is not emitted as ordinary output, fields a later event omits (input, cache) keep their earlier values, and an explicit zero replaces them. Cache writes keep the returned cache_creation five-minute and one-hour counts as a breakdown of the aggregate cache_creation_input_tokens (never added on top); with no breakdown the tiers stay absent rather than assumed. Stop reasons map as: end_turn/stop_sequence to stop, tool_use to tool calls, max_tokens/model_context_window_exceeded to length, refusal to content filter, pause_turn to other.
adaptive_thinking override
An optional provider config field overrides the class derived from the model ID:
truesends adaptive thinking explicitly. This is the right choice for a proxy or custom model ID that can't be parsed but fronts an adaptive model.falseforces budget thinking. The API rejects budget thinking on Opus 4.7+ and every Claude 5 or later model.
The sampling and forced-tool-choice rules always use the parsed model ID and ignore this override.
Strict tool use (strict_tools)
Strict tool use makes the API enforce a tool's input schema during sampling. One optional provider setting controls it:
A tool is eligible when its definition sets strict: true or its unprefixed name is in strict_tools (names are matched before the OAuth mcp_ prefix is applied). The provider itself has no default list: when strict_tools is unset or empty, no tool is selected by name, but tools whose definitions explicitly set strict: true stay eligible. The QueryMT agent fills in ["edit", "multiedit", "replace_symbol"] for Anthropic when you have not set strict_tools; set strict_tools = [] to turn that off. Builtin tool definitions never set strict, so OpenAI Responses behaviour is unchanged.
Eligible tools are sent with "strict": true only when every check passes:
- Model. Opus and Sonnet 4.5 or later, Haiku 4.5 or later, and all Fable and Mythos models. Older or unrecognised model IDs send no
strictfield and the original schemas (logged at debug level). - Schema. Strict mode accepts a subset of JSON Schema, so the provider converts a copy of each schema: fixed-property objects are closed (
additionalProperties: false), and numeric limits, string-length limits,maxItemsandminItemsabove 1 move into the property description, for example(minimum: 0). Required and optional properties are unchanged. The agent still validates calls against the original schema. A tool whose schema cannot be converted safely (external or recursive references, dictionaries or open objects,pattern, unsupported formats,oneOf/allOf/notand other unknown keywords) is sent non-strict with its original schema and a warning naming the tool and the unsupported feature. Other eligible tools stay strict. This applies to explicit and name-selected strictness alike. - Budgets. Counted over the successfully converted tools only: at most 20 strict tools, 24 optional properties and 16 union properties (
anyOfor type arrays). If any limit is exceeded, every tool in that request is sent non-strict with its original schema and a warning names the limit.
Strict tools work the same over API key and OAuth: OAuth strict requests were verified against the live API on claude-sonnet-4-5 and claude-sonnet-5-5 (see scripts/verify-anthropic-strict.sh).
Usage normalization across API providers
Every provider adapter reports usage in the same exclusive categories: uncached input, ordinary output, reasoning, cache reads and cache writes. Each token appears in one category, so totals and cost estimates never count it twice. What each wire format needs to get there:
| Provider | Wire shape | Normalization | Limitations |
|---|---|---|---|
| OpenAI Chat, OpenRouter, xAI, Mistral, Alibaba | prompt_tokens includes prompt_tokens_details.cached_tokens and cache_write_tokens; completion_tokens includes reasoning_tokens |
Cache reads and writes are subtracted from the prompt; reasoning is subtracted from the completion | A missing detail object means zero, not unknown |
| DeepSeek | Flat prompt_cache_hit_tokens / prompt_cache_miss_tokens |
An explicit miss count, including 0, is used as uncached input instead of a derived value |
Cache writes are not reported (they are billed as ordinary input) |
| OpenAI Responses, Codex | input_tokens includes input_tokens_details.cached_tokens and cache_write_tokens; output_tokens includes reasoning_tokens |
Same subtraction as Chat | Only terminal usage is authoritative; each attempt carries its own usage |
| Google Gemini | promptTokenCount includes cachedContentTokenCount; candidatesTokenCount excludes thoughtsTokenCount; toolUsePromptTokenCount is separate |
Cached tokens are subtracted from the prompt, thoughts become reasoning, tool-use prompt tokens count as input | Gemini reports no cache-write counter (implicit cache writes and cache storage time are not metered here) |
| Anthropic | See Thinking replay, usage and stop reasons | input_tokens is already uncached; thinking is subtracted from output_tokens |
Catalog prices cover base-duration cache writes; one-hour writes need an explicit one-hour rate |
These adapters only report what the response states. They never infer a cache counter from the requested cache settings or the provider name.
llama-cpp
Wraps llama.cpp. Supports GGUF models, vision/multimodal models, and streaming. Broadest hardware support of the three native providers.
Supported platforms:
| OS | Architecture | CPU | Metal | Accelerate | Vulkan | CUDA 12.8 | ROCm 7.2 |
|---|---|---|---|---|---|---|---|
| Linux | x86_64 | ✓ | — | — | ✓ | ✓ | Build only* |
| Linux | arm64 | ✓ | — | — | ✓ | ✓ | — |
| macOS | x86_64 | — | ✓ | — | — | — | — |
| macOS | arm64 | — | ✓ | — | — | — | — |
| Windows | x86_64 | ✓ | — | — | — | ✓ | — |
*ROCm is published with compiled target coverage; GPU runtime validation is pending. See AMD ROCm compatibility.
Configuration:
Key config options:
| Option | Type | Description |
|---|---|---|
model |
string | Path to GGUF model file, or owner/repo:filename HuggingFace reference |
n_ctx |
integer | Context window size (default: model native size) |
n_gpu_layers |
integer | Layers to offload to GPU. 0 = CPU only, 99 = all layers |
flash_attention |
string | "auto" | "enabled" | "disabled" |
kv_cache_type_k |
string | KV cache key quantization: "f16", "q8_0", "q4_0" |
kv_cache_type_v |
string | KV cache value quantization: "f16", "q8_0", "q4_0" |
max_tokens |
integer | Maximum tokens to generate (default: 256) |
temperature |
float | Sampling temperature. 0 = greedy |
mmproj_path |
string | Path to multimodal projection file (vision models only) |
For vision model configuration and the full option reference see the llama-cpp provider README.
izwi
Wraps izwi-core. Efficient local inference with Flash Attention support. CUDA builds are compiled per SM architecture for maximum performance.
Supported platforms:
| OS | Architecture | CPU | Metal | Accelerate | CUDA 12.8 |
|---|---|---|---|---|---|
| Linux | x86_64 | ✓ | — | — | SM 80, 86, 89, 120 (+ Flash Attn) |
| Linux | arm64 | ✓ | — | — | SM 87 (+ Flash Attn) |
| macOS | x86_64 | — | ✓ | ✓ | — |
| macOS | arm64 | — | ✓ | ✓ | — |
| Windows | x86_64 | ✓ | — | — | — |
Configuration:
mrs
Wraps mistral.rs. High-performance inference for Mistral and compatible architectures. CUDA x86_64 builds include both Flash Attention and cuDNN.
Supported platforms:
| OS | Architecture | CPU | Metal | Accelerate | CUDA 12.8 |
|---|---|---|---|---|---|
| Linux | x86_64 | ✓ | — | — | SM 80, 86, 89, 120 (+ Flash Attn + cuDNN) |
| Linux | arm64 | ✓ | — | — | SM 87 (+ cuDNN, no Flash Attn) |
| macOS | x86_64 | — | ✓ | ✓ | — |
| macOS | arm64 | — | ✓ | ✓ | — |
| Windows | x86_64 | ✓ | — | — | — |
| Windows | arm64 | ✓ | — | — | — |
Configuration:
Complete configuration recipes
Drop one of these into ~/.qmt/providers.toml and adjust paths as needed.
Cloud APIs only
No config needed — repo.query.mt handles this automatically on first run. If you want explicit control:
Cloud + local llama-cpp on macOS Apple Silicon
Fully local on Linux with NVIDIA RTX 40-series
Fully local on macOS Apple Silicon
Fully local on Linux (CPU only)
Further reading
- Plugin Configuration — full
providers.tomlfield reference, OCI signature verification, JSON/YAML format - OCI Plugins — how OCI image resolution and caching works
- llama-cpp provider README — vision models, full config reference, troubleshooting