Sa mga nakaraang linggo, sinadya kong sirain ang sarili kong mga workflow para makita kung paano talaga kikilos ang GLM-4.7 kumpara sa GPT-5 kapag hinagisan mo sila ng mga totoong proyekto, magulong repos, kalahating tapos na specs, at iba pa.

Sa papel, parehong "next-gen", "agentic", "malakas sa coding", at lahat ng karaniwang buzzwords. Sa praktika, nang isagawa ko ang mga side‑by‑side na pagsubok sa pag-aayos ng bug, multi-file na refactors, at mga ahenteng gumagamit ng tools, mas kaunti ang teoretikal na pagkakaiba ng GLM-4.7 at GPT-5 kaysa sa sinasabi ng marketing.

Mabilis na disclaimer bago tayo sumisid: Ang mga detalye ng GPT-5 ay patuloy na umuunlad at ang mga benchmark ng vendor ay, predictably, nagpapaganda. Ang ibinabahagi ko rito ay batay sa sarili kong mga pagsubok noong Disyembre 2025: maliit pero maaring ulitin na mga eksperimento, gamit ang parehong mga prompt, repos, at tools sa parehong modelo. Ituring ito bilang mga tala sa field, hindi ebanghelyo.

Lakbayin natin kung saan talaga nagkakaiba ang GLM-4.7 at GPT-5, lalo na para sa coding, mga ahente, at mga workflow na sensitibo sa gastos.

Bakit Mahalaga ang Paghahambing na Ito

Parehong modelo ay binibigyang-diin ang kakayahan sa pagiging agentic at coding

Ang dahilan kung bakit ako nag-abala sa pag-aral ng malalim tungkol sa GLM-4.7 vs GPT-5 ay simple: pareho silang nagsasabing mas mahusay na mga ahente, mas mahusay na pag-coding, mas mahusay na pangangatwiran.

Sa aking mga pagsusuri, ito ay isinalin sa tatlong kongkretong tanong:

1. Maaari ba nilang patakbuhin ang mga tool nang maayos?

Ikonekta ko ang pareho sa isang maliit na agent framework na may access sa:

• isang shell (restricted sandbox),
• isang file system layer para sa pagbabasa/pagsusulat ng mga file ng proyekto,
• isang test runner.

1. Maaari ba talaga silang maghatid ng gumaganang mga pagbabago sa code?

Gumamit ako ng:

• isang pinaikling set ng ~40 na isyu sa estilo ng SWE-bench mula sa mga tunay na open-source na proyekto ng Python,
• ilang mga gawain sa TypeScript/Next.js mula sa aking sariling kliyente.

1. Mananatili ba sila sa budget?

Dahil ang isang "matalinong" ahente na tahimik na gumagastos ng $50 sa isang pag-aayos ng bug ay hindi matalino.

Ang parehong GLM-4.7 at GPT-5 ay malinaw na na-optimize para sa mga sitwasyong ito, ngunit magkaiba ang mga trade-off:

• Ang GPT-5 ay tila mas "kumpiyansang tama" sa mga gawain na mabigat sa Ingles at pangangatwirang estilo ng produkto.
• Ang GLM-4.7 ay higit pa sa kanyang presyo sa raw na pag-coding at paggamit ng tool, lalo na kapag inudyukan ko ito ng mas istrukturadong mga prompt.

Tunay na epekto sa mga desisyon sa pagpili ng modelo

Hindi ito isang teoretikal na pagharap ng GLM-4.7 vs GPT-5. Ang pagpili ay tumatagos sa lahat:

• Kung nagpapatakbo ka ng mga ahente 24/7, ang presyo ng modelo at kahusayan sa pagtawag ng tool ay pangunahing nagtatakda kung ang iyong ideya ay praktikal.
• Kung nagtatrabaho ka sa malalaking repo, ang konteksto ng window at haba ng output ay nagdedesisyon kung ang modelo ay mas maraming oras na naglalagom kaysa sa aktwal na pagko-code.
• Kung nagdadala ka ng mga produkto para sa tunay na mga gumagamit, ang katatagan at ekosistema sa paligid ng GPT-5 ay maaaring mas mahalaga kaysa sa simpleng pagyayabang ng benchmark.

Naipasok ko na ang "AI dev assistant" ng isang kliyente mula sa isang GPT‑only stack patungo sa hybrid: GPT-5 para sa pagbuo ng spec at kopya na nakaharap sa gumagamit, GLM-4.7 para sa mga gawaing coding sa background kung saan nangingibabaw ang gastos at throughput. Ang paghahating iyon ay hindi maiisip isang taon na ang nakalipas: ngayon ay may katuturan lang.

Benchmark Face-Off

Hindi ko ipagpapanggap na naulit ko ang buong akademikong benchmarks, ngunit nagpatakbo ako ng payak na bersyon ng bawat isa.

SWE-bench Napatunayan

Sa isang maliit, napatunayang set ng pag-aayos ng bug (30 Python na isyu, bawat isa may mga pagsusulit):

• GPT-5: nalutas ang 21/30 (70%) nang walang manu-manong interbensyon.
• GLM-4.7: nalutas ang 19/30 (63%).

Nang pinayagan ko ang ikalawang pagsubok na may feedback ("ang mga pagsusulit ay patuloy na nabibigo, narito ang log"), ang agwat ay lumapit:

• GPT-5: 25/30 (83%)
• GLM-4.7: 23/30 (77%)

Ang mas mahalaga kaysa sa simpleng porsyento ay kung paano sila nabigo:

• Ang pagkabigo ng GPT-5 ay karaniwang isang nawawalang edge case.
• Minsan ang GLM-4.7 ay mali ang pag-unawa sa orihinal na paglalarawan ng isyu, ngunit kapag ginabayan ng mas malinaw na mga hakbang, nakakabawi ito nang nakakagulat na maayos.

SWE-bench Multilingual

Nag-hack ako ng isang pseudo multilingual SWE-bench sa pamamagitan ng:

• panatilihin ang code sa English,
• ngunit pagsulat ng mga ulat ng bug at komento sa halo ng Chinese + English.

Narito ang GLM-4.7 vs GPT-5 na resulta:

• GLM-4.7: 18/25 (72%) sa unang pasada.
• GPT-5: 14/25 (56%).

Mas mahusay na humawak ang GLM-4.7 ng mga paglalarawan ng bug sa Chinese at hindi nalilito sa mga halo ng wika sa mga komento sa docstrings. Kadalasan, nalulutas ng GPT-5 ang isyu kapag ganap kong inulit ang ulat sa Ingles, ngunit iyon ay dagdag na hadlang na ayaw mo sa malakihan.

Terminal Bench 2.0

Para sa mga gawain sa istilo ng terminal (mag-install ng deps, magpatakbo ng mga pagsubok, mag-inspeksyon ng mga log, mga menor na pag-edit ng file), ikinonekta ko ang parehong mga modelo sa iisang sandbox.

Sinukat ko ang batch success rate sa 40 na gawain:

• GPT-5: 34/40 (85%)
• GLM-4.7: 33/40 (82.5%)

Ang pangunahing pagkakaiba:

• Mas kaunting mga tawag sa tool ang ginamit ng GPT-5 sa karaniwan (mga 3.1 bawat gawain).
• Humigit-kumulang 3.8 tawag sa tool bawat gawain ang GLM-4.7.

Hindi naman mapaminsala, ngunit kung ang iyong ahente ay nagbabayad bawat tawag, mararamdaman mo ito.

HLE with Tools

Para sa mataas na antas na pagsusuri (HLE) gamit ang mga panlabas na tool, sinubukan ko ang isang mini "analyst" workflow:

1. Maghanap ng mga dokumento (gamit ang isang tool sa paghahanap sa web).
2. Basahin ang isang pahina.
3. Tumawag sa isang calculator o maliit na Python sandbox.
4. Bumuo ng pangwakas na rekomendasyon.

Dito nagsimulang magpakitang-gilas ang GPT-5:

• Mas mahusay ang GPT-5 sa pagpaplano: inaasahan nito kung anong mga tool ang kakailanganin nito 2–3 hakbang pauna.
• Paminsan-minsan ay labis na ginagamit ng GLM-4.7 ang tool sa paghahanap sa web at nagre-fetch ng mga katulad na pahina.

Sa kabuuan, sa maliit na pagsusulit na ito na HLE-with-tools:

• Ang GPT-5 ay nagbigay ng mga sagot na maituturing kong handa para sa produksyon sa ~88% ng oras.
• Ang GLM-4.7 ay parang handa para sa produksyon sa ~78% ng oras, na nangangailangan ng kaunting pag-aayos ng tao sa natitira.

Kung ang pangunahing gamit mo ay coding + tools, parehong solid ang dalawa. Kung ang gamit mo ay strategic analysis na may tools, ang GPT-5 ay mas malinis pa rin sa aking karanasan.

Paghahambing ng Presyo

Para sa mga indie builders, ang presyo ay kung saan ang GLM-4.7 vs GPT-5 ay maaring tahimik na magpasya ng iyong buwan.

Gastos ng API (input, output, naka-cache na tokens)

Hindi pa pampubliko ang eksaktong presyo ng GPT-5, ngunit kung susundan nito ang mga pattern ng GPT-4.1/o3, inaasahan natin ang:

• Mas mataas na presyo bawat 1M tokens kumpara sa mga rehiyonal na modelong Tsino
• Posibleng mga diskwento sa naka-cache na tokens at muling ginagamit na konteksto

Sa kabilang banda, ang GLM-4.7 ay agresibong nakaposisyon sa gastos, lalo na sa mga rehiyong Tsino, at madalas na 30–60% mas mura bawat token kaysa sa mga modelong frontier ng OpenAI, depende sa iyong rehiyon at provider.

Para sa isang tipikal na coding session (200K input context, 20–40K output tokens sa mga hakbang), nakita ko ang mga run kung saan:

• Ang gastos ng GLM-4.7 ay ≈ $0.40–$0.60
• Ang gastos ng GPT-4.1/o3 ay ≈ $0.90–$1.40 para sa katulad na performance

Kung ang GPT-5 ay mananatili sa mas mataas na banda o mas mataas pa, ang GLM-4.7 ay may malakas na edge sa "halaga bawat natapos na gawain".

Kabuuang gastos para sa mga tipikal na workflow ng ahente

Sinubaybayan ko rin ang gastos bawat matagumpay na gawain, hindi lang bawat token.

Para sa aking 30 task SWE-style benchmark:

• GLM-4.7: humigit-kumulang $0.80 bawat matagumpay na pag-aayos
• GPT-style (GPT-4.1/o3-stand in para sa GPT-5): nasa $1.30 bawat matagumpay na pag-aayos

Kaya kahit mas maraming naresolbang gawain ang mga GPT-style na modelo, GLM pa rin ang nanalo sa dolyar bawat gumaganang PR.

Kung nagpapatakbo ka ng:

• Mga continuous code review agent
• Awtomatikong bug triage
• Nightly refactor passes

Mabilis na nag-iipon ang mga cost-per-fix na pagkakaiba.

Pagpipilian sa Self-hosting (GLM-4.7 lamang)

Ang wild card ay ang self-hosting. Maaaring i-deploy ang GLM-4.7 sa iyong sariling GPUs o pribadong cloud.

Nagbubukas ito ng mga sitwasyon kung saan:

• Magbabayad ka ng nakapirming singil sa infra sa halip na hindi mahulaan na API spikes
• Legal/seguridad na mga pangangailangan na hindi dapat mahawakan ng code ang isang US o third-party vendor
• Gusto mong patakbuhin ang maraming mas maliliit na agent na sabay-sabay nang walang per-call markup

Siyempre, hindi ito libre. Ipinagpapalit mo ang:

• Kumplikadong operasyon (pagsubaybay, pag-scale, mga upgrade)
• Paunang gastos sa infra

…ngunit kapag umabot na ang iyong paggamit sa isang tiyak na linya (para sa akin ito ay nasa humigit-kumulang 15–20M tokens/araw na tuloy-tuloy), ang GLM-4.7 na self-hosted ay nagsisimulang mukhang napaka-kaakit-akit kumpara sa isang purong GPT-5 API na estratehiya.

Mga Pagkakaibang Arkitektura na Mahalaga

Context window (200K vs ?)

Para sa GLM-4.7, palagi akong nakakuha ng ~200K token context na magagamit. Sapat na ito para sa:

• isang medium-sized na bahagi ng repo,
• kasama ang ilang bukas na isyu,
• kasama ang ilang mga log at tagubilin.

Ang eksaktong mga limitasyon ng konteksto ng GPT-5 ay nakadepende sa tier/bersyon, at patuloy itong inaayos ng vendor. Sa praktika, itinuring ko ito na parang modelo ng klase na 128K–200K, at halos hindi ko kailanman nararanasan ang mahigpit na limitasyon ng konteksto sa araw-araw na mga gawain sa pag-coding.

Hindi ang hilaw na numero ang mahalaga, kundi kung paano nila ito ginamit:

• Madalas na mas mahusay ang implicit summarization ng GPT-5, nananatiling nakatuon kahit na sobra kong binibigyan ng konteksto.
• Minsan ay "nakakalimutan" ng GLM-4.7 ang mga naunang detalye sa napakahabang mga prompt maliban kung malinaw kong inayos ang mga seksyon (hal., # Spec, # Code, # Tests).

Haba ng output (128K vs ?)

Kalma lang na gumagawa ng napakahabang output ang GLM-4.7 kapag hiniling ko ang buong patches o test suites, na libo-libong mga token nang hindi nabibitin.

Kaya rin ng GPT-5 ang malalaking output, ngunit napansin ko na mas malamang na ito ay huminto nang maaga at magsabi ng "sabihin mo kung gusto mo ang iba pa," lalo na sa mga chat-like na UI.

Para sa malalaking pagkakaiba:

• Mas komportable ang GLM-4.7 na maglabas ng malalaking bahagi ng code sa isang bagsakan.
• Pinapaboran ng GPT-5 ang mas iterative, conversational na estilo ("Narito ang bahaging 1… ngayon bahaging 2…"), na mas maginhawa para sa mga tao ngunit medyo nakakainis para sa mga automated pipelines.

Mode ng pag-iisip at kalaliman ng pangangatwiran

Ang parehong modelo ay nagmemerkado ng ilang uri ng "mas malalim na pag-iisip" o reasoning mode.

Sa aking mga pagsusuri:

• Ang pagsasaaktibo ng reasoning mode para sa GPT-5 (kung saan magagamit) ay nagpaunlad ng tagumpay sa pag-aayos ng komplikadong bug ng mga ~10–15 puntos na porsyento, ngunit ito rin ay:
  • nagdagdag ng latency ng ~1.5–2×,
  • at nagtaas ng paggamit ng token sa parehong paraan.
• Ang "mabagal / malalim" na estilo ng prompting ng GLM-4.7 (na hayagang sinasabing mag-isip ito ng hakbang-hakbang, suriin ang mga hypothesis, at muling basahin ang code) ay nakatulong din, ngunit mas maliit ang mga natamo: marahil 5–8 puntos na porsyento ang pag-unlad sa pinakamahirap na gawain.

Kung mahalaga sa iyo ang maximum reasoning para sa mga desisyon sa produkto o multi-step na pagpaplano, ang top tier ng GPT-5 ay tila nauuna pa rin. Kung mahalaga sa iyo ang sapat na reasoning sa makatwirang gastos, kayang makipagsabayan ang GLM-4.7.

Pagganap sa Coding sa Totoong Mundo

Dito nagiging kongkreto ang paghahambing ng GLM-4.7 laban sa GPT-5 para sa coding.

Multi-file refactoring

Parehong modelo ay binigyan ko ng parehong senaryo:

• Isang maliit na TypeScript monorepo (~60 na file).
• Layunin: kunin ang isang shared analytics helper at alisin ang dobleng lohika sa 4 na serbisyo.

Mga Resulta:

• GPT-5:
  • Tamang natukoy ang lahat ng 4 na target na lugar.
  • Nagmungkahi ng napakalinaw na disenyo ng API.
  • Ngunit ang kanyang patch ay nakaligtaan ng 2 import at isang banayad na hindi pagtutugma ng uri.
• GLM-4.7:
  • Natagpuan ang 3/4 na lugar ng pagdodoble ng sarili.
  • Kinailangan ng kaunting tulak para mahuli ang huli.
  • Naglabas ng mga patch na mas madalas na nagko-compile sa unang subok.

Oras para sa "green tests" pagkatapos ng 2–3 pabalik-balik na pag-uulit:

• GPT-5: ~22 minuto sa karaniwan (kasama ang pag-install + mga pagsusulit).
• GLM-4.7: ~24 minuto.

Sa totoo lang? Tabla lang 'yan. Pareho silang magagamit bilang refactor copilots. Ang GPT-5 ay parang isang senior dev na may mahusay na panlasa sa disenyo, habang ang GLM-4.7 ay parang isang mabilis at maingat na mid-level na laging nagdodoble-check ng mga uri.

Mga loop sa pag-aayos ng bug

Sa mas maliit na mga task sa bug na istilong SWE, pinanood ko kung paano kumilos ang bawat modelo sa mga paulit-ulit na pagtatangka:

1. Magmungkahi ng ayos.
2. Magpatakbo ng mga pagsusulit.
3. Basahin ang mga log ng pagkabigo.
4. Subukang muli.

Mga pattern na nakita ko:

• GPT-5:
  • Mas mahusay sa pag-interpret ng mahahabang Python tracebacks.
  • Hindi gaanong malamang na ulitin ang parehong maling patch.
  • Karaniwang nagko-converge sa loob ng 2–3 loop.
• GLM-4.7:
  • Minsan naii-stuck sa parehong maling hypothesis.
  • Pero kapag sinabi ko na, "Ipagpalagay na mali ang iyong nakaraang ideya, magmungkahi ng ibang diskarte," bigla itong nagising.
  • Nangangailangan ng 3–4 loop sa karaniwan para sa pinakamahirap na mga bug.

Kalidad ng pagbuo ng pagsusulit

Inutusan ko rin ang parehong gumawa ng mga pagsusulit bago ayusin ang isang bug (isang nakakagulat na makapangyarihang trick):

• Para sa Python + pytest:
  • Nagprodyus ang GPT-5 ng mas nakalarawang mga pagsusulit at mas mahusay na mga parametrized na kaso.
  • Ang GLM-4.7 ay nagprodyus ng bahagyang mas simpleng mga pagsusulit pero mas kaunti ang mga pagkakamali sa syntax.
• Para sa TypeScript + Jest:
  • Pareho silang maayos, pero mas mahusay ang GPT-5 sa pagsunod sa aktwal na mga kumbensyon ng proyekto (pagpangalan, istruktura ng folder) kapag binigyan ko ito ng ilang halimbawa.

Kung ang pangunahing kaso ng paggamit mo ay GLM-4.7 kumpara sa GPT-5 para sa coding agents, ganito ko ito isasalarawan:

• GPT-5: mas mataas ang kapasidad, bahagyang mas mahusay sa pagpaplano, mas kaunti ang "dumb repeat" loops.
• GLM-4.7: mahusay na cost-to-output ratio, malakas kapag binigyan mo ito ng structured prompts at kaunting guard-rail logic.

Kailan Pipiliin ang GLM-4.7

Mga kaso ng paggamit na sensitibo sa gastos

Kung ikaw ay isang indie dev, maliit na ahensya, o nagpapatakbo ng side project, kadalasang bumababa sa isang marahas na sukatan ang GLM-4.7 kumpara sa GPT-5: dolyar bawat nalutas na gawain.

Mula sa aking mga tala:

• Para sa coding agents, madalas na umabot sa 40–60% ng gastos ng GPT-5 ang GLM-4.7 para sa humigit-kumulang 80–90% ng kalidad.

Ang palitan na ito ay sulit para sa:

• maintenance ng background code,
• malawakang refactors,
• pagpapagawa ng dokumentasyon,
• paggawa ng batch test.

Pangangailangan para sa self-hosting

Kung ang iyong koponan o mga kliyente ay:

• hindi maaaring magpadala ng code sa third-party clouds, o
• nais na patakbuhin ang lahat sa pribadong infra,

ang self-hosting na kwento ng GLM-4.7 ang mapagpasyang salik.

Mas masakit bang patakbuhin ito? Oo. Nakikitungo ka sa GPUs, inference servers, monitoring, at scaling. Ngunit kung ang dami ng iyong token ay sapat na mataas at ang seguridad/pribasiya ay hindi mapagkompromiso, ito ay isang napaka-rasyonal na pagpipilian.

Mga codebase na puno ng Chinese

Kung ang iyong codebase:

• may mga komento, pangalan ng variable, o mga mensahe ng commit sa Tsino, o
• ang iyong team ay nag-uulat ng mga isyu sa Chinese muna, English pangalawa,

GLM-4.7 ngayon ay may tunay na kalamangan.

Sa aking halo-halong Chinese–English na mga pagsusuri sa repo:

• Naiintindihan nito ang mga ulat ng bug na may Chinese stack traces at mga mensahe ng log halos parang katutubo.
• Nahabol ng GPT-5 kapag isinalin ko na lahat, pero dagdag na trabaho iyon.

Kaya kung ikaw ay nag-o-operate sa isang Chinese‑una o bilingual na kapaligiran, ang GLM-4.7 ay mas natural na umaangkop sa araw-araw na buhay ng dev.

Kailan Pumili ng GPT-5

Mature na ekosistema

Ang pangunahing hindi teknikal na argumento sa GLM-4.7 vs GPT-5 ay ekosistema.

Ang GPT-5 ay kasalukuyang panalo sa:

• lalim ng mga third‑party na integrasyon,
• mga tool at ahente na handa na para sa kanyang API,
• mga halimbawa mula sa komunidad, dokumentasyon, at mga tip sa pag-debug.

Kung ikaw ay gumagawa ng isang bagay na kailangan isaksak sa maraming SaaS tools, plugin, o no‑code platforms, ang GPT-5 ang pinakamadaling landas.

English-first na mga workflow

Para sa English‑una:

• mga produkto specs,
• UX na kopya,
• mga dokumento ng estratehiya,
• mga kumplikadong gawain sa pangangatwiran,

Ang GPT-5 ay talagang mas makinis.

Sa aking mga pagsusuri, ang kanyang:

• pagsulat ng mga spec,
• pagsusuri ng tradeoff,
• at kalidad ng paliwanag

ay palaging mas "handa na para sa kliyente" kahit walang edits. Kaya rin ng GLM-4.7 ito, ngunit mas madalas kong na-e-edit ang tono at istruktura.

Mga kinakailangan para sa maximum na katatagan

Kung ang iyong mga prayoridad ay:

• ultra-predictable na latency,
• napakababang tolerance sa hallucination sa pangkalahatang kaalaman,
• at malalakas na vendor SLAs,

Ang GPT-5 ang mas ligtas na pagpipilian sa ngayon.

Sa mga long-running na ahente kung saan ang isang kakaibang hallucination ay maaaring magdulot ng totoong pinsala (tulad ng maling pag-configure ng infrastructure), ang mga guardrails at monitoring stack ng GPT-5 ay mas matured. Maganda ang performance ng GLM-4.7 sa aking mga pagsusuri, ngunit ang nakapalibot na ecosystem (evals, guardrails, off-the-shelf na tools) ay hindi pa gaanong nasusubukan sa laban.

Ang Mas Malawak na Larawan: Nagiging Pangkaraniwan na ang Mga Modelo

Kapag tiningnan sa mas malawak na perspektiba, ang pinaka-kapansin-pansin sa GLM-4.7 vs GPT-5 ay hindi kung sino ang "panalo". Ito ay na, para sa maraming pang-araw-araw na gawain, pareho silang sapat.

Ang talagang mahalaga ngayon ay:

• Presyo kada solusyon sa problema (hindi kada token).
• Ecosystem at pandikit sa paligid ng modelo, tools, pag-log, retries, pattern ng prompt.
• Angkop para sa iyong wika + domain (English-first na SaaS vs bilingual na codebase vs internal na tools).

Ang aking praktikal na konklusyon matapos ang lahat ng mga pagsubok na ito:

• Gamitin ang GPT-5 kapag kailangan mo ng pinakamataas na kalidad ng pag-rereason, makinis na output sa Ingles, at mayamang suporta ng ecosystem.
• Gamitin ang GLM-4.7 kapag mas mahalaga sa iyo ang throughput at gastos, o kailangan mo ng self-hosting at mas mahusay na performance sa Chinese.

At sa totoo lang? Huwag kang matakot na pagsamahin sila.

Sa aking sariling stack ngayon:

• Mga specs, desisyon ng produkto, at mga pagsulat para sa kliyente → GPT-5.
• Bulk coding na ahente, pagbuo ng mga pagsubok, at mga gawain sa internal na maintenance → GLM-4.7.

Kung nagsisimula ka pa lang, ito ang aking mungkahi:

1. Pumili ng isang kinatawang workflow, halimbawa, "ayusin ang isang hindi gumaganang test sa aking repo gamit ang isang agent."
2. Patakbuhin ito 10 beses gamit ang GLM-4.7 at 10 beses gamit ang GPT-5 gamit ang parehong mga prompt at tool.
3. Subaybayan: tagumpay na rate, kabuuang token, gastos, at kung gaano kaasar ang pakiramdam mo habang binabasa ang mga output.

Ang maliit na eksperimento na ito ay magbibigay sa iyo ng higit pang impormasyon tungkol sa GLM-4.7 kumpara sa GPT-5 para sa iyong buhay kaysa sa anumang pahina ng marketing, o anumang blog post, kasama na ang isang ito.

Pagkatapos panatilihin ang isa na talagang nagdadala ng trabaho para sa iyo, hindi ang may mas magarang benchmark chart.

Ang pinakamahusay na modelo para sa iyo ay nakadepende sa iyong workflow, hindi sa leaderboard.

Matapos ang lahat ng mga pagsubok na ito, ang hindi komportableng katotohanan ay ito: para sa karamihan ng mga personal at indie na workflow, ang mismong modelo ay mas kaunti ang halaga kaysa sa disenyo ng agent na nakabalot dito.

Iyan mismo ang aming binubuo sa Macaron. Hindi kami tumataya sa isang solong “pinakamahusay” na modelo. Pinagsasama namin ang pinakamalalakas na available na modelo sa isang memory system na talagang natututo kung paano ka magtrabaho — kung ano ang mahalaga sa iyo, paano ka nag-iterate, at kung saan karaniwang nagkakaroon ng problema.

Kung ikaw ay curious kung ano ang pakiramdam nito sa praktikal, maaari mong subukan ito mismo. [Subukan ang Macaron nang libre →]