GitHub Copilot 里的 GPT-5.4，到底是 1M context 还是只有 128K？

AI攻城狮
0 阅读8分钟

GitHub Copilot 里的 GPT-5.4，到底是 1M context 还是只有 128K？

最近在使用 OpenClaw 接 GitHub Copilot 的 GPT-5.4 时，我注意到一个很容易让人困惑的现象：UI 里显示的 token budget 是 128K，但网上又能查到 OpenAI 官方说 GPT-5.4 支持 1M tokens of context。

那问题来了：GitHub Copilot 里的 GPT-5.4，真实可用的 context window 到底是多少？

这篇文章我把能查到的公开信息做了一次交叉验证，结论先放前面。

TL;DR

短结论：

  • GPT-5.4 模型本体：OpenAI 官方公开能力是 up to 1M tokens of context。
  • GitHub Copilot 官方文档：确认 GPT-5.4 已上线，但没有公开写死 numeric context window / max_prompt 数字。
  • Copilot 实际接入层：从 GitHub Community 对 Copilot backend models API 的实测来看，GitHub Copilot 体系里很多 GPT-5 系列模型都存在一个现象：
    • context_window 看起来很大
    • 但 实际 max_prompt 只有 128000
  • 因此，对 github-copilot/gpt-5.4 这类接入来说，最合理的判断是：
    • 理论模型窗口 = 1M
    • 实际在 Copilot / 某些集成中的有效输入上限，很可能仍然是 128K 左右

换句话说，1M 和 128K 这两个数字并不一定互相矛盾，它们描述的可能不是同一层限制。

为什么会出现两个不同的数字？

这类问题通常是因为大家把三个不同概念混在一起了：

  1. Model context window
  2. Max prompt tokens
  3. Max output tokens

很多产品页面、文档甚至 API，会把它们同时暴露出来，但用户最直觉看到的往往只有 “context window” 这个数字，于是容易误以为：

既然模型支持 1M，那我就应该能一次性喂进去接近 1M 的 prompt。

实际上不一定。

更精确一点说：

  • context window：模型总上下文容量
  • max prompt：你单次请求里最多能塞进去多少输入 token
  • max output：模型最多能吐出多少输出 token

如果平台在接入层做了限制，那么就可能出现：

  • 模型本体支持 1M context
  • 但平台实际只允许你塞 128K prompt

这恰恰就是 GitHub Copilot 体系里最值得注意的地方。

证据 1：OpenAI 官方明确说 GPT-5.4 支持 1M context

在 OpenAI 的官方文章 Introducing GPT-5.4 中，有一句非常关键：

“It supports up to 1M tokens of context ...”

这条信息的可信度最高，因为它来自模型提供方本身。

所以如果问题是：

“GPT-5.4 这个模型本体的公开 context window 是多少？”

答案就是：1M。

这也是很多二手文章、媒体报道会直接引用的数字来源。

但是，这里要强调一句：

模型能力上限，不等于每个接入方都会无损暴露全部能力。

这点在企业接入、代理层、IDE 集成、第三方平台中都很常见。

证据 2：GitHub 官方确认 GPT-5.4 已进入 Copilot，但没给 token 数字

GitHub 官方 changelog GPT-5.4 is generally available in GitHub Copilot 已经明确：

  • GPT-5.4 已在 GitHub Copilot rollout
  • 可在 VS Code、Visual Studio、JetBrains、Xcode、Eclipse、GitHub CLI、Copilot Coding Agent 等环境中使用

同时，GitHub Docs 的这些页面也都能确认 GPT-5.4 的存在：

  • Supported AI models in GitHub Copilot
  • AI model comparison
  • Hosting of models for GitHub Copilot Chat

但关键点在于：

这些 GitHub 官方文档，至少在我检索时，都没有公开写出 GPT-5.4 在 Copilot 中的 context_window、max_prompt、max_output 的具体 token 数值。

也就是说，GitHub 官方给了你：

  • 模型可用性
  • 使用场景
  • 托管方式
  • 计费 multiplier

但没有给你最容易引发误解的那组 limits。

这正是很多用户会困惑的原因：模型名可选到了，但配套的真实 token 限制信息不透明。

证据 3：GitHub Community 讨论显示，Copilot API 里常见“大 context + 小 max_prompt”

在 GitHub Community 的一个讨论里，有开发者直接查询了 Copilot backend 的 models API，并总结出这样的现象：

  • 某些模型的 context_window 可以是 400K
  • 但 max_prompt 只有 128K
  • 用户实际遭遇的报错，也是：
    • prompt token count exceeds the limit of 128000

这个讨论里举到的例子主要是 GPT-5、GPT-5.1、GPT-5.2 等模型，而不是直接贴出 GPT-5.4 的官方 limits 文档。但它至少说明了一件非常重要的事实：

在 GitHub Copilot 的模型接入体系里，“声明的大窗口”和“用户真实可喂的 prompt 上限”并不总是相同。

这就让 128K 这个数字不再像一个偶然 bug，而更像是 Copilot integration 的有效输入限制。

如果你的工具链里显示：

  • tokens 0/128k

那它很可能显示的是：

  • effective prompt budget

而不是：

  • 模型理论上的 absolute context ceiling

为什么 OpenClaw / 其他工具会显示 128K？

如果你在上层工具里看到的是 128K，通常有三种可能：

1）工具读取的是 provider/model registry 的保守值

很多 agent framework 不会直接显示“模型宣传页数字”，而是使用：

  • 自己维护的 model registry
  • provider 返回的已知稳定限制
  • 本地配置里写死的 contextWindow

这种做法是合理的，因为从工程视角来看：

宁可按稳定可用的 128K 估算，也不要盲信 1M 后导致请求失败。

2）工具显示的是可用 prompt cap，而非总 context

一些 UI 会把：

  • 实际允许输入的 tokens

直接展示成上下文预算。

这对用户来说更实用，但会和模型宣传口径不一致。

3）provider 侧本身做了 routing / policy / mode-specific limits

即使底层模型支持更大窗口，不同入口也可能有不同策略，例如：

  • CLI 一套限制
  • IDE Chat 一套限制
  • Agent mode 一套限制
  • Edit mode 一套限制

所以同一个“GPT-5.4”，在不同产品形态下看到的限制不一定一样。

一个更准确的理解框架

如果以后再看到某个模型写着 “1M context”，建议不要立刻把它理解成：

“我现在就能稳定喂 1M 的 prompt。”

而应该分成两层来看：

Layer 1：模型规格（theoretical model capability）

  • 例如 GPT-5.4 = 1M context

Layer 2：平台接入规格（effective serving limits）

  • 例如 Copilot 某接入口 = 128K max_prompt

对于开发者真正重要的，往往不是 Layer 1，而是 Layer 2。

因为决定你代码、日志、文档、历史消息能否一次塞进去的，是：

  • 实际 prompt cap
  • 而不是 marketing-friendly 的 max context window

那么，GitHub Copilot 里的 GPT-5.4 应该怎么表述才更准确？

我认为最不容易误导用户的表述应该是下面这种：

GitHub Copilot 已支持 GPT-5.4。OpenAI 官方将 GPT-5.4 定义为 1M context 模型；但 GitHub Copilot 官方当前未公开 GPT-5.4 的 numeric limits。结合 Copilot API 的社区实测与实际工具表现，Copilot 集成中的有效输入上限很可能仍接近 128K。

这个说法有几个好处：

  • 不否认 OpenAI 的 1M 官方规格
  • 不把 1M 误说成 Copilot 里必然可用的 prompt 上限
  • 也不把 128K 误说成模型本体的极限

它把“模型能力”和“平台可用额度”清楚地区分开了。

对开发者的实际建议

如果你在 GitHub Copilot、Copilot CLI、OpenClaw 或类似接入里使用 GPT-5.4，我建议这样处理：

建议 1：按 128K 级别做 prompt 设计

在 GitHub 官方没公开 GPT-5.4 limits 前，工程上优先按 128K 左右预算去设计 是更稳妥的。

例如：

  • 不要一次性把整个 monorepo 全塞进去
  • 先做文件筛选、摘要、检索再组装 prompt
  • 对历史对话做 compaction
  • 控制 tool output 的长度

建议 2：把“模型 context”与“产品可用 context”分开记录

团队内部如果要做文档、选型或 benchmark，最好明确写成两列：

维度含义
Model context window模型理论上限
Effective max prompt平台当前实际可用输入上限

这样可以少掉很多沟通误差。

建议 3：关注 provider 返回的 limits，而不是只看 marketing 页面

真正影响工程稳定性的，通常是：

  • max_prompt_tokens
  • max_output_tokens
  • 是否按模式区分限制
  • 是否存在自动压缩 / compaction / truncation

只看“1M context”很容易做出过于乐观的设计。

最后的结论

回到文章开头那个问题：

GitHub Copilot 里的 GPT-5.4，到底是 1M context 还是只有 128K？

更准确的回答是：

  • 如果你问模型本体规格：是 1M。
  • 如果你问 GitHub Copilot / 现有集成里用户大概率实际能稳定使用的输入额度：更像是 128K 级别。

所以，这不是“谁对谁错”的问题，而是“你在问哪一层限制”的问题。

对开发者而言，最重要的不是宣传页上写多少，而是：

当前接入层到底允许你稳定输入多少。

在这一点上，现阶段关于 GitHub Copilot GPT-5.4 的最稳妥工程判断，依然应该偏向：

1M theoretical, ~128K effective until proven otherwise.

参考资料

  1. OpenAI — Introducing GPT-5.4
    openai.com/index/intro…

  2. GitHub Blog — GPT-5.4 is generally available in GitHub Copilot
    github.blog/changelog/2…

  3. GitHub Docs — Supported AI models in GitHub Copilot
    docs.github.com/en/copilot/…

  4. GitHub Docs — Hosting of models for GitHub Copilot Chat
    docs.github.com/en/copilot/…

  5. GitHub Community — Why can't we fully utilize context_window? (Data from Copilot's own API)
    github.com/orgs/commun…

avatar
文章
阅读
粉丝