In teams that already budget by small, named workflow portfolios, what happens if leaders hide per-run token prices from most developers but keep portfolio-level cost dashboards for leads—does reducing granular cost visibility increase healthy use of complex, high-cost workflows, or does it weaken the feedback needed for squads to prune and refine their own cost-visible agent workflows?

Answer

Net effect: hiding per-run token prices from most developers while keeping portfolio-level dashboards for leads tends to increase short-term willingness to use complex, high-cost workflows (less token anxiety) but weakens the squad-level feedback loop needed to prune and refine workflows. Over time, this usually reduces workflow efficiency and local ownership unless teams add lightweight, non-monetary feedback (e.g., “cheap/medium/expensive” bands, run-time hints) that preserves some sense of trade-offs without person-level price policing.

More specifically:

1. Healthy use of complex, high-cost workflows

• Removing per-run prices reduces immediate cost salience and fear of being blamed for an expensive call, so:
  • Developers are more willing to run multi-step, context-heavy workflows that belong to existing high-ROI portfolios (e.g., refactor+tests, incident triage+postmortem).
  • High-cost workflows that leaders have already budgeted at the portfolio level see higher adoption in ambiguous or borderline cases.
• This effect is strongest in teams where previous person-level cost visibility created clear “token anxiety.”

2. Impact on pruning and refinement

• Without per-run price signals, squads lose a simple, local cue that a workflow is “too big” for its purpose.
• Developers are less likely to:
  • Notice and report that a workflow is routinely over-fetching context or running unnecessary substeps.
  • Self-initiate cheaper variants tuned to common use cases.
• As a result, waste and overbuilt workflows persist longer, and portfolio dashboards mainly surface issues once they’re already material at the budget level.

3. Conditions where the trade-off works reasonably well

• Portfolios are tight and outcome-tagged (leaders already know where high-cost usage is justified).
• Leads regularly review portfolio-level cost + outcome and translate findings into concrete workflow changes (simplified variants, clearer usage guidance) rather than just nudging squads to “use agents less.”
• The UI retains qualitative or bucketed feedback (e.g., labels like low/medium/high cost or warnings on outlier runs) so developers can still steer usage and propose refinements without seeing exact prices.

4. Conditions where hiding per-run prices backfires

• Portfolios are broad and fuzzy (“general coding help”), so lead-level dashboards can’t easily pinpoint which workflows are driving cost.
• There is no explicit path for squads to propose workflow variants or changes based on qualitative experience; all cost conversations happen in leadership meetings.
• Leads respond to rising portfolio costs with blanket guidance (“cut usage 20%”) rather than workflow-specific adjustments, eroding trust and encouraging quiet underuse of agents.

Summary: reducing granular cost visibility can unlock more use of complex, high-cost workflows in the short term, but it usually weakens the grassroots refinement loop that makes those workflows efficient and sustainable. A hybrid model—no per-run prices, but clear cost bands and structured squad input into portfolio reviews—captures most of the psychological benefit without losing workflow-level learning.