Free tool / Task-level AI cost evidence

Your AI bill is not your cost per successful task.

A $20 model bill does not tell you which task consumed $3 in failed attempts, or which rows have no project owner. Make a modest, checkable snapshot from a sanitized CSV.

Browser-onlyNo loginNo model API calls
Try it now

AI Cost & Outcome Snapshot

Paste authorized, pseudonymous CSV only. Do not paste prompts, customer names, emails, tokens, or invoice details. Inputs stay in this browser tab; no server calls or persistent storage. The JSON download includes your project labels, so use pseudonyms and review it before sharing. Use the fictional sample first. For preparation and interpretation, read our step-by-step task-cost allocation guide.

No CSV yet? Start with one attempt.

Enter one task attempt and add more as needed. You do not need to open a spreadsheet first. Use short pseudonyms, not client names or private information. Enter only an observed per-attempt cost from your own authorized records; this form cannot calculate your provider's bill for you.

To record a retry, reuse the same task pseudonym with a new observed cost and status. For CSVs with other columns or formats, edit them separately instead of using Quick Add. Data stays in this tab.

Guide / First principles

Why a provider cost export is not an operational outcome report

Start with your provider’s billing source. OpenAI's monthly usage and cost export instructions explain how to obtain activity or detailed cost CSVs, including invoice-like groupings. The Claude Console cost and usage guide describes usage and cost breakdowns by model, workspace and API key. Those are legitimate ways to answer what your provider charged.

But provider cost records usually do not, on their own, prove whether a real task was completed for a customer. That mapping requires your own task or job identifier, a meaningful outcome state, and a trustworthy reconciliation between usage and business records. The downloadable CSV formats are provider-specific: this tiny tool does not import raw OpenAI or Claude billing exports directly. You must first create a safe task-level ledger that joins the billing evidence to your own authorized work identifiers.

Example: the cheaper-looking workflow that failed twice

In this completely fictional sample, one catalog job costs $0.18 on a failed attempt and then $0.25 on its successful retry. That job’s observed cost is $0.43, not $0.25. Another $0.41 catalog job has only a failed record. A third remains pending and costs $0.16. The ledger also includes an $0.08 row without a project label.

project,task_id,cost_usd,result_status catalog,job-1,0.18,failed catalog,job-1,0.25,success catalog,job-2,0.41,failed catalog,job-3,0.16,pending ,job-4,0.08,success support,job-5,0.22,success support,job-6,0.19,success

Run this with Load fictional sample. The result is $1.49 of supplied costs, $0.59 in failed-attempt rows, $0.16 in pending rows, and $0.08 without a project. Across four task IDs marked as reported successful, the observed total for those tasks is $0.92, or $0.23 each. That is a descriptive ledger calculation, not evidence that four customers were served or that the failed-attempt spend was avoidable. The job with both failed and success rows has an unknown final state: this simple ledger does not contain attempt timestamps, so the existence of a success row cannot prove the last attempt or eventual business outcome. The tool counts task IDs with a success row as an observation and separately flags mixed-success/failure IDs for investigation.

The actionable question: Does the $0.41 job really need another attempt, should it be routed to a cheaper verified method, or is the job no longer worth running? First verify the business result and retry history. Do not remove a safety or human-review step just because its cost is visible.

Build a trustworthy input ledger

  1. Choose one UTC-aligned billing window and the right organization, project, currency and credits. Compare totals to provider records before asserting invoice parity.
  2. Assign a non-sensitive task_id to each real task. Use the same task ID for genuine attempts; avoid using an email or customer name as an ID.
  3. Add a pseudonymous project, a nonnegative decimal cost_usd up to four decimal places, and an observed result_status.
  4. Keep failed, pending and unrecognized states visible. Do not infer missing tasks from absent rows; a separate expected-work inventory is needed for coverage checks.
  5. Compare the snapshot with the provider ledger and, separately, with real task acceptance. Review exported project labels before sharing; a grouped report is not necessarily anonymous.

Know what the tool cannot do

  • It cannot access your API account, invoices, repository or project systems.
  • It cannot independently verify a success label or calculate revenue, gross margin or ROI.
  • Its “observed cost per task ID with a success row” includes all listed attempts for those IDs. This is not verified task completion. When failure and success appear together, the final state is unknown without trusted timestamps or business evidence. Open or unknown observations make a task unresolved.
  • It does not infer retries from repeated IDs, only highlights them for investigation.
  • It does not include hosting, salaries, human review, platform subscriptions, taxes or unrecorded provider charges.
  • Empty or malformed data fails closed; a clean-looking report never proves completeness.

Compare alternatives before adding another dashboard

Provider billing + spreadsheet: Often the right answer if you have clean exports, stable task IDs and someone who can make a pivot table. Excel PivotTables can already summarize the same ledger with flexible groupings. Use the free native approach if it is enough.

Observability platform: Langfuse already supports detailed generation-level token and cost tracking, including ingested and inferred costs. If your team has instrumentation and ongoing needs, a tracing platform may outperform a manually pasted CSV snapshot.

This free snapshot: A low-setup, read-only investigation aid when you have a small authorized ledger and want to see failed-attempt spend, task-level reported outcomes and unattributed rows before deciding whether to invest in an integration. The test for real usefulness is simple: can a person do the same analysis faster or more accurately than with their provider export and spreadsheet?

What might justify a paid service?

Not a prettier chart. The possible paid work is controlled data extraction, matching model usage to existing job IDs, validating business receipts with the actual system owner, handling timing and retries, and recurring exception reports under an agreed scope. Those outcomes require explicit access, security review and a real buyer. Moruneva has not yet established demand or measured a cost saving from this experiment.

Related reliability question: when a workflow says success but the CRM record does not exist, use the Workflow Outcome Reconciler instead. That tool compares expected source events, executions and downstream receipts; it does not estimate your AI bill.

Primary sources and research notes

Source review: 25 October 2026. Source capabilities and interfaces may change; check current documentation before exporting confidential data.