Merge pull request #427 from SudoJacky/feat/zai-glm-provider

feat: add Z.ai GLM provider and vision model support

Author: SudoJacky

docs/api/agent-runtime.md

@@ -76,9 +76,9 @@ Optional provider features must be declared explicitly on the selected provider
 `structured_output` (camel-case spellings are also accepted). A requested undeclared feature fails
 with the resolved provider ID and missing capability. Built-in profile capabilities fall back to the
 provider catalog when the profile omits the field; an explicit profile value overrides that default.
-Custom OpenAI-compatible profiles are the exception for reasoning effort: they default
+Reasoning effort is not capability-gated: all OpenAI-compatible profiles default
 `supportsReasoningEffort` to `true`. Setting it to `false` omits effort instead of failing the Turn;
-reasoning summaries still require the `reasoning` capability.
+reasoning summaries still require the separate `reasoning` capability.
 Declared settings map to Chat Completions fields as follows: service tier to `service_tier`, reasoning
 effort to `reasoning_effort`, reasoning summary configuration to `reasoning`, and output schemas to
 `response_format.type = "json_schema"`. For Responses requests, effort and summary map to

docs/api/desktop.md

@@ -491,15 +491,19 @@ configuration for a separate backend process. Secret fields
 return `value: null` with `secret` metadata and must remain redacted in exported/public config.
 Provider selection is profile-based. New config should use `agents.defaults.activeProfile` and
 `providers.profiles.<profileId>.provider`; `agents.defaults.provider: "auto"` is a legacy value only.
+The Provider & Models default selector updates `agents.defaults.activeProfile` and
+`agents.defaults.model` in one native patch so Profile-based endpoint resolution and global model
+fallbacks cannot diverge.
 Reasoning effort is not an Agent Defaults setting. A legacy `agents.defaults.reasoningEffort` value
 may remain in raw config for read compatibility, but the settings registry does not expose it and the
 agent runtime does not apply it to model requests.
-The built-in provider catalog currently exposes only `deepseek`, `dashscope`, and `openai`.
+The built-in provider catalog currently exposes `deepseek`, `dashscope`, `openai`, and `zai`.
 Profiles are not limited to that catalog: a profile with a custom provider ID, explicit `apiBase`,
 and at least one model is resolved as an OpenAI-compatible provider. Its optional API key remains on
 the existing secret/redaction path, and `supportsModelDiscovery` controls `/models` discovery.
-`supportsReasoningEffort` defaults to `true`; set it to `false` to omit effort from both Chat
-Completions and Responses requests for endpoints that reject the field.
+Every built-in and custom Provider profile defaults `supportsReasoningEffort` to `true`; set it to
+`false` to omit effort from both Chat Completions and Responses requests for endpoints that reject
+the field.
 Context windows are model-specific. A provider profile can store explicit overrides as
 `modelContextWindows`, for example:
 
@@ -513,11 +517,38 @@ Context windows are model-specific. A provider profile can store explicit overri
 
 The runtime prefers a turn override, then the active profile's model override, then Tinybot's
 known-model default. `deepseek-v4-flash`, `deepseek-v4-flash-vision-exp`, and
-`deepseek-v4-pro` default to `1000000`; unknown models use the legacy
-`agents.defaults.contextWindowTokens` value when present and otherwise fall back to `128000`.
+`deepseek-v4-pro`, plus `glm-5.3` and `glm-5.3-flash`, default to `1000000`;
+unknown models use the legacy `agents.defaults.contextWindowTokens` value when present and
+otherwise fall back to `128000`.
 The settings UI edits these values per model instead of applying one global window to every model.
+Provider profiles can also separate their discovered model catalog from the models shown in model
+selectors. `models` retains the available IDs, while `enabledModels` contains only the IDs exposed
+in Chat, Agent Graphs, and other shared model pickers. When `enabledModels` is absent, existing
+profile `models` remain enabled for backward compatibility. Models newly returned by a refresh are
+added to the catalog but remain disabled until selected in Provider & Models settings.
+
+Image input is a model capability rather than an API-mode capability. Profiles can override it with
+`modelCapabilities`:
+
+```json
+{
+  "enabledModels": ["custom-vision"],
+  "modelCapabilities": [
+    { "model": "custom-vision", "inputModalities": ["image"] }
+  ]
+}
+```
+
+Missing capability entries use Tinybot's known-model defaults. `glm-5.3-flash` and
+`deepseek-v4-flash-vision-exp` support image input by default; unknown models default to text-only
+until enabled explicitly. The runtime enforces the resolved model capability before either Chat
+Completions or Responses requests are constructed.
 Each profile defaults to Chat Completions. Set `apiMode` to `responses` (or enable **Use Responses
 API** in provider settings) only when its endpoint supports `/responses`.
+The built-in `zai` profile is restricted to Chat Completions. It uses
+`https://open.bigmodel.cn/api/paas/v4` and maps Tinybot's maximum-output setting to Z.ai's
+`max_tokens` field. Z.ai profiles reject unsupported Responses mode, out-of-range temperature,
+and explicitly requested parallel tool calls before a request is sent.
 
 OpenAI-compatible provider profiles accept separate network deadlines:
 
@@ -541,6 +572,9 @@ Provider model discovery:
 - `dashscope` uses the same OpenAI-compatible model discovery shape against its configured
   `apiBase`, so the default discovery URL is
   `https://dashscope.aliyuncs.com/compatible-mode/v1/models`.
+- `zai` uses the static `glm-5.3`, `glm-5.3-flash`, and `glm-5.2` model list. Live `/models`
+  discovery is disabled because the supported integration contract only guarantees Chat
+  Completions.
 
 `POST /api/provider-models` accepts `{ provider, profile, apiBase, refreshLive }`. When
 `refreshLive: true` is used for an OpenAI-compatible provider, the backend reads the configured

docs/api/events.md

@@ -104,7 +104,7 @@ catalog, and legacy Agent defaults:
 - Turn `contextWindowTokens` / `context_window_tokens`: an explicit override for that turn.
 - Profile `modelContextWindows`: per-model overrides containing `model` and
   `contextWindowTokens`. When unset, `deepseek-v4-flash`, `deepseek-v4-flash-vision-exp`, and
-  `deepseek-v4-pro` use `1000000` automatically.
+  `deepseek-v4-pro`, plus `glm-5.3` and `glm-5.3-flash`, use `1000000` automatically.
 - `agents.defaults.contextWindowTokens` / `context_window_tokens`: legacy fallback for unknown
   models only. Unknown models fall back to `128000` when it is absent.
 - `contextWindowStrategy` / `context_window_strategy`: `discard` or `compact`. The fallback is

docs/api/threads-and-memory.md

@@ -10,7 +10,7 @@ src-tauri/src/threads/domain/types/records.rs
 src-tauri/src/threads/domain/types/requests.rs
 src-tauri/tests/crate/threads.rs
 -->
-<!-- tinybot-doc-fingerprint: sha256:14fba07c2b89b249048fabd2c90c08f1d92430b30e2b441b28c105b86c2c0896 -->
+<!-- tinybot-doc-fingerprint: sha256:c46a50f6806b4ad0ba04e02a97083d4bae810bc6045ada37e9ae57794d2fc60e -->
 
 This document covers Thread queries, memory, persistence, and project grouping.
 It is part of the [Rust backend API reference](rust-backend-api.md), which
@@ -248,6 +248,11 @@ is materialized before a later append.
 Thread discovery metadata, checkpoint pointers, and Rollout heads are maintained only in memory and
 rebuilt from those files when the process starts.
 
+`thread.create` pins the Thread's provider API mode in `metadata.extra.apiMode` and the Rollout
+session metadata. When `metadata.extra.modelProvider` explicitly selects a provider, that provider's
+profile determines the mode; otherwise creation falls back to the active provider profile. Later
+turns must use the pinned mode, and a mismatch fails before the provider is called.
+
 The durable hierarchy is strict: a Thread may exist without an active Turn, but every persisted
 `ThreadItem` and every Turn checkpoint has one non-empty `turnId`. Thread-level metadata updates made
 while no Turn is active update Thread metadata without manufacturing a turnless Item. A Rollout
@@ -384,7 +389,7 @@ message verbatim and does not copy attachment files. The agent reads a mentioned
 ```
 
 The renderer sends the composer's effort choice as `spec.reasoningEffort`. Composer values are `low`,
-`medium`, `high`, `xhigh`, and `max`; a missing or invalid local preference starts at `medium`. Model
+`medium`, `high`, `xhigh`, and `max`; a missing or invalid local preference starts at `high`. Model
 support varies, and an unsupported explicit value remains a provider request error rather than being
 silently downgraded.
 

docs/architecture/agent-turn-lifecycle.md

@@ -11,7 +11,7 @@ src-tauri/src/runtime/README.md
 src-tauri/src/threads/domain/README.md
 src-tauri/src/threads/rollout/store/README.md
 -->
-<!-- tinybot-doc-fingerprint: sha256:549fd76f9c28d4743007f8f9053fed32e671b6de7ebe4d3a821fe7d2e299aea7 -->
+<!-- tinybot-doc-fingerprint: sha256:242038ad076dad391f3a9aa0b30b90cad72c8d045e552b09e1a9581ec91a3660 -->
 
 A Turn begins with one user request and contains all provider iterations,
 reasoning records, tool calls, tool results, form checkpoints, and the terminal

docs/architecture/context-and-instructions.md

@@ -11,7 +11,7 @@ src-tauri/src/runtime/working_directory.rs
 src-tauri/src/system_prompt.rs
 src-tauri/src/workspace/README.md
 -->
-<!-- tinybot-doc-fingerprint: sha256:4740b7f5bf36ce5691febc3b89b54bdbd77ea348e35ca1b8eb498bfdd10e73e5 -->
+<!-- tinybot-doc-fingerprint: sha256:fbca262683bcc87d45f9c2fbc286d38a9ec94db6d2f1d92adc4d197a194dcf5c -->
 
 Tinybot composes model-visible instructions from explicit, traceable sources
 before the Agent Runtime builds the bounded provider request. Instruction
@@ -109,10 +109,11 @@ unbounded prompt text in diagnostics.
 
 Managed image attachments remain typed references on the originating user
 message. Rollouts retain only the managed path, MIME type, byte size, and
-content hash. When Responses history is encoded, the runtime revalidates the
-local file and creates a request-local Base64 data URL; later Turns repeat that
-encoding while the message remains in replayed context. Chat Completions fails
-explicitly when such a reference is present.
+content hash. Before constructing a provider request, the runtime verifies that
+the selected model declares image-input support. It then revalidates the local
+file and creates a request-local Base64 data URL; later Turns repeat that
+encoding while the message remains in replayed context. Chat Completions emits
+`image_url` content, while Responses emits `input_image` content.
 
 Trusted lifecycle command hooks may add bounded developer context after static
 instruction composition: at initial prompt submission, around a completed tool

docs/architecture/system-overview.md

@@ -16,7 +16,7 @@ src/react-workbench/agent-graph/README.md
 src/react-workbench/shell/README.md
 src/react-workbench/sidecar/README.md
 -->
-<!-- tinybot-doc-fingerprint: sha256:703f7c0745a79d90c144dd769971c79478584a5617dc1cceae0d70cdefa0668f -->
+<!-- tinybot-doc-fingerprint: sha256:a366d810c4cf5b2f00ffdc371b01e1210499a377d3b45d17a8243cb80d0a077c -->
 
 Tinybot Desktop is a local-first React and Rust application. The renderer owns
 presentation, the application core owns framework-independent UI contracts,
@@ -108,8 +108,9 @@ Desktop Commands / Desktop Host
   budget. The first visit to an Agent node creates a canonical Thread; later
   visits in the same Run continue it. Per-node role
   instructions and optional Provider, model, and reasoning-effort settings use
-  the existing Turn interfaces; the renderer only offers models from available
-  Provider connections, while absent settings inherit application defaults.
+  the existing Turn interfaces; the renderer only offers profile-enabled models
+  from available Provider connections and carries their image-input capability,
+  while absent settings inherit application defaults.
   Router decisions use a separate, single-shot, tool-free provider request and
   do not create Threads or load Agent instruction sources.
   Ordinary Chat Turns expose Graphs from their exact working directory as

docs/architecture/tool-execution-and-permissions.md

@@ -11,7 +11,7 @@ src-tauri/src/tools/registry/README.md
 src-tauri/src/tools/registry/mod.rs
 src-tauri/src/workspace/README.md
 -->
-<!-- tinybot-doc-fingerprint: sha256:9f4a8625b8ad11297f66d665d46d7cd090a8bc650a849fde2f082d0be7b8ace5 -->
+<!-- tinybot-doc-fingerprint: sha256:e83304a4f4b61acb66490f3d0962f567588e53e380eff3411556590c3109719e -->
 
 Tinybot exposes one protocol-neutral tool registry to the Agent Runtime. Tool
 metadata, per-Turn exposure, capability policy, execution routing, lifecycle,

docs/desktop.md

@@ -111,7 +111,7 @@ The page also offers an explicit Agent-assisted migration for standalone Skills,
 
 ## Conversation Models
 
-Model selection belongs to the conversation rather than a separate editable global default. Tinybot stores the recently used model as the starting choice for a new conversation, then persists the selected model in that Thread's metadata. Switching conversations restores each Thread's model, and changing the Composer model updates both the Thread and the recently used choice.
+Model selection belongs to the conversation after a Thread is created. The Provider & Models page, Chat drafts, empty Threads, and desktop-pet quick chat all use one Settings-store operation for the starting model: it saves the native `activeProfile`/`model` pair before mirroring that choice as the renderer's recently used preference. A first send waits for this save. The native pair is also the coherent fallback for background model work such as long-term Memory. When model options load, an explicitly selected native Profile paired with another Provider's model is repaired from a valid renderer preference or that Profile's default model and emits a structured warning. Switching populated conversations restores each Thread's own model, and changing their Composer model updates only the Thread.
 
 Desktop turn submission resolves models in this order:
 
@@ -120,7 +120,7 @@ Desktop turn submission resolves models in this order:
 3. the recently used model for new conversations;
 4. the native runtime's configured fallback when no user selection exists.
 
-Automatic turns, including Agent-assisted plugin migration, use the same resolution path. Provider profiles keep a provider-specific fallback model for connection setup and native runtime recovery, but that value is not presented as the user's current conversation model.
+Automatic turns, including Agent-assisted plugin migration, use the same resolution path. Provider profiles keep a provider-specific fallback model for connection setup and native runtime recovery, while background work without a Thread-specific selection uses the native default Profile/model pair.
 
 ## Desktop Adapters