Asana: 76x mas mababang gastos sa modelo gamit ang GPT‑6.1 Sol
Sa mga test gamit ang GPT‑6 Astra sa Codex, naging 76x mas mura at 5x mas mabilis ang browser agent ng Asana para mag-alok ng mas mahusay na mga modelo sa mga customer.
76x
Mas mababang tinatayang gastos sa modelo gamit ang optimized na workflow sa GPT-6.1 Sol
5x
Mas mabilis na mga pagpapatakbo sa browser gamit ang optimized na workflow sa GPT-6.1 Sol
$0.47
Average na tinatayang gastos sa modelo gamit ang optimized na workflow sa GPT-6.1 Sol
Sa tulong ng mga eksperimento ng GPT‑6 Astra sa Codex, na-optimize ng Asana ang workflow ng browser agent nito sa GPT‑6.1 Sol para maging 76x mas mura at 5x mas mabilis itong patakbuhin.
Tinutulungan ng Asana ang mga customer na i-automate ang trabaho sa iba't ibang business application sa pamamagitan ng StackAI(magbubukas sa bagong window), isang platform na binili(magbubukas sa bagong window) nito. Gamit ang StackAI, makakabuo ang mga customer ng mga workflow na nagna-navigate sa mga website, nagpupuno ng mga form, at nangangalap ng impormasyon nang hindi nagsusulat ng code. Sa laki ng operasyon ng Asana, naiipon ang maliliit na pag-aaksaya ng oras at resources sa mga workflow na ito.
Layunin ng StackAI CTO ng Asana na si Frank Hidalgo, PhD, na gawing mas mabilis at mas murang patakbuhin ang browser agent. Inatasan niya ang GPT‑6 Astra sa Codex na suriin ang agent, subukan ang mga pagpapahusay, at ihambing ang mga resulta. Ang trabahong tinataya niyang aabot ng isa hanggang dalawang buwan kung mano-mano ay natapos sa halos isang linggo.
Sa pag-aaral ng Asana na may 144 na pagpapatakbo(magbubukas sa bagong window), sinubukan ang GPT‑6.1 Sol at tatlong iba pang frontier na modelo, na tinatawag ditong Modelo A, B, at C. Ang nabuong optimized na workflow sa GPT‑6.1 Sol ay may average na tinatayang gastos sa modelo na $0.47 at tagal na halos apat na minuto bawat pagpapatakbo—76x mas mura at 5x mas mabilis kaysa sa orihinal na production setup sa Modelo B.
“Ganito talaga nagtutulungan ang mga tao at agent bilang isang team. Isang engineer ang nagtakda ng direksyon, GPT-6 Astra ang nagsagawa ng mga eksperimento, at dumaan sa Command ang mga resulta bago inilapat sa production. Ipinapakita nito kung paano isinasakatuparan ng Asana ang pagtutulungan ng mga tao at agent sa mga team.”
Para mapabilis ang trabaho, ginamit muna ni Hidalgo ang GPT‑6 Astra sa Codex para suriin ang istruktura ng codebase at ipaliwanag kung paano binubuo ng agent ang bawat request sa modelo. Natuklasan ng GPT‑6 Astra na kina-cache ng agent ang mga nakapirming tagubilin at tool definition nito, pero hindi ang lumalaking history ng nakalap na teksto at screenshot ng mga pahina. Kaya sa bawat request, muling ipinapadala ang history na iyon sa buong presyo.
Inaalis din ng agent ang mas lumang mga screenshot at binabawasan ang teksto sa halos bawat hakbang. Nababago ang history sa bawat edit, kaya hindi sapat na i-cache lang ito. Dahil din sa nawawalang impormasyon, maaaring kailangang balikan ng agent ang mga pahinang nabasa na nito.
Sinuri ni Hidalgo ang mga pag-aayos na iminungkahi ng GPT‑6 Astra at pumili ng tatlong susubukan:
Pagsama sa browsing history ng agent sa caching
Pagdaragdag sa dami ng tekstong maaari nitong panatilihin
Pag-aalis ng mga screenshot nang pangkatan sa halip na sa bawat hakbang
Nagsimula ang GPT‑6 Astra sa mabibilis na test para matukoy kung aling mga variable ang mahalaga. Dahil hindi idinisenyo ang code para sa mga kontroladong eksperimento, inayos nito ang istruktura ng code para masuportahan ng iisang frontend at backend ang maraming sabay-sabay na workflow, bawat isa ay may sariling settings.
Isinagawa ng Astra ang buong pag-aaral: mga limitasyon sa history na 120,000 at 480,000 character at anim na patakaran sa caching at screenshot, bawat isa ay sinubukan nang tatlong beses sa bawat isa sa apat na modelo (tingnan ang talahanayan sa ibaba). Sa pinakamabisang patakaran, hinahayaang umabot sa 20 ang mga screenshot bago alisin ang lahat maliban sa pinakabago. Dahil dito, mas matagal na nananatiling hindi nababago ang naunang history sa pagitan ng mga pag-aalis. Nang ipares ito sa mas malaking kapasidad para sa history, nabuo ang optimized na workflow. Pareho ang gawain ng bawat configuration: pangangalap ng anim na field para sa bawat isa sa 32 aklat mula sa isang pampublikong demo catalog, na kumakatawan sa mga gawaing pinapatakbo ng ilang customer ng Asana sa StackAI.
Modelo | Paglalarawan | Presyo |
|---|---|---|
Modelo A | Mas maliit at mas murang modelo mula sa ibang frontier lab, inilabas noong taglagas ng 2025 | Kalahati ng presyo ng GPT‑6.1 Sol |
Modelo B | Ang modelong unang ginamit sa production, mula sa lab na gumawa rin ng Modelo A, inilabas noong tag-init ng 2026 | Kapresyo ng GPT‑6.1 Sol |
Modelo C | Na-update na bersyon ng Modelo B, inilabas noong taglagas ng 2026 | Kapresyo ng GPT‑6.1 Sol |
GPT‑6.1 Sol | Modelo ng OpenAI |
Pinatakbo ng GPT‑6 Astra ang mga workflow at sinuri ang mga request, tala ng paggamit, at output. Sinuri naman ng magkakahiwalay na session ng modelo ang trabaho. Itinala ang mga request, data trace, at resulta ng bawat session sa Command(magbubukas sa bagong window), ang software delivery platform ng Asana, para masuri ng team ang buong pag-aaral pagkatapos. Mula sa Command, ginawang mga ticket ang mga natuklasan, saka mga pull request, at inilapat sa production ang mga pagbabago.
“Aabutin ako ng isa hanggang dalawang buwan kung mano-mano ko itong gagawin. Gamit ang GPT-6 Astra sa Codex, halos isang linggo lang ang inabot: nagtatakda ako ng /goal bago matulog at sinusuri ang mga resulta sa umaga.”
Para sa Modelo B, napababa ng optimization ang tinatayang gastos sa modelo mula sa hindi bababa sa $36.21 (naabot ng ilang orihinal na pagpapatakbo ang limitasyon sa hakbang bago matapos) tungo sa $1.24 bawat pagpapatakbo—29x na pagbaba. Mas mura pa nang 2.6x ang optimized na workflow sa GPT‑6.1 Sol, sa halagang $0.47. Sa bawat pagpapatakbo ng optimized na workflow, natapos ang gawain at naibalik ang tamang sagot.
Mga average ng 3 pagpapatakbo. ≥: kasama sa baseline ang mga pagpapatakbong umabot sa limitasyon, kaya ang average nito ay ang pinakamababang posibleng halaga.
Ang dalawang multiplier sa kanan ay paghahambing sa na-optimize na Modelo B. Pinatakbo ang Modelo B sa yugto 1, at ang Modelo C at Sol 6.1 sa yugto 2 ng parehong pag-aaral (tuldok-tuldok na linya).
Sa GPT‑6.1 Sol pa lang, gamit ang mas malaking kapasidad para sa history, napababa ng bagong patakaran sa caching at screenshot ang gastos nang 4x, mula $1.97 tungo sa $0.47 bawat pagpapatakbo. Naging halos 3x mas mura ang bawat call dahil 89% ng input ay mula sa cache, sa halagang 5% lang ng presyo ng hindi naka-cache. Bumilis din ang mga pagpapatakbo: mula sa hindi bababa sa 22.5 minuto sa orihinal na setup sa Modelo B tungo sa halos apat na minuto sa optimized na workflow sa GPT‑6.1 Sol.
Average ng 3 pagpapatakbo, may mga whisker para sa SD. ≥: kasama sa average ang isang pagpapatakbong umabot sa limitasyon o hindi natapos, kaya ang tunay na halaga ay hindi bababa rito.
Asul ang tema ng mga bar. Ihambing ang mga epekto ng caching sa bar na may mas malaking kapasidad na 480k.
Ang mga marker ng pagpapatakbo at whisker ng SD ay tinatayang muling pagbuo mula sa pinagmulang larawan; hindi available ang orihinal na mga halaga ng pagpapatakbo at standard deviation.
Average ng 3 pagpapatakbo, may mga whisker para sa SD. ≥: kasama sa average ang isang pagpapatakbong umabot sa limitasyon o hindi natapos, kaya ang tunay na halaga ay hindi bababa rito.
Asul ang tema ng mga bar. Ihambing ang mga epekto ng caching sa bar na may mas malaking kapasidad na 480k.
Ang mga marker ng pagpapatakbo at whisker ng SD ay tinatayang muling pagbuo mula sa pinagmulang larawan; hindi available ang orihinal na mga halaga ng pagpapatakbo at standard deviation.
Ipinakita rin ng pagsusuri kung paano nakaaapekto ang pamamahala ng history sa kakayahan ng agent na makapagbigay ng sagot. Nang dagdagan ang kapasidad ng GPT‑6.1 Sol na panatilihin ang browsing history nito, dumami ang mga pagpapatakbong nakapagbigay ng sagot: mula tatlo sa 18 gamit ang mas maliit na kapasidad tungo sa lahat ng 18 gamit ang mas malaking kapasidad, at tama ang bawat sagot. Para kay Hidalgo, ang pakinabang nito sa negosyo ay ang pagbibigay sa mga customer ng mas mabilis at mas mahusay na mga modelo habang pinananatiling abot-kaya ang mga gastos sa operasyon.
“Dati, nililimitahan ng gastos kung aling mga modelo ang maiaalok namin sa mga customer para sa ganitong mga workload. Sa mas episyenteng agent, maibibigay namin sa mga customer ang mas mahusay at mas mabilis na modelo habang pinabababa ang aming gastos sa operasyon.”
Inilabas na ng Asana ang mga pagbabago sa browser navigation sa StackAI at gumagawa ito ng mga tool para mas madaling ulitin ang mga katulad na eksperimento. Sa hinaharap, plano ng team na isama ang pagsubok na ito sa mga pagsusuri ng platform para maihambing ng mga customer at internal team ang gastos, tagal ng pagpapatakbo, at kalidad ng sagot habang kino-configure ang kanilang mga agent.
“Hindi na ang bilis ng paglalabas ng software ang sagabal, kundi ang atensyon ng tao. Malapit na tayo sa panahong bawat engineer ay isang PM na namumuno sa isang pangkat ng mga agent.”
Ginagamit na ngayon ng Asana ang GPT‑6 Astra sa Codex para subukan ang mga feature ng produkto bago ilabas: nagna-navigate ang Astra sa platform, sumusubok ng iba't ibang input, at nag-uulat ng mga bug para sa mga taong nagsasagawa ng QA review. Para kay Hidalgo, pundasyon ito ng isang bagong software development lifecycle, kung saan maraming cloud agent session ang sabay-sabay na sumusubok ng mga feature.
Available ang buong pag-aaral sa mga blog ng Asana(magbubukas sa bagong window) at StackAI(magbubukas sa bagong window).
