GPT-6 Astra API 报错：model_not_found、401，以及 max_tokens 那个坑

下面每一段报错原文都是 2026 年 9 月 6 日对 GPT-6 Astra 端点发真实请求抓回来的。 没有转述，没有编造的错误文本。另外还有一个发现，它根本不是报错，但会比上面任何一条都更烧你的钱：Astra 无视 max_tokens。

model_not_found        404 → 模型字符串不存在
invalid_api_key        401 → key 错了、缺了或被吊销
invalid_request_error  400 → 缺了一个必填字段
invalid_request_error  --- → 某个参数值不被接受
max_tokens             ⚠️  被静默忽略——见下文

最贵的那条：max_tokens 不起作用

我们要 16 个 token，被计了 2,614 个。 finish_reason 返回的是 stop 而不是 length，所以响应里没有任何东西提示你的上限被无视了。

在 openai/gpt-6-astra 上实测，每次 prompt 相同：

返回数和请求数之间毫无关系。换成 max_completion_tokens——OpenAI 推理模型平常认的那个参数——也没有任何变化。

这是 Astra 独有的，不是网关的问题。 同一个端点上，同样的请求打给 GPT-5.6 Sol 就是正常的：

Sol 会截断并如实报 length。Astra 无视上限，然后报 stop。

这要花多少钱。 按每百万输出 token $50 算，一个你按 50 token（$0.0025）做的预算，实际返回 2,900 个（$0.145），是估算的 58 倍。跑一个 1 万次调用的循环，就是预算 $25、账单 $1,450。如果你的成本护栏是建在 max_tokens 上的，那它在这个模型上什么都没护住。

现在能做的替代方案：

• 在 prompt 里限长。「用一句话回答」是真的有用；max_tokens 没用。
• 把 reasoning.effort 调低。 推理 token 按输出价计费，超支的大头就在这里。
• 在 usage 上告警，别在请求上。 每个响应都读 completion_tokens，对总量设告警。你的请求参数在这里不是花费控制手段。
• 如果你的供应商支持，就在网关或账号层面设上限，既然单请求那个开关不管用。

我们没在任何地方找到关于这个行为的文档，所以请把它当成一次实测而不是规格——自己重跑一遍再围着它做设计，并且要预期它随时可能变。

报错清单，附真实响应体

model_not_found

{"error":{"message":"Model 'gpt-6' not found","type":"model_not_found","code":404}}

这个字符串在目录里不存在。 有效标识符：

• openai/gpt-6-astra
• 别名 gpt-6-astra 和 gpt-6-astra-2026-09-03

两种最常见的踩法：

光写 gpt-6。 404。OpenAI 自家 API 在某些情况下会给短名做别名映射；网关不替你猜。

加档位后缀。 gpt-6-astra-sol 报同一个 404：

{"error":{"message":"Model 'gpt-6-astra-sol' not found","type":"model_not_found","code":404}}

GPT-5.6 分 Sol、Terra、Luna 三档。GPT-6 没有分档——只有 Astra 和 Astra Pro。任何靠拼接档位后缀来生成模型字符串的路由或配置模板，在这一代上都会失败。代际对比里讲了这次命名变化还会弄坏什么。

invalid_api_key

{"error":{"message":"Invalid or expired API key","type":"invalid_api_key","code":401}}

key 错了、被吊销了，或者是另一个账号的。 检查 Authorization 是不是 Bearer <key>，以及那个 key 是真的从环境里读出来了、而不是悄悄读成了空串——环境变量为空报的是这个错，不是「缺 header」的错，所以大家常常去查错层。

如果你的问题具体出在 Codex CLI 而不是裸 API 调用，Codex CLI 401 Unauthorized 讲了那边鉴权路径的差异。

invalid_request_error —— 缺字段

{"error":{"message":"Missing required parameter: 'messages' is required. [ofox.ai]","type":"invalid_request_error","code":400}}

少了一个必填字段。 值得留意末尾的 [ofox.ai]：它标记这条报错是网关生成的，不是从上游转发的。排查到底哪一层拒了请求时，这个标记直接告诉你请求压根没出网关。

invalid_request_error —— 参数值非法

{"error":{"code":null,"message":"Unsupported value: 'reasoning_effort' does not support 'ultra' with this model. Supported values are: 'none', 'low', 'medium', 'high', and 'xhigh'.","param":null,"type":"invalid_request_error"}}

你传了一个模型不接受的值。 这和缺字段那种不一样：字段是存在的，值不存在。

但别信那个列表。 报错里列了五个值，漏了 max。我们把六个值全打到线上端点测了一遍，每一个都成功返回了补全：

所以这段报错文本是过时或不完整的，不能当权威。max 是一个真实存在的档位——我们的测评里讲了为什么它很少是你该选的那个：第三方测量显示它只比 high 高一个指数点，成本却大约翻倍。

哪些不是报错

响应变长不是失败。 结合上面 max_tokens 的行为，这个模型上最常见的「好像出问题了」的反馈，其实就是响应远长于预期。那是模型当前的正常表现，账单也照此走。

content 为空但有推理 token，同样不是失败。 在推理模型上，上限给低了可能在产出任何可见文字之前就被推理耗尽，于是 content 是空的，而 completion_tokens_details.reasoning_tokens 有值。这时该调高上限而不是重试。不过——Astra 本来就不认这个上限，所以你要是看到这种情况，先读 usage 再判断到底是哪种原因。

一个能跑通的请求

curl -X POST https://api.ofox.io/v1/chat/completions \
  -H "Authorization: Bearer $OFOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-6-astra",
    "messages": [{"role": "user", "content": "Answer in one sentence: what is quicksort?"}],
    "reasoning": {"effort": "high"}
  }'

注意真正起作用的是什么：限长写在 prompt 里，不在 max_tokens 里。把这个铺成循环之前，先读响应里的 usage.completion_tokens，和你的预期对一下。

到底哪些模型可调、什么价，以 GET https://api.ofox.io/v1/models 为准，不要以本页为准。

相关

• GPT-6 Astra API 价格——上面这些 token 到底值多少钱，含 272K 长上下文加价。
• GPT-6 Astra 测评——独立 benchmark 全貌和 effort 档位的成本曲线。
• 在 Codex、Cursor、Cline、DSH 里用 GPT-6 Astra——每个 agent 的可用配置。
• GPT-5.6 model not available——上一代的同类命名问题，包括 Codex 配 ChatGPT 账号那种情况。

来源

• https://ofox.io/models/openai/gpt-6-astra
• https://developers.openai.com/api/docs/models/gpt-6-astra

本页每一段报错原文都是 2026 年 9 月 6 日对 Ofox /v1/chat/completions 端点发真实请求抓回来的。max_tokens 的测量是四次打 openai/gpt-6-astra 的请求，加一次打 openai/gpt-5.6-sol 的对照，prompt 相同，只改被测参数。这是一天之内、单条线路上的小样本，不是规格——围绕它建成本模型之前，请在你自己的账号上验一遍。其他线路（包括 OpenAI 直连）的报错文本用的是另一套外壳。