{
    // 通用实用任务：标题生成、摘要、意图分类、重命名建议、终端命令/修复/解释、搜索助手、VS Code 问答
    "chat.utilityModel": "gcmp.deepseek/gcmp.deepseek:::deepseek-v4-pro",
    // 轻量实用任务：提交信息、分支名生成、进度消息、待办跟踪（建议用快速低成本模型）
    "chat.utilitySmallModel": "gcmp.deepseek/gcmp.deepseek:::deepseek-v4-flash",
    // 内联聊天（Inline Chat）默认模型
    "inlineChat.defaultModel": "GLM-4.7 (CodingPlan) (gcmp.zhipu)",
    // Agent 模式中的探索/规划子 Agent（如代码库搜索、方案规划）
    "chat.exploreAgent.defaultModel": "GLM-4.7 (CodingPlan) (gcmp.zhipu)",
    "chat.planAgent.defaultModel": "GLM-4.7 (CodingPlan) (gcmp.zhipu)",
    // GitHub Copilot Chat 各专用 Agent（Ask / Implement / Explore）
    "github.copilot.chat.askAgent.model": "GLM-4.7 (CodingPlan) (gcmp.zhipu)",
    "github.copilot.chat.implementAgent.model": "GLM-4.7 (CodingPlan) (gcmp.zhipu)",
    "github.copilot.chat.exploreAgent.model": "GLM-4.7 (CodingPlan) (gcmp.zhipu)",
    // GCMP 内置 Commit 消息生成模型
    "gcmp.commit.model": {
        "provider": "zhipu",
        "model": "glm-4.7"
    },
    // GCMP 内置视觉分析模型（必须支持图像输入）
    "gcmp.vision.model": {
        "provider": "zhipu",
        "model": "glm-4.6v"
    }
}

推荐规格：utilitySmallModel 选择响应快的模型（如 deepseek-v4-flash），可配合 maxInputTokens: 16384 等低规格满足快捷任务即可。通用任务（标题生成、摘要等）使用 chat.utilityModel。

在 settings.json 中编辑时，将光标置于值位置，使用 VS Code 智能提示从已注册的模型中选择即可。若未配置这些设置，VS Code 会使用 Copilot 内置模型执行实用任务，这可能会消耗免费用户的 Copilot 月度额度。推荐配置为 GCMP 模型，可避免实用任务占用 Copilot 配额。

也可通过命令面板执行 GCMP: 设置辅助工具模型，在可视化面板中统一配置上述所有模型。

入口快捷方式：悬停状态栏的 Token 消耗图标，在弹出的每日统计底部文本菜单中点击「设置辅助工具模型」即可进入同一面板。

• chat.utilitySmallModel：轻量实用任务模型（默认 gpt-4o-mini）。覆盖 chat-title（标题）、git-commit-message（提交信息）、git-branch-name（分支名）、inline-progress-message（进度消息）、prompt-categorizer（意图分类）、todo-tracker（待办跟踪）、rename-suggestions（重命名建议）、terminal-command/quickfix/explain（终端命令/修复/解释）、workspace-search（搜索助手）。
• chat.utilityModel：通用实用任务模型（默认 CAPI fallback）。覆盖 settings-resolver（设置搜索）、explain-code（代码解释）、vscode-qa（VS Code 问答）。
• inlineChat.defaultModel：内联聊天（Inline Chat）默认模型，用于编辑器内联对话（Ctrl+I / 右键 "在行内聊天"）。
• chat.exploreAgent.defaultModel：Explore 子 Agent 默认模型，用于 search-subagent 代码库探索与搜索。
• chat.planAgent.defaultModel：Plan 子 Agent 默认模型，用于 Agent 模式中的方案规划与任务拆解。
• github.copilot.chat.askAgent.model：Ask Agent 默认模型，用于 Ask 模式问答。
• github.copilot.chat.implementAgent.model：Implement Agent 默认模型，用于 Implement 模式代码实现。
• github.copilot.chat.exploreAgent.model：Explore Agent 默认模型，用于 Explore 模式代码库探索。
• gcmp.commit.model：GCMP 内置提交消息生成模型。
• gcmp.vision.model：GCMP 内置视觉分析模型，必须选择支持图像输入的模型。

通用模型参数 及 额外支持功能 配置

{
    "gcmp.retry.enabled": true, // 启用自动重试（默认 true），关闭后请求失败直接停止
    "gcmp.retry.maxAttempts": 3 // 1-10，仅对可重试错误生效
}

• gcmp.retry.enabled 默认值为 true，开启后自动重试 429 限流、503 服务繁忙等可重试错误。设为 false 可完全禁用重试，请求失败立即停止。
• gcmp.retry.maxAttempts 默认值为 3，用于控制 429 限流、502/503/504 服务端错误、网络中断等可重试错误的最大自动重试次数。
• 重试延迟按累加序列递增（1s → 3s → 6s → 10s → 15s），上限 15s。
• 重试期间状态栏会显示重试进度（如 模型名 retry [#2](https://github.com/VicBilibily/GCMP/issues/2)/3 in 3s），模型开始返回数据时自动清除。
• gcmp.maxTokens 已弃用：此设置不再生效，各模型现在自动使用自身的 maxOutputTokens 配置。

提供商级别重试配置覆盖

通过 gcmp.providerOverrides.{provider}.retry 可为每个提供商独立设置重试策略，覆盖全局 gcmp.retry.* 行为。maxAttempts 不受全局 1-10 上限约束，允许设置为任意正整数或 -1（无限重试）。

{
    "gcmp.providerOverrides": {
        "xfyun": {
            "retry": {
                "enabled": true,
                "maxAttempts": 15, // 不受 1-10 上限约束
                "maxDelayMs": 30000 // 最大延迟上限 30s
            },
            "retry.xfyun-coding": {
                // 子 provider 独立策略（优先级更高）
                "enabled": true,
                "maxAttempts": 20,
                "maxDelayMs": 60000
            }
        }
    }
}

合并优先级（字段级合并，每个字段独立回退）：

providerOverrides["retry.{subProvider}"] → providerOverrides.retry → 内置预置 → 全局默认

特殊语义：

各功能专属设置（如 gcmp.commit.enabled、gcmp.vision.model、gcmp.zhipu.search.enableMCP）分别在其对应的功能章节中说明，不在此处展开。

调试与 HAR 录制

{
    "gcmp.debug.captureHar": false, // 是否将所有 HTTP 请求记录为 HAR 文件（默认关闭）
    "gcmp.debug.harRetentionCount": 7 // 每个 VS Code 进程保留的最近 HAR 文件数量（0 表示仅禁用按数量清理，2 小时硬删除仍生效）
}

• 开启 gcmp.debug.captureHar 后，GCMP 会在 globalStorage/har/ 目录下按 VS Code 实例和日期生成 HAR 1.2 文件，方便排查兼容性与网关问题。
• FIM / NES 补全、Gist 同步、CLI OAuth 刷新等敏感或高频请求默认不录制，避免敏感凭据和大量重复请求落盘。
• 写入前会对敏感请求头、URL 查询参数及重定向 URL 中的凭据进行脱敏，但请求体和响应体仍会按原样保存，请妥善保管 HAR 文件。
• HAR 文件最长每 30 分钟轮换一次；超过 2 小时的旧文件会在新录制或文件轮换时强制删除。
• harRetentionCount 控制每个进程按数量保留的最近文件数；设为 0 时仅禁用按数量清理，2 小时硬删除仍会继续执行。

代理与系统证书配置

{
    "gcmp.proxy": "http://127.0.0.1:7890", // 全局代理（可选），推荐使用完整 URL
    "gcmp.tls.useSystemCertificates": true // 追加系统根证书（默认开启）
}

• gcmp.proxy 会作为扩展内所有网络请求的默认代理，包括：聊天请求、FIM / NES 补全、联网搜索、MCP 客户端、状态栏余额/用量查询、Compatible Provider 的"获取模型"请求，以及 CLI OAuth 刷新请求。
• 代理优先级为：model.proxy → gcmp.providerOverrides.<provider>.proxy → gcmp.providerOverrides.compatible.proxy（仅非内置 provider） → gcmp.proxy → VS Code http.proxy → 环境变量（HTTPS_PROXY / HTTP_PROXY）→ 系统代理（自动检测）。
• 代理地址支持 host:port 简写（如 127.0.0.1:7890），但推荐使用完整 URL，如 http://127.0.0.1:7890。
• 填写 noproxy 可显式绕过所有代理（包括系统代理和已配置代理），且在代理链路上任一层次设为 noproxy 时立即短路，不再继续回退。
• 当无显式代理配置时，扩展会自动检测 Windows 注册表或 macOS scutil 中的系统代理设置并自动沿用。

• ⚠️ 不支持 PAC (Proxy Auto-Config) 代理协议。若系统代理设为 PAC，扩展将忽略该配置，需要时请改为显式代理地址。

• gcmp.tls.useSystemCertificates 用于将操作系统信任的根证书追加到 Node.js 默认 CA 列表，适合企业代理、内网网关或本地安装自签根证书场景。
• 支持带认证的代理 URL，日志中会自动脱敏用户名和密码。

提供商配置覆盖

GCMP 支持通过 gcmp.providerOverrides 配置项来覆盖提供商的默认设置，包括 baseUrl、proxy、customHeader 等。

支持范围因提供商类型而异：

已知/自定义/compatible 提供商不支持 models[]，模型定义统一通过 gcmp.compatibleModels 配置。

配置优先级：

模型自身设置 > providerOverrides.{provider} > providerOverrides.compatible

• providerOverrides.compatible 作为全局默认值，对所有 Compatible Provider 下的模型生效
• 代理地址：model.proxy > providerOverrides.{provider}.proxy > providerOverrides.compatible.proxy（仅非内置 provider） > gcmp.proxy > VS Code http.proxy > 环境变量
• 自定义 HTTP 头：providerOverrides.{provider}.customHeader > 模型自身 customHeader > providerOverrides.compatible.customHeader
• 重试配置：providerOverrides["retry.{subProvider}"] > providerOverrides.retry > 内置预置 > 全局 gcmp.retry.*

配置示例：

{
    "gcmp.providerOverrides": {
        "dashscope": {
            "proxy": "http://127.0.0.1:7890", // 可选：提供商级默认代理
            "models": [
                {
                    "id": "deepseek-v3.2", // 增加额外模型：不在提示可选选项，但允许自定义新增
                    "name": "Deepseek-V3.2 (阿里云百炼)",
                    "tooltip": "DeepSeek-V3.2是引入DeepSeek Sparse Attention（一种稀疏注意力机制）的正式版模型，也是DeepSeek推出的首个将思考融入工具使用的模型，同时支持思考模式与非思考模式的工具调用。",
                    // "sdkMode": "openai", // 阿里云百炼已默认继承提供商设置，其他提供商模型可按需设置
                    // "baseUrl": "https://dashscope.aliyuncs.com/compatible-mode/v1",
                    "maxInputTokens": 128000,
                    "maxOutputTokens": 16000,
                    "capabilities": {
                        "toolCalling": true,
                        "imageInput": false
                    }
                }
            ]
        },
        "aihubmix": {
            "proxy": "http://127.0.0.1:7890", // 已知或自定义提供商也支持代理覆盖
            "customHeader": { "X-Custom": "value" },
            "retry": {
                // 提供商级重试覆盖
                "enabled": true,
                "maxAttempts": 5,
                "maxDelayMs": 30000
            }
        },
        "compatible": {
            "proxy": "http://127.0.0.1:7890" // 全局默认代理，所有 Compatible Provider 模型生效
        }
    }
}

自定义模型内置已知提供商ID及显示名称列表

聚合转发类型的提供商可提供内置特殊适配，不作为单一提供商提供。
若需要内置或特殊适配的请通过 Issue 提供相关信息。
已知提供商支持通过 gcmp.providerOverrides.{providerId} 覆盖 customHeader、proxy。

配置示例：

{
    "gcmp.compatibleModels": [
        {
            "id": "glm-4.6",
            "name": "GLM-4.6",
            "provider": "zhipu",
            "model": "glm-4.6",
            "sdkMode": "openai",
            "baseUrl": "https://open.bigmodel.cn/api/coding/paas/v4",
            // "proxy": "http://127.0.0.1:7890", // 可选：仅对该模型生效，也用于“获取模型”探测请求
            // "sdkMode": "anthropic",
            // "baseUrl": "https://open.bigmodel.cn/api/anthropic",
            "maxInputTokens": 128000,
            "maxOutputTokens": 4096,
            "capabilities": {
                "toolCalling": true, // Agent模式下模型必须支持工具调用
                "imageInput": false
                // "editTools": ["multi-find-replace", "find-replace", "code-rewrite"] // 可选：模型偏好的编辑工具，对应 VS Code LanguageModelChatCapabilities.editTools
            },
            // customHeader 和 extraBody 可按需设置
            "customHeader": {
                "X-Model-Specific": "value",
                "X-Custom-Key": "${APIKEY}"
            },
            "extraBody": {
                "temperature": 0.1,
                "top_p": 0.9,
                // "top_p": null, // 部分提供商不支持同时设置 temperature 和 top_p
                "thinking": { "type": "disabled" }
            }
            // "webSearchTool": true, // 可选：启用联网搜索（仅 sdkMode=anthropic / openai-responses 生效）
            // "nativeTools": [{ "type": "web_search" }] // 可选：注入原生工具（仅 sdkMode=openai-responses 生效）
        }
    ]
}

• gcmp.compatibleModels[*].proxy 仅作用于当前自定义模型；在填写 baseUrl 后点击“获取模型”时，也会使用同一代理设置进行探测。

sdkMode

gcmp.compatibleModels[*].sdkMode 指定请求/流式解析方式，可选值：openai（默认）、openai-sse、openai-responses、anthropic。

自定义 provider 余额/用量查询示例：usage + usages 智能合并

对于 Compatible 自定义 provider，可在 gcmp.providerOverrides.{providerId} 下配置：

• usage：可选；单一余额查询时只配置它即可，也可作为 usages 的公共默认值
• usages：可选；仅在需要多个命名金额/余额查询模式时使用，每个条目都可在 usage 基础上增量覆盖

也就是说：

• 只配置 usage：就是单一余额查询
• 需要多个查询模式时：再通过 usages 做多金额/多余额覆盖查询
• usage 和 usages 都不配置：就不会注册该自定义 provider 的余额/用量查询

内置已知 provider 的 usage / usages 参考配置方式，可直接查看源码 src/utils/knownProviders.ts。

注意：gcmp.providerOverrides 的 provider key 必须与 gcmp.compatibleModels[*].provider 完全一致，包括大小写。

例如，下面这个更贴近实际 settings.json 的 NekoCode 相关配置片段表示：

• gcmp.compatibleModels 下有多个模型共用同一个 provider: "NekoCode"
• gcmp.providerOverrides.NekoCode.usage 提供默认查询 URL https://api2.nekoapi.ai/v1/usage 和公共字段路径 balance
• gcmp.providerOverrides.NekoCode.usages.pay 与 usage 的最终查询配置等价，只额外提供显示名称 余额
• gcmp.providerOverrides.NekoCode.usages.sub 复用 usage.fields.balance，但把查询 URL 覆盖为 https://api2.nekoapi.ai/v1/user/balance

{
    "gcmp.compatibleModels": [
        {
            "id": "nekocode:gpt-5.5",
            "name": "GPT-5.5 (NekoCode)",
            "provider": "NekoCode",
            "model": "gpt-5.5",
            "sdkMode": "openai-responses",
            "baseUrl": "https://api2.nekoapi.ai/v1",
            "proxy": "noproxy",
            "maxInputTokens": 272000,
            "maxOutputTokens": 128000,
            "capabilities": {
                "toolCalling": true,
                "imageInput": true
            },
            "reasoningDefault": "xhigh",
            "reasoningEffort": ["none", "low", "medium", "high", "xhigh"],
            "extraBody": {
                "store": false,
                "reasoning": {
                    "effort": "xhigh",
                    "summary": "auto"
                }
            },
            "useInstructions": true,
            "customHeader": {
                "version": "0.134.0",
                "user-agent": "codex-tui/0.134.0 (Windows 10.0.26200; x86_64) unknown (codex-tui; 0.134.0)",
                "originator": "codex-tui"
            }
        }
    ],
    "gcmp.providerOverrides": {
        "NekoCode": {
            "usage": {
                "url": "https://api2.nekoapi.ai/v1/usage",
                "fields": {
                    "balance": "balance"
                }
            },
            "usages": {
                "pay": {
                    "displayName": "余额",
                    "url": "https://api2.nekoapi.ai/v1/usage"
                },
                "sub": {
                    "displayName": "订阅",
                    "url": "https://api2.nekoapi.ai/v1/user/balance",
                    "fields": {
                        "balance": "remaining"
                    }
                }
            }
        }
    }
}

该配置的实际效果是：

• providerOverrides.NekoCode 会同时作用于所有 provider: "NekoCode" 的兼容模型，例如上面的 GPT-5.4 (NekoCode) 和 GPT-5.5 (NekoCode)
• pay 会继承 usage.fields.balance = "balance"
• sub 也会继承 usage.fields.balance = "balance"
• 因为 pay 与 usage 解析出的查询配置等价，所以不会再额外生成一个重复的 default 模式

最终状态栏会按两个命名模式进行查询与展示：

• NekoCode / 余额
• NekoCode / 订阅

FIM / NES 内联补全建议模型配置

FIM 和 NES 补全都使用单独的模型配置，可以分别通过 gcmp.fimCompletion.modelConfig 和 gcmp.nesCompletion.modelConfig 进行设置。

代理配置：FIM 和 NES 支持通过 proxy 字段单独设置代理地址（如 http://127.0.0.1:7890），方便在不同网络环境下调试。支持带认证的代理，日志中会自动脱敏用户凭据。

• 启用 FIM 补全模式（推荐 DeepSeek、Qwen 等支持 FIM 的模型）：
  • 已测试支持 DeepSeek、硅基流动，特殊支持 阿里云百炼。

{
    "gcmp.fimCompletion.enabled": true, // 启用 FIM 补全功能
    "gcmp.fimCompletion.debounceMs": 500, // 自动触发补全的防抖延迟
    "gcmp.fimCompletion.timeoutMs": 5000, // FIM 补全的请求超时时间
    "gcmp.fimCompletion.modelConfig": {
        "provider": "deepseek", // 提供商ID，其他请先添加 OpenAI Compatible 自定义模型 provider 并设置 ApiKey
        "baseUrl": "https://api.deepseek.com/beta", // ⚠️ DeepSeek FIM 必须使用 beta 端点才支持
        // "baseUrl": "https://api.siliconflow.cn/v1", // 硅基流动(provider:`siliconflow`)
        // "baseUrl": "https://dashscope.aliyuncs.com/compatible-mode/v1", // 阿里云百炼(provider:`dashscope`)
        // "proxy": "http://127.0.0.1:7890", // 可选：单独设置代理地址
        "model": "deepseek-chat",
        "maxTokens": 100
        // "extraBody": { "top_p": 0.9 }
    }
}

• 启用 NES 手动补全模式：

{
    "gcmp.nesCompletion.enabled": true, // 启用 NES 补全功能
    "gcmp.nesCompletion.debounceMs": 500, // 自动触发补全的防抖延迟
    "gcmp.nesCompletion.timeoutMs": 10000, // NES 补全请求超时时间
    "gcmp.nesCompletion.manualOnly": true, // 启用手动 `Alt+/` 快捷键触发代码补全提示
    "gcmp.nesCompletion.modelConfig": {
        "provider": "zhipu", // 提供商ID，其他请先添加 OpenAI Compatible 自定义模型 provider 并设置 ApiKey
        "baseUrl": "https://open.bigmodel.cn/api/coding/paas/v4", // OpenAI Chat Completion Endpoint 的 BaseUrl 地址
        // "proxy": "http://127.0.0.1:7890", // 可选：单独设置代理地址
        "model": "glm-4.6", // 推荐使用性能较好的模型，留意日志输出是否包含 ``` markdown 代码符
        "maxTokens": 200,
        "extraBody": {
            // GLM-4.6 默认启用思考，补全场景建议关闭思考以加快响应
            "thinking": { "type": "disabled" }
        }
    }
}

• 混合使用 FIM + NES 补全模式：

• 自动触发 + manualOnly: false：根据光标位置智能选择提供者
  • 光标在行尾 → 使用 FIM（适合补全当前行）
  • 光标不在行尾 → 使用 NES（适合编辑代码中间部分）
  • 如果使用 NES 提供无结果或补全无意义，则自动回退到 FIM
• 自动触发 + manualOnly: true：仅发起 FIM 请求（NES 需手动触发）
• 手动触发（按 Alt+/）：直接调用 NES，不发起 FIM
• 模式切换（按 Shift+Alt+/）：在自动/手动间切换（仅影响 NES）

MistralAI Coding FIM 配置示例

{
    "gcmp.compatibleModels": [
        {
            "id": "codestral-latest",
            "name": "codestral-latest",
            "provider": "mistral",
            "baseUrl": "https://codestral.mistral.ai/v1",
            "sdkMode": "openai",
            "maxInputTokens": 32000,
            "maxOutputTokens": 4096,
            "capabilities": {
                "toolCalling": true,
                "imageInput": false
            }
        }
    ],
    "gcmp.fimCompletion.enabled": true,
    "gcmp.fimCompletion.debounceMs": 500,
    "gcmp.fimCompletion.timeoutMs": 5000,
    "gcmp.fimCompletion.modelConfig": {
        "provider": "mistral",
        "baseUrl": "https://codestral.mistral.ai/v1/fim",
        // "proxy": "http://127.0.0.1:7890", // 可选：单独设置代理地址
        "model": "codestral-latest",
        "extraBody": { "code_annotations": null },
        "maxTokens": 100
    }
}

熔断器（Circuit Breaker）

FIM 与 NES 补全请求连续失败时，熔断器会暂时停止请求，避免无限重试浪费资源和费用。

三态模型：

工作流程：

1. 请求连续失败达到 failureThreshold 后，熔断器从 Closed → Open
2. Open 状态下所有请求被立即拒绝，等待 cooldownSeconds 秒冷却
3. 冷却结束后首次 allowRequest() 进入 HalfOpen，发放一次探测请求
4. 探测成功（recordSuccess()）→ 回到 Closed，恢复服务
5. 探测失败（recordFailure()）→ 回到 Open，重新冷却。每冷却周期只重试一次（默认每 30 秒一次），直到成功或用户手动「立即重试」
6. 请求被用户取消（recordCancellation()）→ 不消耗 HalfOpen 探测名额，可重新探测

熔断通知：Open 状态首次触发时弹出通知提示（30 秒内不重复），支持「立即重试」恢复服务或「查看设置」跳转配置页。

配置项：

{
    // FIM 熔断器配置（默认启用）
    "gcmp.fimCompletion.circuitBreaker": {
        "enabled": true, // 启用熔断
        "failureThreshold": 10, // 默认 10，范围 2-60
        "cooldownSeconds": 30 // 默认 30，范围 10-300
    },
    // NES 熔断器配置（默认启用）
    "gcmp.nesCompletion.circuitBreaker": {
        "enabled": true, // 启用熔断
        "failureThreshold": 5, // 默认 5，范围 2-20
        "cooldownSeconds": 30 // 默认 30，范围 10-300
    }
}

配置修改即时生效，无需重启 VS Code。

快捷键与操作

主要特性

• 实时监控：状态栏以饼图图标实时显示当前会话的上下文窗口占用比例（0/1/8 ~ 8/8）
• 悬停详情：鼠标悬停可查看模型名称、占用百分比、Token 用量及请求来源类型
• 增量预估：支持基于上一轮 API 实际用量做增量预估，WebView 详细视图中会显示"本次新增"（~+xx）列，帮助追踪长会话中每轮请求的新增 Token 消耗

主要特性

• 持久化记录：基于文件系统的日志记录，无存储限制，支持长期数据保存
• 用量统计：记录每次 API 请求的模型和用量信息，包括：
  • 模型信息（提供商、模型 ID、模型名称）
  • Token 用量（预估输入、实际输入、输出、缓存、推理等）
  • 请求状态（预估/完成/失败）
• 多维度统计：按日期、提供商、模型、小时等多维度查看统计数据
  • 小时统计详情：支持按小时、提供商、模型三层嵌套显示
    • ⏰ 小时级别：显示该小时的总计数据
    • 📦 提供商级别：显示该提供商在该小时的汇总数据
    • ├─ 模型级别：显示该模型在该小时的详细数据
    • 提供商和模型按请求数降序排列，无有效请求的提供商和模型不显示
• 实时状态栏：状态栏实时显示今日 Token 用量，30秒自动刷新
• 可视化视图：WebView 详细视图支持查看历史记录、分页显示请求记录
• 请求来源分类：记录并显示每次请求的 Copilot 请求类型（如主 Agent、标题生成、提交消息、搜索子 Agent、视觉识别等），便于追踪后台实用任务的实际消耗
• 实时请求指标：流式阶段实时展示首流延迟（TTFT）与输出耗时（TPOT），完成后由真实 usage 自然刷新
• 实时输出 token 估算：流式阶段基于 tokenizer 实时估算输出 token 与输出速度（tokens/s），输出列以"最近一次接收的预估增量"（+xx tks）形式展示，完成后由真实 usage 覆盖
• 缓存命中率可视化：输入列合并展示缓存命中数与输入总数，并显示缓存命中率，帮助判断缓存策略效果
• 客户端成本估算：支持峰谷分档定价、服务等级（serviceTier）计费和上下文大小条件分档，Token 数量下方内联显示预估成本，状态栏、详情页、多日趋势页均集成展示
• 双币种成本展示：定价配置支持 USD/RMB 双币种并列，按模型原生结算币种标记展示；状态栏（中文环境）、详情页、侧边栏日期列表与会话记录、多日趋势页均支持成本双币显示，并新增 USD/RMB 货币切换视图
• 多日成本视图：多日趋势图新增成本趋势折线图与成本卡片汇总

使用方式

• 查看统计：点击状态栏的 Token 用量显示，或通过命令面板执行 GCMP: 查看今日 Token 消耗统计详情 命令
• 历史记录：在详细视图中可查看任意日期的统计记录
• 数据管理：支持打开日志存储目录进行手动管理

配置选项

{
    "gcmp.usages.retentionDays": 100 // 历史数据保留天数（0表示永久保留）
}

系统要求

• vscode.git 扩展：该功能依赖 VS Code 内置的 vscode.git 扩展来访问 Git 仓库信息
  • 扩展会自动检测 Git 可用性，当 Git 不可用时相关按钮将自动隐藏
  • 如果你的环境中禁用了 vscode.git 扩展，Commit 消息生成功能将不可用

使用入口：Git仓库管理视图

• 仓库标题栏按钮：生成提交消息
• 更改分组栏按钮：
  • 在“暂存的更改”上生成：生成提交消息 - 暂存的更改
  • 在“更改”上生成 生成提交消息 - 未暂存的更改

生成范围说明（staged / working tree）

• 生成提交消息：默认行为，同时分析 staged + working tree（tracked + untracked）。
• 生成提交消息 - 暂存的更改：仅分析 staged，适合“分步提交/拆分提交”。
• 生成提交消息 - 未暂存的更改：仅分析 working tree（tracked + untracked），不包含 staged。

多仓库工作区：如果当前工作区包含多个 Git 仓库，GCMP 会尝试根据你点击的 SCM 区域推断仓库；无法推断时会弹出仓库选择。

模型选择与配置

该功能基于 VS Code Language Model API 调用模型。

• 第一次使用或未配置模型时，会自动引导选择模型（也可手动运行 GCMP: 选择 Commit 消息生成模型）。
• 相关配置项：

{
    "gcmp.commit.enabled": true, // 启用内置提交消息生成功能（默认 true，将在下个主版本移除）
    "gcmp.commit.language": "chinese", // 生成语言：chinese / english（auto 模式语言不明确时的回退值）
    "gcmp.commit.format": "auto", // 提交消息格式：auto(默认) / 见下方 format 说明
    "gcmp.commit.customInstructions": "", // 自定义指令（仅当 format=custom 时生效）
    "gcmp.commit.sensitiveFiles": ["*.pem", "**/.env.local", "secrets/**"], // 额外排除在 diff 分析之外的敏感文件路径模式
    "gcmp.commit.model": {
        "provider": "zhipu", // 生成模型的提供商（providerKey，例如 zhipu / minimax / compatible）
        "model": "glm-4.6" // 生成模型的 ID（对应 VS Code Language Model 的 model.id）
    }
}

gcmp.commit.sensitiveFiles 过滤规则说明

gcmp.commit.sensitiveFiles 用于补充内置敏感文件过滤规则。它接收一组简单的类 glob 字符串：

• *.pem：匹配任意 .pem 文件
• **/.env.local：匹配任意目录下的 .env.local
• secrets/**：匹配 secrets/ 目录下的所有文件
• **/private/*.key：匹配任意 private 目录下的 .key 文件

命中后，该文件不会参与 Commit diff 分析，也不会被发送给模型用于生成提交消息。

gcmp.commit.format 格式说明与示例

说明：以下示例仅用于展示格式形态；实际内容会根据你的 diff 自动生成。

• auto：自动推断（会参考仓库历史的语言/风格；不明确时回退为 plain + gcmp.commit.language），默认推荐。

• plain：简洁一句话，不含 type/scope/emoji（适合快速提交）。

• custom：完全由你的自定义指令控制（gcmp.commit.customInstructions）。

• conventional：Conventional Commits（可带 scope，常见写法是“标题 + 可选正文要点”）。

feat(commit): 新增提交消息生成

- 支持 staged / 未暂存分别生成
- 自动补充相关历史提交作为参考

• angular：Angular 风格（type(scope): summary，语义上接近 conventional）。

feat(commit): 新增 SCM 入口

- 在仓库标题栏与更改分组栏增加入口

• karma：Karma 风格（偏“单行”，保持短小）。

fix(commit): 修复多仓库选择

• semantic：语义化 type: message（不带 scope；也可以带正文要点）。

feat: 新增提交消息生成

- 自动识别本次变更的关键 diff

• emoji：Emoji 前缀（不带 type）。

✨ 新增提交消息生成

• emojiKarma：Emoji + Karma（emoji + type(scope): msg）。

✨ feat(commit): 新增提交消息生成

- 更贴合仓库既有提交习惯

• google：Google 风格（Type: Description）。

Feat: 新增提交消息生成

- 支持按仓库风格自动选择语言与格式

• atom：Atom 风格（:emoji: message）。

:sparkles: 新增提交消息生成

工具列表

使用方式

视觉工具通过 # 引用调用，例如 #gcmpUiToArtifact。调用时可直接粘贴图片、截图或引用图片文件路径，模型会基于图片内容生成对应产物或分析结果。所有工具共用同一个视觉分析模型配置。

配置视觉分析模型

视觉工具依赖 gcmp.vision.model 指定的多模态模型。首次调用视觉工具时若未配置，会自动拉起选择向导；也可手动运行命令 GCMP: 选择视觉分析模型，或通过 GCMP: 设置辅助工具模型 面板统一配置。

{
    "gcmp.vision.model": {
        "provider": "zhipu",
        "model": "glm-4.6v"
    }
}

• 所选模型必须支持图像输入能力（capabilities.imageInput: true）。
• 支持选择内置提供商模型、已配置图像输入能力的 Compatible Provider 模型，也支持选择 GitHub Copilot 原生多模态模型（将 provider 设为 copilot，model 设为 Copilot 模型 ID）。
• 未配置时首次调用会自动引导选择模型，无需提前手动填写 JSON。

存储原理

加密流程

GitHub 数字ID + pepper + [自定义口令] → scrypt(N=16384, r=8, p=1) → AES-256 密钥
                                                                       ↓
 每个 API Key → 随机 Salt(32B) + 随机 IV(16B) → AES-256-GCM 加密 → Salt+IV+Tag+密文 → JSON

• 每条密钥加密时使用独立的随机盐值和初始向量，相同明文每次加密结果不同
• 加密后的数据包包含 Salt、IV、Tag（认证标签）和 密文，全部以十六进制字符串编码
• 解密依赖于 GitHub 用户数字 ID：同一 GitHub 账号在不同设备上登录，派生出的加密密钥相同，因此可以互相解密

自定义加密口令

由于扩展是开源项目，加密方式（pepper、scrypt 参数等）均可在源码中直接查看。如果希望额外加强保护，可以设置自定义加密口令。

• 在同步菜单中选择「设置加密口令」即可添加，输入两次确认
• 口令与 GitHub 用户 ID、pepper 共同参与密钥派生，三者缺一不可（最少 8 个字符）
• 口令更改后，之前用旧口令加密的数据将无法再解密（派生密钥不同）
• 口令通过 VS Code SecretStorage 存储在本地（操作系统级加密），不会上传到任何服务器
• 同一 GitHub 账号的不同设备需设置相同的口令才能互相解密

下载时的口令验证

下载时如果本地口令与上传时不匹配，会自动弹出提示：

• 已设置口令但无法解密 → 提示口令可能已更改，引导输入之前使用的口令
• 未设置口令但数据无法解密 → 提示数据可能在其他设备上用口令加密过，引导输入
• 输入口令后自动验证：解密成功则自动存储正确口令，后续下载无需再次输入
• 若只有部分密钥能解密，会提示数量不匹配

跨设备提示

设置口令时会弹出提示，告知多设备同步需要所有设备使用相同口令：

• 首次设置：提示请牢记口令并在所有设备上设置
• 更改口令：提示更改后需在所有设备上同步更新

数据兼容性

• 已有 Gist 数据时设置/更改口令，可选择**「设置并重新上传」**直接进入上传流程，避免遗漏
• 清除口令时需确认，清除后现有加密数据将无法再解密

安全说明

• Gist 会暴露在用户的 Gist 列表中，但内容经过 AES-256-GCM 加密，未经解密不可读
• 加密密钥不在网络中传输
• 本地 API Key 通过 VS Code SecretStorage 存储，操作系统级加密保护
• 所有网络请求均通过 HTTPS