Research Preview

Tencent WorkBuddy Bench Tencent WorkBuddy Bench

Can coding agents solve real repository, front-end and office tasks end-to-end? 编程 Agent 能否端到端解决真实的仓库、前端与办公任务?

Loading leaderboard…

01

Key Takeaways核心结论

  • No single model dominates — column leadership splits across subsets and harnesses: Claude Opus 4.8 leads five of the eight scored columns (Code on both harnesses 74.43 / 77.90, Web on both harnesses 68.14 / 69.86, Office on CodeBuddy Code 82.37), GLM-5.2 two (Security 76.32 / 80.86 on both), GPT-5.5 one (Office 86.05 on Claude Code).没有一家通吃：各列榜首分散在不同子集与 harness 之间:Claude Opus 4.8 拿下八个计分列中的五个(Code 双 harness 74.43 / 77.90、Web 双 harness 68.14 / 69.86、CodeBuddy Code 下 Office 82.37),GLM-5.2 两个(Security 双 harness 76.32 / 80.86),GPT-5.5 一个(Claude Code 下 Office 86.05)。
  • An open-weight model holds its own: GLM-5.2 tops Security under both harnesses — two of the eight columns — and stays within a point of the Code lead under Claude Code; open-weight competitiveness here is board-dependent, not uniform.开源权重模型不落下风:GLM-5.2 在两个 harness 下均领跑 Security(拿下八个计分列中的 两个),并在 Claude Code 下的 Code 榜上与榜首相差不到一分。开源权重的竞争力在这套基准上因榜单而异,并非全面领先。
  • The harness is part of the result: the same model can swing hard between harnesses — GLM-5.2 on Web scores 67.43 vs 60.71, GPT-5.5 on Security 77.91 vs 64.39 — so read scores per harness.harness 是结果的一部分:同一模型在不同 harness 下可能大幅波动 —— GLM-5.2 在 Web 上 67.43 vs 60.71,GPT-5.5 在 Security 上 77.91 vs 64.39，分数应按 harness 分开解读。
  • Efficiency does not follow rank: GPT-5.5 reaches top-tier scores on the smallest CodeBuddy Code output budgets across all four subsets, while some mid-table runs spend 3–4× the tokens.效率与排名并不一致:GPT-5.5 在 CodeBuddy Code 下的全部四个子集都以最小的输出 token 预算拿到第一梯队分数,而一些中游成绩却要花 3–4 倍 的 token。
  • Integration details move scores: enabling cross-turn reasoning passback for HY-3 lifted its Code score by +3.82 (CodeBuddy Code) / +1.92 (Claude Code) in a diagnostic rerun.接入细节会左右分数:在一次诊断性复跑中,为 HY-3 开启跨轮推理回传后,其 Code 分数提升 +3.82(CodeBuddy Code)/ +1.92(Claude Code)。
02

Token efficiencyToken 效率

score vs output tokens per run, 3-run avg分数 vs 每次运行输出 token，三次运行平均

CodeBuddy Code 2.109.3 · Claude Code 2.1.187 · think

Efficiency does not follow rank order: GPT-5.5 posts top-tier scores at the smallest output budgets in every subset (Code 6.9k, Office 10.2k, Security 7.5k output tokens on CodeBuddy Code), while GLM-5.2’s column leads are paid for in tokens — 22.0k for its Code lead under Claude Code, 30–31k on Security. Security is by far the heaviest subset: MiniMax-M3 averages 88.8 turns and roughly 11.1M cache-inclusive input tokens per run under CodeBuddy Code for its 74.14. 效率与排名并不一致：GPT-5.5 在每个子集都以最小的输出预算拿到第一梯队分数（CodeBuddy Code 上 Code 6.9k、Office 10.2k、Security 7.5k 输出 token），而 GLM-5.2 的多个榜首列是用 token 换来的：Claude Code 下 Code 榜首花费 22.0k，Security 30–31k。Security 是 token 消耗最大的子集：MiniMax-M3 在 CodeBuddy Code 下平均每轮运行 88.8 次交互、输入 token（含缓存）约 1,110 万，最终得分 74.14。

All points are 3-run averages in think mode. Turns count unique assistant messages including subagent activity; output tokens come from each run’s final usage. Output tokens are the comparable axis — input-token accounting differs across harness configurations, so input tokens are never compared across harnesses. 所有数据点均为 3 次运行平均、think 模式。轮数按去重后的 assistant 消息计数（含 subagent 活动）；输出 token 取自每次运行的最终 usage。图中仅比较输出 token，输入 token 的统计口径随 harness 配置不同，因此不做跨 harness 的输入 token 比较。