Miért drágák az AI-ügynökök és hogyan lesznek olcsóbbak? Az AI-ügynök költségének csökkentése tömörítéssel, eszközkereséssel és kevesebb hívással

Az AI-ügynök költsége ritkán ott dől el, ahol a legtöbben keresik. A tokenárak fillérekben mérhetők, egy rosszul beállított ügynök mégis képes egyetlen feladaton több ezer forintot elégetni, mert minden lépésnél újraolvassa a teljes addigi munkáját, betölti a soha nem használt eszközök leírását, ha pedig valami nem sikerül, türelmesen újrapróbálkozik. Szeptemberben ráadásul egymás után több szolgáltató is ezen a számlán kezdett faragni: az OpenAI szeptember 3-án bemutatott GPT-6 Astra modellje a Codexben tömörítés helyett kereshető jegyzeteket vezet, a szeptember 10-én nyilvános bétába küldött Agents API automatikusan tömöríti a kontextust, a Meta Muse Spark 1.3 modellje pedig a cég szerint nagyjából 20%-kal kevesebb eszközhívással és 25%-kal kevesebb tokennel dolgozik, mint az elődje.

Ez az útmutató 2026. szeptember 22-i állapot szerint mutatja meg, hol folyik el a pénz egy ügynöknél, mennyit hoz valójában a gyorsítótár, a kontextustömörítés, az eszközkeresés és a modell-routing, illetve hogyan érdemes feladatonként mérni a költséget. A végén egy képzeletbeli ajánlatkészítő ügynökön forintra kiszámoljuk, hogyan lesz egy 6 672 forintos futtatásból nagyjából 186 forintos. Friss fejlemény is került bele, hiszen az OpenAI éppen ma, szeptember 22-én adta ki a GPT-6 Sol és a GPT-6 Luna modellt, amelyek elődeiknél feleannyiba vagy még kevesebbe kerülnek.

Röviden

• Az AI-ügynök költsége elsősorban nem a tokenártól függ, hanem attól, hányszor olvassa újra a modell ugyanazt: egy 30 lépéses futtatásnál saját becslésünk szerint a beolvasott tokenek több mint 90%-a már korábban látott, ismételt tartalom.
• Az OpenAI hivatalos dokumentációja szerint a GPT-5.6 és az újabb modellek (köztük a GPT-6 Astra) gyorsítótárból olvasott bemenete az alapár tizedébe kerül, a gyorsítótárba írás viszont az alapár 1,25-szöröse, az Anthropic Claude-modelljeinél hasonló a szorzók nagyságrendje.
• A kontextustömörítés, a GPT-6 Astra kereshető jegyzetei és az eszközkeresés ugyanazt a célt szolgálják, vagyis hogy minden lépésben kevesebb felesleges token kerüljön a modell elé: az Anthropic mérésében az eszközkeresés 85%-kal csökkentette az eszközleírásokra jutó tokenmennyiséget.
• A költséget feladatonként kell mérni (egy elkészült ajánlat, egy lezárt ügyfélszolgálati jegy), nem a havi számlán, mert csak így derül ki, melyik ügynök, melyik lépés és melyik modell viszi el a keretet.
• Saját becslésünk szerint egy képzeletbeli győri épületgépész cég ajánlatkészítő ügynöke öt egyszerű optimalizálási lépés után 6 672 Ft helyett nagyjából 186 Ft-ba kerül ajánlatonként, havi 120 ajánlatnál 800 640 Ft helyett 22 320 Ft-ba.
• Az optimalizálás ott éri meg igazán, ahol a futtatások száma és az egységköltség szorzata nagy, egy havonta harmincszor futó, pár száz forintos ügynöknél ugyanis a fejlesztői idő többe kerül, mint amennyit valaha megspórolsz vele.

Mitől drágább egy AI-ügynök, mint egy egyszerű chat?

Azért drágább, mert az ügynök nem egyszer kérdez és egyszer válaszol, hanem ciklusban dolgozik: minden lépésnél újra elküldi a modellnek a teljes utasítást, az összes eszköz leírását és az addigi lépések eredményét. A költség így nem a lépésszámmal arányosan, hanem annál jóval meredekebben nő, mert a korábbi tartalmat újra meg újra kifizeted.

Az AI-ügynök olyan program, amely egy nagy nyelvi modellt eszközökkel (CRM-mel, e-maillel, árlistával, webkeresővel) köt össze, majd egy kitűzött cél felé több lépésben, önállóan halad. A modell minden körben eldönti, melyik eszközt hívja meg, a vezérlő szoftver (a szakma nyelvén harness) végrehajtja a hívást, az eredményt hozzáfűzi az addigi beszélgetéshez, majd az egészet visszaküldi a modellnek. A nyelvi modell ugyanis két hívás között semmire nem emlékszik, így minden lépésnél újra meg kell kapnia mindazt, amit addig látott.

Olyan ez, mintha egy társasházi közgyűlésen minden új napirendi pont előtt valaki felolvasná a teljes addigi jegyzőkönyvet, a házirendet és a közös képviselő összes levelét. Az első napirendi pontnál ez még belefér, a huszadiknál viszont már mindenki az óráját nézi, a számlát pedig ebben a hasonlatban a felolvasott oldalak után kell kifizetni.

Tegyük fel, hogy egy ügynök állandó része (utasítás, eszközleírások, a feladat adatai) 22 000 token, minden lépés pedig 3 000 tokennel növeli a kontextust az eszköz válaszával és a modell saját kimenetével. A token a nyelvi modellek elszámolási egysége, nagyjából szótöredéknyi szövegdarab. Tíz lépésnél a modell összesen 355 000 bemeneti tokent olvas be, harminc lépésnél már 1 965 000-et, vagyis háromszor annyi lépés 5,5-szer annyi beolvasott tokennel jár.

A számítás menete: a lépésszám szorozva az állandó résszel, plusz a lépésenkénti növekmény szorozva a lépésszám és az eggyel kisebb szám szorzatának felével. Harminc lépésnél ez 30 × 22 000 + 3 000 × (30 × 29 / 2) = 660 000 + 1 305 000 = 1 965 000 token. Ebből valóban új tartalom csak 109 000 token (az állandó rész egyszer, plusz 29 lépés növekménye), a maradék 1 856 000 token, a teljes mennyiség 94%-a, ismételt olvasás.

A kimenet ehhez képest kis tétel, csakhogy tokenenként sokkal drágább: a GPT-6 Astránál az OpenAI árlistája szerint egymillió bemeneti token 10 dollár, egymillió kimeneti token (a rejtett gondolatmenettel együtt) 50 dollár. Ha a fenti ügynök lépésenként 800 kimeneti tokent ír, az harminc lépésnél 1,20 dollár, miközben a bemenet gyorsítótár nélkül 19,65 dollár. Egy ügynöknél tehát a bemenet a nagy falat, egy rövid e-mail-válasznál viszont jellemzően fordított a helyzet, ahogy a modellárakról szóló cikkünkben is kiszámoltuk.

Hol megy el a pénz? Kontextus, ismétlés, felesleges eszközhívás

Egy ügynök számláján jellemzően öt tétel dominál: az újra meg újra beolvasott kontextus, a minden körben elküldött, de ritkán használt eszközleírások, a feleslegesen terjedelmes eszközválaszok, az ismételt vagy elakadt hívások, végül a feladathoz képest túl erős modell. Az első három a bemenetet hizlalja, az utolsó kettő a lépésszámot és a kimenetet.

Az újraolvasott kontextus

A fenti példában a beolvasott tokenek 94%-a olyan tartalom, amelyet a modell egy korábbi lépésben már látott. Ez önmagában nem hiba, hiszen a modellnek látnia kell az előzményeket ahhoz, hogy jól döntsön, a kérdés csak az, milyen áron olvassa újra őket: működő gyorsítótárral az alapár tizedéért, nélküle minden alkalommal teljes áron, ami a következő szakasz példája szerint közel ötszörös különbség.

Eszközleírások, amelyekhez senki nem nyúl

Minden eszköznek van egy leírása (mit csinál, milyen paramétereket vár, mit ad vissza), amelyet a modellnek minden körben látnia kell. Az Anthropic 2025. november 24-i mérnöki blogbejegyzése egy valós példát hoz: öt MCP-szerver 58 eszköze nagyjából 55 000 tokent foglalt el, mielőtt a beszélgetés egyáltalán elkezdődött volna, ebből a GitHub 35 eszköze egymagában körülbelül 26 000 tokent. Az MCP (Model Context Protocol) nyílt szabvány, amellyel egy külső rendszer egységes formában kínálhatja fel a műveleteit az AI-ügynököknek.

Tegyük fel, hogy valaki egy ajánlatkészítő ügynökhöz bekötötte a teljes CRM-et, a levelezést, a dokumentumtárat és az árlistát, összesen 40 eszközzel, eszközönként átlagosan 400 tokenes leírással (saját becslés). Ez lépésenként 16 000 token, harminc lépésnél 480 000 token, ami a GPT-6 Astra 10 dolláros bemeneti árán gyorsítótár nélkül 4,80 dollár, kerekített 320 Ft-os dollárárfolyammal 1 536 Ft. Ennyibe kerül ajánlatonként csak az, hogy a modell harmincszor elolvassa azoknak az eszközöknek a használati utasítását is, amelyekből jó, ha nyolcat valóban meghív.

Túl bőbeszédű eszközválaszok

Az eszközök válasza bekerül a kontextusba, onnantól pedig a modell minden további lépésben újraolvassa. Ha az árlista-lekérdezés 200 tételt ad vissza teljes JSON-szerkezetben, holott a feladathoz három tétel ára kellett volna, az a pár ezer token a futtatás végéig ott marad. Egy ötödik lépésben érkező, 2 200 tokenes eszközválaszt egy harminclépéses futtatás a hátralévő 25 lépésben összesen 55 000 tokennyi bemenetként olvas újra.

Ismétlés, újrapróbálkozás és elakadás

Az ügynökök egyik legdrágább szokása az elakadás. Ha egy eszköz hibát ad vagy félreérthető választ küld, a rosszul beállított ügynök ugyanazt a hívást próbálja újra és újra, minden körben a teljes kontextussal. Öt felesleges újrapróbálkozás egy 100 000 tokenes kontextusnál 500 000 bemeneti token, ami a GPT-6 Astrán gyorsítótár nélkül 5 dollár, azaz 1 600 Ft, érdemi eredmény nélkül.

Nem véletlen, hogy a modellgyártók éppen ezen dolgoznak. A Meta a Muse Spark 1.3-nál a MarkTechPost beszámolója szerint azt emeli ki, hogy a modell tisztázó kérdést tesz fel a kétértelmű feladatoknál, elakadás esetén kitalált eredmény helyett bevonja a felhasználót, a következményekkel járó lépések előtt pedig megerősítést kér. Mindhárom viselkedés azt jelenti, hogy kevesebb kör megy el vakon. A saját eszközeidnél ugyanezt úgy éred el, hogy a sikertelen hívás egyértelmű hibaüzenetet adjon vissza, ne egy üres vagy félrevezető választ, amelyet az ügynök sikernek néz.

Túl erős modell, túl sok gondolkodás

Ha minden lépés a levél címkézésétől a végső ellenőrzésig a legdrágább modellen fut, a rutinlépéseket is prémium áron fizeted ki. A gondolkodási szinttel ugyanez a helyzet, hiszen egy egyszerű adatkinyeréshez nem kell hosszú, rejtett gondolatmenet, amelyet a szolgáltató kimeneti tokenként számláz.

A táblázat oldalra húzható ↔

Gyorsítótár: a legolcsóbb token az, amelyiket már egyszer kifizetted

A promptgyorsítótár (prompt caching) a szolgáltató oldalán működő mechanizmus, amely a kérések betűre azonos elejét, szakszóval előtagját (prefix) eltárolja és a következő kérésnél töredékáron számolja el. Egy ügynöknél, ahol minden lépés az előző lépés teljes tartalmával kezdődik, ez a legnagyobb egyedi megtakarítási lehetőség, feltéve, hogy semmi nem rontja el az egyezést.

Az OpenAI prompt caching útmutatója szerint a gyorsítótár a támogatott modelleknél alapból be van kapcsolva, tehát nem bekapcsolni kell, hanem vigyázni, hogy ne rontsd el. A GPT-5.6 és az újabb modelleknél legalább 1 024 bemeneti tokennek kell egyeznie. A gyorsítótárba írt előtag az utolsó írás vagy felhasználás után legalább 30 percig marad elérhető. Az elszámolás két szorzóval történik: a gyorsítótárba írás az alapár 1,25-szöröse, az onnan olvasás az alapár 0,1-szerese. A GPT-6 Astránál ez saját számításunk szerint millió tokenenként 12,50 dollárt jelent íráskor és 1 dollárt olvasáskor a 10 dolláros alapár helyett, az utóbbi az OpenAI árlistáján is így szerepel.

Az útmutató egy beszédes arányt is közöl: ha egy előtagot egyszer beírsz a gyorsítótárba és egyszer újra felhasználod, az a normál bemeneti ár 1,35-szörösébe kerül, szemben a gyorsítótár nélküli kétszeressel. Minél többször olvasod újra ugyanazt, annál jobban megéri, márpedig egy harminclépéses ügynök ugyanazt az állandó részt 29-szer olvassa újra. A fenti példaügynöknél a gyorsítótár működése egymagában 6 672 Ft-ról 1 414 Ft-ra viszi le a futtatásonkénti költséget, a számítás menetét az ajánlatkészítő példánál részletesen megmutatjuk.

Az Anthropic dokumentációja szerint a Claude-modelleknél az ötperces gyorsítótárba írás az alapár 1,25-szöröse, az egyórásba írás a kétszerese, az olvasás a 0,1-szerese, az alapértelmezett ötperces élettartam pedig minden felhasználáskor díjmentesen újraindul.

A táblázat oldalra húzható ↔

Mi rontja el a gyorsítótárat?

A gyorsítótár csak akkor talál, ha a kérés eleje karakterre azonos a korábbival, ezért a legtöbb hiba apróságnak tűnik, a számlán mégis nagyot üt. Az OpenAI útmutatója egyértelmű ajánlást ad: az állandó fejlesztői utasítások és a közös referenciaanyagok kerüljenek a kérés elejére. Tapasztalatunk szerint az alábbi hibák a leggyakoribbak:

• Változó adat a rendszerprompt elején: a pontos időpont, a jegy azonosítója vagy az ügyfél neve az első sorban minden kérést egyedivé tesz, így a gyorsítótár soha nem talál. Ezek az adatok a kérés végére valók.
• Futás közben változó eszközlista: ha a fejlesztő lépésenként más sorrendben vagy más összetételben küldi az eszközöket, a gyorsítótár érvénytelenné válik.
• Modellváltás egy cikluson belül: a gyorsítótár az adott modellhez tartozik, így ha a ciklus közepén másik modellre váltasz, az új modell mindent teljes áron olvas be.
• Utólagos szerkesztés az előzményekben: minden tömörítés vagy régi eszközválasz törlése a módosítás pontjától újraírja a gyorsítótárat, ezért ritkán és nagyobb adagokban érdemes csinálni, nem lépésenként.
• Hosszú szünet: ha az ügynök egy jóváhagyásra 45 percet vár, az OpenAI-nál a 30 perces, az Anthropicnál az alapértelmezett ötperces élettartam lejár, így a folytatás teljes áron indul.

Hogy működik-e, azt nem kell találgatni, mert az OpenAI minden válasz használati adataiban (usage) külön visszaadja a gyorsítótárból olvasott és a gyorsítótárba írt tokenek számát. Egy hosszú, harminclépéses ügynöknél 90% fölötti találati arány is reális, ha ennél jóval alacsonyabbat látsz, valamelyik fenti hiba szinte biztosan ott van a rendszerben.

Három technika: perzisztens jegyzet (Astra), tömörítés (Agents API), 25%-kal kevesebb token (Muse)

A gyorsítótár olcsóbbá teszi az ismételt olvasást, a szeptemberi újdonságok ennél is tovább mennek: azt célozzák, hogy eleve kevesebb token kerüljön a kontextusba, illetve hogy a modell kevesebb lépésből jusson el a célig. A három megoldás nem kizárja, hanem kiegészíti egymást.

Kontextustömörítés az OpenAI Agents API-ban

A kontextustömörítés (compaction) olyan technika, amely a munkamenet korábbi részét rövid összefoglalóra cseréli, amikor a kontextus megtelni készül, így az ügynök csak a lényeget viszi tovább. Az OpenAI szeptember 10-i bejelentése szerint az Agents API automatikusan tömöríti a korábbi kontextust, amikor a munkamenet a kontextuskorláthoz közelít, közben megőrzi azt, amire az ügynöknek a folytatáshoz szüksége van.

A tömörítésnek három ára van. Maga az összefoglalás is egy modellhívás, amely beolvassa a teljes addigi kontextust és kimeneti tokenként megírja az összefoglalót, utána az új, rövidebb kontextust újra be kell írni a gyorsítótárba. A harmadik ár a legkellemetlenebb: minden összefoglalásban elveszhet egy részlet, például egy ügyfél egyedi fizetési határideje, amiről az Agents API-ról szóló cikkünkben bővebben írtunk. Hosszú munkameneteknél a tömörítés ennek ellenére bőven megéri.

Mennyit hoz a tömörítés egy egész napos ügynöknél?

Vegyünk egy képzeletbeli pécsi ingatlanirodát, ahol egy ügynök egész nap az érdeklődőket kezeli: leveleket olvas, hirdetéseket keres ki a saját adatbázisból, időpontot egyeztet. Tegyük fel (saját becslés), hogy egy munkanap 200 lépésből áll, az állandó rész 10 000 token, minden lépés 2 000 tokennel növeli a kontextust és 500 kimeneti tokent termel, az ügynök a GPT-6 Sol modellen fut, a gyorsítótár pedig végig működik.

Tömörítés nélkül a nap utolsó lépésénél a kontextus 408 000 tokenes lenne (ha a modell kontextusablaka egyáltalán elbírja), miközben a modell a nap során összesen 41,8 millió bemeneti tokent olvasna be. Ha viszont az ügynök minden alkalommal, amikor a kontextus átlépi a 100 000 tokent, 3 000 tokenes összefoglalót készít és 20 000 tokenes kontextussal folytatja, a napi beolvasás négy tömörítéssel 11,9 millió tokenre csökken, ami 72%-kal kevesebb.

Forintban a megtakarítás kisebb, de így is jelentős. A GPT-6 Sol árán (millió tokenenként 2 dollár alapár, 0,20 dollár olvasás, 2,50 dollár írás, 10 dollár kimenet) a tömörítés nélküli nap saját számításunk szerint 10,30 dollár, vagyis kerekített 320 Ft-os árfolyammal 3 295 Ft, a tömörítéses nap 4,62 dollár, azaz 1 477 Ft, a tömörítő hívásokkal együtt. Ez 55%-os csökkenés, 22 munkanapos hónappal számolva 72 490 Ft helyett 32 494 Ft. Az arány azért kisebb a tokenekben mért 72%-nál, mert a gyorsítótár az ismételt olvasást eleve olcsóvá tette, a tömörítések után viszont az új kontextust újra be kell írni.

Az Anthropic kontextuskezelési bejelentése is ebbe az irányba mutat: a hasonló elven működő kontextusszerkesztés (context editing), amely a kontextus megtelése előtt automatikusan kitörli az elavult eszközhívásokat és eredményeiket, a cég értékelésében 84%-kal csökkentette a tokenfelhasználást, miközben az ügynökök olyan munkafolyamatokat is végigvittek, amelyek enélkül elakadtak volna.

Kereshető jegyzetek a GPT-6 Astrában

Az OpenAI a GPT-6 Astra bejelentésében nyíltan kimondja a tömörítés gyengeségét, saját fordításunkban: „minden tömörítés kihagyhat részleteket arról, miért bukott el egy javítás vagy hogyan viselkedik egy komponens”. Az Astra ezért a Codexben, az OpenAI programozóügynökében, kontextusablakokon átívelő jegyzeteket vezet, így a felhalmozott részleteket nem kell újra és újra egyetlen összefoglalóba sűríteni. A korábbi kontextusablakok ráadásul kereshetők maradnak, vagyis az Astra akkor is visszakeresheti egy korábbi üzenet követelményeit vagy egy teszt eredményét, ha az nem került be a jegyzetekbe. A funkció egyelőre kísérleti, a Codex konfigurációs fájljában kapcsolható be. Az OpenAI szerint a következő hetekben ez lesz az Astra alapértelmezett működése.

Költségoldalról ennek a haszna közvetett, de valós. A jegyzet kicsi, a kontextusba csak az kerül, amire éppen szükség van, míg a kereshető előzmény megóvja az ügynököt attól, hogy egy elfelejtett részlet miatt újra lefuttasson egy már elvégzett vizsgálatot. Egy KKV-folyamatban ez házilag is megvalósítható: az ügynök a fontos tényeket (az ügyfél kért határidejét, a kiválasztott termékek cikkszámát, a jóváhagyott kedvezményt) egy külső jegyzetbe vagy a CRM egy mezőjébe írja, így a nyers eszközválaszok nyugodtan kikerülhetnek a kontextusból. Az Anthropic memóriaeszköze (memory tool) ugyanezt fájlalapú tárolással oldja meg a Claude-modelleknél, a kontextusablakon kívül.

Takarékosabb modell: Muse Spark 1.3

A harmadik út maga a modell. A MarkTechPost szeptember 3-i beszámolója szerint a Meta mérnökeinek belső összehasonlításában a Muse Spark 1.3 nagyjából 20%-kal kevesebb eszközhívással és körülbelül 25%-kal kevesebb tokennel dolgozott, mint az 1.2-es változat, a cikk azonban nem részletezi, pontosan milyen feladatokon mértek. Az ár közben nem változott, millió bemeneti tokenenként 1,25, millió kimeneti tokenenként 4,25 dollár maradt.

Ha a feladat bemeneti és kimeneti aránya nem változik, ugyanazon az áron negyedével kevesebb token saját következtetésünk szerint nagyjából negyedével alacsonyabb feladatonkénti költséget jelent, a kevesebb eszközhívás emellett a futási időn és a hibalehetőségeken is spórol. A Muse Spark 1.3 ugyanakkor ügynöki programozásra készült, zárt súlyú modell, így irodai folyamatokra nem feltétlenül ez a legjobb választás. A tanulság ettől még általános érvényű: két modell összevetésekor ne csak a tokenárat nézd, hanem azt is, hány lépésből és hány tokenből oldják meg ugyanazt a feladatot.

Mi az eszközkeresés és hogyan csökkenti az ügynök költségét?

Az eszközkeresés (tool search) olyan megoldás, amelyben az ügynök nem kapja meg előre az összes elérhető eszköz leírását, hanem egy keresőeszközzel mindig csak a feladathoz szükségeseket tölti be. Így lépésenként kevesebb token megy el eszközleírásokra, sok eszköz esetén pedig a pontosság is javulhat, mert a modellnek kevesebb hasonló eszköz közül kell választania.

Az Anthropic 2025. november 24-i mérnöki bejegyzése szerint az eszközkeresés 85%-kal csökkentette az eszközdefiníciókra jutó tokenfelhasználást: a hagyományos megoldással a kontextusablakból 122 800 token maradt szabadon a munkára, eszközkereséssel 191 300. A cég belső, MCP-alapú értékelésein a pontosság is javult, a Claude Opus 4-nél 49%-ról 74%-ra, a Claude Opus 4.5-nél 79,5%-ról 88,1%-ra. Ezek a gyártó saját mérései, az irány azonban egybevág a tapasztalatunkkal: a negyven hasonló nevű eszköz között válogató modell többet téved, mint a nyolc jól elnevezett eszközt használó.

Az OpenAI Agents API bejelentése szerint az eszközkeresés a szükséges eszközleírásokat igény szerint tölti be, ami csökkenti a tokenfelhasználást és a költséget, miközben megőrzi a modell gyorsítótárát. Ez utóbbi azért fontos, mert ha a fejlesztő maga variálná az eszközlistát lépésről lépésre, minden változtatás érvénytelenítené a gyorsítótárat, így az eszközleírásokon spórolt tokeneket a teljes áron újraolvasott kontextuson fizetné vissza.

A rokon technika a programozott eszközhívás (programmatic tool calling), amelynél a modell nem egyesével kéri a hívásokat, hanem kódot ír, amely párhuzamosan futtatja, láncba fűzi és kódban szűri őket, így a köztes adatok nem folynak át a kontextuson. Az Anthropic mérése szerint összetett kutatási feladatokon ez 43 588-ról 27 297 tokenre, vagyis 37%-kal csökkentette az átlagos tokenfelhasználást. Az OpenAI Agents API szintén kínál programozott eszközhívást.

Ha a platformod nem ismeri az eszközkeresést, akkor is sokat tehetsz, mert a legtöbb nyereség az eszközök tervezésén múlik:

• Csak azokat az eszközöket kösd be, amelyeket az ügynök valóban használ: egy ajánlatkészítőnek nem kell a CRM összes művelete, elég az ügyfél lekérdezése, a korábbi ajánlatok keresése és az új ajánlat mentése.
• Írj rövid, egyértelmű eszközleírásokat, beszédes nevekkel, mert a leírás hosszát minden lépésben kifizeted.
• Tervezd úgy az eszközt, hogy csak a szükséges mezőket adja vissza: az árlista-lekérdezés a három releváns tétel árát és készletét hozza, ne a teljes, 200 soros táblát.
• Ahol lehet, egy hívással kérj le több adatot (például három cikkszám árát egyszerre), mert minden külön hívás egy újabb teljes kontextusolvasást jelent.

Modell-routing: minden lépéshez a legolcsóbb modell, amelyik még elég jó

A modell-routing (útválasztás) azt jelenti, hogy egy szabály vagy egy olcsó osztályozó modell eldönti, melyik lépést melyik modell végezze, így a prémium modell csak a valóban nehéz részeket kapja meg. Egy ügynöknél ez az egyik legnagyobb szorzó, mert a modellek tokenárai között ma százszoros különbség is lehet.

A legfrissebb fejlemény ebben a sávban ma jelent meg. Az OpenAI 2026. szeptember 22-én bejelentette a GPT-6 Sol és a GPT-6 Luna modellt, amelyek a hivatalos árlista szerint millió tokenenként 2 dolláros bemenettel, 0,20 dolláros gyorsítótárazott bemenettel és 10 dolláros kimenettel (Sol), illetve 0,10, 0,01 és 0,50 dollárral (Luna) érhetők el az API-ban. A VentureBeat összefoglalója szerint a GPT-6 Sol pontosan feleannyiba kerül, mint a GPT-5.6 Sol, a GPT-6 Luna bemenete a GPT-5.6 Lunáénak fele, kimenete 58,3%-kal olcsóbb. A lap szerint a Luna a nagy volumenű, szűken körülhatárolt feladatokra (összefoglalás, adatkinyerés, egyszerű kérdések megválaszolása) szánt modell, a Sol pedig az ismétlődő programozási és ügynöki munkára. Független mérések még nincsenek róluk, a korábbi cikkeinkben szereplő GPT-5.6 Sol- és Luna-árak így mostantól az elődmodellekre vonatkoznak.

Egyetlen lépésen is látszik a különbség: egy beérkező ajánlatkérés osztályozása (3 000 bemeneti és 200 kimeneti token, saját becslés) a GPT-6 Astrával 0,04 dollár, vagyis 12,8 Ft, a GPT-6 Lunával 0,0004 dollár, azaz 0,13 Ft. Ugyanaz a munka százszor olcsóbb, egy levél típusának felismeréséhez pedig aligha kell a piac legerősebb modellje.

A táblázat oldalra húzható ↔

A routingnak is megvannak a csapdái. A gyorsítótár modellenként külön él, ezért a modellváltást a részfeladatok határára tedd: egy olcsó modellen futó alügynök a saját, rövid kontextusával dolgozik, nem a fő ciklus közepén veszi át a munkát. Az olcsóbb modell több lépésből vagy több hibával juthat el ugyanoda, ezért a döntést nem a tokenár, hanem a sikeres feladatonkénti költség hozza meg. Végül kell egy vészfék is: ha az olcsó modell válasza nem megy át egy egyszerű ellenőrzésen (hiányzik egy kötelező mező, a végösszeg nem egyezik a tételek összegével), a lépés automatikusan a drágább modellhez kerüljön.

Mikor éri meg várni és mikor fizetni a sebességért?

Várni akkor éri meg, ha a feladat nem sürgős és önálló kérésekből áll: az OpenAI Batch API-ja ilyenkor felezi az árat, a GPT-6 Astránál millió tokenenként 5 és 25 dollárra. Egy több lépésből álló ügynöki ciklushoz viszont nem való, a Fast módért pedig csak akkor érdemes duplán fizetni, ha közben ember vár a válaszra.

A Batch API olyan elszámolási mód, amelyben sok, egymástól független kérést adsz le egyszerre, amelyeket a szolgáltató később dolgoz fel. Az ügynöki ciklusban minden lépés az előző eredményére épül, ott tehát nincs mit kötegelni, az ügynök körüli tömeges munkákra (éjszakai termékleírás-frissítés, régi ajánlatok összefoglalása, archív levelek címkézése) ugyanakkor kiváló. Tegyük fel, hogy egy webshop 500 termékleírást íratna újra, darabonként 1 500 bemeneti és 600 kimeneti tokennel. A GPT-6 Astra normál árán ez 22,50 dollár, vagyis 7 200 Ft, Batch módban 11,25 dollár, azaz 3 600 Ft, pusztán azért, mert nem kellett azonnal.

A másik irány a gyorsítás. Az OpenAI szerint a GPT-6 Astra Fast módja legfeljebb kétszeres sebességet ad a normál ár kétszereséért. Egy élő chaten, ahol az ügyfél a képernyő előtt vár, ez indokolt lehet, egy éjszaka futó háttérügynöknél viszont kidobott pénz. Kevésbé ismert tétel, hogy az OpenAI árlistája szerint a 2026. március 5-én vagy később megjelent, regionális adatfeldolgozásra (data residency) jogosult modelleknél a regionális végpontok 10% felárral járnak. Ha adatvédelmi megfontolásból európai feldolgozást választasz, ezt a 10%-ot is tedd bele a feladatonkénti költségbe.

Mérés: költség feladatonként, nem havonta

A havi számla csak annyit mond, hogy mennyit költöttél, azt viszont nem, hogy mire. Egy ügynök költségét ezért feladategységben érdemes mérni: mennyibe került egy elkészült ajánlat, egy lezárt ügyfélszolgálati jegy vagy egy feldolgozott számla, a modellhívásokkal, az eszközdíjakkal és az emberi javítással együtt. Csak így derül ki, ha egy ügynök drágább, mint a kolléga, akit tehermentesítenie kellene.

A gyakorlatban ez azt jelenti, hogy minden futtatás kap egy feladatazonosítót, a rendszer pedig lépésenként naplózza a használt modellt, a bemeneti, a gyorsítótárból olvasott, a gyorsítótárba írt és a kimeneti tokeneket, valamint az eszközhívásokat, az alügynökökét is beleértve. Az OpenAI ezeket a számokat minden válasz használati adataiban visszaadja. Az eszközdíjakat is a feladathoz kell rendelni: az OpenAI árlistája szerint a webkeresés 1 000 hívásonként 10 dollár plusz a behúzott tartalom tokenjei, a fájlkeresés 1 000 hívásonként 2,50 dollár. Ebből három szám számolható:

• Futtatásonkénti költség: a lépések tokenköltségének és az eszközdíjaknak az összege.
• Sikeres feladatonkénti költség: az összes futtatás költsége osztva a sikeresen lezárt feladatok számával, így a félresikerült futtatások ára is látszik.
• Teljes egységköltség: a sikeres feladatonkénti költség plusz az emberi ellenőrzés és javítás ideje forintban.

Az OpenAI Agents API bejelentésében a SafetyKit nevű cég is ebben a mértékegységben számolt: saját közlése szerint az esetellenőrzési munkafolyamat átköltöztetése után 60%-kal csökkent az esetenkénti költség. Ez gyártói adat, a mértékegység ettől még pontosan az, amelyet egy magyar KKV-nak is követnie kell.

A táblázat oldalra húzható ↔

Két korlátot minden ügynökre érdemes beállítani: egy lépésszám-korlátot és egy futtatásonkénti költségkorlátot, például a medián futtatási költség háromszorosánál. Ha az ügynök eléri valamelyiket, álljon meg és jelezzen egy embernek, ahelyett, hogy csendben tovább költene. A szolgáltatók felületén beállítható havi keret és értesítés ezen felül is kell, ez azonban csak a teljes keret elfogyásakor fékez, a feladatszintű korlát viszont már az első elszabadult futtatást megfogja.

Példa számokkal: mennyibe kerül egy ajánlatkészítő ügynök?

Saját becslésünk szerint egy képzeletbeli győri épületgépész cég harminclépéses ajánlatkészítő ügynöke a GPT-6 Astrával, működő gyorsítótár nélkül ajánlatonként 6 672 Ft-ba kerül, ami drágább, mint ha egy kolléga írná meg. Öt optimalizálási lépés után ugyanez nagyjából 186 Ft, havi 120 ajánlatnál 800 640 Ft helyett 22 320 Ft.

Vegyünk egy képzeletbeli, 18 fős győri épületgépészeti céget, amely hőszivattyúkat, klímákat és padlófűtést telepít, havonta nagyjából 120 ajánlatkéréssel. Az ügynök elolvassa a kérést, kikeresi az ügyfelet és a hasonló korábbi ajánlatokat, lekérdezi az árlistát és a készletet, kiszámolja az anyag- és munkadíjat, megírja az ajánlattervezetet, végül jóváhagyásra küldi egy kollégának. A kiinduló beállítás feltételezései mind saját becslések:

• a rendszerprompt (cégszabályok, kedvezménypolitika, ajánlatsablon) 4 000 token, a 40 bekötött eszköz leírása 16 000 token, az ajánlatkérés és az ügyfél adatai 2 000 token, vagyis az állandó rész 22 000 token;
• lépésenként átlagosan 2 200 token eszközválasz és 800 kimeneti token (gondolkodással együtt), azaz 3 000 token növekmény;
• 30 lépés, mindegyik a GPT-6 Astrán, a rendszerprompt első sorában az aktuális időbélyeggel, ami miatt a gyorsítótár soha nem talál;
• árfolyam: kerekített 320 Ft/dollár, árak: a szolgáltatók szeptember 22-i listaárai.

Kiindulás. A bemenet 1 965 000 token × 10 dollár / 1 000 000 = 19,65 dollár, a kimenet 24 000 token × 50 dollár / 1 000 000 = 1,20 dollár, összesen 20,85 dollár, azaz 6 672 Ft ajánlatonként.

1. lépés, a gyorsítótár rendbetétele. Az időbélyeg a kérés végére kerül, így minden lépés az előző lépés teljes kontextusát a gyorsítótárból olvassa: 1 856 000 token × 1 dollár / 1 000 000 = 1,856 dollár. Csak az új részt kell beírni a gyorsítótárba, ez 109 000 token × 12,50 dollár / 1 000 000 = 1,3625 dollár, a kimenet változatlanul 1,20 dollár. Összesen 4,42 dollár, vagyis 1 414 Ft.

2. és 3. lépés, eszközkeresés és rövidebb eszközválaszok. A 16 000 tokenes eszközlista helyett lépésenként átlagosan 3 000 token eszközleírás töltődik be, az eszközök pedig szűrt adatot adnak vissza, így egy eszközválasz 2 200 helyett 900 token. Az állandó rész 9 000, a növekmény 1 700 token, a harminc lépés összes bemenete 1 009 500 token, a költség gyorsítótárral 2,88 dollár, azaz 922 Ft.

4. lépés, kevesebb kör. Összevont lekérdezésekkel (egy hívás három cikkszám árára), egyértelmű munkatervvel a rendszerpromptban és pontos hibaüzenetekkel a futtatás 30 helyett 20 lépésből áll. A bemenet 503 000, a kimenet 16 000 token, a költség 1,78 dollár, azaz 569 Ft.

5. lépés, modell-routing. A ciklus a GPT-6 Sol modellen fut a fent ismertetett árakon, így 0,36 dollárba, azaz 114 Ft-ba kerül. A kész tervezetet a GPT-6 Astra egyetlen hívásban ellenőrzi 15 000 bemeneti és 1 500 kimeneti tokennel, ez 0,225 dollár, vagyis 72 Ft. Összesen nagyjából 186 Ft ajánlatonként.

A táblázat oldalra húzható ↔

Figyeld meg, hogy a legnagyobb ugrást a legolcsóbb javítás hozta, hiszen az időbélyeg áthelyezése egyetlen sor módosítása. Most vegyük hozzá az emberi időt is, feltételezve, hogy az ajánlatot készítő kolléga teljes munkáltatói óraköltsége 6 000 Ft (ezt cseréld a sajátodra), egy ajánlat kézzel egy óra munka, az ügynök tervezetének átnézése 10 perc. Kézzel egy ajánlat 6 000 Ft, a kiinduló ügynökkel 6 672 + 1 000 = 7 672 Ft, vagyis a rosszul beállított ügynök drágább a kézi munkánál. Az optimalizált ügynökkel ugyanez 186 + 1 000 = 1 186 Ft, havi 120 ajánlatnál 720 000 Ft helyett 142 320 Ft, a legnagyobb tétel pedig már nem a modell, hanem az emberi ellenőrzés.

Ha a futtatások 12%-ánál (feltételezés) a tervezet használhatatlan és a kolléga kézzel írja meg az ajánlatot, a sikeres ajánlatonkénti modellköltség 186 / 0,88, vagyis nagyjából 211 Ft, a kézzel újraírt ajánlatok munkaórái pedig külön tételt jelentenek. A példa szándékosan egyszerűsít: minden lépést egyformának vesz, nem számol webkereséssel, továbbá feltételezi, hogy a GPT-6 Sol ugyanannyi lépésből dolgozik, mint az Astra. A Sol ma jelent meg, ezért mielőtt a ciklust átköltöztetnéd, 30 valódi ajánlatkérésen mérd meg, hány lépésből és milyen minőséggel dolgozik. Ha nem elég jó, a 4. lépés utáni, 569 forintos Astra-változat is a kiindulás tizedénél kevesebbe kerül.

Hogyan csökkentsd az AI-ügynök költségét lépésről lépésre?

Először mérd meg a feladatonkénti költséget, aztán a legolcsóbb javításokkal kezdd: tedd rendbe a gyorsítótárat, szűkítsd az eszközleírásokat és az eszközválaszokat, vágd le a felesleges lépéseket, végül irányítsd a rutinlépéseket olcsóbb modellre. Minden változtatás után ugyanazon a mintán mérj újra, különben nem tudod, mi hozta a javulást.

• Válaszd ki a feladategységet és a mintát. Egy ajánlat, egy jegy vagy egy számla legyen az egység, a mintához 20 és 30 közötti valódi, átlagos futtatás kell.
• Naplózd lépésenként a tokeneket. Modell, bemeneti, gyorsítótárazott és kimeneti tokenek, eszközhívások és hibák, mindez feladatazonosítóval.
• Javítsd a gyorsítótárat. Az állandó rész (utasítás, eszközlista, referenciaanyag) kerüljön elöl, a változó adat a végére, az eszközök sorrendje pedig ne változzon futás közben.
• Szűkítsd az eszközkészletet. Csak a ténylegesen használt eszközöket kösd be, vagy kapcsold be az eszközkeresést, ha a platformod tudja.
• Rövidítsd az eszközválaszokat. Az eszközök csak a szükséges mezőket és a releváns tételeket adják vissza.
• Vágd le a felesleges köröket. Vonj össze lekérdezéseket, adj világos munkatervet, a sikertelen hívás pedig pontos hibaüzenetet küldjön vissza.
• Irányítsd a rutinlépéseket olcsóbb modellre. Osztályozás és adatkinyerés az olcsó sávban, a ciklus a középsávban, a prémium modell csak az ellenőrzésre.
• Állíts be korlátokat és mérj újra. Lépésszám- és költségkorlát futtatásonként, havi keret, majd ugyanazon a mintán újramérés.

Mikor nem éri meg az optimalizálás?

Nem éri meg, ha az ügynök ritkán fut és eleve olcsó, mert a fejlesztői munka ára évekig nem térül meg. Az egyszerű szabály szerint a megtérülési idő a fejlesztési költség osztva a havi megtakarítással. Ha ez egy évnél hosszabb, inkább foglalkozz a következő ügynökkel.

Tegyük fel, hogy egy fejlesztői óra 15 000 Ft (feltételezés). Az ajánlatkészítő ügynöknél a gyorsítótár javítása egy óra munka, miközben a havi megtakarítás 630 960 Ft, vagyis már az első napon megtérül. Az eszközkeresés, az eszközválaszok rövidítése és a lépésszám csökkentése együtt mondjuk 16 óra, vagyis 240 000 Ft, a havi megtakarítás 169 680 és 68 280 Ft különbsége, 101 400 Ft, a megtérülés így nagyjából 2,4 hónap. Egy havonta harmincszor futó, 300 forintos ügynöknél viszont a teljes havi költség 9 000 Ft, a felezése 4 500 Ft megtakarítás, így a 240 000 forintos fejlesztés 53 hónap alatt térülne meg. Ennél az ügynöknél a legjobb optimalizálás az, ha nem nyúlsz hozzá. Olykor a várakozás is stratégia, hiszen a mai GPT-6 Sol és Luna bejelentés is mutatja, hogy egy olcsóbb utódmodell egy alapos teszt után fejlesztés nélkül is felezheti a számlát.

Miben segít a Convergo?

A Convergónál abban segítünk, hogy az AI-ügynököd kiszámítható, feladatonként mérhető költséggel működjön. A workflow automatizáció keretében n8n-alapú ügynököket építünk működő gyorsítótárral, szűkített eszközkészlettel, lépés- és költségkorláttal, feladattípus szerinti modell-routinggal. Ha az ügynöknek az Odoo ERP-hez vagy a CRM-hez kell kapcsolódnia, egyedi AI-integrációval kötjük be úgy, hogy az eszközök csak a szükséges adatot adják vissza. Ha már fut nálad ügynök, az AI-felmérés során a naplóid alapján kiszámoljuk a feladatonkénti költségét és megmutatjuk, hol folyik el a pénz. Az első lépés egy ingyenes egyeztetés, ahol egy valódi folyamatodon közösen megbecsüljük a megtakarítási lehetőséget.