LLM-kostnader behover prisversionerade allokeringsposter, inte bara dollar i statusraden
Lokala dashboards for LLM-kostnader gor dold tokenanvandning synlig, men ett synligt dollarbelopp ar inte automatiskt en redovisningsbar kostnadspost. Denna studie analyserar workspace-koden for Claude Usage Cost, jamfor den med en angransande Codex-dashboard, tidigare AlexandrAI-artefakter och aktuella officiella dokument fran Anthropic, FinOps/FOCUS, W3C och VS Code. Resultatet ar att extensionen redan har flera starka byggblock: message-id-dedupe, separata tokenklasser for input, output, cache write och cache read, en prisversion, override-mekanismer, varningar och synliga dashboardfalt. Men samma bevis visar ocksa en granskning: lokala belopp ar API-ekvivalenta estimat, inte fakturor, och prislistor kan aldras. Bidraget ar en Cost Allocation Event for LLM-anvandning med sex grupper: identity, measurement, price, allocation, provenance och disclosure. Slutsatsen ar att LLM-kostnadsstyrning bor exportera prisversionerade allokeringsposter, medan statusraden bara far vara en ingang till evidensen.
Introduktion
En statusrad som visar en LLM-kostnad ar praktisk. Den ar ocksa farlig om den ser mer exakt ut an den ar. I det granskade projektet Claude Code Usage & Cost laser extensionen lokala Claude Code-transkript, raknar tokenkategorier och visar API-ekvivalent USD-kostnad per modell och period [[cite:repoReadme]]. Det ar en bra synlighetsyta, men finance-accounting-fragan ar hardare: kan beloppet delas upp, forklaras och allokeras till ansvariga dimensioner utan att overdriva vad lokala loggar bevisar?
En tidigare AlexandrAI-artikel har redan visat att lokala transcript dashboards behover dedupe-ansvarighet snarare an raka tokensummor [[cite:graphDedupPaper]]. En annan kunskapsbas beskriver samma extensions funktioner och gransningar [[cite:graphKnowledgeBase]]. Denna artikel forsoker darfor inte gora dedupe till en ny upptackt. Den behandlar dedupe som en nodvandig identitetskolumn i en vidare redovisningspost.
Forskningsfragan ar: vilka falt maste ett lokalt LLM-kostnadsverktyg bevara for att kunna bli en prisversionerad kostnadsallokeringspost snarare an bara en dollarindikator? Svaret ar en Cost Allocation Event. Den ska lagra identitet, matning, pris, allokering, provenance och disclosure. Poangen ar inte att ersatta leverantorens faktura, utan att gora intern styrning, forklaring och granskningsbar fordelning mojlig.
Metod
Studien ar en workspace-baserad fallstudie med redovisningssyntes. Lokala filer granskades som repo-relativa kallor, inte som privata maskinbanor. Centrala implementationer var `src/parser.ts`, `src/pricing.ts`, `src/types.ts`, `src/extension.ts`, `media/dashboard.js`, `src/selftest.ts` och `package.json` [[cite:parserTs,pricingTs,typesTs,extensionTs,dashboardJs,selftestTs,packageJson]].
Tva lokala verifieringar kordes: `npm run check-types` och `npm run compile`. Bada lyckades den 29 juni 2026 [[cite:typeCheckRun,compileRun]]. Dessa verifierar TypeScript- och bundle-konsistens, inte att alla mojliga transcript-scheman ar tackta och inte att leverantorens faktura matchar det lokala estimatet.
Extern evidens avgransades till primarkallor eller standards: Anthropic for kostnader, pricing och prompt caching; FinOps och FOCUS for allokering och normaliserade cost-and-usage records; W3C PROV for provenance; samt VS Code-dokumentation for statusbar/webview-gransen [[cite:anthropicCosts,anthropicPricing,anthropicCaching,finopsAllocation,focusSpec,w3cProv,vscodeStatus,vscodeWebview]]. Figur 1 sammanfattar var evidensen ar starkast och svagast.
Lokal evidens
Parsern ar starkast pa identitet och matning. `UsageStore` skannar `.jsonl`-filer, laser i chunkar, sparar ofullstandiga rader, filtrerar pa usage-linjer och aggregerar bucketar per modell och timme [[cite:parserTs]]. Nar dedupe ar pa raknas varje `message.id` en gang. Om en senare kopia har storre tokensnapshot tas den mindre contributionen bort och den storre anvands [[cite:parserTs]].
Typerna visar varfor en allokeringspost inte far ha ett enda tokenfalt. `TokenCounts` delar upp input, output, cacheWrite5m, cacheWrite1h och cacheRead; `CostBreakdown` delar upp input, output, cacheWrite, cacheRead och total [[cite:typesTs]]. Pricing-koden beraknar kostnad per kategori och anvander en explicit `PRICING_AS_OF` samt overrides [[cite:pricingTs]]. Tabell 2 oversatter detta till redovisningsfalt.
Dashboarden gor flera denominators synliga: total cost, total tokens, billable messages, duplicates removed, token/cost split, daglig serie, per-modell-tabell, cap-gauge, sessioner och varningar [[cite:dashboardJs]]. Det betyder att extensionen redan producerar mycket av en allokeringspost. Det som saknas ar inte en till graf, utan en export- eller ledger-konvention som bevarar dessa falt som redovisningsbara event.
Extern kalibrering
Anthropic-dokumentationen ar viktig av tva skal. For det forsta beskriver Claude Code-dokumentationen kostnadsytor och skiljer lokal kostnadssynlighet fran leverantorens bredare billing-kontekst [[cite:anthropicCosts]]. For det andra visar pricing- och prompt-caching-dokumentationen att tokenklasser har olika prissattning, sa cache write och cache read maste vara redovisningsfalt, inte bara etiketter [[cite:anthropicPricing,anthropicCaching]].
FinOps allocation handlar om att fordelade kostnader maste kunna kopplas till ansvariga dimensioner och anvandbara rapporter [[cite:finopsAllocation]]. FOCUS ger en normaliseringslogik for cost-and-usage records [[cite:focusSpec]]. Dessa kallor ar inte LLM-specifika, men de ger en rimlig regel: om en LLM-kostnad ska styras internt maste posten vara mer an modell och total USD.
W3C PROV hjalper till att beskriva varfor ett event behover lineage. En transcript-rad ar en entity, parserkorningen ar en activity, pricing-resolvern ar en activity, och den lokala extensionen eller anvandaren ar en agent i provenance-termer [[cite:w3cProv]]. Figur 3 visar vilka falt som bar vilken claim.
Cost Allocation Event
Den foreslagna Cost Allocation Event ar inte ett nytt fakturaformat. Den ar ett internt kontrollrecord som binder lokalt observerad LLM-anvandning till en ansvarsdimension och en prisversion. Tabell 4 visar minsta schema. Falten kommer fran lokalkoden, men gruppningen kommer fran redovisningsfragan och FinOps/PROV-ramarna [[cite:typesTs,parserTs,pricingTs,finopsAllocation,focusSpec,w3cProv]].
Det granskade systemet har manga av falten redan, men inte alla som forstaklassig export. `DashboardData` har rawTokens, duplicatesRemoved, rows, totals, capGauge, sessions och warnings [[cite:typesTs]]. Parsern vet dedupe och tokenklasser [[cite:parserTs]]. Pricing vet price key, static date, overrides och estimated/unpriced tillstand [[cite:pricingTs]]. Det nya ar att samla dessa i ett event som inte tappar denominatorn nar totalen visas.
Diskussion
Skillnaden mellan dashboard och redovisningspost ar friktion. Dashboarden kan sammanfatta; posten maste forklaras. VS Code-statusraden ar medvetet kompakt och bor inte bara full accounting payload [[cite:vscodeStatus]]. Webviewen ar en battre drill-down-yta, och den granskade extensionen anvander den for split, tabeller, cap, sessioner och varningar [[cite:extensionTs,dashboardJs,vscodeWebview]].
Den angransande Codex-dashboarden visar att ett allmant 'LLM cost' schema inte kan anta samma tokenklasser overallt. Codex-projektet talar om input, cached input, output och reasoning output, medan Claude-projektet talar om input, output, cache write och cache read [[cite:codexReadme,repoReadme]]. Backport-noterna ar intressanta eftersom de foreslar projektaggregation och mer forklarande statusbar-tooltip, men de sager ocksa att Claude-kategorierna maste bevaras som Claude-kategorier [[cite:codexBackport]].
Det praktiska radet ar att exportera bade headline och denominator. En intern rapport far garna visa total API-ekvivalent kostnad, men posten bakom totalen bor innehalla message identity, raw-vs-deduped relation, tokenklass, modell, prisversion, override/estimate flagga, ansvarsdimension och disclaimer. Om ett falt saknas ska claimen bli svagare: lokal trend i stallet for fakturerbar kostnad , API-ekvivalent estimat i stallet for betalbar invoice line .
Begransningar
Studien ar kallbackad men inte en production billing audit. Den korde inte en VS Code-session, publicerade inga privata transcript-utdrag och jamforde inte lokala belopp mot en verklig Anthropic-faktura. `npm run check-types` och `npm run compile` lyckades, men dessa verifieringar sager inget om alla framtida loggscheman [[cite:typeCheckRun,compileRun]].
Prisdata ar tidskansliga. Den lokala koden har `PRICING_AS_OF`, medan Anthropic-dokumentation ar den aktuella leverantorskallan [[cite:pricingTs,anthropicPricing]]. Darfor ar prisversionering en slutsats, inte en formalitet. En allokeringspost utan price_as_of och price_source blir snabbt svar att granska.
Allokeringsdimensionerna ar ocksa delvis framtida arbete. Extensionen har modell-, period- och dashboardfalt; backport-noterna pekar pa projektaggregation som relevant nasta steg [[cite:codexBackport]]. For att bli en stark intern kostnadsledger behover implementationen lagga till eller exportera projekt/team/cost-center-dimensioner utan att publicera privata lokala paths eller transcriptinnehall.
Slutsats
LLM-kostnader behover prisversionerade allokeringsposter, inte bara dollar i statusraden. Den granskade Claude Usage Cost-extensionen har en bra grund: dedupe, tokenklasser, prisresolver, override, varningar, dashboard och disclosure. Men redovisningsnyttan uppstar forst nar dessa falt binds till en Cost Allocation Event med identity, measurement, price, allocation, provenance och disclosure.
Det viktigaste designkravet ar proportionalitet. Lokal transcript-evidens kan ge API-ekvivalent synlighet och intern fordelning. Den kan inte ensam bevisa leverantorens faktura. Om verktyget exporterar eventet med tydlig prisversion och disclaimer kan organisationer fa battre LLM-kostnadsstyrning utan att forvandla en lokal dashboard till en falsk fakturakalla.