For engineering and platform leaders

Defend the budget with numbers instead of adjectives.

Cost per workflow, per agent and per run, with retries broken out. Enough evidence to justify what you spend, and early enough warning to stop what you should not.

What does an engineering leader get from AI cost tooling built for finance?

Cover and evidence. When AI spend is unexplained, the pressure eventually arrives as a cap. Camaze gives you cost per workflow, per agent and per run, with retry cost isolated, so you can show what a system costs and what it produces. It also catches runaway jobs within a day instead of at month end, which is the difference between a four day overrun and a twenty six day one.

The problem

You get asked why AI costs so much, and you have no way to answer.

The provider console shows spend by API key. Your systems do not map to API keys.

More detail

It cannot tell you what one agent run costs, what share of a workflow's spend is retries that produced nothing, or whether the increase last month was your new feature or somebody's eval suite running nightly.

So the answer is qualitative, and qualitative answers lose budget arguments. Eventually a cap appears, applied uniformly, and it lands hardest on the systems that were actually working.

  • Spend visible by API key, not by service, workflow or agent
  • No cost per run, so no unit economics for anything you build
  • Retries and loops invisible because they do not produce errors
  • Non-production usage mixed in with production
  • Self-hosted inference buried in a shared infrastructure account
Agent and workflow economics Last 30 days
WorkflowRuns Calls per runCost per run Spent on retries
Ticket resolution agent 18,400 3.2 $0.41 34%
Contract review workflow 2,100 11.8 $2.90 71%
Lead enrichment agent 44,900 1.4 $0.06 12%
Code review agent 6,300 6.1 $0.88 48%
Weekly report generator 310 22.4 $4.15 9%

Illustrative product view. Figures are examples.

What we do about it

Cost, at the level you actually build at.

Workflows, services and agents rather than keys and invoices. Read-only and out of band, so nothing enters the request path and nothing new can fail in production.

  • Cost per workflow, per agent and per run
  • Retry share of run cost, isolated and trended
  • Production separated from evals, testing and prototypes
  • Self-hosted inference costed per million tokens served, comparable to hosted APIs
  • No proxy, no SDK, no added latency, no new dependency
Unit economics

What a run costs, and what it should cost.

An agent that averages twelve model calls per run against a design target of four is a defect, not a cost problem, but it is only visible as a cost.

More detail

Camaze reports calls per run, cost per run and retry share, so drift is caught as a measurable regression rather than as a surprise on the invoice.

Set a target cost per run and it is tracked like any other service level objective, with an alert when it is breached.

  • Cost and calls per run, tracked against a target
  • Retry share of run cost, alerted at a threshold you set
  • Runs that never terminate, surfaced explicitly
  • Cost regression on deploy, so a change that doubles unit cost is visible immediately
Agent and workflow economics Last 30 days
WorkflowRuns Calls per runCost per run Spent on retries
Ticket resolution agent 18,400 3.2 $0.41 34%
Contract review workflow 2,100 11.8 $2.90 71%
Lead enrichment agent 44,900 1.4 $0.06 12%
Code review agent 6,300 6.1 $0.88 48%
Weekly report generator 310 22.4 $4.15 9%

Illustrative product view. Figures are examples.

Model choice

Evidence for the routing decision.

The argument for using a cheaper model on part of a pipeline is usually correct and usually unfunded, because nobody can quantify what the change is worth against the engineering time it takes.

More detail

Camaze attaches a dollar figure. A routing step billed at frontier rates, a retrieval stage sending context nothing reads, caching available on a static prefix: each is quantified so the work can be prioritized against everything else in the backlog on the same basis.

  • Candidate workloads for a smaller model, with the saving quantified
  • Context and prompt overhead measured against output quality
  • Caching and batch eligibility identified per workflow
  • New models scored against your workloads as they are released
Optimization opportunities Updated weekly
  • New model2 days ago

    A cheaper model now covers your largest workload

    Ticket triage runs 41M tokens a month on a frontier model. A newly released mid-tier model matches it on your own eval set.

    $21,300a month
  • Price change1 week ago

    Input pricing dropped on a model you already run

    No change needed. The saving lands automatically. The forecast has been updated and plan variance is now favorable.

    $4,900a month
  • New capability2 weeks ago

    Prompt caching is now available on the document workflow

    78% of that workflow's input tokens are an unchanged system prompt. Caching them is a configuration change, not a rewrite.

    $8,700a month
  • Discount tier3 weeks ago

    Volume now qualifies for committed-use pricing

    Twelve months of usage supports a commitment at the next tier. Draft terms and a break-even are attached.

    $14,200a month

Illustrative product view. Figures are examples.

Early warning

Find the runaway job on Friday, not on the invoice.

The expensive incidents are the quiet ones. A retry loop that eventually succeeds produces no errors, no alerts and no user complaints.

More detail

It produces a bill, three weeks later.

Per-workload baselines catch this within a day. The alert goes to your channel with the workload named and the projected month-end effect, before it becomes a finance conversation.

  • Per-workload anomaly detection, active from day one
  • Alerts routed to engineering channels, not only to finance
  • Spikes caught even when the company total stays within budget
  • Webhook delivery, so it can join your existing on-call routing
Platform team budget Alert sent day 5
Budget burn-up for the month, crossing the limit before month end Actual spend runs above the even-pace line all month and the projection crosses the ninety thousand dollar budget on day 28, ending the month at about one hundred and four thousand dollars. 0 $30k $60k $90k Budget $90k Even pace Over on day 28 Day 1Day 8Day 15Day 22Day 31
Actual spend Projection Even pace

Illustrative product view. Figures are examples.

Self-hosted

Whether running it yourself is actually cheaper.

Self-hosting is frequently justified on unit cost and then quietly undermined by utilization.

More detail

A dedicated endpoint provisioned for peak and running at eleven percent is not cheaper than an API, but nothing in the cloud bill says so.

Camaze attributes GPU compute to the endpoints and models it serves and expresses it as cost per million tokens served, directly comparable to a hosted provider, with idle capacity reported separately.

Cost by project and model July
ProjectModel ShareCostChange
Support automation Claude Sonnet $34,800 +22%
Search and ranking GPT-4o mini $21,400 -6%
Sales copilot GPT-4o $18,900 +31%
Docs assistant Llama 3.1 70B, self-hosted $15,200 +9%
Data enrichment Gemini 1.5 Flash $11,600 -14%
Internal agents Mixed $9,800 +64%
Engineering seats Cursor, Copilot $8,300 0%

Illustrative product view. Figures are examples.

Get the numbers before the budget conversation.

30 minutes, read-only, nothing in the request path. You will see cost per workflow and per run on your own systems.

In practice

What engineering actually has to do

Deliberately very little.

1

Provide read-only credentials

Billing and usage credentials per provider, plus read access to cloud cost data. About 30 minutes. No code, no deployment, no SDK, nothing in the request path.

2

Confirm the mapping

Someone who knows which keys and projects belong to which services spends an hour confirming the mapping. That is the only step that needs engineering knowledge.

3

Optionally, tag requests

Adding a workflow or customer identifier to requests upgrades attribution from apportioned to measured. It is a small change and it is worth doing, but nothing depends on it.

FAQ

Questions people ask

Does this sit in the request path?

No. Camaze reads billing and usage data out of band. There is no proxy, no gateway and no SDK in your application. Nothing about it can add latency or fail in a way that affects production.

Do you read our prompts and completions?

No. Camaze works from usage and billing metadata: token counts, model, timestamp, key, project. Prompt and completion content is not collected. See the security page.

How do you attribute cost to a workflow if we do not tag requests?

Through the identifiers that already exist: keys, projects, workspaces, deployments and cloud tags. That is enough for workflow-level attribution in most setups. Where it is not, spend is apportioned and clearly labeled as apportioned. Adding a workflow identifier to requests upgrades it to measured, and it is a small change.

Will finance use this to micromanage engineering?

That depends on how it is introduced, and the honest answer is that visibility works in both directions. In practice engineering teams tend to benefit, because the alternative to evidence is an arbitrary cap. A team that can show cost per run and what that run produces is in a considerably stronger position than one that cannot.

Can alerts go to our channels rather than to finance?

Yes. Routing is per rule, and webhook delivery means alerts can join whatever on-call routing you already run. Most teams send workload anomalies to engineering and budget thresholds to finance.

Show what your systems cost.

Book 30 minutes. We will show you cost per workflow, per agent and per run on your own spend.

5 minute setup. Read-only. No engineering time needed.