Per-Customer AI Cost Attribution: See AI Cost By Customer, Plan, And Workflow

Use a non-guessable account, tenant, workspace, or customer ID. Do not use raw emails, domains, phone numbers, or personal names as customer identifiers. Emails change, people leave companies, and personal data creates avoidable privacy risk.

Opaque IDs also make joins cleaner. Finance can map customer_id to plan and revenue in a controlled system, while runtime telemetry stays focused on cost-shaped operational data.

Workflow and step names should describe product capabilities, not user input. Good examples include onboarding_qna, support_triage, document_review, retrieve_context, summarize, rerank_results, and draft_reply.

Avoid turning step_name into a free-form log line. A controlled vocabulary keeps dashboards readable and makes it possible to compare costs across customers, plans, and releases.

Pick the durable customer_id that already represents the commercial account in your product. For multi-tenant apps, this is often an account ID, workspace ID, organization ID, or tenant ID.

Pass that ID through background agents as well as interactive user flows. Background usage is easy to miss because it may not be tied to a visible chat message, but it still affects margin.

Cost attribution metadata should not include prompts, completions, raw user messages, emails, phone numbers, tool arguments, or customer names. Those fields are not needed to calculate cost by account and they increase privacy risk.

Pylva is designed around cost-shaped telemetry: identifiers, labels, provider data, model data, token counts, usage metrics, latency, status, and timestamps. That keeps the ledger useful without turning cost reporting into prompt storage.

Workflows should map to product capabilities that product and finance understand. Step names should map to the technical unit of work engineering can optimize.

For example, a document review workflow might include upload_parse, embed_sections, retrieve_context, draft_summary, and final_answer. If final_answer is expensive but retrieve_context is cheap, the optimization path is different from a blanket model downgrade.

Wrap or centralize LLM calls so supported provider usage is captured consistently. The Pylva TypeScript SDK instruments OpenAI, Anthropic, and Vercel AI calls. The Pylva Python SDK instruments OpenAI and Anthropic clients.

Each supported call can produce cost-shaped telemetry such as model, provider, token counts, latency, status, customer ID, and step name. This is the request-level evidence needed for token-level logging, cost allocation, and workflow diagnostics.

Per-customer attribution breaks if only model calls are tracked. Use reportUsage() in TypeScript or report_usage() in Python to record vector search, embedding jobs, transcription, image generation, external APIs, and other cost sources.

Use the same customer_id, workflow, step_name, metric, value, timestamp, and status model for non-LLM events. That lets LLM and non-LLM usage roll up into one customer cost view.

Application code should emit usage facts, not hardcoded dollars. The runtime knows tokens, characters, requests, seconds, images, or workflow executions. A server-side pricing or rate-card layer should translate those facts into cost.

This separation matters because model prices, vendor prices, internal markups, and customer pricing can change. If pricing lives centrally, teams can adjust rates without redeploying every agent workflow.

Once data is flowing, review cost by customer_id, plan, workflow, step_name, model, provider, and status. Weekly review is useful while a feature is scaling because monthly invoices arrive too late for runtime surprises.

The review should ask practical questions: which customers are margin-negative, which steps are expensive, which retries are waste, which plans need limits, and which workflows should use a cheaper model or smaller context window?

Customer-level cost data feeds the broader operating loop described on the AI agent cost management software page: margin analysis, budget rules, pricing decisions, customer-facing usage, and billing exports.

Do not jump straight to automated billing from untrusted data. First prove that usage records are stable, customer IDs are correct, pricing is server-side, and edge cases such as retries, failures, cancellations, and background work are visible.

Rank customers by AI cost to serve and compare that cost with plan revenue. Heavy automation can make one customer look like strong adoption while quietly creating negative gross margin.

This is especially important for flat-price or seat-based plans where usage is not directly billed. Attribution shows whether the plan economics still work.

Step-level views reveal cost drivers such as repeated retrieval, excessive context windows, parallel tool fanout, unnecessary high-cost model selection, and retry loops.

Engineering can then optimize the step that matters instead of treating the entire AI feature as expensive.

Plan-level cost views show whether Pro, Scale, Enterprise, or legacy contract tiers are aligned with real usage. If one plan has lower revenue but higher model or tool consumption, the pricing model needs attention.

Attribution data gives budget rules the context they need: customer, workspace, plan, workflow, and step. Depending on product architecture, a rule can alert, downgrade, route, or block supported calls before a customer burns through the intended budget.

Use bounded language with customers. Cost controls reduce risk; they do not guarantee that every overrun is impossible.

The same ledger that explains cost can become the evidence behind usage-based billing, overage lines, customer usage pages, or internal showback reports.

Billing-ready records need stable customer identity, source, metric, value, timestamp, status, pricing version, and auditability. They do not need prompt text.

The first win is direct attribution for the usage streams that are closest to customer activity. A precise LLM and non-LLM ledger creates more decision value than a fragile attempt to allocate every overhead cost immediately.

Usage events should remain durable facts. Price calculation should happen in a controlled pricing layer so teams can handle vendor price changes, customer-specific terms, and billing versions without rewriting runtime history.