Tool-Call Cost Attribution Prompt per Tool

This prompt is designed for FinOps engineers and platform teams who need to move beyond aggregate cost monitoring and understand exactly which tools are driving inference spend within a production agent trace. The core job-to-be-done is post-hoc cost attribution: taking a raw trace containing multiple tool calls, their descriptions, arguments, and outputs, and producing a per-tool cost breakdown. This breakdown must separate token consumption into tool description tokens (the schema overhead), argument tokens (the input), and output tokens, then assign a cost based on the model's pricing tier. The output is a structured report that ranks tools by cost, identifies the most expensive calls, and highlights optimization targets such as tools with oversized descriptions or verbose outputs. The ideal user is someone who already has access to production trace data and needs to make budget planning, tool rationalization, or context-window optimization decisions based on real usage patterns rather than assumptions.

Use this prompt when you have exported a single agent trace or a batch of traces from your observability platform and need a detailed cost attribution before making engineering decisions. The prompt expects a structured [TRACE_INPUT] containing the model identifier, per-token pricing, and a list of tool calls with their full schemas, arguments, and outputs. It is not designed for real-time cost estimation during a live request; that requires a lightweight token-counting function in your application code, not an LLM call. This prompt is also not a replacement for aggregate cost dashboards—it is a diagnostic tool for deep-diving into specific traces to find optimization opportunities. Do not use this prompt when you need sub-millisecond latency or when the trace contains sensitive data that should not be sent to an external model; in those cases, pre-process the trace to redact sensitive fields or use a local model. The prompt assumes you have already resolved the model's per-token pricing (input and output) and included it in the input context; it will not fetch or guess pricing tiers.

Before running this prompt, ensure your trace data includes the full tool call payload: the tool's name, its JSON Schema description (the part that consumes description tokens), the arguments passed, and the complete tool output. Missing any of these components will produce an incomplete or misleading cost report. After receiving the output, validate that the token counts are plausible by spot-checking against a known tokenizer for your model. The report should be treated as a starting point for optimization conversations—pair it with latency data and error rates to prioritize which tools to refactor, simplify, or replace. If the report identifies a tool whose description tokens exceed its argument and output tokens combined, that tool's schema is likely too verbose and should be trimmed before the next deployment.

This prompt template is designed for FinOps engineers and platform developers who need to attribute costs to individual tool calls within a production agent trace. It takes a raw trace, a pricing table, and an output schema, and returns a per-tool cost breakdown. Use this when you need to identify which tools are driving your inference spend, so you can target optimization efforts at the most expensive calls.

codeCopy
You are a cost attribution analyst for an AI platform. Your task is to analyze the provided agent trace and attribute token and latency costs to each tool call.

[TRACE]
[PRICING]

Instructions:
1. Parse the trace to identify every distinct tool call. A tool call includes the tool description tokens sent to the model, the argument tokens, and the output tokens returned by the tool.
2. For each tool call, calculate the token count for:
   - `tool_description_tokens`: Tokens used to describe the tool's schema and purpose in the system prompt or function manifest.
   - `argument_tokens`: Tokens in the arguments the model generated for the call.
   - `output_tokens`: Tokens in the tool's response that were fed back into the model's context.
3. Using the provided [PRICING] table, calculate the cost for each token category based on the model used for that step.
4. Sum the costs to get a `total_cost` for each tool call.
5. Calculate the `latency_ms` for each tool call from the trace timestamps.
6. Return the results as a single JSON object matching the [OUTPUT_SCHEMA].

[OUTPUT_SCHEMA]
{
  "trace_id": "string",
  "total_trace_cost": "number",
  "total_trace_latency_ms": "number",
  "tool_calls": [
    {
      "tool_name": "string",
      "call_index": "integer",
      "tool_description_tokens": "integer",
      "argument_tokens": "integer",
      "output_tokens": "integer",
      "total_tokens": "integer",
      "cost": "number",
      "latency_ms": "number"
    }
  ]
}

[CONSTRAINTS]
- Do not estimate or interpolate costs. Use only the provided [PRICING] table.
- If a token count cannot be determined from the trace, set the field to null and add a `warnings` array to the output object explaining the gap.
- Round all costs to 6 decimal places.
- If the trace contains no tool calls, return an empty `tool_calls` array with `total_trace_cost` and `total_trace_latency_ms` set to 0.

To adapt this template, replace the [TRACE] placeholder with your raw agent trace data, typically a JSON object containing model requests, tool call events, and timestamps. The [PRICING] placeholder should be a table mapping model names to per-token costs. If your trace format differs, adjust the parsing instructions in step 1. For high-stakes financial reporting, always validate the output against a known trace with pre-calculated costs before trusting the prompt in an automated pipeline.

This prompt is designed to operate on a single, pre-processed trace object. The primary integration point is a post-processing step within your observability pipeline, triggered after a trace is completed and exported. The application harness is responsible for extracting the relevant trace segment, formatting it into the [TRACE_JSON] input, and injecting the [TOOL_MANIFEST] and [PRICING_CONFIG] before calling the model. Do not send raw, full-trace blobs; pre-filter to include only the tool_calls array, their arguments, outputs, and associated usage metadata to keep the prompt focused and token-efficient.

The harness must enforce a strict validation contract on the model's output. Parse the generated JSON report and validate that every tool_name in the cost_breakdown array exists in the provided [TOOL_MANIFEST]. Reject any report that attributes cost to hallucinated or non-existent tools. Implement a retry loop with a maximum of two attempts: if validation fails, append the validation error to the prompt context and re-request the report. Log all validation failures and retries as a cost_attribution_error metric. For high-stakes FinOps workflows, route reports with a total_cost variance greater than 5% from the trace's own recorded cost to a human review queue before ingestion into your billing system.

Model choice matters here. Use a model with strong JSON mode and long-context handling, such as gpt-4o or claude-3-opus, because the prompt requires precise arithmetic across many tokens and strict schema adherence. Cache the [TOOL_MANIFEST] and [PRICING_CONFIG] as a reusable system prefix to reduce per-request latency and cost. Finally, store the validated cost report as a structured log event keyed by trace_id, enabling downstream aggregation into per-tool cost dashboards. Avoid running this prompt on every trace in real-time; sample high-cost or anomalous traces first to control inference spend.