{
    // 通用实用任务：标题生成、摘要、意图分类、重命名建议、终端命令/修复/解释、搜索助手、VS Code 问答
    "chat.utilityModel": "gcmp.deepseek/gcmp.deepseek:::deepseek-v4-pro",
    // 轻量实用任务：提交信息、分支名生成、进度消息、待办跟踪（建议用快速低成本模型）
    "chat.utilitySmallModel": "gcmp.deepseek/gcmp.deepseek:::deepseek-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-flash），可配合 maxInputTokens: 16384 等低规格满足快捷任务即可。通用任务（标题生成、摘要等）使用 chat.utilityModel。

在 settings.json 中编辑时，将光标置于值位置，使用 VS Code 智能提示从已注册的模型中选择即可。

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

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

• chat.utilitySmallModel：轻量实用任务模型。覆盖 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：通用实用任务模型。覆盖 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 → 内置预置 → 全局默认

特殊语义：

提供商级别限流配置（limit）

通过 gcmp.providerOverrides.{provider}.limit 可为每个提供商独立设置请求限流。支持四个维度，0 或缺省表示该维度不限；任一维度触顶即自主延迟（匀速 pacing）或排队等待。

{
    "gcmp.providerOverrides": {
        "dashscope": {
            "limit": { "rpm": 60, "parallel": 3 },
            // 子 provider 独立限流（优先级更高）
            "limit.dashscope-coding": { "rpm": 30 },
            "models": [
                // 模型级限流：字段级覆盖 provider 级同名维度，并使用独立的 provider::model 限流桶
                { "id": "deepseek-v4-pro", "limit": { "tpm": 100000 } }
            ]
        }
    }
}

合并优先级（与 retry 一致，字段级合并）：

providerOverrides["limit.{subProvider}"] → providerOverrides.limit → 内置预置

跨实例行为：多个本地 VS Code 窗口共享 Leader 权威限流桶（窗口间自动选举），维度以 Leader 本机配置为准，配置修改即时生效；Leader 不可用时自动降级为单窗口本地桶并每 60 秒探测恢复，恢复后自动回到跨实例严格模式；窗口关闭或断线时，其排队请求与持有的配额会被自动回收，不会阻塞其他窗口。Remote（SSH/WSL/容器等）窗口统一使用兼容模式，不参与 Leader 选举、心跳或交接，不启用 IPC 和文件协调通道；各窗口使用本地限流桶，在当前宿主启动时生成当天 Token 统计，并独立执行统计、余额和模型/CLI 元数据的周期刷新及过期日志清理，周期任务仍遵守用户活动、缓存过期和保留天数设置；不影响本地窗口的 Leader，状态栏显示“兼容模式”。

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

状态栏余额警告阈值

余额型状态栏默认在可用余额不高于 20 时显示黄色背景，负余额显示红色背景。可通过 gcmp.providerOverrides.{provider}.balanceWarning 按提供商覆盖阈值，设置为 0 可仅在欠费时标红。

{
    "gcmp.providerOverrides": {
        "deepseek": {
            "balanceWarning": 10
        },
        "moonshot": {
            "balanceWarning": 30
        },
        "compatible": {
            // 未单独设置的 Compatible provider 使用 compatible 默认阈值
            "balanceWarning": 20
        }
    }
}

• 适用 DeepSeek、Moonshot、纯余额模式的智谱/CommandCode，以及 Compatible 中的各余额查询提供商。
• 数值单位与提供商返回的余额单位一致；套餐用量状态栏仍按用量百分比警告。
• 修改设置会立即按当前缓存重绘背景，不会额外发起余额查询请求。

调试与 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 刷新等敏感或高频请求默认不录制，避免敏感凭据和大量重复请求落盘。
• Responses WebSocket 请求不录制为 HAR；独立的用量统计和请求记录仍正常处理，服务端未返回用量时不会补造数据。
• 写入前会对敏感请求头、URL 查询参数及重定向 URL 中的凭据进行脱敏，但请求体和响应体仍会按原样保存，请妥善保管 HAR 文件。
• HAR 文件最长每 30 分钟轮换一次；超过 2 小时的旧文件会在新录制或文件轮换时强制删除。
• harRetentionCount 控制每个进程按数量保留的最近文件数；设为 0 时仅禁用按数量清理，2 小时硬删除仍会继续执行。

代理与系统证书配置

{
    "gcmp.proxy": "http://127.0.0.1:7890", // 全局代理（可选），推荐使用完整 URL
    "gcmp.machineOverrides": {
        "dashscope": {
            "proxy": "http://127.0.0.1:7891", // 当前机器的提供商代理
            "models": [
                {
                    "id": "deepseek-v3.2",
                    "proxy": "noproxy" // 当前机器上仅此模型绕过代理
                }
            ]
        },
        "codex": {
            "proxy": "noproxy" // 当前机器上所有 Codex 模型绕过代理
        }
    },
    "gcmp.tls.useSystemCertificates": true // 追加系统根证书（默认开启）
}

• gcmp.proxy 会作为扩展内所有网络请求的默认代理，包括：聊天请求、FIM / NES 补全、联网搜索、MCP 客户端、状态栏余额/用量查询、Compatible Provider 的"获取模型"请求，以及 CLI OAuth 刷新请求。
• gcmp.machineOverrides 是不会参与设置同步的机器级总配置入口；当前支持在每个 Remote SSH 窗口的“远程”设置中按 provider 配置 proxy，或在 models[] 中按模型 id 配置 proxy。
• gcmp.machineOverrides 的 Provider ID 区分大小写，键名必须与模型或内置配置中的 Provider ID 完全一致；例如 Acme 与 acme 是两个不同的 Provider。
• gcmp.providerOverrides.<provider>.proxy 与内置 Provider 的 models[].proxy 保持兼容并参与设置同步；需要每台机器使用不同代理时，请使用 gcmp.machineOverrides。gcmp.compatibleModels[*].proxy 仍是模型自身配置。
• 代理优先级为：gcmp.machineOverrides.<provider>.models[] 匹配模型 → 模型自身 model.proxy → gcmp.machineOverrides.<provider>.proxy → gcmp.providerOverrides.<provider>.models[] 匹配模型 → gcmp.providerOverrides.<provider>.proxy → 提供商内置代理 → 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 覆盖提供商默认设置，包括兼容原有的同步代理字段；仅当前机器使用的代理覆盖请使用 gcmp.machineOverrides，且其优先级更高。

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

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

配置优先级：

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

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

配置示例：

{
    "gcmp.providerOverrides": {
        "dashscope": {
            "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": {
            "customHeader": { "X-Custom": "value" },
            "retry": {
                // 提供商级重试覆盖
                "enabled": true,
                "maxAttempts": 5,
                "maxDelayMs": 30000
            }
        }
    }
}

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

聚合转发类型的提供商可提供内置特殊适配，不作为单一提供商提供。
若需要内置或特殊适配的请通过 Issue 提供相关信息。
已知提供商支持通过 gcmp.providerOverrides.{providerId} 覆盖同步的 proxy、customHeader、retry；仅当前机器使用的代理请配置 gcmp.machineOverrides.{providerId}。

配置示例：

{
    "gcmp.compatibleModels": [
        {
            "id": "glm-4.7",
            "name": "GLM-4.7",
            "provider": "zhipu",
            "model": "glm-4.7",
            "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
            },
            // 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 生效）
            // "cacheTtl": "1h" // 可选：Anthropic 提示缓存 TTL（仅 sdkMode=anthropic 生效），省略为默认 5m；1h 缓存写入约为基础输入价 2 倍
        }
    ]
}

提示：使用 OpenAI Responses / 兼容转发时，将 extraBody.include 显式设为 null 或 [] 会同时关闭历史推理的密文和明文回放，不会改用明文替代密文。需要请求并回传密文时，请在该数组中包含 reasoning.encrypted_content。GPT 模型不回传明文推理；其他模型仅在未显式配置 include 时允许明文回放。回放仅使用当前消息或其中保留的 StatefulMarker，不恢复已裁剪或丢失的推理状态。

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

sdkMode

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

gemini-sse 对 Google 官方端点使用 x-goog-api-key，对第三方网关默认使用 Authorization: Bearer，并请求 /v1beta/models/{model}:streamGenerateContent?alt=sse；可通过 customHeader 覆盖或删除默认鉴权头。extraBody.generationConfig 会合并到 generationConfig，其余字段按 Gemini GenerateContent 顶层字段透传（contents、tools、systemInstruction 等核心字段除外）。serviceTier 支持 unspecified、standard、flex、priority。

Responses WebSocket（实验性）：useWebSocket

仅有效 sdkMode 为 openai-responses 的模型可设置 useWebSocket，默认关闭。在 Compatible 模型编辑器中选择 OpenAI Responses 模式后，可勾选「使用 WebSocket（实验性）」；也可在 settings.json 的模型配置中设置：

{
    "gcmp.providerOverrides": {
        "codex": {
            "models": [
                {
                    "id": "gpt-5.6-sol",
                    "useWebSocket": true // 按需实验性开启
                }
            ]
        }
    },
    "gcmp.compatibleModels": [
        {
            "id": "responses-example",
            "name": "Responses Example",
            "provider": "your-provider",
            "model": "your-responses-model",
            "sdkMode": "openai-responses",
            "baseUrl": "https://api.example.com/v1",
            "useWebSocket": true,
            "maxInputTokens": 128000,
            "maxOutputTokens": 4096,
            "capabilities": {
                "toolCalling": true,
                "imageInput": false
            }
        }
    ]
}

示例中的提供商、模型、地址和能力参数需替换为实际值，并配置对应 API Key；baseUrl 仍填写 HTTPS API 基址，无需改成 wss://。内置 Responses 模型可在 gcmp.providerOverrides.<provider>.models[] 中按现有模型 id 设置 useWebSocket: true，继承的有效模式必须为 openai-responses。不要将开关放入 extraBody。

• 请求范围：仅识别为主 Agent 或子 Agent 对话的请求使用 WebSocket；摘要、SDK 压缩、标题等辅助任务及无法可靠分类的独立请求仍使用 HTTP。这是按用途选择通道，不是失败降级。
• 兼容与回退：服务端必须实现 Responses WebSocket 协议，仅支持 HTTP Responses 的端点不一定可用。Agent 的 WebSocket 请求失败不会自动回退 HTTP；需要使用 HTTP 时，将该模型的 useWebSocket 设为 false 或移除该字段。
• 上下文续传：在会话身份、请求参数和历史前缀满足条件时复用连接，通过 previous_response_id 仅发送新增输入；不满足条件时发送当前完整输入。每次仍发送完整请求原有的 instructions 和 tools，不依赖服务端继承这两个字段。
• 工具与状态边界：WebSocket 请求固定发送 parallel_tool_calls: false，不支持原生 custom 工具或原生 compaction。历史已裁剪时只使用当前输入，不恢复已丢失的推理状态。
• 诊断：继续使用已有代理和证书设置；WebSocket 不录制为 HAR，不能以没有 HAR 条目判断请求未发送。该功能为实验性，不代表所有提供商或网关均已验证兼容。

Anthropic 提示缓存 TTL：cacheTtl

sdkMode=anthropic 的模型可配置 gcmp.compatibleModels[*].cacheTtl：

• 省略（默认）：不写 ttl 字段，走 Anthropic 默认 5 分钟缓存，行为与历史版本一致
• "5m" / "1h"：请求内全部块级 cache_control 断点统一携带该 TTL，不会出现混用 TTL 导致的 400
• "1h" 适合会话常出现 5 分钟以上、1 小时以内空档的场景；缓存写入按基础输入价约 2 倍计费，缓存读取仍为 0.1 倍

注意：extraBody 中的顶层 cache_control 会被剥离并提示告警（它会与自动注入的 4 个块级断点叠加超限或混 TTL 报 400），请改用 cacheTtl。

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

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

• usage：可选；配置一个查询接口。即使同一响应包含多个额度，也只需一个 usage 配合 fields 配置数组；它还可作为 usages 的公共默认值
• usages：可选；用于多个命名查询模式，例如不同 URL、鉴权方式或查询参数。每个条目可在 usage 基础上增量覆盖，但 fields 数组是完整替换，不按项合并

一个接口返回多个额度：fields 配置数组

fields 既可以保持旧的单对象写法，也可以是非空数组。数组中每项都必须提供 balance，并可独立配置：

• balance：必填，可用余额/剩余额度的字段路径或计算字段
• paid：可选，充值/已付余额的字段路径或计算字段
• granted：可选，赠送余额的字段路径或计算字段
• displayName：可选，先尝试按路径读取名称；得到非空字符串或有限数字时使用该值，否则原样显示配置文本。例如 data.wallet.name 或 现金钱包
• arrayPath：可选，明确指定要遍历的数组，其元素分别解析为额度项
• unit：可选，该项的单位；依次回退到外层 usage.unit、USD，不做货币或单位换算

外层 usage.displayName / usages.<key>.displayName 用于命名查询模式；fields 内的 displayName 用于命名额度项。二者都存在时可组合显示为“模式 / 额度”。没有配置额度名称时，会尝试当前元素的 name、model、title、id、type、plan 字符串字段；数组拆分后仍未找到名称时，再回退为 #1、#2 等序号。

假设接口返回如下 JSON：

{
    "data": {
        "wallet": { "name": "现金钱包", "remaining": 88.5, "paid": 80, "granted": 8.5 },
        "packages": [
            { "name": "月度套餐", "total": 1000, "used": 250 },
            { "name": "加油包", "total": 200, "used": 50 }
        ],
        "addons": [{ "name": "联网搜索", "remaining": 30 }]
    }
}

下面的配置会从一次响应中解析钱包、两个套餐和搜索额度。示例 provider 与 URL 仅作说明，需替换为实际配置；自定义模型的 provider 也应使用相同的 key。

{
    "gcmp.providerOverrides": {
        "readme_demo": {
            "usage": {
                "url": "https://api.example.com/usage",
                "unit": "CNY",
                "fields": [
                    {
                        "displayName": "data.wallet.name",
                        "balance": "data.wallet.remaining",
                        "paid": "data.wallet.paid",
                        "granted": "data.wallet.granted"
                    },
                    {
                        "arrayPath": "data.packages",
                        "displayName": "name",
                        "balance": {
                            "operation": "subtract",
                            "paths": ["total", "used"]
                        },
                        "unit": "次"
                    },
                    {
                        "displayName": "data.addons[].name",
                        "balance": "data.addons[].remaining",
                        "unit": "次"
                    }
                ]
            }
        }
    }
}

解析结果按 fields 配置顺序、再按数组元素顺序展开：

钱包还会显示充值 80、赠送 8.5 的明细。不同单位的额度分别展示，不会把它们累加成一个总额，也不会为每个额度项单独请求接口。

数组路径：拆分、求和与索引的区别

拆分范围由 arrayPath 或 balance 的路径决定；计算字段也会检查其操作数路径。paid、granted 与 displayName 跟随同一个额度上下文解析，不独立决定拆分范围。

假设 data.packages 包含两个元素，其 remaining 分别为 10 和 20：

arrayPath 不是必填项。它适合明确指定某个数组，并将其元素作为字段解析上下文，让名称、余额与计算操作数可以使用元素相对路径：

{
    "fields": {
        "arrayPath": "data.packages",
        "displayName": "name",
        "balance": "remaining",
        "unit": "次"
    }
}

不写 arrayPath 时，可用 data.packages[].remaining 或 data.packages.remaining 自动拆分。嵌套数组也可逐层展开，例如 data.groups[].limits[].remaining；响应本身是数组时，直接写 remaining 即可按元素解析。

这些路径是 dot 字段路径及数组索引/通配语法，不是完整的 JSONPath 表达式。不要把 [*] 当作拆分，也不要把 [0] 当作遍历全部元素。

计算字段与数组求和

fields 中的 balance、paid、granted 支持 sum / subtract / multiply / divide。paths 里既可以写字段路径、常量数值（例如 500000），也可以继续嵌套计算字段对象，适合 Ticket / 500000、(总额 - 已用) / 500000 这类余额换算。

数组拆分后，计算按元素执行，相对操作数路径优先在当前元素、父级元素中查找，再回退到响应根数据；完整数组路径会绑定到当前选中的元素。因此上面的 arrayPath 示例可以直接用 total 和 used，无需手写元素索引。

{
    "balance": {
        "operation": "divide",
        "paths": [
            {
                "operation": "subtract",
                "paths": [
                    "data.subscriptions[0].subscription.amount_total",
                    "data.subscriptions[0].subscription.amount_used"
                ]
            },
            500000
        ]
    }
}

嵌套对象会先计算子表达式，再参与外层运算。

路径中的 [*] 可匹配数组中的所有元素，并对目标字段求和。例如，data.subscriptions[*].subscription.amount_total 会汇总所有订阅的 amount_total。匹配不到数组、字段缺失或值无法解析为有限数字时按 0 处理；该规则也适用于嵌套计算，以及 fields.paid 和 fields.granted。

{
    "balance": {
        "operation": "divide",
        "paths": [
            {
                "operation": "subtract",
                "paths": [
                    "data.subscriptions[*].subscription.amount_total",
                    "data.subscriptions[*].subscription.amount_used"
                ]
            },
            500000
        ]
    }
}

查询模式的继承与请求次数

• 只配置 usage：注册一个查询模式；一个模式仍可通过 fields 数组返回多个额度
• 需要多个查询模式时：通过 usages 配置，每个最终注册的模式分别查询一次。即使 URL 相同，不同模式也不会因为使用同一个接口而自动合并请求；同一响应内的多额度应优先使用 fields 数组
• usage 与某个命名模式最终解析出的查询配置等价时，不额外生成重复的 default 模式；外层模式 displayName 不影响该等价判断
• usage 和 usages 都不配置：就不会注册该自定义 provider 的余额/用量查询

usages 每项继承 usage 的 URL、鉴权、字段与单位等默认值。fields 的覆盖规则是：

• 默认值为单对象时，覆盖对象按字段增量合并，例如只修改 granted，仍保留默认 balance
• 覆盖值为数组时，完整替换默认 fields，不拼接、不按索引继承。数组不能为空，每一项都必须重新提供 balance
• 默认 fields 是多项数组时，改成单对象不会继承其中任意一项；必须提供完整的 balance。默认数组只有一项时，兼容对该唯一项作对象增量覆盖
• 未配置共享 usage 时，每个 usages 条目都必须自行提供 url 和完整 fields

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

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

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

• gcmp.compatibleModels 中的模型使用 provider: "NekoCode"，也可继续添加相同 provider 的其他模型
• gcmp.providerOverrides.NekoCode.usage 提供默认查询 URL https://api2.nekoapi.ai/v1/usage 和公共字段路径 balance
• gcmp.providerOverrides.NekoCode.usages.pay 与 usage 的最终查询配置等价，只额外提供显示名称 余额
• gcmp.providerOverrides.NekoCode.usages.sub 把查询 URL 覆盖为 https://api2.nekoapi.ai/v1/user/balance，并把余额字段覆盖为 remaining

{
    "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.5 (NekoCode)
• pay 会继承 usage.fields.balance = "balance"
• sub 会使用覆盖后的 fields.balance = "remaining"
• 因为 pay 与 usage 解析出的查询配置等价，所以不会再额外生成一个重复的 default 模式

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

• NekoCode / 余额
• NekoCode / 订阅

展示、告警与刷新注意事项

• Compatible 状态栏逐项显示余额；悬浮表格显示额度名称、余额及可选的充值/赠送明细。配置面板对具名的单个额度和多个额度显示名称与余额；无名单项保持紧凑展示
• 所有成功解析的额度都参与余额告警：任意一项为负数时标红，否则按提供商的 balanceWarning 阈值判断黄色警告。不同单位的额度沿用同一个提供商数值阈值，不做单位换算
• balance 未取到数值时，仅当 paid 与 granted 都有效才回退为两者之和，否则跳过该额度项。空的拆分数组不会生成额度项，所有配置都未解析出额度时查询失败；[*] 求和的缺失值仍按 0 处理
• 修改 gcmp.providerOverrides 下的 usage / usages 后，不会立即重新查询现有缓存；可点击 Compatible 状态栏手动刷新。状态栏尚未出现时，可重新加载窗口；配置面板可点击对应配置的“刷新”按钮重新查询

数组目标校验：显式 arrayPath 必须对应实际数组。路径缺失或目标不是数组时，跳过该 fields 配置；嵌套路径只跳过无效分支，不回退到根余额。其他有效额度仍正常展示，所有配置都没有有效额度时查询失败。配置前应核对真实响应结构。

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.7", // 推荐使用性能较好的模型，留意日志输出是否包含 ``` markdown 代码符
        "maxTokens": 200,
        "extraBody": {
            // GLM-4.7 默认启用思考，补全场景建议关闭思考以加快响应
            "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。

快捷键与操作

主要特性

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

使用方式

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

请求余额与额度快照

• 查看明细：请求记录的 Key 标签旁展示余额或剩余额度摘要，悬停或聚焦摘要可查看明细及查询时间。支持原生提供商与 Compatible 多项查询，历史快照可离线查看，展示语言跟随当前界面。
• 缓存边界：请求实际派发时，读取所用凭据对应的已有有效缓存，不会为保存快照额外查询接口。查询时间可能早于请求开始时间，不代表该次请求的实时余额或实际扣费。
• 缺失数据：尚未查询、查询失败且没有有效缓存，或缓存已过期时，可能没有可展示的快照；不会使用其他 Key 的余额替代。
• 刷新调度：实际派发的请求结束后，在同一窗口内按提供商合并刷新通知，默认延迟 2 秒、调度间隔至少 30 秒；冷却期内的新通知保留一次尾部刷新，周期和手动刷新仍可用。
• 历史不回填：后续刷新只更新当前状态栏数据，不覆盖已保存的请求快照；没有快照的旧请求也不会使用当前额度回填。

配置选项

{
    "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.7" // 生成模型的 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 参数等）均可在源码中直接查看。若希望把 Gist 同步数据视为真正的跨设备机密，必须设置自定义加密口令。

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

恢复时的口令验证

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

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

跨设备提示

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

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

数据兼容性

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

安全说明

• Gist 会暴露在用户的 Gist 列表中；设置自定义口令后，其内容才应视为面向离线攻击者的机密数据备份
• 未设置自定义口令时，请不要把该方案视为针对有意离线分析者的强机密性保护
• 加密密钥不在网络中传输
• 本地 API Key 通过 VS Code SecretStorage 存储，操作系统级加密保护
• 所有网络请求均通过 HTTPS