Claude Code tévhitek

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.

vast.ai info

https://vast.ai/pricing

One of the biggest advantages of Vast.ai is that it gives you access to GPU resources that are simply not realistic for the average home PC.

### Some examples

* **RTX 3060 (12 GB VRAM)** – Training smaller models and LoRA fine-tuning.
* **RTX 4090 (24 GB VRAM)** – Fine-tuning 7B–14B models and serious AI development.
* **A100 (80 GB VRAM)** – Training and inference for large models.
* **H100 (80–94 GB VRAM)** – Currently one of the top-tier GPUs for AI training.

### What can you do with a home PC?

For example:

* **RTX 3060 or RTX 4060** → Run 7B–8B models and perform smaller fine-tuning tasks.
* **RTX 4090** → Excellent for advanced AI development, but still not enough to train a full Llama 70B model from scratch.

### What is Vast.ai good for?

With Vast.ai, you can rent configurations such as:

* 2× RTX 4090
* 4× RTX 4090
* 8× A100
* Even 8× H100

Buying hardware like this yourself would cost tens or even hundreds of thousands of dollars, making it impractical for most individual developers and small teams.

## An important distinction: Training vs. Fine-tuning

When people say they’re “training Llama,” they often mean one of two very different things:

### Fine-tuning

Fine-tuning means taking an existing model (for example, Llama 3.1 8B) and adapting it to your own data. This can often be done on a single RTX 4090 or on a rented GPU through Vast.ai.

### Pretraining (training from scratch)

Pretraining means building a completely new Llama-class model by training it on trillions of tokens. This requires an enormous amount of compute—typically hundreds or thousands of GPUs running continuously for weeks or months. That is far beyond what a single rented machine on Vast.ai is intended for and is usually done only by major AI labs and large technology companies.

### The practical approach

If your goal is to build your own AI assistant or a chatbot powered by your company’s knowledge base, then **fine-tuning** or **Retrieval-Augmented Generation (RAG)** is a much more practical and cost-effective approach. Vast.ai is an excellent platform for these workloads and costs only a fraction of what it would take to train a large language model from scratch.