
Last week, an engineering lead at a mid-sized startup told us his team's coding agent bill had grown 6x in two quarters. Not because the work got 6x harder. Because nobody was watching.上周,一家中型初创公司的工程主管向我们诉苦,言其团队的代码助手账单在短短两个季度内竟增长了六倍。并非是任务难度陡增六倍,而是无人加以审视,任其疯长。
Uber blew through their full 2026 AI budget in 4 months. Microsoft is cancelling Claude Code licenses across divisions. Salesforce is staring at a $300M Anthropic bill.昔日Uber在四月之内便耗尽了其2026全年之AI预算。微软亦在各部门取消了Claude Code的授权。Salesforce则面临着高达三亿美元的Anthropic账单。
The aftermath of “tokenmaxxing”“令牌最大化”之乱象初显
At the start of 2026, coding agent usage exploded, and teams started celebrating spend as progress. More tokens spent must mean more work done, more leverage gained, more proof that the AI bet is paying off. Just a few months later, we’re seeing the tides turn as bills explode and cost management becomes critical to scaling AI workloads.及至2026年初,代码助手的运用如燎原之火,各团队欢欣鼓舞,视花费为功绩。以为令牌消耗越多,则功业越盛,助力越强,AI之赌注越显其值。然仅数月之后,风向骤变,账单如山洪暴发,成本管控遂成AI运功之要务。
So how do you figure out where to cut spend? A single feature might touch Claude Code for the initial implementation, Cursor for inline edits, and Copilot Chat for a teammate's review, and each of those tools logs its own activity in its own format. Ask "what did we actually spend building this feature, and was it worth it?" and most teams can't answer.然则,何处可削减开支?一项功能,或由Claude Code初拟其形,再由Cursor细雕慢琢,复由Copilot Chat供同僚审阅。此三者,各自记录其行迹,格式迥异。若问:“此功能之筑,究竟耗费几何?又是否物有所值?” 大多数团队皆瞠目结舌,无从作答。
That's the moment tokenmaxxing turns into a liability instead of a phase. You have no reliable way to see whether it's earning its keep, because the unit of measurement is scattered across tools that don't talk to each other.此乃“令牌最大化”由盛转衰,化作累赘之刻。因衡量之尺规散落于互不相通之器械之中,故无从确知其是否确有所值。
The actual problem: fragmentation, not lack of data症结所在:非数据之匮乏,乃是割裂之顽疾
Every coding tool exposes some cost visibility. Copilot emits OpenTelemetry spans. OpenCode has session hooks. Pi has an extension. Cursor uses hooks. A tool call in Claude Code and a tool call in Cursor aren't recorded the same way, so you can't put them side by side and ask which one is doing more for the money.每种代码工具,皆能窥见其成本之一斑。Copilot吐纳OpenTelemetry之跨度,OpenCode设有会话钩子,Pi亦有扩展。Cursor则借助于钩子。然Claude Code与Cursor之工具调用,记录方式天差地别,故无法并列而论,探究何者性价比更高。
That fragmentation isn’t noticeable right up until your team scales past one tool, which is almost immediately. So how do you get one consistent view across all the agents your team actually uses?此种割裂,直至团队超越单一工具之界限,方显其弊,而此际几乎转瞬即至。故而,如何能一统观照,洞悉团队所用之诸般助手?
From visibility to control由洞察至掌控
Once we started digging into this with teams, a pattern emerged: solving it isn't just one problem, it's part of a cycle.吾等与诸团队深入探究此困,一脉络渐显:此症之解,非独一事之功,乃是循环往复之修炼。
- See your spend: Instead of five dashboards in five formats, you’ll want one consistent view across every coding agent your team actually uses. LangSmith now traces sessions from Claude Code, Codex, Cursor, GitHub Copilot Chat, Pi, and OpenCode into the same trace model. It’s the same metadata, same query syntax, regardless of which tool ran the session. You can finally ask "which sessions were expensive" and get one answer instead of five partial ones.洞察开销:摒弃五份迥异之仪表盘,当求一统视图,涵盖团队所用之所有代码助手。LangSmith今已能将Claude Code、Codex、Cursor、GitHub Copilot Chat、Pi及OpenCode之会话,悉数纳入同一追踪模型。其元数据、查询语法皆同,无论何种工具催动会话。终可问曰:“何种会话耗费巨资?”而得一统之答,而非五分之零散。

- Standardize cost across tools: Once you can see sessions side by side, you can compare them honestly. Token usage, cost per session, tool calls, and subagent activity normalized across tools means you can finally tell how much Cursor or Claude Code is doing for the money on a given workflow.统一诸工具之成本:一旦会话可并列而观,便可坦诚相较。令牌消耗、每次会话之成本、工具调用、子助手之活动,皆已统一衡量,方能明辨Cursor或Claude Code在特定工作流中,究竟物有所值几何。
- Optimize your usage: Seeing the data is what makes optimization possible, but most teams don't act on it because nobody has the bandwidth to manually review every session for waste. This is where Engine comes in: it analyzes agent sessions and surfaces concrete skill improvements, the kind of refinements a senior engineer would suggest if they had time to review every PR an agent produced. For example, if an agent is making redundant tool calls to retrieve the same context multiple times in a session, Engine flags it and recommends consolidating them. Instead of a dashboard telling you spend is high, you get a specific recommendation for what to change.优化运用:洞察数据乃优化之基石,然多数团队因无暇逐一审视会话之浪费,故难以为之。此乃Engine之用武之地:它剖析助手之会话,呈献具体之技艺精进,此乃资深工程师若有暇审阅助手所产之每一份代码,所能提出之改良建议。譬如,若助手在一次会话中,冗余调用工具以获取相同之上下文,Engine便会标记此弊,并建议整合。不再是仪表盘告知你开销过高,而是给出具体之改进建议。

- Govern your spending: Our LLM Gateway cost caps and governs at the user, team, and org level, and will soon be able to route to open source models where they're a fit. Open source models have gotten good and cheap enough that they belong as an option in every agent harness — not as a replacement for frontier models everywhere, but as a default for most work that doesn't require frontier intelligence. The same goes for subagents: cheap models handling scoped subtasks can keep a smart model from burning frontier-level cost on grunt work.管控开销:吾等之LLM Gateway,可于用户、团队及组织层面设定成本上限并加以管控,且不久将能依需将任务导向开源模型。开源模型已日臻精妙且价廉,足以成为每种助手配置之选项——非为全面取代前沿模型,而是作为大多数无需前沿智能之工作的默认之选。子助手亦然:廉价模型处理特定子任务,可免使智能模型于繁琐之事上耗费前沿级之成本。

Each of these stages makes the next one possible. Visibility tells you where to optimize. Optimization tells you where governance needs to be tightest. Governance protects the gains so the next round of visibility shows real progress instead of new waste.此诸阶段,环环相扣,相辅相成。洞察指明优化之径。优化揭示管控之要害。管控则守护所得之果,使下一轮洞察显现真实之进步,而非新增之浪费。
This solution is built for teams running more than one coding agent, which, based on what we hear from customers, is most teams within a few months of adoption. If your org has fully standardized on a single tool and that tool's native dashboard already answers your questions, you may not need a second layer yet. But the moment a second tool enters the mix, native dashboards stop being able to answer "across all of them, where is the money going”?此解法专为运行不止一种代码助手的团队而设,据吾等所闻,多数团队在采用数月后,皆会涉足此境。若贵组织已完全统一于单一工具,且该工具之原生仪表盘已能解答汝之疑问,则尚无需第二层之介入。然一旦第二种工具介入,原生仪表盘便无法回答“纵观全局,资金流向何方?”之问。
LangSmith for Coding AgentsLangSmith赋能代码助手
You don't need all four pieces on day one. If your team is in the early adoption phase, observability is the right place to start — you need to know which agents are running, what they're spending, and where sessions are failing before you can decide what to fix. If you're past that and starting to feel the bill, Engine and LLM Gateway are built to plug into the same trace data, so the move from "we can see it" to "we can fix it and cap it" doesn't require ripping anything out.非一日之功,四者皆需。若团队尚处早期采用阶段,可先从可观测性入手——需明了何种助手在运行,其花费几何,会话何处溃败,方能决断何处修补。若已越过此阶段,账单渐感沉重,Engine与LLM Gateway已备就,可接入同一追踪数据,故从“可见”至“可解可控”之转变,无需推倒重来。
Once configured, coding agent sessions appear as traces in LangSmith, the same way any production agent run would. Depending on the integration, a session can include:一旦配置就绪,代码助手之会话便如生产环境中之任何助手运行一般,以追踪之态显现于LangSmith。依集成之不同,一次会话可包含:
- User and assistant turns用户与助手之回合交锋
- Model calls with token usage and cost模型调用及其令牌消耗与成本
- Tool calls and shell commands工具调用与shell命令
- MCP activity and subagent invocationsMCP活动与子助手之召唤
- Errors and timing错误与时序
Traces are normalized to a common model (root session, turns, tool calls, metadata) so you can query across agents using the same fields. Filter by thread_id, model, provider, or tool name. You can find the expensive sessions, find the failing tool calls, and compare behavior across Cursor and Copilot without switching contexts.追踪数据已统一为通用模型(根会话、回合、工具调用、元数据),故可跨助手以相同字段进行查询。可按thread_id、模型、提供商或工具名称过滤。可寻觅耗费巨资之会话,探究失败之工具调用,并无需切换上下文,即可比较Cursor与Copilot之行为。
Getting Started启程之道
Setup is different for each tool: find the steps for Claude Code, Codex, OpenCode, Cursor, GitHub Copilot, Pi, or dcode.各工具之设置步骤各异:请查阅Claude Code、Codex、OpenCode、Cursor、GitHub Copilot、Pi或dcode之相关指南。
We built this because we lived through this problem ourselves: the bill kept climbing, and and we didn't have a clear sense of what work was actually worth the spend. Your engineering team will never standardize on one agent (and they shouldn’t have to!) since they’ll keep picking whatever fits the task best. The observability later has to meet them where they are: different agents, different event formats, one place to make sense of all of it.吾等构建此法,乃因亲历此困:账单节节攀升,而对何种工作确值此花费,却茫然无知。汝之工程团队,绝不可能统一于单一助手(亦不应如此!),因其总会择取最契合任务者。故而,可观测性之层级,必须迎合其所处之境:助手各异,事件格式纷繁,然皆需汇于一处,方能理清头绪。
LangSmith gives teams one place to debug and measure sessions across all your coding agents. Find your tool and get started.LangSmith为团队提供一统之地,用以调试与衡量所有代码助手之会话。寻觅汝之工具,即刻启程。







