Spotify-eszköz 90%-kal csökkenti a kódolási feladatok tokenfogyasztását

A Spotify mérnökei egy új módszert dolgoztak ki a kódolási feladatokhoz használt AI-modellek tokenfogyasztásának drasztikus csökkentésére. A Portal nevű eszközükben bevezetett AiKA Modes funkció segítségével a fejlesztők akár 90%-kal kevesebb tokent használhatnak fel, miközben a feladatok minősége nem csökken. A megoldás lényege, hogy az I/O-intenzív, ismétlődő feladatokat, mint a fájlok olvasása vagy sablonkód generálása, egy olcsóbb, speciális modellre, a Gemini 2.5 Flash-re delegálják. (Hacker News)

A fejlesztőknek gyakran több fájlt kell elolvastatniuk a modellel egyetlen kérdés megválaszolásához, vagy sablonkódokat kell generáltatniuk, amelyek szinte teljesen megegyeznek a projekt többi részével. Ezek a műveletek rengeteg tokent emésztenek fel, miközben minimális gondolkodást igényelnek. A Spotify becslései szerint az AI-kódolás költségei gyorsan növekednek, mivel a mérnöki vezetők negyede már most havi 200–500 dollárt költ tokenekre fejlesztőnként, egyesek pedig több mint 2000 dollárt.

Két új mód a hatékony delegáláshoz

Az AiKA Modes két új funkciót kínál: a „bulk-reader” és a „code-writer” módot. Ezek deklaratív agensek, amelyek egy ideiglenes futtatókörnyezetben futnak, hasonlóan az AWS Lambda funkcióihoz. A felhasználó definiálja az utasításokat, kiválaszt egy modellt (például a Gemini 2.5 Flash-t, de bármelyik konfigurált modell használható), beállítja a paramétereket, és a Portal elvégzi a többit. Nincs szükség infrastruktúra-kezelésre, API-kulcsokra vagy szerverek futtatására. A módok a Portal CLI-ből vagy API-ból hívhatók meg, és lehetnek publikusak vagy privátak.

A „bulk-reader” mód akkor hasznos, amikor a modellnek több nagy fájlt kellene elolvasnia egyetlen kérdés megválaszolásához. A mód átveszi az I/O-feladatot, és csak a lényegre szűrt, strukturált információt adja vissza. A „code-writer” mód pedig sablonkódok, tesztek vagy konfigurációs fájlok generálására szolgál.

Ez a funkció a meglévő minták, konvenciók és stílusok pontos követésével dolgozik, és csak a generált kódot adja ki, magyarázatok vagy formázási jelölések nélkül, amennyiben ezt az utasítások nem kérik. Ez a megközelítés biztosítja, hogy a generált kód illeszkedjen a projekt meglévő struktúrájához.

Hogyan működik a delegálás?

A rendszer több rétegben működik. A Claude Code beépített „shunt” pluginje kezeli a delegálást. Az első rétegben a „check-file-size” és „check-bash-read” horgonyok (hooks) minden fájlolvasási kísérlet előtt lefutnak. Ha egy fájl meghaladja a beállított sor-küszöböt (alapértelmezetten 350 sor), a horgony blokkolja a közvetlen olvasást, és átirányítja Claude-ot a „bulk-reader” képesség használatára.

A második rétegben bash szkriptek futnak, amelyek a Portal CLI hívásait kezelik. Claude egy szkriptet hív meg argumentumokkal, a szkript pedig elvégzi a kérés felépítését, a módok meghívását és a tokenhasználat jelentését. A harmadik rétegben pedig két „skill” fájl (markdown fájlok leírással és példákkal) segít Claude-nak megérteni, mikor és hogyan hívja meg a szkripteket.

A tesztek egy Java monorepon egy négy forgatókönyvben történtek. Az eredmények szerint a „bulk-reader” móddal átlagosan mintegy 90%-os megtakarítás érhető el a tokenfogyasztásban. A „code-writer” forgatókönyv esetében a tokenmegtakarítás nehezebben mérhető, mivel a shunt nélkül Claude mind a referenciatartalmat olvassa, mind a kimenetet generálja drága tokenekkel. Az új rendszerrel a kód közvetlenül a lemezre kerül, így Claude soha nem látja a generált kódot.

Fontos megjegyezni, hogy a rendszer nem alkalmas szerkesztésre: a delegált modellek által generált összefoglalók nem tartalmaznak megbízható sor-számokat, így ha Claude szerkesztést igényel az elemzés alapján, továbbra is közvetlenül kell elolvasnia az adott szakaszt. A delegálás tehát az értelmezés során takarít meg tokent, nem a szerkesztési fázisban, és a megoldás a Gemini 2.5 Flash modellt használja.