Self Checks
1. Is this request related to a challenge you're experiencing? Tell me about your story.
I've been building workflows using the new Agent node (the sandboxed, beta Agent introduced in 1.16.0) both as a standalone chat app and as a step inside a workflow. My use case requires tracking how much each Agent run costs — specifically, how many input/output tokens the underlying LLM consumed during that run — so I can convert this into an internal credit/billing system for our users.
The problem is that the new Agent node's output variables are currently limited to just text and json. There is no usage field (or any equivalent like input_tokens / output_tokens / total_tokens) available for downstream nodes to reference.
This is a real blocker for cost-tracking and billing use cases:
The classic Agent node at least surfaces token usage in its execution log/details panel (for human inspection), even though that data still isn't exposed as a referenceable output variable for downstream nodes.
The new Agent node doesn't appear to expose usage information anywhere in the node output that a workflow can consume — not even for manual inspection in the run log, as far as I can tell.
As a workaround, I've had to instruct the Agent (via its system prompt) to self-report an estimated token_usage object as part of its own JSON output, then parse that with a downstream Code node. This is unreliable — the numbers are the model's own estimate, not the actual usage reported by the LLM provider's API, and the output format is inconsistent (sometimes the structured data lands in text, sometimes in json, sometimes duplicated/nested across both).
Since the underlying LLM call already returns real usage data from the provider (prompt_tokens / completion_tokens / total_tokens, following the OpenAI-compatible format that most providers including DeepSeek, Claude, and GPT already return), it seems like this data should already exist somewhere in the Agent runtime — it's just not being surfaced to the node's output.
2. Additional context or comments
Feature request: please add a structured usage output variable to the new Agent node (both as a standalone app and as a workflow node), containing at minimum:
input_tokens (or prompt_tokens)
output_tokens (or completion_tokens)
total_tokens
If possible, it would also be valuable to include:
Per-tool-call token/credit breakdown, since a single Agent run can invoke multiple tools internally, and we currently have no way to know how many times each tool was called from the node output alone.
A separate reasoning_tokens (or thinking_tokens) field for models that support extended thinking/reasoning mode, since this is currently mixed into the general output token count with no way to distinguish it.
This would let workflow builders reliably calculate cost/credits downstream without having to rely on the LLM self-reporting an estimated token count in its own reply, which is both inaccurate and format-unstable.
Thanks for considering this — happy to provide more details on our use case if helpful.
3. Can you help us with this feature?
Self Checks
1. Is this request related to a challenge you're experiencing? Tell me about your story.
I've been building workflows using the new Agent node (the sandboxed, beta Agent introduced in 1.16.0) both as a standalone chat app and as a step inside a workflow. My use case requires tracking how much each Agent run costs — specifically, how many input/output tokens the underlying LLM consumed during that run — so I can convert this into an internal credit/billing system for our users.
The problem is that the new Agent node's output variables are currently limited to just text and json. There is no usage field (or any equivalent like input_tokens / output_tokens / total_tokens) available for downstream nodes to reference.
This is a real blocker for cost-tracking and billing use cases:
The classic Agent node at least surfaces token usage in its execution log/details panel (for human inspection), even though that data still isn't exposed as a referenceable output variable for downstream nodes.
The new Agent node doesn't appear to expose usage information anywhere in the node output that a workflow can consume — not even for manual inspection in the run log, as far as I can tell.
As a workaround, I've had to instruct the Agent (via its system prompt) to self-report an estimated token_usage object as part of its own JSON output, then parse that with a downstream Code node. This is unreliable — the numbers are the model's own estimate, not the actual usage reported by the LLM provider's API, and the output format is inconsistent (sometimes the structured data lands in text, sometimes in json, sometimes duplicated/nested across both).
Since the underlying LLM call already returns real usage data from the provider (prompt_tokens / completion_tokens / total_tokens, following the OpenAI-compatible format that most providers including DeepSeek, Claude, and GPT already return), it seems like this data should already exist somewhere in the Agent runtime — it's just not being surfaced to the node's output.
2. Additional context or comments
Feature request: please add a structured usage output variable to the new Agent node (both as a standalone app and as a workflow node), containing at minimum:
input_tokens (or prompt_tokens)
output_tokens (or completion_tokens)
total_tokens
If possible, it would also be valuable to include:
Per-tool-call token/credit breakdown, since a single Agent run can invoke multiple tools internally, and we currently have no way to know how many times each tool was called from the node output alone.
A separate reasoning_tokens (or thinking_tokens) field for models that support extended thinking/reasoning mode, since this is currently mixed into the general output token count with no way to distinguish it.
This would let workflow builders reliably calculate cost/credits downstream without having to rely on the LLM self-reporting an estimated token count in its own reply, which is both inaccurate and format-unstable.
Thanks for considering this — happy to provide more details on our use case if helpful.
3. Can you help us with this feature?