forrás
1. tévhit
„A rövidebb prompt jobb, mert kevesebb tokent használ.”
A második fele igaz, az első fele a gyakorlatban ritkán. Megspórolsz valamennyit a feladat leírásán, aztán jön három kör visszakérdezés meg két félrement próbálkozás, és a végén rájössz, hogy összesen többet költöttél, mint ha elsőre leírtad volna rendesen.
Szóval a rövid prompt nem olcsó. Az egyértelmű prompt az olcsó.
2. tévhit
„Új sessiont indítani mindig olcsóbb.”
Az új session tényleg tiszta lappal (üres kontextus ablakkal) indul,
csakhogy a tiszta lap azt is jelenti, hogy a Claude Code semmire nem emlékszik. Újra feltérképezi a projektet, a fájlszerkezetet, a korábbi döntéseket, és amit még szükségesnek ítél a nyitópromptod, illetve a claude.md alapján a folytatáshoz. És ez az ismerkedés bizony tokenbe kerül. Akkor éri meg újrakezdeni, amikor a régi beszélgetés már zajos, és a vele való munka többe kerül, mint az új ismerkedés.
3. tévhit
„A compact parancs minden kontextusproblémát megold.”
Nem igaz. A kompaktálás tömöríti, kivonatolja az addigi beszélgetést. Csakhogy közben elvesznek/elveszhetnek dolgok: részletek, döntési indokok, kivételek és apróbb korlátozások.
Ha van a beszélgetésben egy rossz feltételezés, azt nem javítja ki, csak rövidebben viszi tovább.
4. tévhit
„A legerősebb modell a legdrágább munkafolyamat.”
Logikusan hangzik, és pont ezért veszélyes. Igaz, hogy egy erős modell drágább tokenenként, például a Fable 5 használata kétszer annyit von le a heti keretedből, mint egy Opus, viszont sokszor elsőre megoldja azt, amin egy gyengébb modell három kört pörög.
Szóval a kérdés sosem az egységár, hanem hogy mennyibe kerül a teljes út a kész megoldásig.
5. tévhit
„A subagentek automatikusan tokent spórolnak.”
Na, ez így ebben a formában hülyeség. A subagent olyan, mint egy gyakornok: kiadsz neki egy részfeladatot, és nem terheli a te asztalodat, a fő sessiont. De a gyakornoknak is van saját asztala, saját kontextusa, saját fogyasztása. Sőt, az se mindegy, hogy milyen modellként indítod az alügynököt. Ha például egy Fable 5 session elindít 3-4 alügynököt, de mindet Fable 5 modellként, mert nem tisztáztad a részleteket, akkor az elég drága mulatság lesz.
Egy subagent igazából akkor spórol, ha jól körülhatárolt munkát kap. Rosszul szervezett feladattal sokszor csak megsokszorozza a költséget.
Ha megnézitek, az első öt mítosz kb. ugyanott hazudik. Mind egyetlen lépés árát nézi ahelyett, hogy a teljes utra kalkulálna: az ötlettől a kész kódig.
6. tévhit
„A CLI mindig erősebb, mint a Desktop.”
Ez egyszerű sznobizmus, és elég sok kockától hallottam már. Ugyanazok a modellek futnak mindkét változat mögött. A Claude CLI, vagyis a terminálos változat az automatizálásban lehet hasznosabb, meg a scriptelésben. A Desktop meg abban, hogy jobban átlátod, mi történik. Ott vannak egymás alatt a munkamenetek egy képernyőn és könnyen tudsz köztük váltani, modellt vagy effort szintet állítani.
7. tévhit
„A Claude Desktop csak kezdőknek való.”
Baromság. Én harminc éve abból élek, hogy látok 
Nekem pl. a folyamatok vizuális követése nem kényelem, hanem munkamódszer. A profizmus nem azon múlik, milyen felületet nyomkodsz. Hanem hogy mit hozol ki belőle. Én például azokat a feladatokat, ahol több kommunikációra van szükség a modellel a Desktop változatban viszek, drag&drop-pal bedobok neki segédanyagokat, példákat, stb. De közben ott fut mellette, sokszor több ablakban is a CLI, ami meg SPEC-ek alapján kódol vagy épp hibákat keres és javít.
8. tévhit
„Claude minden alkalommal beolvassa a teljes repót (repository-t)”
Dehogy olvassa. Úgy dolgozik, mint aki a könyvtárban
először a katalógushoz megy: keres, listáz, és csak azt nyitja meg, ami kell. Ebből viszont következik valami, ami rajtad múlik:
beszédes fájlnevek, tiszta mappaszerkezet, readme.md file-ok, stb. használata, hogy gyorsabban, olcsóbban (kevesebb tokennel) találja meg, amit keres.
9. tévhit
„Minél többet írsz a CLAUDE.md-be, annál jobb.”
A CLAUDE.md (máshol agent.md) a projekt “post-it cetlije”, amit a Claude minden munkakezdésnél (minden sessionben) elolvas.
És pont ezért hasonló a helyzet, mint amikor a hűtőajtón hagysz üzenetet valaki számára. A lényet írd le! A projekt specifikus dolgokat pedig ne a globális “cetlin” tárold. A hosszú projektmemória felhígítja a fontos szabályokat, és egy idő után önmagának is ellentmond. Egyébként ez az egyik leggyakoribb hiba, amit látok. De van rosszabb: amikor valaki halmozza a skill-eket, és betolja a kontextusba, ha kell, ha nem.
10. tévhit
„A párhuzamos sessionök mindig növelik a produktivitást.”
Ha két munka tényleg független egymástól, mehet, hajrá! De ha ugyanazokhoz a fájlokhoz nyúlnak, akkor nem produktivitást kapsz, hanem merge conflictot Kb. mint amikor két kőműves rakja ugyanazt a falat, csak másfelé.
11. tévhit
„Havi előfizetőként nem kell foglalkoznom a tokenekkel.”
Jajj, dehogynem. Számlát ugyan nem kapsz minden tokenről, hiszen van egy kereted, de az ugyanúgy fogy. Heti és 5 órás limitek vannak, amiket nagyon is érdemes figyelni, és úgy optimalizálni a munkát, hogy mindig tudsz dolgozni, és ne kelljen plusz pénzért credit-eket vásárolni, mert az a legdrágább.
Nekem most épp 3 Max csomagom van, mert az elmúlt hónapban sok munkám volt, és kellett a kapacitás. De volt, amikor két, havi 18 USD-s Pro csomaggal is elboldogultam, amikor az egyikben elfogyott az 5 órás keret, váltottam a másikra. És persze mellettük ott van a ChatGPT és más modell is, ami, ha szükséges besegít.
12. tévhit
„Az API-használat meg a Max csomag ugyanaz.”
Jajj, ez fáj! Két külön világról van szó: a Max előfizetés (ugyanúgy mint az olcsóbb Pro) keretet ad. A havidíjban benne van bizontos token mennyiség. Kevesen tudják azt is, hogy a Max csomagból egyékként kettő is létezik, és lehet köztük fel-le váltani havonta. Az egyik 90 USD és 5x annyi használatot biztosít, mint a 18 USD-s Pro, a legdrágább csomag pedig 180 USD, de az már 20x annyi tokent ad.
Ezekkel szemben az API használatra bármikor lehetőséged van fejlesztőként, de az mindig a tényleges forgalom alapján, és külön lesz számlázva! Szóval, hiába van a legdrágább Max csomagod, ha valamelyik app-od API-t használ, mert olyan funkció van benne, amihez LLM kell, akkor arról bizony külön számlát fogsz kapni. Az API esetében az árak modellenként változnak, és még az is számít, hogy kimeneti vagy bemeneti tokenről beszélünk.
