OpenClaw Adds Run-Level Cost Attribution Headers Because Agent Spend Is Now an Operations Problem
The most expensive agent in your stack is not necessarily the smartest one. It is the one running quietly in the background, triggered by a channel you forgot about, calling a long-context model through a proxy that only knows an API key and a model name. OpenClaw PR #93451 is small on paper — 68 additions across five files — but it touches the control plane every serious agent operator eventually has to build: explaining what spent the money.
The change adds an opt-in requestContextHeaders compatibility setting for OpenAI-compatible completions and responses providers. When configured, OpenClaw can forward three pieces of run context as custom HTTP headers: runId, messageChannel, and runKind. The operator chooses the header names. Nothing is sent by default. That last part matters: the feature is deliberately plumbing, not analytics theater.
The immediate driver is issue #93436, opened on June 15, which asks the question every AI budget owner eventually asks in less polite language: “how much is my costs going to Telegram, Whatsapp, email or heartbeat, this month?” OpenClaw already knows whether a run came from Slack, Telegram, WhatsApp, cron, heartbeat, or a normal message. But once the request leaves the embedded-agent runner and hits a metering proxy, that context previously collapsed into the same thing most LLM billing sees: provider, model, tokens, timestamp.
That is enough for a chatbot. It is not enough for an agent platform.
Token spend is now a runtime trace, not a spreadsheet row
Agent cost attribution is harder than assistant cost attribution because agents do not map cleanly to one human click. A Slack message can trigger a tool call. A cron job can kick off a research task. A heartbeat can check inboxes, calendars, weather, and project state. A subagent can fork work that calls a different model. Retry behavior can multiply spend without anyone seeing another user-visible reply. In that world, “model X cost $Y” is the least interesting line in the report.
PR #93451 wires normalization in packages/model-catalog-core/src/model-catalog-normalize.ts and injects headers in src/agents/embedded-agent-runner/run/attempt.ts. It follows OpenClaw’s existing session-affinity header pattern but avoids hard-coding any observability vendor. That is the right design. Helicone-style and LiteLLM-style gateways already live in front of many teams’ model traffic; OpenClaw does not need to become the billing product. It needs to preserve the metadata those products need.
The subtle win is that this happens at the model request boundary. Local logs can tell you what OpenClaw thought it was doing. Provider invoices can tell you what the model API charged. The boundary between them is where causality often dies. Custom run-context headers make that join deterministic: this request belonged to this run, from this channel, in this run kind. If your proxy records the headers alongside tokens and price, you can finally ask whether the runaway spend came from a human conversation, a scheduled job, a background heartbeat, or a loop that should have been killed ten minutes ago.
That changes how teams should compare coding agents. Price tables are useful, but only in the way cloud VM price tables are useful: necessary, incomplete, and dangerous when treated as the whole story. A cheaper model inside a runtime that cannot explain channel-level spend may be more expensive operationally than a pricier model behind good attribution. The grown-up question is not “what does a million tokens cost?” It is “what unit of work produced those tokens, and could we have capped, routed, or prevented it?”
The governance surface is bigger than the billing dashboard
There is a security angle here too. Headers are metadata, and metadata travels. runId, messageChannel, and runKind are not secrets in the same category as API keys, but they can still reveal workflow shape: which channels are active, which automation types exist, how often background jobs call models, and which run identifiers correlate to internal incidents. That does not mean “do not send them.” It means treat the feature like observability: opt in deliberately, choose boring header names, document retention, and redact where logs leave your trust boundary.
The PR’s operator-controlled header names are a good escape hatch. Enterprises can map OpenClaw context into their own internal conventions. Small teams can keep it simple. Proxies that already group requests by tenant, project, or agent can add channel and run kind without waiting for a standard nobody has written yet.
Practitioners should use this as a checklist item. If you are running OpenClaw behind a metering proxy, configure headers for run ID, channel, and run kind, then verify they appear in request logs before you need them during a cost incident. If you are evaluating Claude Code, Codex, OpenCode, Cursor, or a homegrown harness, ask the same thing: can the runtime attach stable cost context to each model call? Can background jobs be separated from interactive work? Can cron, heartbeat, chat, and delegated runs be budgeted independently? If the answer is no, your cost controls are vibes with invoices.
This is also where product teams should stop pretending “AI coding agent cost comparison” is a leaderboard article. The meaningful comparison now includes orchestration behavior: retries, concurrency, context compaction, model fallback, background triggers, and per-call attribution. A platform that can only show aggregate token usage is not ready for autonomous workflows at scale. It may still be useful. It is just not governable yet.
OpenClaw’s PR is not a complete cost system. It will not calculate budgets, enforce quotas, or detect loops on its own. But it moves the missing context to the place where those systems can see it. That is how infrastructure gets better: not with another dashboard first, but with the right identifiers crossing the right boundary.
The editorial take: the best coding agent is no longer just the one that solves the task. It is the one that can explain the bill. PR #93451 is boring header plumbing, which is exactly why it matters.
Sources: OpenClaw PR #93451, OpenClaw issue #93436