arrow_back Semua catatan
20 Ogos 2026 · 7 minit bacaan ·

Cara Membuat Langganan Grok Anda Lebih Tahan Lama: Apa yang Kami Ukur Sebenarnya

Yang membakar had penggunaan Grok Build bukan prompt yang anda taip — sebaliknya fail yang ejen baca sendiri. Kami ukur berapa tepat data yang mengalir dalam satu sesi, dan ubah cara meshcode menjalankan Grok berdasarkan penemuan kami.

Apabila Grok Build berhenti dengan mesej had dicapai, kebanyakan orang menyangka mereka bertanya terlalu banyak. Tetapi apabila anda mengukur berapa tepat aliran bait dalam sesi, gambarnya berbeza. Kebanyakan yang membakar had bukan prompt anda — sebaliknya apa yang ejen baca sendiri.

Kami tidak membiarkannya sebagai tekaan — kami ukurnya, dan ubah cara meshcode menjalankan Grok berdasarkan penemuan kami. Tulisan ini ialah catatan tentang apa yang kami ukur, apa yang kami ubah, dan tepat di mana hasilnya benar — serta di mana hasilnya tidak lagi benar.

Corong gangsa di atas meja menangkap kaskade zarah biru berkilau dan mengecilkannya menjadi aliran nipis mengalir ke komputer riba yang memaparkan kod
Prinsipnya mudah: sempitkan kaskade aliran masuk yang lebar supaya hanya yang diperlukan sampai ke sesi.

30.4MB yang Ditarik Satu Sesi

Pada 19 Ogos 2026, kami instrumentasikan keseluruhan korpus masuk untuk satu sesi Grok. Jumlahnya mencecah 30.4MB. Dipecah mengikut kategori, pesalahnya jelas.

Korpus masuk sesi Grok — jumlah 30.4MB (2026-08-19)read_file11.9MB · n=3,528search_tool2.75MB · peak 39KBAliran lainoutput shell, skema tool, sejarah sembang, dll.Dalam item terbesar, read_file 11.9MB:· Panggilan normal: had mandiri 20–80 baris — tiada masalah· 290 panggilan tanpa limit = jumlah 1.83MB (fail penuh)· Panggilan ekor >10KB = 1.32MB→ Ekor yang membakar bajet, bukan purata — had hanya perlu capai ekor.
Item terbesar ialah read_file. Dan di dalamnya, masalahnya bukan panggilan purata — sebaliknya sejumlah kecil panggilan yang tidak pernah set had dan menarik fail penuh.

Apa yang penting di sini ialah bentuk distribusinya. Kebanyakan masa, Grok membaca 20–80 baris secara mandiri — panggilan-panggilan itu tidak masalah. Yang membakar bajet ialah 290 panggilan yang langsung tidak set had, dan angka itu sahaja mencecah 1.83MB. Setiap satu menarik fail penuh.

Tool carian meta Grok, search_tool, menunjukkan pola yang sama. P90-nya hanya 11KB, tetapi maksimumnya mencecah 39KB dan jumlahnya 2.75MB. Sebaliknya, tool milik meshcode sendiri sudah mehadkan diri — maksimum yang diukur ialah 9.9KB untuk read dan 8KB untuk grep. Tiada yang perlu diperbaiki di situ.

Sambungkan Claude atau Codex yang anda sudah bayar — selebihnya dibuat pekerja yang kosnya cuma sebahagian kecil.

Muat turun meshcode →

Kenapa Satu Ekor Membakar Seluruh Sesi

"1.83MB daripada 30MB hanya 6%" ialah kesimpulan yang mudah untuk dibuat. Ia juga perangkapnya.

Konteks dalam perbualan ejen bertimbun. Jika fail 30KB mendarat penuh di giliran 3 dan sesi berjalan 40 giliran, 30KB itu dikira semula pada setiap 37 giliran yang tinggal. Satu pembacaan tanpa disiplin bukan kos sekali — ia berkembang semakin lama sesi berjalan.

Di sinilah tepatnya had Grok Build paling sensitif. Seperti yang kami liput sebelumnya, had peringkat percuma Grok tidak memberitahu anda masa reset — ia hanya menunjukkan tawaran naik taraf. Semakin kurang anda tahu bila bajet terisi semula, semakin besar kos kebocoran awal.

Jadi matlamat yang kami tetapkan bukan "buat orang guna Grok secara berjimat" — ia jauh lebih spesifik: jangan sentuh panggilan normal, dan potong hanya ekornya.

Empat Had yang meshcode Tetapkan pada Grok

Buka panel Grok dalam meshcode, dan berbeza dengan menjalankan grok tulen, empat mekanisme aktif bersamanya.

Empat had sesi Grok oleh meshcode1. read_file dihadkan 300 barisHook PreToolUse sisip limit=300ke panggilan yang belum setSasaran: 290 panggilan tanpa limit (1.83MB)Tidak sentuh panggilan normal 20–80 baris2. Output MCP dihadkan 12,000BTetapkan GROK_MAX_MCP_OUTPUT_BYTESuntuk proses ini sahajaSasaran: puncak ekor 39KB search_toolTidak sentuh tool kami (9.9KB/8KB)3. Katalog giliran pertama disekatMatikan imbasan default GrokCursor MCP/skills/rules/agents/hooksSasaran: skema tool luar di giliran 1meshcode tak berjalan di Cursor4. Peraturan okestratorSisip peraturan delegasi di awal,ingat semula jika eksplorasi bertimbunSasaran: carian pukal ke child murahChild baca diluar sesi ini
Semua empat direka dengan prinsip yang sama: biarkan penggunaan normal tanpa disentuh, dan potong hanya yang melebihi had.

1. Had 300 baris pada read_file. read_file Grok ialah tool terbina dalam biner Grok itu sendiri, jadi kami tidak boleh ubah outputnya selepas itu. Sebagai ganti, kami sekat panggilan sebelum ia keluar, menyuntik limit=300 hanya ke panggilan yang tidak ada had atau meminta lebih daripada 300. Panggilan normal 20–80 baris tidak pernah hampir nilai ini.

2. Had 12,000 bait pada output tool MCP. Kerana P90 search_tool ialah 11KB, had 12,000 bait memotong ekor 39KB tanpa menyentuh respons normal. Ia hanya berkuat kuasa untuk proses yang meshcode lancarkan — ~/.grok/config.toml anda tidak pernah disentuh.

3. Tiada katalog orang asing di giliran pertama. Grok TUI mengimbas konfigurasi MCP Cursor dan skills/rules secara default. meshcode tidak berjalan di Cursor, jadi kami matikan sebarang katalog Cursor tertinggal yang sebaliknya akan melekat sebagai skema tool pada giliran pertama.

4. Eksplorasi pukal dihantar ke model murah. Penjimatan terbesar bukan daripada had — tetapi daripada struktur. Apabila meshcode menyerahkan kerja "cari di mana ini" ke sesi child pada backend yang lebih murah, berpuluh megabyte yang child baca tidak pernah memasuki sesi Grok. Yang kembali ialah beberapa rujukan file:line. meshcode letakkan peraturan ini pada permulaan sesi dan tegaskan semula dengan peringatan ringkas jika panggilan eksplorasi mula bertimbun.

Apa yang "Menggunakan Sedikit" Benar-Benar Bermakna — dan Apa yang Tidak

Kami perlu bersikap terus terang tentang ini. Kami tidak akan mengaku nombor seperti "40% lebih sedikit token." Jenis angka itu berubah-ubah mengikut beban kerja, dan bukan itu yang kami ukur.

Berikut yang kami benar-benar boleh katakan:

  • Satu sesi menarik 30.4MB, dan item terbesar ialah read_file sebesar 11.9MB.
  • Di dalamnya, had sebenarnya menyasarkan 290 panggilan tanpa limit sebanyak 1.83MB dan ekor panggilan melebihi 10KB sebanyak 1.32MB.
  • search_tool jumlahnya 2.75MB, dengan respons 39KB bercampur di puncak, dan had 12,000 bait memotong ekor itu.
  • Apa yang dipotong dijimatkan bukan sekali tetapi pada setiap giliran yang tinggal, kerana konteks bertimbun.

Yang tidak benar: tiada satu pun daripada mekanisme ini menjadikan Grok lebih bijak. Jika ejen memerlukan lebih daripada sesuatu fail daripada yang diizinkan had 300 baris, ia terus membaca — cuma sekarang ia membaca bahagian yang benar-benar diperlukan. Intipati had bukan larangan — ia menukar default daripada tidak terhad kepada disengaja.

Tidak Merosakkan TUI grok Tulen Juga Syarat

Bahagian paling sukar kerja ini bukan penjimatanannya — tetapi mengelak kesan sampingan.

Fail hook Grok tidak boleh berada pada tahap projek — ia hanya diletakkan dalam direktori global ~/.grok/hooks/. Itu bermakna sebarang hook yang meshcode pasang juga berjalan apabila seseorang menaip grok tulen dalam terminal sendiri. Pelaksanaan pertama menjalankan biner meshcode pada setiap panggilan untuk menyemak "adakah ini sesi kami?" — dan semakan itu sahaja menelan 895ms setiap panggilan, dan dalam sesetengah keadaan membuka tetingkap untuk setiap panggilan read_file. Dalam sesi orang lain.

Jadi kami alihkan semakan daripada biner ke skrip shell luaran kecil. Jika sesi tidak membawa penanda yang meshcode tanam semasa melancarkan sesi, skrip itu tidak melakukan apa-apa dan terus lepas.

Berikut yang kami sahkan semula semalam:

Senario Hasil
TUI grok tulen (tiada penanda) 0.00s, sifar proses dilancarkan, tiada tetingkap
Sesi meshcode + read_file tanpa had Disahkan limit: 300 disuntik
Sesi meshcode + panggilan limit: 50 Dilalui tanpa perubahan
Kelewatan hook sesi meshcode 895ms → kira-kira 12ms

Penjimatan yang memperlahankan tool orang lain bukan penjimatan. Kos hook ini untuk pengguna Grok tulen mesti tepat sifar, dan kami hanya keluarkan ia setelah itu disahkan.

Sudut meshcode

meshcode ialah aplikasi desktop native untuk macOS dan Windows, dibina sekitar menjalankan beberapa ejen dalam panel selari. Anda boleh sambungkan langganan Grok sedia ada terus ke panel — bil yang sama, had yang sama, tiada tambahan daripada meshcode.

Perbezaannya ialah langganan yang sama bertahan lebih lama. Bukan kerana sebarang helah khusus, tetapi kerana kami benar-benar mengukur berapa banyak data yang mengalir ke sesi dan berapa banyak, serta memotong ekornya. Dan kerana eksplorasi yang benar-benar besar diatur untuk berjalan dalam konteks model yang lebih murah sejak awal — bukan dalam konteks Grok anda.

Jika anda lebih suka berhenti mengurus had langsung, model berbayar milik meshcode duduk di sebelahnya — tiada yuran bulanan, tiada tetingkap kongsi, cuma baki yang susut mengikut penggunaan. Bermakna ada tempat untuk pergi apabila salah satu tool anda kata "kemudian." Jika anda mahu pecahan yang sama untuk Claude, kami sudah liput dalam cara membuat langganan Claude Pro anda lebih tahan lama.

Jangan cuba jimatkan had dengan menahan prompt — hadkan yang mengalir masuk. meshcode percuma untuk dimulakan, dan panel Grok terus aktif dengan keempat-empat had di atas sejak pertama kali dilancarkan.

👉 Muat turun meshcode — Mac, Windows.

tips jimat langganan grokpenggunaan token grokpengurusan konteks ejen aipanjangkan langganan grokintegrasi meshcode grok