Jeden z největších problémů s AI produkty: nikdo neví, kolik toho spotřeboval a kolik mu ještě zbývá. Uživatel vidí „12 450 kreditů” a netuší, jestli to znamená hodinu nebo celý měsíc. Interní čísla jako kredity, tokeny a context window jsou pro lidi španělská vesnice.
Před pár dny jsem předělal billing/limits stránku v CoreSynthu — konkrétně pro Alexe. Cíl byl jednoduchý: přestat ukazovat surová čísla a začít ukazovat to, co uživatelé skutečně potřebují vědět.
Co se změnilo
Progress bary místo čísel
Dřív stránka ukazovala 12 450 / 50 000 kreditů. Teď ukazuje 74% a progress bar, který se mění zelená → oranžová → červená podle toho, jak se blíží limit. Uživatel na první pohled vidí, jestli je v pohodě, nebo by měl zpomalit.
PŘED: 12 450 / 50 000 kreditů
PO: [████████░░] 74% · zbývá 26%Barva se mění dynamicky:
- Zelená — pod 70 %, v pohodě
- Oranžová — 70–90 %, pozor
- Červená — nad 90 %, blíží se strop
Tokeny místo kreditů
Dřív byly ve sloupcích „kredity” a „tokeny” vedle sebe — zmatení dvojí. Teď tam jsou jen tokeny, rozdělené na tři přehledné kategorie:
PŘED: Input | Output | Cache | Kredity
PO: Kontext | Cache | Celkem„Kredity” zmizely z pohledu zákazníka úplně. Jsou interní měrná jednotka, která nikomu venku nic neřekne. Místo toho uživatel vidí:
- Kontext — kolik tokenů spotřeboval na vstupu a výstupu (reálná práce AI)
- Cache — kolik ušetřil díky cacheingu (bonus)
- Celkem — součet
User-cost modal
Nový modal, který uživateli ukáže worst-case odhad nákladů. Místo abych mu řekl „máš 50 000 kreditů”, mu řeknu „v nejhorším případě tě tohle bude stát — ale díky cacheingu to bude pravděpodobně méně.”
MAX (strop) Týden / Měsíc
Cache hit: ~40% tvá reálná cena bude nižšíUživatel tak dopředu ví, do čeho jde. Žádné překvapení na faktuře.
Jedna stránka pro všechno
Dřív byly limity roztahané po vícero routech — každá služba měla svou. Teď je jedna kanonická stránka /account/alex/limits, která zobrazí všechno přehledně na jednom místě. Pokud má uživatel víc objednávek, přepne si je přes ?order= parametr.
Technické řešení
Na pozadí to znamenalo pár věcí:
- Jeden zdroj pravdy pro limity — všechny limity (chat i proxy API) teď čerpají z jedné tabulky v DB. Dřív byly roztahané v konfiguracích, hardcoded fallbackách a spreadsheotech.
- Baseline model sjednocen — jeden konfigurační bod pro základní model, místo hardcoded hodnot ve dvou různých prostředích.
- Pooled billing — stránka umí pracovat s tím, že za AI platí jeden uživatel, ale využívá ji víc lidí. Zobrazí breakdown podle jednotlivých uživatelů.
- Progress bar helper —
_usedPercentspočítá procenta, frontend pak jen renderuje barvu a šířku.
BEFORE AFTER
───────────────────────────── ─────────────────────────────
50 route paths 1 canonical page
Hardcoded limits in 3 places DB table (single source)
Raw credit counts Percentage progress bars
4 token columns 3 (Context|Cache|Total)
No cost projection User-cost modal (worst-case)Proč tohle řeším
Billing v AI produktech je stále v plenkách. Většina SaaS nástrojů to řeší tak, že ukáže číslo a hotovo. Ale u AI je to složitější — spotřeba závisí na modelu, context window, cacheingu a tom, jak moc se AI „rozepisuje”. Ukázat surová čísla bez kontextu je stejně užitečné jako říct člověku „spotřeboval jsi 12 450 elektřiny” bez jednotky.
Cíl byl: uživatel musí na první pohled vědět, jak na tom je, a v případě potřeby vidět detail. Žádné překvapení, žádné „co je to kredit”, žádné překlikávání mezi třemi stránkami.
Nejlepší billing je ten, o kterém uživatel nemusí přemýšlet — a přitom mu všechno dává smysl.
Proč o tom píšu
Protože tohle je typický případ, kdy 80 % práce je rozhodování a 20 % implementace. Vymyslet „progress bar místo čísel” trvá minutu. Udělat to tak, aby to fungovalo s pooled billingem,cacheováním, vícero modely a jazykovými mutacemi — to už je na delší odpoledne.
A je to taky ukázka toho, jak malé UX rozhodnutí může mít velký dopad na to, jak uživatel vnímá celý produkt. Transparentní billing = důvěra v produkt.