---
title: "模型、Adaptive、BYOK 与用量"
description: "按官方文档整理 Windsurf 模型选择、Adaptive、SWE 模型族、BYOK、quota、extra usage 和团队计费边界。"
verifiedAt: "2026-05-09"
---

Windsurf 的模型、用量和价格变化很快。官方 AI Models 页面也明确提示：最新 pricing 和 availability 要以 Windsurf IDE 里 Cascade 的 model selector 为准（**model selector 在哪**：打开 Cascade 面板，输入框下方有一个模型下拉菜单，那里实时列出当前可用模型 + 价格）。教程只能讲稳定机制，不能把某一天的模型表当成长期事实。

本章的重点是建立选型边界：什么时候默认 Adaptive，什么时候指定模型，什么时候启用 BYOK，什么时候查 quota，团队什么时候需要统一模型策略。

> [!TIP]
> **阅读目标**：读完本章，你应该能在不死记价格表的情况下，判断模型、quota、BYOK 和团队预算分别该看哪里。

## 1. 高波动事实只给查法

模型和用量类问题，先按这个顺序核验：

| 问题 | 首选来源 | 原因 |
| --- | --- | --- |
| 当前可选模型 | Windsurf IDE 的 Cascade model selector | 官方说明这里最及时 |
| 模型单价/额度消耗 | 官方 AI Models / Adaptive / Quota 页面 | 页面会随套餐和计费方式变 |
| 当前剩余额度 | Windsurf usage meter 或 plan page | 和个人账号、团队账号绑定 |
| 团队可用模型 | Admin Portal 的 Models Configuration | 管理员可按 model 或 provider 过滤 |
| 企业计费 | 合同、ACU 或 legacy credits 页面 | 企业计划可能和 self-serve 不同 |

不要在团队文档里写死“某模型永远最便宜”或“某套餐永远够用”。正确写法是：写清任务分层和查询入口。

官方 `AI Models` 页面本身会内嵌模型成本数据，但它仍然不是团队长期文档的硬编码来源。正确做法是：上线前从 model selector 和官方模型页核一次，团队文档只写“允许的 provider/model、默认模型、预算负责人、超额处理方式”。

## 2. Adaptive 默认优先

官方模型页和 Adaptive 页面都推荐多数用户使用 Adaptive。Adaptive 是 Cognition 的 intelligent model router：在 model picker 里选中后，它会根据请求自动选择底层模型，简单任务走更轻的模型，复杂任务走更强的模型。

```mermaid
flowchart TD
    Task["开发任务"] --> Adaptive{"默认 Adaptive?"}
    Adaptive -->|日常解释/小修/测试| Route["自动路由"]
    Adaptive -->|有明确模型需求| Specific["手动选择指定模型"]
    Route --> Simple["简单任务：轻量模型"]
    Route --> Complex["复杂任务：更强模型"]
    Specific --> Budget["确认 quota / extra usage / enterprise policy"]
    Budget --> Run["执行并记录原因"]

    style Adaptive fill:#dbeafe,stroke:#2563eb,stroke-width:2px
    style Budget fill:#fef3c7,stroke:#d97706,stroke-width:2px
```

适合 Adaptive：

- 解释代码、定位入口、总结文件职责。
- 小范围 bug 修复。
- 写测试和修普通 lint/type 错。
- 让 Cascade 探索项目并形成计划。

适合指定模型：

- 复杂架构迁移。
- 需要特定模型推理能力的任务。
- 团队需要可预测的成本和审计口径。
- 企业合规要求只允许特定 provider 或模型。

官方 Adaptive 页面还说明，它的定价依赖 billing plan；2026-05-06 核验时，页面列出过一个截至 2026-05-07 的 introductory promotional rate。这个细节说明价格信息非常高波动，教程不应固化成长期规则。

## 3. 模型族的稳定理解

官方 AI Models 页面会列出 Windsurf / Cognition 自有模型，以及 Anthropic、OpenAI、Google 等供应商模型。具体列表变化很快，教程只保留稳定分工。

你不需要背宣传语，理解分工就够：

| 类型 | 稳定职责 | 使用判断 |
| --- | --- | --- |
| Adaptive | 自动选择底层模型 | 默认选项，适合多数日常任务 |
| SWE agentic coding 模型 | 面向软件工程任务 | 复杂实现、修复、重构、长任务 |
| Fast / lighter variants | 更偏速度和成本控制 | 解释、小改、常规测试和低风险任务 |
| Tab / autocomplete 模型 | 实时补全和跳转建议 | 编辑器内被动辅助，不替代 Cascade 大任务 |
| Retrieval 模型，例如 SWE-grep | context retrieval 和 Fast Context | 找相关代码，减少上下文污染 |
| 外部 frontier models | 特定推理、代码或上下文能力 | 只有明确理由时手动指定 |

真正影响结果的不是“永远选最强”，而是任务是否有足够上下文、是否拆得够小、是否有测试和 diff 审查。

## 4. BYOK 只适合个人明确管理账单

官方 AI Models 页面说明 **BYOK（Bring Your Own Key，自带密钥——用你自己在模型供应商那里申请的 API key 付钱给模型，Windsurf 只收订阅费不收模型费）** 只面向 free 和 paid individual users。个人用户会在 model dropdown 里看到带 `BYOK` 标记的模型；需要在 subscription settings 里添加 API key。未配置 key 时，使用 BYOK 模型会报错。

不要在教程里写死 BYOK 支持模型清单。它应以官方模型页和 IDE model dropdown 为准。

BYOK 适合：

- 你已经有供应商额度。
- 希望把 Windsurf 订阅和模型账单分开。
- 个人项目需要特定模型。

BYOK 不适合：

- 团队要求统一供应商和审计。
- 你无法监控供应商账单。
- key 可能被写入项目、截图或日志。

> [!WARNING]
> **BYOK 不是省钱开关**。它把一部分账单和密钥风险转移到你的模型供应商账号。不要把 key 写进项目文件、教程截图或 `mcp_config.json`。

## 5. Quota、extra usage 和 legacy credits

官方 Quota-Based Usage 页面说明：2026 年 3 月，Windsurf 对 self-serve customers 从 **credit-based system**（按 prompt 计费——每条请求扣固定积分，模型不同积分倍率不同）切到 **quota-based usage system**（按用量计费——按你这次请求实际消耗的 token 数算钱，token 越多扣越多；好处是低消耗任务更省钱，坏处是长会话会快速烧 quota）。计划包含 daily 和 weekly usage allowance，并按模型请求使用的 tokens 计算；free models 不计入 quota。

关键机制：

| 机制 | 官方含义 | 实操影响 |
| --- | --- | --- |
| daily / weekly quota | 每日和每周 allowance 自动刷新 | 长任务要分批，不要一天烧完 |
| token-based cost | 请求消耗取决于模型和上下文 token | 少带无关上下文，能省 quota |
| extra usage | Pro、Teams、Max 达到额度后可购买继续使用 | 要有预算上限和负责人 |
| free limit | Free 达到限制后等下一次 reset | 适合试用，不适合稳定生产工作流 |
| enterprise | 可能走 ACU、legacy credits 或合同 | 以合同和管理员页面为准 |

官方还给出让 quota 更耐用的建议：指令更精确、移除不必要上下文、 routine tasks 使用 free models、避免不必要长会话、尽量在同一 frontier model 上利用 caching。

<details>
<summary>深读：为什么“继续对话”也会影响成本</summary>

Agentic IDE 的成本不只来自你输入了几个字。共享 timeline、编辑器上下文、系统提示、工具调用、文件读取和输出 tokens 都会参与计算。长会话会积累更多上下文，跨多文件任务也会增加 token 使用。

所以商业项目里要把任务切成可验证阶段。先让 Cascade 只读定位，再决定是否继续；每一阶段结束后审 diff 和测试，不要让一个会话无限扩张。
</details>

## 6. 团队模型策略

团队不要让每个人凭感觉选模型。管理员可以在 Admin Portal 配置模型访问，官方 Guide for Admins 说明可按 model 或 provider 过滤，且只能同时强制一种 filter 类型；也可以设置默认 Cascade 模型，但用户在会话中仍可切换到允许的模型。

推荐团队规则：

| 任务 | 推荐策略 |
| --- | --- |
| 日常解释、普通 bug、小改动 | Adaptive 或团队默认模型 |
| 跨模块重构、复杂架构 | 指定强模型，先计划后执行 |
| 高消耗批量 workflow | 加 review gate 和预算负责人 |
| 合规敏感项目 | 只开放允许 provider / model |
| 培训和 onboarding | 禁止死记价格，教 model selector 和 quota page 查法 |

模型策略最好写进团队 onboarding 或项目 `AGENTS.md`。不是为了限制开发者，而是为了让成本、合规和任务质量有统一口径。

## 7. 使用量排查

当成员反馈“额度掉得太快”时，先按这个顺序查：

1. 是否在长会话里带了过多文件、timeline 或无关上下文。
2. 是否用 frontier model 做了大量 routine tasks。
3. 是否频繁切模型导致缓存收益降低。
4. 是否让 Cascade 在一个 prompt 内连续 tool calls 和 continue。
5. 是否启用了 extra usage，但没有预算上限。
6. 是否存在团队共享账号、未离职回收或异常自动化。

官方 quota 页面给出的 token pricing example 说明，同一次看似简单的 refactor 会包含用户输入、共享 timeline、编辑器上下文、系统提示、tool call 输入、cache read/write 和输出 tokens。成本排查要看整条 trajectory，不只看用户最后发了几个字。

## 本章自检

完成本章后，用这 5 个问题检查：

1. 当前模型可用性应该在哪里核验？
2. 什么时候默认 Adaptive，什么时候手动选模型？
3. BYOK 的账单和密钥风险由谁承担？
4. self-serve quota、extra usage、enterprise ACU/credits 的边界是什么？
5. 团队是否有 usage 异常排查顺序？

通过标准：你能为个人和团队分别写出一条模型选择规则，而不是背某一天的价格表。

## 官方来源

- [AI Models](https://docs.windsurf.com/windsurf/models) —— 官方模型页，说明 Adaptive 推荐、model selector、SWE 模型族、BYOK 和最新价格可用性查询入口。
- [Adaptive](https://docs.windsurf.com/windsurf/adaptive) —— 官方 Adaptive 页面，说明智能路由、选择入口、pricing 依赖计划和使用建议。
- [Quota-Based Usage](https://docs.windsurf.com/windsurf/accounts/quota) —— 官方 quota 页面，说明 2026 年 3 月后的 daily/weekly allowance、extra usage、reset 和省用量建议。
- [Plans and Usage](https://docs.windsurf.com/windsurf/accounts/usage) —— 官方 plans/usage 页面，说明 Free、Pro、Max、Teams、Enterprise、usage 查看和 enterprise credit 边界。

## 接下来去哪

<Cards>
  <Card title="团队控制与排障" description="继续学习 Admin Portal、SSO、SCIM、命令策略、MCP 准入和常见故障定位。" href="/docs/windsurf/official/07-teams-troubleshooting" />
  <Card title="从原理到实战" description="回到实战篇，把模型、quota 和命令边界放进真实项目循环。" href="/docs/windsurf/understanding/07-model-usage-strategy" />
</Cards>
