Start with two different questions
Billing question: how many dollars did the provider charge over this billing period? The right source is the provider's own usage and cost export, not a pricing table or a hand-written approximation. Operations question: how much of that observed cost was associated with a particular job, including its failed or retried attempts? That requires a stable identifier belonging to your own workflow.
Do not invent a “cost per successful task” by dividing the entire monthly bill by the number of delivered outputs. That blends tests, retries, unrelated projects, credits and uncompleted work unless your data collection really accounts for each. The safer first step is to map what you can observe and label the unknown portion.
Build the smallest possible evidence chain
- Choose one time window and timezone. Compare the same organization, project and UTC period used by the billing export. Record that selection in your working notes.
- Keep an internal task ID. Assign each accepted job a pseudonymous task_id before the first model call. Preserve that ID across attempts so retries are grouped correctly. Never use a customer's email address as the ID.
- Record each billed attempt. Your own authorized ledger joins task_id and project to the per-attempt USD cost. Costs should be reconciled back to the provider’s authoritative report; a provider export does not automatically contain your business task IDs.
- Record the reported state. Did the attempt succeed, fail, remain pending or become unknown? Do not collapse a later failure and an earlier success into a definitive “final success” without timestamps or verified attempt ordering.
- Separately confirm the actual outcome. A successful model response does not prove the correct asset, CRM record, notification or booking was delivered. Verify downstream receipts only in a system you are authorized to access.
A fictional retry changes the apparent cost
Imagine two video-caption jobs. One succeeds after a failed generation. Another is still waiting. This example is invented to demonstrate the accounting method, not a vendor performance benchmark.
project,task_id,cost_usd,result_status captions,job-a,0.18,failed captions,job-a,0.25,success captions,job-b,0.16,pending
The visible costs total $0.59. The first job has $0.43 across two recorded attempts, not just the $0.25 successful row. The other $0.16 has no completed state. You can compute these facts from the supplied entries without pretending the first caption was accepted by an editor or delivered to a client.
Use Moruneva's browser-local AI Cost & Outcome Snapshot to paste this four-column ledger, analyze grouped totals, and export the summary. The checker does not connect to provider accounts, infer usage from prompts, assign prices to models, or verify final customer outcomes. The downloaded JSON includes the project labels you entered; use pseudonyms before sharing.
No CSV yet? Use the checker’s new guided entry fields to add one pseudonymous attempt at a time, without opening a spreadsheet. You can also download a blank CSV template. Both still require your own observed per-attempt costs: the tool cannot retrieve or infer a provider bill.
Three mistakes worth checking before trusting the result
1. A “success” label is not a customer outcome
It may mean an HTTP call completed, the model returned text, or the workflow reached its final step. Each has a different evidence standard. For important work, ask what independent destination record or human acceptance confirms the result.
2. Ambiguous retries create ambiguous denominators
If the same task ID has both success and failed rows but no reliable attempt order, the final state is unknown. You can report that a success row exists and show all observed costs, but must not promise one final completed task. Similarly, reused task IDs across unrelated jobs distort task counts. Include a version or separate ID when necessary.
3. Some spend cannot yet be assigned
Blank project or task identifiers, different invoice periods, credits, hosting, labor and third-party fees all affect interpretation. Display unattributed spend instead of distributing it across known tasks without justification. A tiny sample might be useful for diagnosis without being a complete profit-and-loss statement.
When a spreadsheet or observability product is better
Excel or a spreadsheet may already be sufficient if your bill is small and you can safely join a few task IDs. A pivot table gives stronger control over custom grouping, but requires more setup and review. Langfuse may be more suitable for a team already collecting generation traces and usage metadata: its official documentation covers model usage and cost attribution. Provider dashboards remain the source of truth for charges. Moruneva's local checker is for a quick, inspectable, no-account snapshot from a deliberately narrow ledger—not an analytics platform replacement.
What should you do next?
If you lack a task ID, instrument one future fictional or safe sandbox workflow before reconstructing old invoices. If your ledger is already clean, compare one manually reviewed small sample in the spreadsheet and Moruneva tool. If the results disagree, investigate the source data and assumptions before acting. If you can already do all of this faster in your existing platform, stay there.
Open the free task-cost checker →
Primary sources and further reading
- OpenAI Help: export monthly API usage and costs — official billing and usage export reference.
- Claude Help: API cost and usage reporting — official provider breakdown reference.
- Langfuse: token and cost tracking — an existing monitoring alternative.
Source and method review: October 26, 2026. This guide contains original fictional calculations; it is not based on customer deployments or verified invoices.