Tracking and controlling AI call costs in your n8n workflows

An n8n workflow that triages emails or answers questions via an LLM never shows a running cost counter. As long as volume stays low, nobody looks. Then the monthly OpenAI or Anthropic bill arrives, and it becomes impossible to tell which workflow, which node, or which model consumed what — let alone catch a cost drift before it gets expensive. The problem isn't only organizational: n8n makes token tracking harder than it looks, for one specific technical reason.

The AI Agent node trap

The AI Agent node (@n8n/n8n-nodes-langchain.agent), used in most AI workflows — including those in the Inbox AI Pack and the RAG Assistant Pack — does compute a tokenUsage object on every model call. That's visible in the execution panel of the Chat Model sub-node itself (lmChatOpenAi, lmChatAnthropic). The catch: that data is never propagated up to the parent Agent node's output. Only tokens spent on any tool calls surface in intermediateSteps — not the ones from the main model call, which is where most of the cost actually sits. This is a documented, repeatedly-reported limitation in the n8n community, still unresolved as of today: you cannot wire a downstream node to {{ $json.tokenUsage }} off an Agent's output and get anything usable.

In practice, that means a clean cost-monitoring setup can't just bolt a node onto the AI Agent's output — the approach has to change depending on what the workflow actually does.

Two ways to get the real usage numbers

For workflows that don't need multi-tool function calling — an email classification task like the triage workflow in the Inbox AI Pack, a summary, a field extraction — swap the AI Agent node for an LLM Chain node (chainLlm, often paired with a Structured Output Parser to force JSON output). This node exposes the tokenUsage object directly in its output, no workaround needed.

For workflows that genuinely need the AI Agent — a RAG chatbot like the one in the RAG Assistant Pack, which has to query a vector-search tool before answering — the fix is to call the provider's API directly through an HTTP Request node instead of the native Chat Model node, at least on the path where cost matters. OpenAI's raw API response (/v1/chat/completions) includes a usage field with prompt_tokens and completion_tokens; Anthropic's API (/v1/messages) returns usage.input_tokens and usage.output_tokens. It's more setup than a prebuilt node, but it's the only reliable way to get an accurate number until n8n fixes this behavior.

Building a cost log in Supabase

Once you're capturing usage, the next stop is a logging table — the same pattern described in our guide on GDPR audit trails, applied here to cost instead of compliance:

create table ai_usage_log (
  id uuid primary key default gen_random_uuid(),
  created_at timestamptz default now(),
  workflow_name text not null,
  node_name text,
  model text not null,
  input_tokens integer not null,
  output_tokens integer not null,
  estimated_cost_usd numeric(10,6) not null
);

A Code node, placed right after usage is captured, computes the cost from a manually maintained per-model pricing table (provider rates change often enough that this Code node is the one place you need to keep up to date):

const pricing = {
  "gpt-4o-mini": { input: 0.15, output: 0.60 },
  "gpt-4o": { input: 2.50, output: 10.00 },
  "claude-haiku": { input: 0.80, output: 4.00 },
};

const { model, prompt_tokens, completion_tokens } = $input.item.json;
const rate = pricing[model];
const cost =
  (prompt_tokens / 1_000_000) * rate.input +
  (completion_tokens / 1_000_000) * rate.output;

return { json: { model, input_tokens: prompt_tokens, output_tokens: completion_tokens, estimated_cost_usd: cost } };

(Indicative prices per million tokens, for illustration — always check your provider's current pricing page before relying on this for a real budget.)

A Supabase insert node, run in parallel with the rest of the workflow rather than blocking the critical path, writes the row to ai_usage_log. Within a few days, a simple SQL query grouped by workflow_name or model answers the question your provider's monthly invoice never breaks down: which specific workflow costs what.

Alert before the drift, not after the bill

Logging isn't enough if nobody checks the table before month-end. A second workflow, triggered by a daily Cron, sums up the day's or rolling month's costs and compares the total to a defined threshold. Past it, it sends a Slack alert — the same mechanism described in our guide on n8n error handling and alerts, applied here to a budget threshold instead of a technical failure:

SELECT model, SUM(estimated_cost_usd) as total
FROM ai_usage_log
WHERE created_at > now() - interval '1 day'
GROUP BY model;

This guardrail changes the dynamic in practice: instead of discovering at month-end that a poorly tuned daily digest sent ten times more calls than expected, the alert lands the same day, with the responsible model and workflow already identified.

Model choice is still the first lever

Tracking doesn't replace upfront optimization. The workflows in the Inbox AI Pack default to gpt-4o-mini, precisely because a classification or urgency-scoring task doesn't need the power — or the price tag — of a larger model: for a 100-email-a-day inbox, the bill stays around a few cents to $1-2 a month. Conversely, a RAG chatbot like the one in the RAG Assistant Pack, where answer quality matters directly to the end user, more often justifies a mid-tier model — that's a trade-off worth making consciously, model by model, rather than leaving the default setting everywhere. Our guide on connecting Claude or GPT to n8n covers switching a workflow between providers or models without rewriting the business logic — a change the cost log lets you validate objectively, before/after, instead of by feel.

Common pitfalls

• Trusting the Chat Model node's token estimate without checking real usage: some sub-nodes display a rough estimate rather than the exact count the API returns; when in doubt, a direct HTTP Request call remains the most reliable source.
• Logging without ever querying the table: an ai_usage_log that grows with no dashboard or alert has the same flaw as an error log nobody re-reads — the data exists, but nobody acts on it in time.
• Forgetting embedding costs: in a RAG pipeline like the one in the RAG Assistant Pack, ingesting large documents also generates billed calls (embeddings), separate from answer-generation calls — log them separately if ingestion volume is significant.
• Not updating the pricing table: AI provider rates change more often than you'd think; a cost estimated on stale rates silently skews every downstream alert.

Going further

Tracking the real cost of your AI calls becomes especially useful once several workflows run in parallel on different models — exactly the situation with the Complete FlowKit Bundle, which brings together email triage, a RAG assistant, and AI-generated compliance reports. A single ai_usage_log, fed by all three packs, is enough to answer in one SQL query the question your provider's monthly invoice never breaks down.