Model providers answer questions or create embeddings. MCP providers remain a separate protected integration surface for external product actions. A Google model provider and a Google Gmail MCP connection are separate integrations with separate credentials, policies, and ownership.

Do not put MCP OAuth credentials into the normal model-provider configuration. MCP uses dedicated provider profiles and dedicated per-user connection records so existing Google, GitHub, Drive, and other integrations remain compatible.

The Thinking selector is model-aware. DeepSpace uses provider-advertised model metadata when available and falls back to a verified model-family profile. If the selected model's cached metadata is missing or stale, DeepSpace refreshes that provider's model catalog in the background and updates the selector when the response arrives. It shows only levels confirmed for that model, including provider-specific names with readable labels.

Each provider receives its own native reasoning control. For example, a provider may map the displayed levels to low, high, and maximum effort internally. Selecting Off sends an explicit disable request where the provider supports disabling reasoning. A model that does not support a setting is never forced into it. A provider catalog that omits reasoning details cannot prove which effort levels an unfamiliar model accepts, so DeepSpace keeps that model on its provider default until a verified profile or explicit metadata is available.

The composer context meter uses the selected model's current context limit when the provider exposes it, then verified provider metadata as a fallback. It is an estimate of the serialized request and output budget, not a billing counter. Unknown model limits are shown as unavailable rather than guessed.

• Cline API uses a Cline API key and its OpenAI Chat Completions route. AverQel loads model IDs from Cline's public OpenAI-style /models route; exact provider/model-name IDs can also be entered manually. Cline does not publish an embeddings route. Streaming and function tools use the documented Chat Completions format. Model discovery reads the public catalog without sending the API key and does not validate the key or model access. AverQel's runtime check is degraded because it does not send a billable chat request; model availability still depends on the Cline account.
• Mistral AI uses a Mistral API key, lists account-accessible models, and supports chat and embeddings. Its current reasoning models use Mistral's reasoning_effort field; Off maps to none where the model exposes that control.
• Meta AI uses a Meta Model API key, lists available models, and routes chat through the Responses API. The provider omits image, voice, and segmentation models from the chat picker, does not offer embeddings, and sends store: false for stateless Meta responses. DeepSpace currently sends text, attached images, and tools; Meta-specific video, audio, PDF, and image-generation routes are not exposed. Muse Spark keeps its reasoning private and uses Meta's sampling defaults; Off omits the effort field because Muse Spark rejects none and may still reason at its default level. Extreme High maps to max on Standard Muse Spark 1.3 and to xhigh on contributor or older models.

• Moonshot AI (Kimi) uses the OpenAI Chat Completions API at https://api.moonshot.ai/v1. AverQel loads models and keeps the vendor's safe context, modality, and reasoning metadata. Kimi does not expose an embeddings route in its API reference. Reasoning controls follow the selected model: Kimi K3 maps Low, High, and Extreme High to its supported effort values; Kimi K2.6 supports its thinking switch; K2.7-Code always thinks.
• Z.AI (GLM) uses the documented OpenAI-compatible chat route at https://api.z.ai/api/paas/v4. Enter the exact GLM model ID in the provider settings because Z.AI's API reference does not publish a model-list endpoint. GLM-5.3 supports Low, High, and Max effort and always reasons; GLM-5.2 supports effort plus an Off switch; earlier supported GLM families use the documented thinking toggle. The integration does not advertise embeddings.
• NVIDIA NIM uses the NVIDIA-hosted OpenAI-compatible API by default at https://integrate.api.nvidia.com/v1. The provider supports chat, model discovery, and the documented embeddings route. Some NVIDIA embedding models require an input_type; AverQel sends query for retrieval andpassage for indexing for the model families that document that field. NIM serves multiple model families. AverQel uses model metadata or verified family profiles for reasoning controls; for example, Nemotron 3 Ultra exposes Off, Medium, and High, while Super exposes Off, Low, and High. Other NIM models keep their provider default unless the catalog or a verified profile describes their controls. A self-hosted NIM can use its own base URL.
• Manus Agent API creates private asynchronous tasks through Manus API v2. Its model choices are agent profiles (Standard, Lite, and Max with supported Max thinking levels), not independently selectable LLM model IDs. AverQel polls the task until it finishes and then returns the final answer; Manus does not stream answer tokens through this API. Stopping generation requests cancellation of the remote Manus task. User image attachments are uploaded to Manus and attached to the task. A task waiting for a question or action is reported with a link to continue in Manus; AverQel does not approve actions automatically. The integration does not provide embeddings, token usage, or AverQel function-tool calls. The API key and prompt are sent to Manus to run the task.

AverQel Desktop includes a Codex Login tab under the OpenAI provider. It first checks whether the local Codex CLI is signed in to a ChatGPT account. When it is, AverQel uses Codex's local app-server for account/model discovery and inference; it does not read the CLI credential file or copy its tokens. A CLI API-key session is not treated as ChatGPT plan access. If no usable CLI ChatGPT session is available, the user can sign in through OpenAI in the system browser. Those OAuth credentials are encrypted with the operating system's desktop credential storage and stay on that desktop. Browser sign-in is unavailable if secure operating-system storage is unavailable. Removing a browser-signed-in account clears its local credentials; AverQel reports whether OpenAI confirmed token revocation and directs users to ChatGPT Settings → Usage if it could not.

The CLI path uses Codex app-server's account and model-list methods. Its model list is a catalog, not proof that every model is enabled for the account; OpenAI checks model access when a request is made. The browser sign-in path loads visible models from OpenAI's /v1/models endpoint and streams Responses API requests with store: false. Both paths run through the Electron main process. Provider settings store an opaque local-account identifier and discovered model metadata; the raw CLI email and credentials stay on the desktop. The backend relays inference through a one-use WebSocket ticket and transient request/response frames. DeepSpace still stores conversation history under its existing retention settings. The desktop must remain open and the account must remain signed in while this provider is in use.

Codex app-server starts outside the project in the operating system's temporary directory, and each inference gets a private temporary workspace. Inference is enabled only when the installed CLI supports AverQel's restricted permission profile, which denies filesystem access except for minimal runtime paths. Shell, MCP, hooks, apps, plugins, subagents, web search, and Codex's local conversation history are disabled. API keys and other token-like environment variables are removed from the Codex subprocess. Older or incompatible CLI versions fall back to browser sign-in.

This option is available only in the AverQel desktop packages for Windows, Linux, and macOS. It is a DeepSpace chat connection; it does not provide API-key billing, embeddings, general Codex CLI agent access, or every hosted Responses API tool. The CLI app-server protocol is experimental; older or incompatible CLI versions use the browser sign-in option instead. Model capabilities and account eligibility come from OpenAI and can change. OpenAI's Sign in with ChatGPT guidancedescribes this integration as a preview and requires its eligibility process for paid or remotely hosted apps. Users may be unable to authorize an account until OpenAI approves the application.

Local OAuth storage does not make DeepSpace conversations local-only. The existing DeepSpace backend receives and stores prompts and conversation history. OpenAI requests use store: false, but AverQel's conversation retention settings still apply.

OpenAI account and usage restrictions are reported as provider errors. A ChatGPT plan usage-limit response is not automatically retried or sent through a different billing path; check ChatGPT settings and retry only when the account can make another request.

AverQel Desktop can use LM Studio or Ollama installed on the same computer. Start LM Studio's OpenAI-compatible server at http://127.0.0.1:1234/v1 or Ollama at http://127.0.0.1:11434, choose the provider, and select This computer. The Electron main process validates the loopback URL and streams chat, model discovery, health, embeddings, and Ollama pulls through the existing authenticated desktop relay.

LM Studio and Ollama are shown as unavailable in the hosted web app because its browser cannot reach a user's loopback process. Open AverQel Desktop to configure them. The desktop option does not make the complete application offline: authentication, conversation storage, DeepSpace orchestration, and tools continue to use the AverQel backend. AverQel does not bundle either runtime or download LM Studio models.

Every model selector in provider settings includes a search field. Search by model ID, display name, model type, context size, or discovered capability metadata such as runtime and quantization. Matching ignores letter case and punctuation, and multiple words narrow the results together. The search covers models AverQel has discovered for that provider; when model discovery is disabled, enter the endpoint's model ID in the search field and choose the exact-ID option.

Add a custom provider for an endpoint that follows either the Chat Completions or Responses request and response format. Enter the API root URL, such as https://gateway.example/v1, then select the protocol that the server implements. AverQel converts its conversation, image, and function-tool data to the selected protocol. A custom route changes the URL path; it does not translate an unrelated API schema. Responses may use the standard protocol object directly or wrap a successful result in a { success: true, data: ... } envelope.

Model discovery uses the configured models route. If discovery is disabled, the provider health status is shown as degraded because AverQel cannot verify chat connectivity without sending a potentially billable generation request. Existing cached models remain available, and you can set the exact chat or embedding model ID in the provider form.

When an endpoint rejects a request field, turn off temperature or select its documented output-token field. For a reasoning error such as Unsupported parameter(s): enable_thinking, leave the reasoning controls unconfigured unless the endpoint explicitly documents them. AverQel does not infer custom endpoint controls from a model name.

Add SearXNG (Self-hosted) from the Web provider tab and enter the URL reachable by the AverQel API, for example http://searxng:8080 when both services share a private Docker network. SearXNG must have its JSON search format enabled. No API key is required.

DeepSpace invokes the bounded web_search tool only when the selected model requests it. Results are fetched server-side, filtered by the configured domain policy, and returned with titles, URLs, snippets, source engines, and available publication dates. The final Markdown response receives a Sources section with links.

Requests use bounded timeouts, Redis-backed per-user rate limits, redirect blocking, URL validation, and endpoint SSRF checks. The model never receives shell or cURL access; it receives only the typed web-search tool and sanitized result data. MCP remains a separate integration surface.

1. AverQel publishes a curated marketplace entry with the official remote endpoint, reviewed tools, requested scopes, and risk policy.
2. An administrator configures AverQel's Google or GitHub OAuth client ID, client secret, and exact callback URI on the VPS.
3. The user selects Connect and is redirected to Google or GitHub.
4. The provider returns an authorization result to AverQel's signed callback.
5. AverQel verifies scopes and account identity, encrypts the token material, refreshes the safe catalog, and opens the connection inspector.
6. MCP actions remain available only through the current user's approved connection after policy and scope checks pass.

If an OAuth client is not configured, the marketplace entry remains visible but shows Setup pending. This is an operator configuration state, not a request for users to give AverQel their Google or GitHub password.

Notion uses its official remote Streamable HTTP MCP endpoint with OAuth discovery and dynamic client registration. AverQel uses PKCE and stores the resulting credentials only in the encrypted per-user MCP token record.

Slack uses its official remote MCP endpoint with confidential OAuth. An administrator must configure an approved Slack app's AKS_MCP_SLACK_OAUTH_CLIENT_ID and AKS_MCP_SLACK_OAUTH_CLIENT_SECRET values on the VPS, together with the same HTTPS callback used by the MCP OAuth service. The catalog requests the reviewed Slack read and write user scopes. Read actions are read-only; message sending, channel changes, reactions, and canvas changes require explicit AverQel approval.

After the required provider setup is available, both entries use the same flow: Connect, provider consent, signed callback, scope verification, encrypted token storage, live tool discovery, policy checks, and DeepSpace routing.

• Official: reviewed provider operated by the represented vendor.
• Community: reviewed third-party provider; it is never automatically official.
• New: recently added provider within its catalog review period.
• Trending: reviewed popularity signal with explicit review metadata.
• Interactive: reviewed support for interactive workflows.

These are catalog attributes, not security permissions. Approval status controls whether a provider can be connected; badges help users understand provenance and product status.

Remote HTTP means a vendor-hosted HTTPS Streamable HTTP MCP endpoint. Remote SSE means a vendor-hosted HTTPS Server-Sent Events MCP endpoint. AverQel validates remote endpoints and does not let the browser probe them directly.

Stdio, SSH, and local process transports are not supported in this release. AverQel does not clone or execute arbitrary vendor MCP repositories on the VPS. This reduces supply-chain and host-execution risk while the product focuses on approved remote services.

Marketplace previews are reviewed metadata. Once connected, AverQel can refresh the live tool catalog and records a safe catalog revision and health status. Health is an operational signal, not an uptime guarantee, and remote providers can change tools or permissions.

The runtime rejects stale catalogs, disabled providers, revoked connections, removed tools, and policy violations. The frontend receives only typed safe DTOs; provider tokens, client secrets, raw OAuth metadata, and raw MCP event payloads remain server-side.

The vendor owns its MCP implementation, endpoint availability, OAuth application, and tool behavior. AverQel owns the marketplace review, tenant/user connection, encryption, policy, approval, runtime routing, and safe inspection. Keeping those responsibilities separate makes provider updates safer and prevents unreviewed code from running inside AverQel.

• Chat runtimes include OpenRouter, OpenAI-compatible providers, Cline, Mistral, Meta, Anthropic, Google, Ollama, LM Studio, and OpenCode Zen.
• Embedding runtimes include local deterministic paths, sentence-transformers, OpenRouter, Mistral, Ollama, LM Studio, and embedding-capable OpenAI-compatible providers.
• Reranking and web search use their own provider routing and secret boundaries.

These model-provider flows remain separate from the remote MCP marketplace and are not replaced by it.