What are you using for agent cost monitoring today?

[Joy-0403]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Some agent runs end up costing $10+ and I’m trying to figure out where the money actually goes. Is there a good way to break cost down by workflow, see how much retries are costing, or catch an agent that’s stuck in a slow loop? Would also be great to set a budget per run — alert when it’s close to the limit, or automatically fall back to a cheaper model.

2. Additional context or comments

No response

[dosubot[bot]]

Hi @Joy-0403! I'm Dosu and I'm helping the Dify team.

Dify gives you partial cost visibility. I found nothing for a per-run budget, a budget alert or a cost-based fallback to a cheaper model.

Token usage and price are tracked per LLM call. Classic agent runners sum usage across iteration rounds, and workflow agent nodes persist it on the node execution record [1]. The App Overview page has token and cost charts for chat, completion and workflow apps. It plots token count, with an approximate dollar amount in the tooltip when the API provides it [2]. That is daily, per-app granularity, not per-run.

For per-run or per-node detail, Dify's ops-trace pipeline can send traces to Langfuse, LangSmith, Phoenix and others [3]. In Langfuse, each LLM node in a workflow becomes its own generation with token and cost fields [1]. That is the closest answer to "where did the $10 go". Retry and loop cost would show up as additional generations or spans in the trace.

The numbers have some gaps:

• Pure workflow runs persist only total_tokens. total_price and currency are stored only for chat and agent message rows, not for workflow runs [4]. Dollar figures per workflow run therefore come from node-level data or an external tracer.
• Some older paths drop usage or report zero. Examples are the new agent backend before PR fix(agent): preserve complete model usage pricing #39201 and Langfuse message traces on v1.14.0 and later, fixed by PR fix(trace): add explicit ids to Langfuse generation #37833 [4] [5]. Make sure you are on a recent version before trusting the numbers.
• A user reported that the new sandboxed Agent node doesn't expose usage as an output variable [6]. A maintainer replied that usage shows on message hover.

For runaway agents, there are global guards on workflow executions: WORKFLOW_MAX_EXECUTION_STEPS (default 500) and WORKFLOW_MAX_EXECUTION_TIME (default 3600 s) [7]. These are server-wide limits, not budgets. For a slow loop, the practical backstop is lowering them on self-hosted setups or setting a max-iterations value on the agent.

For a budget cap today, the usual workaround is to export traces to Langfuse and alert on cost there. You can also build it inside a workflow: use a conditional branch on accumulated tokens, with an iteration or loop limit, to route to a cheaper model.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[domondi1]

@Joy-0403 one option from outside Dify, with an honest limit up front. I maintain Inferrail (open source), a local gateway that sits between an app and the model provider, so weigh this accordingly.

Point Dify's "OpenAI-API-compatible" model provider at the gateway (endpoint_url: http://<gateway-host>:8000/v1, any API key; the real key stays in the gateway). Then:

• Where the money goes: every model call gets a receipt with model, input/output and cached tokens, cost, latency and retry count, so retries show up as their own calls instead of being folded in. inferrail report --by model totals it; the receipts are payload-free (no prompts or outputs stored).
• A hard stop: inferrail serve --quickstart --app-mode --daily-budget-usd 25 refuses calls with HTTP 402 before they reach the provider once the day's total is reached, so a stuck loop can't run all night.

The limit: a budget per run needs each request to carry a run id. The gateway does that with a header (X-Inferrail-Attribute-Work-Id plus X-Inferrail-Budget-Usd), and as far as I can see Dify's OpenAI-compatible provider has no custom-headers field, only user_identity_support, which sends the end user's id in the request body. So from outside Dify you get a per-call ledger and a daily cap, not a per-run cap or per-workflow breakdown. If the provider plugin grew a headers field that could take the workflow run id, per-run budgets would work without anything else changing.

I haven't run this against a Dify instance myself. The gateway side (receipts, daily cap, refusal before the provider) is what I've tested with other OpenAI-compatible clients.

[Joy-0403]

Thanks for the detailed breakdown! One thing I'm wondering about is the custom headers approach. Even if Dify added support for custom headers, wouldn't those usually be configured at the provider level? The workflow run ID changes with each execution, so you'd still need a way to pass it dynamically into every model call, including retries and parallel branches. Seems like adding a headers field alone might not fully solve the per-run budget issue.

[euisuh]

@Joy-0403 Exactly—that’s why I wouldn’t treat a provider-level headers field as sufficient. The run ID needs to be attached at the workflow/model boundary and carried through retries and parallel branches. A static provider header identifies provider config, not a specific execution.

With request-scoped propagation, the gateway can reserve against one budget keyed by the root workflow_run_id. I’d use a hard per-run cap as the backstop, alert at around 80%, and keep cheaper-model fallback opt-in. Reserve estimated cost before each call with an atomic shared ledger; at the cap, stop new calls and let in-flight calls finish.

Without that propagation, a gateway can provide per-call or daily accounting, but not a true per-run cap.