OpenClaw Cost Dashboard: Track Agent Spend by Job, Tool, and Model

Token costs in OpenClaw accumulate silently. A cron job that runs four times a day might consume 50,000 tokens per run across two model providers. A sub-agent that handles customer queries might spike to 200,000 tokens during peak hours. The agent does not know or care what the tokens cost; it optimizes for task completion. The bill arrives at the end of the month, and the question becomes: which jobs, which tools, and which models drove the spend?

This article describes the problem of cost visibility in agentic AI deployments and outlines a practical approach to mapping token spend to specific jobs, tools, and models using event metadata that OpenClaw and its plugin ecosystem already produce.

The Invisible Cost Problem

Agentic AI has a cost structure that is different from traditional API usage. In a standard LLM integration, you control the prompt, you send one request, and you get one response. The cost is predictable and directly attributable to the code that made the call. In an agentic workflow, the agent decides:

• How many model calls to make: a simple task might take one call; a complex task might take ten, including tool-use loops where the agent calls a tool, reads the result, and calls the model again.
• Which model to use: if your agent configuration supports multiple providers (OpenAI for reasoning, Anthropic for code, a local model for simple tasks), the cost per call varies by an order of magnitude.
• How much context to include: the agent's context window grows as the conversation progresses. Later calls in a session include more tokens (all the prior messages, tool results, and memory) than earlier calls.
• Which tools to invoke: tools like browser automation or code execution may trigger additional model calls internally (e.g., the model processes the browser's page content or the code execution output).

The result is that cost per session is variable, cost per job is unpredictable, and cost per tool is invisible. Without instrumentation, you are flying blind.

Where Cost Data Lives in OpenClaw

OpenClaw produces several data points relevant to cost tracking, but they are scattered across different subsystems:

The pattern is familiar from cron run history and tool call history: the raw data exists, but assembling it into a useful view requires a capture-and-aggregate layer.

What a Cost Dashboard Should Show

A cost dashboard for agentic AI workflows needs to support three levels of granularity:

Per-job breakdown

Which cron jobs and interactive sessions are the most expensive? This view ranks sessions by total token cost, making it easy to spot runaway jobs. A weekly report that costs $0.50 per run is fine; one that costs $15 because the agent is re-reading the entire document tree every time is a problem worth fixing.

Per-model breakdown

If your agent uses multiple models, which model is driving the most spend? This view shows cost by provider and model (GPT-4o vs. Claude Sonnet vs. a local model), helping you evaluate whether the model routing is cost-effective. Maybe 80% of tasks could run on a cheaper model without quality loss.

Per-tool breakdown

Which tools trigger the most follow-up model calls? A read that loads a 10,000-line file dumps that content into the context window, inflating the token count for every subsequent call. A tool call timeline correlated with token costs shows which tools are the most expensive in practice.

Building Cost Visibility from Event Metadata

If you already have a tool call audit log capturing events with session IDs and tool names, adding cost data is an incremental step:

1. Capture token counts from llm_input/llm_output hooks or provider response headers. Add inputTokens, outputTokens, and model fields to the event schema.
2. Map tokens to cost using a pricing table (per-model, per-token-type rates). This table needs to be maintained as providers update pricing.
3. Aggregate by session to produce per-run cost summaries. This extends the existing run summary with a cost column.
4. Aggregate by model and tool to produce the per-model and per-tool breakdowns.
5. Set up alerting for sessions that exceed a cost threshold. A cron job that normally costs $0.50 but suddenly costs $5.00 should trigger a notification.

The event stream is the backbone. Cost data is just another dimension layered on top of the same events that power your audit log, run history, and tool call dashboard. This is why investing in a structured event pipeline pays compounding returns: each new view is an aggregation of existing data, not a new data collection effort.

How Zedly Shield Fits

Zedly Shield's event pipeline already captures the metadata that cost dashboards require:

• Session-scoped events: every tool call, policy decision, and lifecycle event is tagged with a session ID. This gives you the grouping key for per-job cost aggregation.
• Runs tab as the foundation: the Runs tab already computes per-session aggregations (duration, tool count, event count, block count). Adding a cost column to this view is an incremental data enrichment, not a new pipeline.
• Multi-instance visibility: for teams running OpenClaw across multiple deployments, the dashboard aggregates events from all instances. Cost data follows the same aggregation path, giving you fleet-wide cost visibility.
• Token tracking on the roadmap: Shield's ops expansion roadmap includes token-level cost tracking as a Phase 3 addition. The event schema, forwarding pipeline, and dashboard rendering are all designed to support new metric fields without architectural changes.

Even before native cost tracking ships, Shield's event stream can be exported to external analytics tools (pandas, a data warehouse, or a BI dashboard) where you can join event data with provider billing data to produce cost reports. The immutable event log ensures the data you analyze is trustworthy.

Frequently Asked Questions

Does OpenClaw track token costs automatically?

OpenClaw tracks some token usage through its diagnostics telemetry, including llm_input and llm_output events that include token counts. However, this data is not aggregated into a cost view. Token counts are available per-call, but mapping them to dollar amounts requires knowing the provider's pricing for the specific model and token type (input vs. output). A cost dashboard performs this mapping and aggregation.

How do I calculate cost per cron job?

You need two data sources: the token usage per LLM call (from OpenClaw's diagnostics or from the provider's API response headers), and the session grouping that maps LLM calls to cron jobs (from the session ID). If you are already capturing events with a tool call audit log, adding token counts to those events gives you the per-session aggregation. Multiply token counts by the model's per-token rate to get cost.

Which OpenClaw costs are hardest to track?

Tool execution costs that are not token-based: API calls to external services with their own billing (like search APIs, geocoding, or payment processors), compute time for long-running code execution, and storage costs for files written to disk or cloud storage. These costs are incurred by tool calls, not by model calls, so they require a different tracking mechanism than token counting. A tool call history dashboard helps identify these indirect costs.

Can I set cost alerts or budgets?

With event-level cost data, alerting is straightforward: sum the cost per session (or per time window) and trigger an alert when it exceeds a threshold. Budgets are harder because they require forecasting: if the current run is 60% through and has consumed 80% of its budget, should you stop it? The event stream gives you the data for both alerting (reactive) and budgeting (proactive), but the logic for budget enforcement is application-specific.

Does Zedly Shield track costs today?

Shield currently captures tool call events, session metadata, and run summaries. Token-level cost tracking is on the roadmap as the next ops expansion (Phase 3). The infrastructure for cost dashboards is already in place: the event pipeline captures session-scoped events, the Runs tab computes per-session aggregations, and the dashboard supports adding new metric columns. When cost data is added to the event schema, it flows through the same pipeline.