尽管 Claude 今年在速率限制方面进行了多项改进，但它仍常在不便时触发限制。这往往并非因为操作复杂，而是会话额度被整理文件、检查文件夹内容等琐碎任务占用。事实上，这类任务无需动用 Claude 的最强模型。
将本地模型接入 OpenCode
即便是搭载 8GB 显存 GPU 的游戏 PC，也能流畅运行相当强大的本地模型。作为 Claude 的免费替代品，OpenCode 几乎可对接任意指定的本地模型。核心问题在于：9B 参数级别的本地模型，能否胜任那些通常大量消耗 Claude 额度的繁重工作？
虽然已习惯从终端运行 AI 智能体，但出于对可视化界面的偏好，我选择使用 OpenCode 桌面应用。我主要通过 LM Studio 服务器运行本地模型，首先在“开发者”选项卡中加载模型。测试对象包括久经考验的 Qwen 3.5 9B 以及基于 Claude 推理能力训练的 Qwythos 9B。两者均采用 Q4_K_M 量化格式，工具调用表现强劲。加载时，我将上下文长度设为约 30k，这在基本会话中与硬件性能取得了良好平衡。
只要 LM Studio、Ollama 和 vLLM 在默认本地地址运行，OpenCode 即可自动识别其中的模型。我的整个 LM Studio 模型库均显示在 OpenCode 设置的“模型”选项卡中，可随时开启所需模型。悬停查看模型的上下文大小及工具支持状态至关重要，因为工具是 OpenCode 打开和编辑文件的基础。
此外，转向本地部署还规避了 Anthropic 的限制，后者禁止用户将 Claude Pro 或 Max 订阅接入 OpenCode。
让本地模型阅读文件
在此场景下，8GB 显存很快成为瓶颈。编码智能体需先读取文件才能发挥作用，OpenCode 赋予模型搜索文件夹和打开文件的工具，每打开一个文件都会占用上下文空间，若设置较低，会迅速触及限制。
初次尝试让 Qwen 在整个 Obsidian 笔记库中查找未标记笔记时，测试未能成功。模型不断打开文件直至上下文耗尽，随后 OpenCode 执行会话压缩（用摘要替换完整对话）。每次压缩后，Qwen 都会遗忘已检查内容并重新开始。停止全库测试后，我将范围限制在单个小文件夹内，结果确实有效。例如，在分析小型习惯追踪器项目时，模型准确概述了每个文件的功能。
Qwythos 在回答前会进行推理，导致速度稍慢。在一次梳理笔记重叠部分的会话中，它耗时超过六分钟才完成回复，但最终找到了两个此前未被关联的笔记并建议链接。虽然它尚不能替代 Claude 处理大型项目，且处理文件数量的上限尚不明确，但它确实可用。最大的限制因素在于硬件性能和可运行的模型规模。
让本地模型编辑文件
这类琐碎任务正是消耗 Claude 会话额度的主力。OpenCode 会对特定行进行修改并显示变更差异（diff），且默认对文件更改进行快照，支持在会话内撤销任何操作。
在要求模型添加标签且不触碰其他内容的测试中，Qwen 和 Qwythos 均展现了出色的指令遵循能力，严格执行要求，未出现某些旗舰级云端模型偶尔发生的越界行为。OpenCode 的差异对比功能也便于清晰查看具体修改点。
它们的短板在于格式处理。9B 参数模型往往字面遵循指令，可能导致生成的代码在差异视图中正确，但实际语法无法被程序识别。因此，在确认编辑完成前，务必用实际程序打开文件验证，而非仅依赖模型摘要。
上下文令牌限制同样影响编辑任务。OpenCode 显示，仅读取八个文件就占用了约 17k 上下文空间，迫使每次会话只能针对单个文件或较小批次，并为新任务启动全新会话。但这足以覆盖修复代码库中少数文件按钮标签等常见场景。
Claude Pro 版本基于滚动五小时窗口及每周上限运行，且各平台额度共用。据估算，仅将琐碎任务迁移至本地，就能释放约四分之一的每周用量，在重度使用周甚至可达三分之一。
Claude 仍负责处理难题
对于需要更多算力的复杂任务，我依然依赖 Claude。但本地 GPU 已能轻松应对那些在 Claude 中堆积的枯燥小任务，从而显著节省用量。即便不升级硬件，依靠这些略显过时的模型，也能很好地完成既定任务。