数学相关建议 5.2-xhigh ，5.3-codex 更加工程一点。然后推理至少都得开到 high 及以上，这种情况下几乎都会比 Claude 考虑全面，特别是长程任务。5.2-xhigh 在任务明确的情况下能工作超过 24h 做出完整的交付

Claude Opus 4.6 之前其实数学是相当糟糕的，我甚至不敢用它写一些难点的实验代码，4.6 好不少，基本能对标 5.2 才放心点

@neteroster 补充，这里有一些人做了一些实际问题的测试，虽然样本比较少，但总体符合我体感 https://linux.do/t/topic/1572659 gpt-5.2+ 在处理复杂长程任务是几乎没有对手的

唯一的例外是前端，这点 gpt 系列模型很一般

codex Windows 下有些小问题，没有处理可能体验不佳

除此之外 5.2-xhigh 是对标 opus4.6 的模型，5.3 codex 最近加快了速度，也很不错

Gemini 就算了，去和国产模型斗斗差不多，这周一批新国模出来大概率会全部超过他（ agent 编码领域）

之前研究过，小黄鱼上只要是你图中这个文案的机器都是有问题的，别买，有些人买到过拆过甚至换过屏幕的机器，根本不是所谓的未拆封

有一个压缩阈值，参见 https://github.com/openai/codex/issues/9429

你不愿意的话也可以 patch 代码改回来

等月末 Intel PTL 产品出来看看

没看懂这是要比啥，语言模型和逻辑编程语言是两个完全不同的物种吧。那我还能说计算器能几 ns 算一个乘法，大模型慢得多呢，何意味...

不要折磨自己了，你这个又不是什么强隐私相关需求。长上下文、rag 这种都是重 prefill ，高计算的负载，M 芯片最不擅长的领域就是这，首字慢到你怀疑人生，16G 内存能跑的模型长上下文注意力可想而知...

@maolon Gemini 的 coding agent 就是不行，SWE 刷那么高，实际上一到实际工况里打不了 Opus 和 GPT 5.2 一点，毕竟 coding agent 起手就是 20+K ，再加上对指令遵循的强要求，都是 Gemini 的弱势区域

Gemini 3 Pro 的有效上下文在 32K 左右，日常使用（特别是多轮对话） 20K 就可注意到显著的注意力和指令遵循下降，40K-50K 左右注意力崩溃。有趣的是，这甚至是相比 Gemini 2.5 Pro 的倒退。甚至 Gemini 3 Flash 也比 Gemini 3 Pro 有效上下文高。

这个问题关注到的人并不多，无脑吹反而更多。RP （角色扮演）社区是最先注意到这个问题的，他们在 Gemini 3 Pro 还未发布在竞技场匿名测试时就系统测试了其上下文能力，并通过体感立即注意到异常。

GPT 5.2 (xhigh)，长程 Agent 任务执行的新高度

Agent 编码的话，拉完了！ Gemini 3 Pro 多轮对话 + (>20K 上下文) 的情况*几乎*是没法用的

当前推荐：

1. Claude Code / Cursor + Claude Opus 4.5
2. Codex + GPT-5.1 / GPT-5 / GPT-5-Codex-Max 或 Cursor + GPT-5 / GPT-5.1

其实 function call 或者 structure output 区别没那么大，推理后端没做约束解码的话，function call 的参数也不能保证准确... 做了约束解码的话，structure output 和 function call 都是保证准确的。

当然，唯一的例外的是，部分提供商只做了 function call ，或者只有 function call 用了约束解码

直接支付不支持大陆和香港卡，别想了

openrouter 不行，他那个 responses 是假的，无状态的。国内有一些中转是考虑了这个东西的，具体方法不明，据我粗略测试大多数应该是只开一个号，状态就不会有问题，还有少数*可能*做了状态管理

Gemini 2.5 Pro / Sonnet 4.5 ，有耐心可以等 Gemini 3 ，大概率强 SOTA

注意 Deepseek 的推理模式不兼容工具调用，出现工具调用后应该是会自动回退到 chat 模型

目前原生视频多模态做的还行的也就 Gemini

有的，通知还会出现去不掉的情况，如 @eagleoflqj 所说。解决方法也很简单

1. 先去设置，开发者设置那里生成一个 classic 的 token

2.
读通知

curl -L \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <YOUR-TOKEN>" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/notifications

记下垃圾未读通知的 ID

3. 把他删掉

curl -L \
-X DELETE \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <YOUR-TOKEN>" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/notifications/threads/THREAD_ID