Kiro 现在可以直接选择 GPT-5.6 Sol、Terra 和 Luna。普通使用路径是登录 Kiro、使用能访问 premium models 的套餐，然后在 Kiro 自己的模型选择器里切换；它不是让你填写 OpenAI Platform API Key，也不是把 Kiro 改成一个 OpenAI-compatible endpoint。
先认清这个边界，后面的价格、上下文和用量才不会算错：Kiro 用 credits 计量，并在自己的产品面提供 272K 上下文；OpenAI 直连 API 则按 token 计费，公开模型页的上下文是另一份合约。
先确认账号里有没有这三款模型
Kiro 的当前模型表把 GPT-5.6 Sol、Terra、Luna列在 Pro、Pro+、Pro Max 和 Power 下，Free 一栏没有勾选。
在 IDE 中打开聊天，点击输入框附近当前模型的名称，再从 model selector 选择目标模型。选择会作用到这个会话后续消息。CLI 最稳妥的入口是交互式命令：
text/model
如果想先确认当前账号和客户端到底返回了哪些模型，可以运行：
bashkiro-cli chat --list-models --format json
不要仅凭发布新闻手写一个 model ID。实时列表没有返回的模型，在当前账号、地区和会话里就不应当作可用路线。
当前积分倍率已经改过一次
Kiro credit 是对用户请求所完成工作的计量单位。复杂的 spec task 往往比短问题消耗更多；倍率只是相对于 Auto 的计量关系，不是固定每次请求价格，也不是 OpenAI token 数量。
| 模型 | 当前 Kiro 倍率（Auto = 1.0x） | 更适合先验证的任务 |
|---|---|---|
| GPT-5.6 Luna | 0.1x | 边界清楚、可批量验证、对吞吐敏感的重复任务 |
| GPT-5.6 Terra | 1.0x | 常规多步骤开发、修复与 review，适合作为平衡基线 |
| GPT-5.6 Sol | 2.4x | 便宜档无法通过验收的长周期重构、复杂终端任务和疑难排障 |
这里要特别防止旧资料误导。Kiro 7 月 14 日发布页写的是 Terra 1.2x、Luna 0.6x；7 月 31 日倍率更新已经把它们降到 1.0x 和 0.1x，Sol 仍是 2.4x。
一般开发任务可以先用 Terra 建立基线；大量、简单且有确定测试的任务可从 Luna 开始；只有当 Sol 确实减少失败、返工或人工 review 成本时，2.4x 才可能值得。Auto 也应该保留在对照组里，指定 GPT-5.6 并不自动等于更划算。
如果你真正要比较的是 OpenAI 直连 API 的 token 单价、缓存价和长上下文成本，查看单独的 GPT-5.6 Sol、Terra、Luna API 选型指南。不要把那里的美元单价套到 Kiro credits 上。
reasoning effort 会改变速度和积分
Kiro 的推理强度文档显示，三款 GPT-5.6 都接受 none、low、medium、high、xhigh、max，Kiro 当前内置默认值为 high。
IDE 可在模型选择器旁的 Effort 面板调整。CLI 可以打开选择器，也可以直接指定：
text/effort /effort medium
CLI 会保存模型与 effort 选择。这很方便，也容易让测试失真：上次会话留下的 max 可能继续生效，而你以为自己正在跑默认配置。
选择原则不是“越高越好”，而是使用能稳定通过验收的最低档。日常实现可以把 medium 当低延迟对照，再和 high 比较；只有明确观察到遗漏边界、逻辑不完整或复杂排障失败时，才继续提高。额外推理没有带来可观察的通过率提升，就不值得更慢和更多 credits。
用一次真实任务决定是否切换
厂商 benchmark 能说明特定评测条件下的表现，不能证明你的仓库、权限、工具链和完成标准也能复现。传播很广的成本下降数字，应当视为供应商结果，而不是你的预算结论。
选一个可以在一次 review 中完成的真实任务，例如：
- 修复一个已有失败测试的 bug，且不允许删除或弱化测试；
- 在行为不变的条件下重构一个模块；
- 按清楚的验收条件实现一个小功能。
让 Luna、Terra、Sol 或 Auto 使用相同起始 commit、相同指令、相同工具权限和相同测试命令。每次只记录会改变决定的证据：
- 要求的测试是否通过，是否引入回归；
- 需要多少次重试与人工修改；
- diff 是否超出要求范围；
- 从发出任务到可 review 结果用了多久；
- Kiro 用量页面最终记录多少 credits。
比较的是“得到一个可接受结果的总成本”，不是第一条回复有多漂亮。Luna 只有 0.1x，但若反复返工，开发者时间可能更贵；Sol 即使能力更强，若生成更大的风险 diff，也不能只凭旗舰标签胜出。
模型不显示时按合约排查
先不要改配置文件或粘贴新密钥，依次确认：
- 当前账号是否为支持 premium models 的付费套餐；Free 当前不含 GPT-5.6。
- 重启 IDE 或 CLI；Web 端刷新页面。Kiro 的发布说明明确建议这样获取最新模型列表。
- CLI 用
--list-models --format json查看真实列表，不猜 ID。 - 企业账号确认管理员 allowlist。Kiro 的企业模型管理文档说明，启用允许列表后，新模型不会自动加入，必须由管理员批准。
- 检查当前国家/地区是否允许这款 premium model。付费套餐本身不能证明每个地区都有同样的模型目录。
把别的 provider key 写进项目，不是在修复 Kiro 内置模型，而是在建立另一条凭据、账单、日志、数据与支持路线。
EU profile 也不等于 EU inference
Kiro 当前推理地区表写明，GPT-5.6 即使在 Europe profile 下也由 US 处理；文档还提醒 experimental models 可能在 profile geography 之外的商业 AWS Regions 处理。
这段说明不能替代完整的数据存储和企业合同核验，但已经足以否定一个危险假设：选了欧洲 Kiro profile，不代表 GPT-5.6 推理就在欧洲完成。若仓库代码、prompt 或日志有数据驻留要求，应先检查当前 Kiro 数据保护条款与企业合同，再让模型读取真实项目。
最终判断标准
当模型在当前 selector 中真实可见、套餐与地区满足要求，并且同一代表任务的通过率、返工、耗时和 credits 优于现有路线时，才值得采用 GPT-5.6。
从最可能通过的低成本档开始，显式控制 effort，用可验收结果决定是否升档。如果 Auto 或其他模型用更少 credits、更少修改或更合适的数据处理条件完成同一任务，保持原路线就是正确选择。真正完成的“集成”不是看见一个新模型名，而是团队能够持续交付并承担它的完整运行合约。
