Většina z nás dnes při bastlení používá AI s nějakým placeným předplatným, a to má svoje limity. Často narazíte na hlášku „dosáhli jste limitu“ zrovna ve chvíli, kdy ladíte tu nejzapeklitější chybu. Ty limity se měří v tokenech. V článku o psaní promptů pro Arduino, ESP32 a Raspberry Pi jsme řešili, jak AI zadat úkol. Tady se podíváme na to, kolik vás ten úkol stojí a jak z jednoho předplatného dostat maximum.
Co je vlastně token
Token je nejmenší kousek textu, se kterým jazykový model pracuje. Není to ani písmeno, ani celé slovo – je to něco mezi. Představte si ho jako nejmenší dělitelnou součástku: podobně jako rozdělíte zapojení na rezistory a kondenzátory, AI si rozkládá text na tokeny. Krátké běžné slovo se vejde do jednoho tokenu, delší nebo méně časté se rozpadne na dva i tři.
Kód má svoje specifika. Řádek jako digitalWrite(LED_BUILTIN, HIGH); se rozpadne na překvapivě hodně tokenů – závorky, podtržítka, středník, každý takový znak něco stojí. Komentáře, odsazení i prázdné řádky se počítají taky.
Hrubé pravidlo: jeden token ≈ 4 znaky ≈ 0,75 slova v angličtině. Pro češtinu (a hustě strukturovaný kód) počítejte spíš s tím, že na slovo padne token i víc. Pro představu: kompletní sketch meteostanice na ESP32-C3 o nějakých 200 řádcích vyjde klidně na 2000–3000 tokenů.
Důležité je, že se počítá vstup i výstup. Tedy nejen kód, který AI vygeneruje, ale i celá konverzace, kterou si při každé nové zprávě znovu načítá do kontextu.
Jak se tokeny spotřebovávají
Tohle je místo, kde většina bastlířů podceňuje realitu. Při každé nové zprávě totiž model nečte jen váš poslední dotaz – načítá si celou historii konverzace, aby udržel kontext.
To znamená, že čím je vlákno delší, čím víc kódu a datasheetů jste do něj nasypali a čím hlubší je historie ladění, tím víc každá další zpráva spotřebuje. Když po dvou hodinách dolaďování WiFiManageru s přiloženým 40stránkovým datasheetem napíšete jen „díky, funguje“, není to zadarmo – model si kvůli té jedné větě znovu projede úplně všechno, co bylo předtím.
Spotřebu tokenů ovlivňují čtyři hlavní faktory:
- Délka a typ dotazu – „co dělá tahle funkce“ spotřebuje zlomek toho, co „napiš kompletní firmware pro meteostanici s deep sleepem a odesíláním na TMEP.cz“.
- Velikost kontextu – přiložené sketche, datasheety, knihovny, screenshoty schémat. Všechno se počítá při každém kole.
- Použitý model – silnější model (typicky řada Opus) spotřebovává víc než lehčí varianta (Sonnet, Haiku).
- Nastavení „effort“ – kolik model přemýšlí, než odpoví. Nejvíc podceňovaný parametr, proto mu patří samostatná kapitola.
Závislost na modelu: Opus vs. Sonnet
Lehčí model jako Sonnet je rychlejší a na limit hodně šetrný. Silnější model jako Opus dává hlubší a přesnější výsledky u složitých úloh, ale za každou zprávu se zaplatí víc.
Klíčové je nepoužívat kanón na vrabce. Drtivá většina běžné práce – vygenerovat funkci na čtení SHT40, přepsat komentáře do češtiny, vysvětlit chybové hlášení kompilátoru – nepotřebuje nejsilnější model. Ten patří na věci, kde se vyplatí: návrh architektury většího firmwaru, ladění zapeklité chyby s deep sleepem, nebo finální kontrola kódu před nahráním do desky.
👉 A co úplná špička? Nad řadou Opus už existuje i nejnovější, ještě výkonnější třída modelů – u Claude třeba Fable 5 z takzvané „Mythos“ třídy, která sedí nad Opusem v žebříčku schopností. Jsou výkonnější, ale taky dražší a hůř dostupné. Pro běžné bastlení je nepotřebujete – berte je jako těžkou techniku na výjimečně náročné projekty. Všechno ostatní v tomhle článku pro ně platí stejně.
Nastavení „effort“: podceňované nastavení
Tady je novinka posledního roku, kterou většina lidí nevyužívá. Vedle volby modelu (například AI Claude) se objevil parametr effort – tedy kolik „přemýšlení“ má model do odpovědi vložit, než začne psát.
U Claude jsou dnes typicky úrovně low, medium, high, xhigh a max, přičemž ne každý model podporuje všechny. Princip je u všech platforem stejný: vyšší effort znamená lepší odpovědi, ale pomalejší reakce a rychlejší spotřebu limitu. Nižší effort znamená rychlejší odpovědi, které spotřebují méně z denních limitů.
Důležitý rozdíl, který stojí za zapamatování: effort a „thinking“ nejsou totéž. Effort je o rozsahu – kolik kroků model udělá od otázky k odpovědi. Odpověď s nízkým effortem se drží přesně toho, na co jste se zeptali. Odpověď s vysokým effortem zkoumá okolí, zvažuje hraniční případy (co když selže Wi-Fi, co když senzor vrátí NaN) a jde dál než nezbytné minimum.
Praktický překlad pro peněženku limitu:
- Low – rychlé dotazy, „vysvětli tenhle řádek“, „co znamená tahle chyba“. Nejmenší spotřeba.
- Medium – vyvážená volba pro běžné generování kódu.
- High – složitější uvažování, návrh struktury firmwaru, ladění netriviální chyby. U API je high výchozí hodnota.
- xhigh / max – jen tam, kde opravdu jde o nejnáročnější úkoly bez ohledu na cenu.
Jedno varování z praxe: nízký effort umí kvalitu srazit víc, než byste čekali. Efekt se promítne do všeho – méně kontrolovaných hraničních případů, méně komentářů v kódu, méně ověřování názvů knihoven. U složitého firmwaru je proto lepší zvednout effort, než to obcházet chytrými prompty.
Chytrá strategie 1: Sonnet na rozbor, Opus na finále
Nabízí se otázka, jestli je lepší pustit rovnou Opus, nebo modely kombinovat. Odpověď zní: kombinace se vyplatí, ale ne vždy a ne automaticky. Funguje to takhle:
- Sonnet na úvodní rozbor – lehčí model zmapuje problém, navrhne strukturu programu, vytahá z datasheetu registry, napíše první draft funkcí. Spotřebuje málo a tahle objemová práce mu jde dobře.
- Opus na finále a kontrolu – silný model pak kód posoudí, najde chyby v logice, ověří kompatibilitu s Arduino core 3.x, doladí obsluhu chyb a dá tomu finální kvalitu.
Je to lepší než rovnou Opus? V mnoha případech ano, protože hrubou objemovou práci (kde se spotřebuje nejvíc tokenů) odbavíte levně a drahý výpočet platíte jen za to, co ho skutečně potřebuje. Je to podobné jako rozdělení práce do více kroků z článku o promptování – jen tentokrát ke každému kroku přiřadíte i vhodný model.
Nevyplatí se to ale u úloh, kde rozbor a řešení nejde oddělit – tedy kde i ten první krok vyžaduje hluboké uvažování. Tam Sonnet udělá rozbor, který Opus stejně celý přepracuje, a zaplatíte dvakrát. Typicky ladění časování přerušení, návrh netriviální stavové logiky nebo hledání záludné chyby v deep sleepu.
👉 Praktické pravidlo: čím líp jde úloha rozdělit na „vygeneruj a poskládej“ (levné) a „rozhodni a zkontroluj“ (drahé), tím víc se kombinace vyplatí. Čím je úloha monoliticky složitá, tím spíš dává smysl jet rovnou silný model s vyšším effortem.
A jak do toho zapadá effort? Logicky stejně: Sonnetu na rozbor stačí medium, Opusu na finální kontrolu kódu patří high. Výsledek je dvojitá úspora – lehčí model i nižší effort tam, kde to stačí.
Chytrá strategie 2: rozložení v čase podle resetu limitu
Druhá úspora není o tom, co spustíte, ale kdy. A vyplatí se pochopit, jak reset limitu funguje.
U většiny dnešních předplatných (Claude, ChatGPT) nejde o pevný reset o půlnoci. Krátkodobý limit běží typicky v 5hodinovém klouzavém okně navázaném na vaši první zprávu. Posouvá se s časem: počítá se spotřeba za posledních pět hodin, takže co jste spotřebovali třeba v 9:00, se vám uvolní zase ve 14:00. U Claude k tomu navíc běží týdenní strop, a ten je důležitý: týden se resetuje v klouzavém 7denním okně navázaném na první zprávu cyklu, ne v pondělí o půlnoci.
Z toho plyne jednoduchá strategie, kterou ocení každý, kdo přes den chodí do práce a večer bastlí:
- Náročnou dávku zadejte ráno (třeba u snídaně) – „navrhni mi kompletní firmware pro meteostanici“ – a spotřebujte klidně velkou část 5hodinového okna. Pustíte silný model s vysokým effortem na to, co potřebuje hloubku.
- Přes den jste v práci a AI neběží – okno se mezitím posune a kapacita se vám uvolní.
- Večer u páječky máte limit zase k dispozici a kód doladíte, otestujete na desce a opravíte. Claude i ostatní agenti přitom navážou tam, kde skončili – stačí pokračovat ve stejné konverzaci, kontext zůstává zachovaný.
Funguje to ale jen tehdy, dokud nenarazíte na týdenní strop. Proto se vyplatí sledovat ukazatel spotřeby. Kdo je ve středu na 70 % týdenního limitu, má problém s plánováním, ne s pětihodinovým oknem. Před náročným projektem proto stojí za to mrknout na stránku se spotřebou – reálná čísla a čas resetu, které aplikace ukazuje, jsou spolehlivější než jakýkoliv odhad.
A ještě jeden detail, který lidi netuší: u Claude tvoří všechno jeden společný limit – konverzace ve webu, desktop aplikace i Claude Code v terminálu pod stejným účtem. Pokud tedy přes den jedete agentní úlohu v Claude Code a večer chcete řešit sketch ve webu, čerpáte ze stejného limitu. Placené API přes klíč (třeba v pluginu AI.duino) se obvykle účtuje zvlášť, ale konkrétní pravidla se čas od času mění – ověřte si je v nastavení účtu.
Praktické tipy na závěr
Pár věcí, které šetří limit při každém bastlení:
- Začínejte nové vlákno na nový projekt. Tahat historii ladění starého firmwaru kvůli novému dotazu je tichý žrout tokenů.
- Nepřikládejte celé datasheety, pokud z nich potřebujete jen tabulku registrů. Vytáhněte relevantní stránku.
- Effort přepínejte podle úkolu, nenechávejte ho natvrdo na max. Vysvětlení chybového hlášení zvládne medium.
- Použijte „hlavičku projektu“ z článku o promptování – pár řádků s hardwarem na začátku nového chatu ušetří zdlouhavé znovuvysvětlování a tím i tokeny.
- Sledujte ukazatel spotřeby před začátkem velkého projektu, ne až když narazíte na zeď uprostřed ladění.
Tokeny nejsou strašák – jsou to jen jednotky práce, podobně jako miliampérhodiny v akumulátoru. Když pochopíte, kde se utrácí nejvíc, dají se předplatné limity natáhnout překvapivě daleko.
👉 Pokud chcete s tokeny pracovat opravdu chytře, připravil jsem k tématu samostatný praktický kurz – s kalkulačkou spotřeby, konkrétními limity předplatných a kvízy: Tokeny a limity AI. Pokud s AI teprve začínáte, mrkněte nejdřív na Všeobecné základy AI, kde se naučíte psát dobré prompty od nuly. A když chcete vědět, jak AI správně zadat bastlířský úkol, vraťte se k článku Jak programovat Arduino, ESP32 a Raspberry Pi s pomocí AI. Všechny kurzy najdete na rozcestníku ai.chiptron.cz.
Žádné sociální komentáře k dispozici.