在 Codex、Cursor、Cline、DSH 里用 GPT-6 Astra：可直接抄的配置（2026）

GPT-6 Astra 用的就是每个编程 agent 早就在用的那套 OpenAI 兼容协议，所以「接入」它是改一个模型字符串，而不是做一次集成。 真正需要做判断的是 effort 档位和缓存读取费率。本文给出 Codex CLI、Cursor、Cline、DeepSeek Harness 的可用配置，以及在把它设成默认之前值得先定下来的两个设置。

模型 ID：      openai/gpt-6-astra
别名：         gpt-6-astra、gpt-6-astra-2026-09-03
端点：         /v1/chat/completions、/v1/responses
Base URL：     https://api.ofox.ai/v1
价格：         每百万输入 $10.00 / 输出 $50.00
缓存：         读 $1.00 / 写 $12.50
上下文：       输入 1,050,000 / 输出 128K
effort 档位：  low、medium、high、xhigh、max

读取自 2026 年 9 月 5 日的实时 /v1/models 端点，也就是 Astra 上架那天。

先把这两件事定下来

在给配置块之前，先说决定这个模型对你的负载到底划不划算的两个设置。

Effort：从 high 起步，不是 max。 Astra 有五档。Artificial Analysis 测得 max 在其 Intelligence Index 上是 61，high 是 60——差一个点——而 max 写了 4200 万输出 token，high 是 1600 万，跑同一套指数的花费是 $3,013 对 $1,429。推理 token 不管你读不读都按输出价计费，所以 effort 这个设置本质上是一个附带质量假设的价格倍率。在为它掏钱之前，先确认那一个点在你的任务上真的存在。

缓存读取的价格是 Claude Fable 5.1 的 4 倍。 两个模型的公开标价都是每百万 $10 / $50。Astra 读缓存输入是每百万 $1.00；Fable 5.1 是 $0.25。编程 agent 每一轮都会把同一套 system prompt、工具定义和文件上下文重新发一遍，所以在长会话里，缓存输入通常是账单上最大的一项。如果你的 agent 循环反复重放一段很长的前缀，这一行对账单的影响比公开费率还大。

独立 benchmark 给出的诚实结论是：Astra 是为 agent 而造、也为 agent 定价的。在 Coding Agent Index 上它 67 分、GPT-5.6 Sol 65 分，而在 Codex harness 里它大约只用了三分之一的 token，所以跑完一个完整任务的花费和 Sol 差不多。在短 prompt 上，你付的是每 token 2.5 倍的钱，换来一个没有变化的通用分数。

Codex CLI

两个环境变量加一个 model 参数。

export OPENAI_API_KEY=<你的 ofox key>
export OPENAI_BASE_URL=https://api.ofox.ai/v1

codex --model openai/gpt-6-astra "Migrate this module off the deprecated client"

单端点场景下，这就是全部配置。Codex 完整配置指南讲了安装和验证。

环境变量这条路什么时候不够用

这个双变量小技巧把端点写死成了一个。一旦你想在同一个终端里同时用 OpenAI 直连和网关，或者不同项目用不同模型，就得动 ~/.codex/config.toml：

[model_providers.ofox]
name = "ofox.ai gateway"
base_url = "https://api.ofox.ai/v1"
env_key = "OFOX_API_KEY"
wire_api = "chat"
request_max_retries = 4

[profiles.astra]
model = "openai/gpt-6-astra"
model_provider = "ofox"
model_reasoning_effort = "high"

codex --profile astra "Refactor the auth layer"

这里有两个键大家老写错：

• wire_api = "chat"，不是 "responses"。两个值都能被接受，OpenAI 自家的一方配置默认也是 "responses"，但第三方 OpenAI 兼容网关在 /v1/chat/completions 上暴露的是 Chat Completions 那套 schema。走网关就设 "chat"。
• env_key 写的是变量名，不是 key 本身。 Codex 会在运行时去读那个环境变量。不要把 token 粘进 TOML。

多供应商深入篇讲了这个块剩下的部分，包括某些需要组织维度作用域的网关要用的 http_headers。

Cursor

Settings → Models → Override OpenAI Base URL。

1. 在 Override OpenAI Base URL 里填 https://api.ofox.ai/v1。/v1 不能省——Cursor 会在你填的地址后面追加 /chat/completions。
2. 在 OpenAI API Key 里填你的网关 key。标签写的是 OpenAI，key 会被发到你上一步配置的那个端点。
3. 点 + Add Model，一字不差地输入 openai/gpt-6-astra。这个字符串必须和端点在请求体里期望的完全一致。

Cursor 的这个 override 是全局的、不是按模型生效的，这也是这条路已知的限制：一旦打开，所有标着 OpenAI 的模型都会指向你的端点。Cursor 与 Cline 配置指南讲了这会弄坏什么，以及相应的绕法。

Cline

用 OpenAI Compatible 这个 provider。

在 Cline 的设置面板里把 API Provider 选成 OpenAI Compatible，填三个字段：

Model ID 需要带 provider 前缀。单写 gpt-6-astra 是网关能解析的别名，但 Cline 那边报「model not found」的情况，几乎都能追溯到在一条要求带前缀的路由上填了不带 openai/ 的字符串。Cline 配置指南也讲了 Anthropic provider 那条路——那条对 Claude 模型有用，对本文这个模型没用。

DeepSeek Harness（dsh）

Settings → Models → Add a custom provider。 表单要填五项：

也可以直接写进 $DSH_HOME/settings.yaml：

llm-pi-ai:
  providers:
    ofox:
      apiKeyEnv: OFOX_API_KEY
      api: openai-completions
      baseURL: https://api.ofox.ai/v1
      models:
        - id: openai/gpt-6-astra

三个 dsh 特有的坑，都在干净安装上验证过：

• models 列表是替换该路由的目录，不是追加。 你没声明的模型会在请求离开这台机器之前就以 UNKNOWN_MODEL 失败。自定义 provider 上没有「照发不误」这种选项。
• Provider ID 不可更改。 会话、默认值、凭据引用全都以它为键，所以改名意味着新建一个 provider 再删掉旧的。
• 定义了 provider 不等于它就成了默认。 headless profile 会去启动内置的 DeepSeek 路由并索要 DEEPSEEK_API_KEY，哪怕你已经把另一个 provider 配全了。先在 web 端把默认模型设好。

dsh 仍是开发者预览版，它自己的 README 里就是用大写字母这么写的。dsh 配置指南和版本与稳定性说明讲了在把它指向你在意的仓库之前，这句话意味着什么。

验证这条路通不通

不管你配的是哪个 agent，检查方法都一样——这条命令能返回补全，就说明传输层没问题，还坏着的东西都是 agent 侧的配置：

curl -X POST https://api.ofox.ai/v1/chat/completions \
  -H "Authorization: Bearer $OFOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-6-astra",
    "messages": [{"role": "user", "content": "Reply with exactly: ok"}],
    "reasoning": {"effort": "high"}
  }'

在预测成本之前，先拿你自己的 prompt 跑一遍并读 usage。每百万输出 token $50，推理也按这个价计，token 数量比价目表更要紧。

model_not_found 又冒出来的时候

几乎总是模型字符串过期或写错了。 有效标识符是 openai/gpt-6-astra，加上别名 gpt-6-astra 和 gpt-6-astra-2026-09-03。

两个具体的坑：

• 旧的 Codex 教程会推荐 openai/gpt-5.4-mini-codex。 那个模型已经不在目录里，报的是同一个 model_not_found。当前 Codex 家族可选的是 openai/gpt-5.1-codex-mini（$0.25 / $2.00）和 openai/gpt-5.3-codex（$1.75 / $14.00）。
• GPT-6 没有档位后缀。 GPT-5.6 分 Sol、Terra、Luna；GPT-6 只有 Astra 和 Astra Pro。任何靠拼接档位后缀生成模型字符串的路由或配置模板都匹配不上。代际对比讲了这次命名变化还会弄坏什么。

到底哪些模型可调，以 GET https://api.ofox.ai/v1/models 为准，任何页面都不算数，包括本页。

这些 agent 到底该指向哪个模型

Astra 并不因为最新就自动是对的默认选项。在同样的 $10 / $50 价位上，另有三条路值得你拿自己的任务和它比一比：

Fable 5.1 以 70 分领跑 Coding Agent Index，缓存读取价只有 Astra 的四分之一，这个组合在长 agent 会话里最要紧。Astra 的反驳是 token 效率：在 Codex harness 里约为 Sol 的三分之一，这也是它标价更高、单任务成本却和 Sol 接近的原因。正面对比有完整拆解。

既然上面每个 agent 都通过同一个端点够得着这四个模型，切换只是改一个字符串。拿你自己的三个任务在两个模型上各跑一遍、读 usage——这个对比只花几分钱，胜过任何 benchmark 表格，包括本站的。

来源

• https://ofox.ai/models/openai/gpt-6-astra
• https://developers.openai.com/codex/config-reference
• https://artificialanalysis.ai/articles/benchmarking-gpt-6-astra
• https://ofox.ai/docs/integrations/cline

模型 ID、费率、上下文长度和端点读取自 2026 年 9 月 5 日的实时 Ofox /v1/models 端点。Coding Agent Index 分数和 effort 档位的成本对比来自 Artificial Analysis，读取于 2026 年 9 月 4 日。Codex config.toml 的键遵循 OpenAI 的配置参考文档。dsh 的 provider 表单字段和那三个坑，是我们此前那篇 dsh 配置指南在干净安装上验证过的，本文又重新核对了一遍；dsh 仍是开发者预览版，其维护者明确表示会有破坏性变更。