ยืดอายุ Grok ของคุณ: สิ่งที่เราวัดจริงๆ

ตอนที่ Grok Build หยุดพร้อมข้อความชนลิมิต คนส่วนใหญ่คิดว่าถามมากเกินไป แต่พอวัด byte ที่ไหลผ่านเซสชันจริงๆ ภาพเปลี่ยนไปเลย ส่วนใหญ่ที่กินลิมิตจริงๆ ไม่ใช่ prompt ของคุณ — แต่สิ่งที่ agent อ่านเอง

เราไม่ได้เดา — เราวัดมันจริงๆ และเปลี่ยนวิธีที่ meshcode เปิด Grok ให้ตรงกับผลที่พบ บทความนี้คือบันทึกสิ่งที่เรา measure, สิ่งที่เปลี่ยน, และตรงไหนผลถูกต้อง — รวมถึงตรงไหนมันไม่ถูกอีกต่อไป

30.4MB ที่เซสชันเดียวดึงเข้ามา

วันที่ 19 สิงหาคม 2026 เราติดตามข้อมูลขาเข้าทั้งหมดของ Grok หนึ่งเซสชัน รวม 30.4MB แยกตามหมวดหมู่ ตัวการชัดเจน

สิ่งสำคัญตรงนี้คือรูปร่างของการกระจาย ส่วนใหญ่ Grok อ่านเอง 20–80 บรรทัด — แบบนั้นโอเค ที่กินงบคือ 290 ครั้งที่ไม่ตั้งลิมิตเลย และแค่นั้นก็ 1.83MB ทุกครั้งดึงทั้งไฟล์เข้ามา

เครื่องมือค้นหาเมตาของ Grok search_tool แสดงรูปแบบเดียวกัน p90 อยู่ที่ 11KB แต่ max แตะ 39KB รวม 2.75MB ในทางตรงข้ามเครื่องมือของ meshcode จำกัดตัวเองอยู่แล้ว — ค่าสูงสุดที่วัดได้คือ 9.9KB สำหรับ read และ 8KB สำหรับ grep ไม่มีอะไรต้องแก้ตรงนั้น

ทำไมส่วนท้ายตัวเดียวกินทั้งเซสชัน

"1.83MB จาก 30MB แค่ 6%" เป็นข้อสรุปง่ายๆ แต่มันก็เป็นกับดักด้วย

บริบทในการสนทนา agent สะสมตัว ถ้าไฟล์ 30KB ตกลงมาทั้งไฟล์ในเทิร์นที่ 3 แล้วเซสชันรัน 40 เทิร์น 30KB นั้นจะถูก คิดซ้ำในทุกเทิร์นที่เหลืออีก 37 เทิร์น การอ่านที่ไม่มีวินัยไม่ใช่แค่ต้นทุนครั้งเดียว — มันทวีคูณยิ่งเซสชันยาว

นี่คือจุดที่ลิมิต Grok Build ไวต่อสิ่งนี้ที่สุด อย่างที่เราเคยเขียนไว้ก่อนหน้า ลิมิตฟรีของ Grok ไม่บอกเวลา reset — แค่แสดงข้อความชวนอัปเกรด คุณยิ่งไม่เห็นว่างบจะเติมเมื่อไหร่ ต้นทุนจากการรั่วไหลช่วงแรกก็ยิ่งแพง

เป้าหมายที่เราตั้งไม่ใช่ "ให้คนใช้ Grok ประหยัด" — แต่แคบกว่ามาก: ไม่แตะการเรียกปกติ ตัดแค่ส่วนท้าย

สี่ข้อจำกัดที่ meshcode ใส่ให้ Grok

เปิด Grok pane ใน meshcode แล้วต่างจาก grok เปล่าๆ สี่กลไกจะทำงานพร้อมกัน

1. แคป 300 บรรทัดสำหรับ read_file read_file ของ Grok เป็นเครื่องมือที่ฝังอยู่ใน binary Grok เอง เราจึงแก้ output ทีหลังไม่ได้ แทนที่จะสกัดกั้น ก่อน คำสั่งจะออกไป โดยใส่ limit=300 เฉพาะคำสั่งที่ไม่ได้ตั้งลิมิตหรือขอเกิน 300 คำสั่งปกติ 20–80 บรรทัดไม่มีทางแตะค่านี้

2. แคป 12,000 byte สำหรับ output เครื่องมือ MCP เพราะ p90 ของ search_tool คือ 11KB เพดาน 12,000 byte ตัดส่วนท้าย 39KB โดยไม่กระทบ response ปกติ ขอบเขตแค่โปรเซสที่ meshcode เปิด — ~/.grok/config.toml ของคุณไม่เคยถูกแตะ

3. ปิดแคตตาล็อกคนแปลกหน้าในเทิร์นแรก Grok TUI สแกน config MCP และ skills/rules ของ Cursor โดยดีฟอลต์ meshcode ไม่ได้รันบน Cursor เราจึงปิดแคตตาล็อก Cursor ที่หลงเหลือซึ่งไม่งั้นจะเกาะเป็น tool schema ในเทิร์นแรก

4. งานสำรวจอันใหญ่ส่งไปโมเดลถูก การประหยัดที่ใหญ่ที่สุดไม่ได้มาจากแคป — แต่มาจากโครงสร้าง เมื่อ meshcode ส่งงาน "หาว่าตรงไหน" ให้เซสชันลูกบน backend ที่ถูกกว่า MB หลายสิบตัวที่ลูกอ่าน ไม่มีทางเข้า Grok ของคุณ สิ่งที่กลับมาคือ ref file:บรรทัด ไม่กี่ตัว meshcode ใส่กฏนี้ตั้งแต่ต้นเซสชันและย้ำอีกครั้งถ้าคำสั่งสำรวจอัดแน่น

"ใช้น้อยลง" หมายความว่าอะไรจริงๆ — และไม่ใช่อะไร

เราต้องพูดตรงๆ เราไม่ได้จะ claim ตัวเลขแบบ "ลด token 40%" ตัวเลขแบบนั้นผันผวนตาม workload และไม่ใช่สิ่งที่เราวัด

นี่คือสิ่งที่เราพูดได้จริงๆ:

• เซสชันหนึ่งดึงเข้ามา 30.4MB สิ่งที่ใหญ่สุดคือ read_file 11.9MB
• ในนั้น แคปเจาะจง 290 ครั้งที่ไม่ตั้งลิมิต (1.83MB) และส่วนท้าย 1.32MB ของคำสั่งที่เกิน 10KB
• search_tool รวม 2.75MB มี response 39KB ที่พีค และแคป 12,000 byte ตัดส่วนท้ายนั้น
• ส่วนที่ถูกตัดถูกประหยัดไม่ใช่ครั้งเดียวแต่ในทุกเทิร์นที่เหลือ เพราะบริบทสะสมตัว

สิ่งที่ไม่จริง: กลไกเหล่านี้ไม่ได้ทำให้ Grok ฉลาดขึ้น ถ้า agent ต้องการไฟล์มากกว่า 300 บรรทัดที่จำกัด มันก็อ่านต่อ — แค่ตอนนี้มันอ่านเฉพาะส่วนที่จำเป็น จุดประสงค์ของแคปไม่ใช่ห้าม — แต่เปลี่ยนค่าดีฟอลต์จากไม่จำกัดเป็นมีเจตนา

ไม่พัง grok TUI เปล่าๆ ก็เป็นข้อบังคับ

ส่วนที่ยากที่สุดของงานนี้ไม่ใช่การประหยัด — แต่หลีกเลี่ยงผลข้างเคียง

ไฟล์ hook ของ Grok วางที่ระดับโปรเจกต์ไม่ได้ — มันอยู่ใน ~/.grok/hooks/ ระดับโกลบอลเท่านั้น หมายความว่า hook ที่ meshcode ติดก็จะทำงานตอนที่คนอื่นพิมพ์ grok เปล่าในเทอร์มินัล รุ่นแรกให้ hook รัน binary meshcode ทุกครั้งเพื่อเช็ค "นี่เป็นเซสชันของเราไหม?" — การเช็คแค่นั้นก็กิน 895ms ต่อครั้ง และในบางเงื่อนไขมันเปิดหน้าต่างทุกครั้งที่เรียก read_file — ในเซสชันของคนอื่น

เราจึงย้ายการเช็คออกจาก binary ไปเป็น script shell เล็กๆ ข้างนอก ถ้าเซสชันไม่มี marker ที่ meshcode ใส่ตอนเปิด session script จะไม่ทำอะไรและผ่านไปทันที

นี่คือสิ่งที่เรา re-verify เมื่อวาน:

การประหยัดที่ทำให้เครื่องมือคนอื่นช้าลงไม่ใช่การประหยัด ต้นทุน hook นี้สำหรับผู้ใช้ Grok เปล่าต้องเป็นศูนย์พอดี และเราเปิดใช้เมื่อยืนยันแล้วเท่านั้น

มุมมองจาก meshcode

meshcode เป็นแอปเดสก์ท็อปเนทีฟสำหรับ macOS และ Windows สร้างรอบการรันหลาย agent ใน pane คู่ขนาน ต่อ Grok subscription ที่มีอยู่แล้วเข้ากับ pane ได้เลย — บิลเดียวกัน ลิมิตเดียวกัน meshcode ไม่ได้หักอะไรเพิ่มตรงกลาง

สิ่งที่ต่างคือ subscription เดิมอยู่ได้นานขึ้น ไม่ใช่เพราะทริคใดๆ แต่เพราะเรา measure จริงๆ ว่าอะไรไหลเข้าเซสชันและมากแค่ไหน แล้วกันส่วนท้าย และเพราะงานสำรวจอันใหญ่ถูกตั้งให้รันในบริบทโมเดลถูกกว่าตั้งแต่แรก — ไม่ใช่ใน Grok context ของคุณ

ถ้าอยากเลิกจัดการลิมิตเลย โมเดลคิดเงินตามจริงของ meshcode อยู่ข้างๆ ไม่มีค่าสมาชิกรายเดือน ไม่มีหน้าต่างร่วม มีแค่ยอดที่หักตามใช้จริง หมายความว่ามีที่ไปทันทีที่เครื่องมือตัวใดตัวหนึ่งบอก "come back later" ถ้าอยากได้บทวิเคราะห์แบบเดียวกันสำหรับ Claude เราเขียนไว้แล้ว วิธียืดอายุ Claude Pro subscription

อย่าประหยัดลิมิตโดยการ rationing prompt — กันสิ่งที่ไหลเข้าแทน meshcode เริ่มใช้ฟรี และ pane Grok เปิดมาพร้อมทั้ง 4 ข้อจำกัดด้านบนทำงานตั้งแต่รันแรก

👉 ดาวน์โหลด meshcode — Mac, Windows.