สัปดาห์นี้ผมทำมิวสิกวิดีโอชิ้นหนึ่งขึ้นมา โดยโยนไฟล์เสียงให้ Grok Bot แล้วสั่งให้มันเรียกใช้ Claude Opus 5.5 บนคอมพิวเตอร์ของผมเพื่อผลิตวิดีโอออกมา
https://x.com/cgnot996/status/2108157846005350754
การทำผลงานชิ้นนี้ต้องนั่งดูรูปภาพและเฟรมวิดีโอจำนวนมหาศาล
ช่วงไม่กี่วันที่ผ่านมา มีหลายโพสต์บ่นว่าโควตาหมดเกลี้ยงภายในสองสามวัน จนต้องนั่งรอการรีเซ็ตรายสัปดาห์อย่างช่วยไม่ได้
ในบทความนี้ ผมรวบรวม 12 เทคนิคที่ผมลองผิดลองถูกจนเจอมาฝากกัน แต่ละเทคนิคจะมีประโยคที่คุณก๊อปปี้ไปวางใน Bot ของคุณได้ทันที พร้อมอธิบายว่าประหยัดตรงไหน และแพ็กเกจเริ่มต้นใช้งานได้ด้วยหรือไม่
ก่อนจะส่งคำสั่งให้ Bot คุณเคยสงสัยไหมว่าทำไมโควตาถึงค่อยๆ หายไปเงียบๆ ทั้งที่ก็ไม่ได้ส่งข้อความอะไรมากมาย?
ทำความเข้าใจก่อนว่าระบบหักโควตาอย่างไร
เอกสารทางการไม่ได้ระบุชัดเจนว่าแต่ละแพ็กเกจได้โควตาเท่าไหร่ แต่กฎเบื้องหลังสรุปได้ 3 ข้อหลักๆ
ข้อแรก โควตาจะถูกหักตาม "ปริมาณงานจริง" ที่ Bot ทำ ไม่ใช่ตามจำนวนข้อความที่ส่ง
ทั้งต้นทุนการเรียกใช้โมเดล ปริมาณตัวอักษร และการเรียกใช้เครื่องมือ ล้วนถูกนับเป็นการใช้งานทั้งหมด
ข้อสอง Bot แต่ละตัวมีเธรดการสนทนาเพียงเส้นเดียว และทุกรอบการตอบ มันจะอ่านประวัติย้อนหลังทั้งหมดใหม่ทุกครั้ง
พนักงานของ Cursor คนหนึ่งที่เข้าไปตรวจสอบบัญชีทีมพบว่า Bot ที่ทำงานหนักที่สุดของพวกเขาอ่านข้อมูลย้อนหลังถึง 80,000 - 90,000 tokens ในแต่ละขั้นตอน
ข้อสาม เมื่อโควตาหมด คุณมีทางเลือกแค่หยุดทำงานแล้วรอรีเซ็ตสัปดาห์หน้า หรือไม่ก็จ่ายเพิ่มตามจำนวน token ที่ใช้ และเมื่อเปิดระบบคิดเงินแบบตามการใช้งานจริง (on-demand) โควตาก็จะถูกหักเร็วมาก
พอเข้าใจกลไกนี้แล้ว กลยุทธ์การประหยัดโควตาก็ตรงไปตรงมา นั่นคือ โยนงานที่กินทรัพยากรมากที่สุดออกไป ลดการสร้างผลลัพธ์ที่ไม่จำเป็น และกระจายงานหนักไปยังเครื่องมือที่คุณมีอยู่แล้ว
ตัดสิ่งที่แพงที่สุดออกก่อนเป็นอันดับแรก
เคล็ดลับที่ 1: โยนงานวิเคราะห์ภาพ กรอวิดีโอ และถอดเสียง ไปให้ CLI Tools
อินพุตแบบมัลติโมดัลคือตัวสูบโควตาชั้นดี การส่งภาพหน้าจอ เฟรมวิดีโอ หรือไฟล์สแกนเข้าแชทโดยตรง จะทำให้ขนาดของ context พองตัวขึ้นอย่างรวดเร็ว
ผู้ใช้คนหนึ่งทดสอบเรื่องนี้ พบว่าการส่งรูปภาพ 4 ภาพในหนึ่งวัน ค้นข้อมูล 1 ครั้ง และประมวลผลเอกสารสแกน 2 ฉบับ กินโควตารายสัปดาห์ของแพ็กเกจสูงสุดไปถึง 11%
วิธีที่ถูกต้องคือการใช้เครื่องมือ command-line อย่าง Grok Build หรือ agy ภายใน cloud computer เพื่ออ่านไฟล์และสร้างสรุปเป็นข้อความ แล้วให้ Bot อ่านแค่ส่วนสรุปนั้น
ถ้าคุณไม่มี environment แบบ CLI ให้หาสรุปผ่านเว็บ grok.com หรือ Gemini เวอร์ชันเว็บฟรีก่อน แล้วค่อยนำข้อความนั้นไปแปะให้ Bot
Prompt สำหรับก๊อปปี้ไปวางให้ Bot:
"สำหรับงานที่ต้องดูภาพหน้าจอ วิเคราะห์เฟรมวิดีโอ กรอวิดีโอทีละเฟรม ถอดเสียง หรือจดจำเอกสารสแกนยาวๆ ห้ามอ่านไฟล์มัลติโมดัลด้วยตัวเองโดยตรง ให้เรียกใช้ Grok Build ใน cloud computer เพื่ออ่านและสร้างสรุปเป็นข้อความก่อนเสมอ แล้วคุณค่อยอ่านเฉพาะข้อสรุปที่เป็นข้อความนั้น หากเครื่องมือ command-line ใช้งานไม่ได้ ให้เตือนฉันไปหาสรุปข้อความจากเวอร์ชันเว็บก่อน แล้วค่อยส่งให้คุณ"
- ประหยัดตรงไหน: ป้องกันไม่ให้ Bot อ่านไฟล์มัลติโมดัลโดยตรง เมื่อเครื่องมือภายนอกสรุปภาพหรือวิดีโอเสร็จแล้ว Bot จะได้อ่านข้อความแค่ไม่กี่ร้อยคำเท่านั้น
- แพ็กเกจเริ่มต้นใช้ได้ไหม: ใช้ได้บางส่วน การติดตั้ง Grok Build ใน cloud computer จะใช้โควตาสมัครสมาชิกของตัวเอง ถ้ายังไม่ได้ติดตั้ง ให้เริ่มจากการหาสรุปผ่านเว็บก่อน
เคล็ดลับที่ 2: อย่าปล่อยให้บทสนทนายาวเกินไป
Bot แต่ละตัวมีเธรดการสนทนาแค่เส้นเดียว ยิ่งคุยยาว โค้ดและ log ก็ยิ่งสะสมมากขึ้น แม้จะแก้แค่เครื่องหมายวรรคตอนตัวเดียว ระบบก็ต้องอ่านประวัติทั้งหมดใหม่ตั้งแต่ต้น
หากต้องการควบคุมความยาวของการสนทนา ให้ทำตาม 4 ขั้นตอนนี้
ข้อแรก เขียนกฎระยะยาวไว้ในคำอธิบาย Bot และบันทึก workflow ที่ลงตัวแล้วเป็น skills อย่ามานั่งพิมพ์คำสั่งซ้ำๆ ในแชททุกวัน
ข้อสอง เก็บเนื้อหาที่ยาวๆ log และความคืบหน้าต่างๆ ไว้ในไฟล์ สั่งให้ Bot ตอบกลับมาแค่ข้อสรุปกับ path ของไฟล์ อย่าให้มันแปะข้อความดิบๆ ยาวเหยียดลงในแชท
ข้อสาม แยกงานที่ตั้งเวลาไว้และโปรเจกต์ระยะยาวไปให้ Bot เฉพาะทางดูแล อย่าเอามารวมกับ Bot หลักที่ใช้คุยงานประจำวัน
ข้อสี่ เมื่อการสนทนายาวเกินไป ให้สั่ง Bot เขียนสรุปส่งมอบงาน จากนั้นบน iPhone ให้ทำการ duplicate Bot ตัวนี้ (ผมทดสอบบน iPhone แล้วว่าได้ผล ส่วนเมนูบนเดสก์ท็อปไม่มีตัวเลือกนี้แล้ว) ส่งสรุปนั้นไปที่ Bot ตัวใหม่ที่ copy มา แล้วซ่อน Bot ตัวเก่าไว้โดยไม่ต้องลบ
ข้อเสียที่ต้องแลกมาคือ Bot ตัวที่ copy มาจะไม่ได้รับประวัติการสนทนา ความทรงจำ หรือไฟล์แนบเดิมไปด้วย คุณจึงต้องป้อนข้อมูลสำคัญให้มันใหม่อีกครั้ง
Prompt สำหรับก๊อปปี้ไปวางให้ Bot:
จัดระเบียบกฎและ skills:
"รวบรวมกฎที่คุณต้องปฏิบัติตามเสมอให้เป็นย่อหน้าเดียว เพื่อให้ฉันนำไปวางในคำอธิบายของคุณ และบันทึก workflow ที่เราเพิ่งทำสำเร็จไปเป็น skill"
เก็บเนื้อหายาวๆ ไว้ในไฟล์:
"จากนี้ไป ให้บันทึกเนื้อหายาวๆ log การแก้ปัญหา และผลลัพธ์ระหว่างทางเป็นไฟล์ไว้ใต้ /workspace/ เวลาตอบฉัน ให้บอกแค่ข้อสรุปและ path ของไฟล์ ห้ามแปะข้อความต้นฉบับกลับลงไปในแชท สร้างไฟล์ notes.md สำหรับตัวคุณเองเพื่อบันทึกบทบาท งานปัจจุบัน และการตัดสินใจที่ทำไป แล้วอัปเดตทุกครั้งที่จบแต่ละช่วงงาน"
เขียนสรุปส่งมอบงาน:
"ช่วยเขียนสรุปส่งมอบงานให้ฉันภายใน 10 บรรทัด โดยระบุบทบาทของคุณ งานปัจจุบัน การตัดสินใจที่ทำไปแล้ว ขั้นตอนต่อไป และ path ของไฟล์ที่ต้องใช้ ฉันจะส่งสิ่งนี้ต่อให้กับ Bot ตัวที่ copy มาจากคุณ"
- ประหยัดตรงไหน: ป้องกันไม่ให้บทสนทนาหลักบวมเป่งจากเนื้อหายาวๆ ช่วยลดการอ่านข้อมูลย้อนหลังในแต่ละรอบได้อย่างมหาศาล กฎสำคัญๆ จะถูกฝังไว้ในคำอธิบายและไฟล์ ไม่เลือนหายไปเรื่อยๆ
- แพ็กเกจเริ่มต้นใช้ได้ไหม: การจัดระเบียบกฎ การเก็บไฟล์ และการแยก Bot สามารถทำได้ทั้งหมด แต่การ duplicate Bot ปัจจุบันต้องทำผ่าน iPhone และ Bot ตัวใหม่ต้องได้รับการป้อนข้อมูลสำคัญอีกครั้ง
เคล็ดลับที่ 3: ยืดระยะเวลาการทำงาน และเงียบไว้ถ้าไม่มีอะไรเปลี่ยน
งานที่ทำเป็นประจำถ้าไม่จัดการให้ดี จะแอบสูบโควตาไปเงียบๆ ศูนย์ช่วยเหลือทางการเตือนไว้ว่างานที่ตั้งรอบเวลาสั้นๆ อาจกินโควตาทั้งสัปดาห์หมดภายในวันเดียว
ผู้ใช้คนหนึ่งลองตรวจสอบตัวเองแล้วพบว่างานที่ตั้งความถี่สูงถูกเรียกถึง 672 ครั้งต่อสัปดาห์ พอเปลี่ยนเป็นรายชั่วโมงก็ลดลงเหลือ 168 ครั้ง
การหยุดงานประจำที่ไม่ได้ใช้ชั่วคราวจะช่วยระงับการหักโควตา แต่ระวังว่าการกดปุ่ม 'Test' ในหน้า UI จะมีการหักโควตาทุกครั้ง
Prompt สำหรับก๊อปปี้ไปวางให้ Bot:
"แสดงรายการงานที่ตั้งเวลาไว้ทั้งหมดของคุณ บอกฉันว่าแต่ละงานทำงานบ่อยแค่ไหน รวมแล้วกี่ครั้งต่อสัปดาห์ และมันส่งข้อความมาไหมถ้าไม่มีอะไรเปลี่ยนแปลง บอกฉันด้วยว่างานไหนกินโควตามากที่สุด ให้ยืดระยะเวลาของมันออกไป และแก้ไขกฎว่า: ถ้าตรวจสอบแล้วไม่พบการเปลี่ยนแปลงที่มีนัยสำคัญ ให้เงียบไว้และไม่ต้องสร้างรายงาน"
- ประหยัดตรงไหน: ลดการปลุก Bot ขึ้นมาโดยเปล่าประโยชน์ การยกเลิกการสร้างรายงานเมื่อ "ไม่มีอะไรเปลี่ยน" ช่วยประหยัดต้นทุนการเรียกใช้ในทุกๆ ครั้งที่ไม่มีข้อมูลใหม่
- แพ็กเกจเริ่มต้นใช้ได้ไหม: ใช้ได้เต็มที่ ทุกแพ็กเกจสามารถปรับรอบเวลาหรือหยุดงานชั่วคราวได้ตลอดเวลา
เคล็ดลับที่ 4: ปลุกขึ้นมาเฉพาะเมื่อมีการเปลี่ยนแปลง
นี่คือเวอร์ชันอัปเกรดของเคล็ดลับที่ 3 ตอนที่ Bot หลับอยู่ cron jobs ของ Linux ใน backend ของ cloud computer ยังคงทำงานตามปกติ
สคริปต์ระบบที่คอยเช็กการเปลี่ยนแปลงของหน้าเว็บหรือไฟล์ใช้เวลาแค่ไม่กี่วินาที ไม่ต้องผ่านโมเดล และไม่กินโควตา Bot เลยแม้แต่นิดเดียว
เมื่อเร็วๆ นี้ผมเพิ่ง refactor Bot ตำแหน่ง Marketing Director ของตัวเอง จากงานที่ตั้งเวลาไว้ 6 ตัว ผมย้ายงานมอนิเตอร์ข้อมูล 2 ตัวไปใช้สคริปต์แทน แล้วค่อยปลุก Bot ผ่าน Webhook เฉพาะตอนที่ข้อมูลมีการเปลี่ยนแปลง
การ refactor นี้ใช้เวลาประมาณ 23 นาที ช่วยลดการทำงานวนลูปโดยเปล่าประโยชน์ไปได้ 8-10 รอบต่อสัปดาห์ แถมยังตอบสนองได้ไวขึ้นในระดับต่ำกว่า 30 นาที
Prompt สำหรับก๊อปปี้ไปวางให้ Bot:
"สำหรับงานประจำประเภทมอนิเตอร์ข้อมูล ห้ามตั้งค่าปลุกแบบ polling ตามเวลาที่กำหนดไว้ใน Routines ให้ตั้งค่าสคริปต์ตรวจสอบแบบเบาๆ ไว้ใน backend ของ cloud computer แทน เพื่อให้ระบบหลับอยู่ตามปกติ และปลุกคุณผ่านที่อยู่ Webhook เฉพาะเมื่อสคริปต์ตรวจพบการเปลี่ยนแปลงที่มีนัยสำคัญในข้อมูลเป้าหมายเท่านั้น"
- ประหยัดตรงไหน: กำจัดวงจร polling ที่ปลุกขึ้นมา ไม่เจออะไร แล้วก็กลับไปหลับใหม่ Bot จะตื่นและกินโควตาเฉพาะเมื่อมีงานต้องทำจริงๆ เท่านั้น
- แพ็กเกจเริ่มต้นใช้ได้ไหม: ใช้ได้ cloud computer ของทุกแพ็กเกจสามารถรันสคริปต์พื้นฐานร่วมกับทริกเกอร์ Webhook ได้
ทำให้ Bot พูดจาไร้สาระน้อยลง
เคล็ดลับที่ 5: เลี่ยง Group Chat และลดการคุยกันเองระหว่าง Bot
วิศวกรของ Grok Bot ออกมาเปิดเผยต่อสาธารณะว่า group chat นั้นกิน token มหาศาล กลุ่มที่ใหญ่กว่าก็ยิ่งแพงกว่า จึงแนะนำให้ผู้ใช้ทั่วไปหลีกเลี่ยง
พนักงานของ Cursor ตั้งข้อสังเกตว่าทุกข้อความที่ส่งจะทำให้ Bot ต้องอ่านประวัตินั้นใหม่ และการตอบกลับก็จะไปปลุก Bot ตัวอื่นให้ตื่นขึ้นมาด้วย
ในบัญชีนั้น ประมาณหนึ่งในสามของรอบการสนทนาคือการที่ Bot ต่างปลุกกันไปปลุกกันมา ผู้ใช้แพ็กเกจเริ่มต้นควรสร้าง Bot ให้น้อยลง และจัดการปัญหาเฉพาะหน้าผ่านการแชทแบบ 1 ต่อ 1 โดยตรง
Prompt สำหรับก๊อปปี้ไปวางให้ Bot:
"ปฏิบัติตามคำสั่งที่ฉันสั่งโดยตรงอย่างเคร่งครัด ห้ามปลุก Bot ตัวอื่นขึ้นมาเพื่อทำงานร่วมกันเป็นกลุ่มหรือยืนยันหลายฝ่ายด้วยตัวเอง หากงานใดต้องประสานงานหลายขั้นตอน ฉันจะเป็นคนถ่ายทอดข้อสรุปสำคัญให้ หรือจะกระจายงานย่อยไปยังเครื่องมือที่รับผิดชอบแต่ละส่วนเอง"
- ประหยัดตรงไหน: ตัดภาระที่เกิดจากการทักทายกันและการอ้างอิงข้ามไปมาระหว่าง Bot เก็บโควตาไว้ใช้กับงานจริงๆ
- แพ็กเกจเริ่มต้นใช้ได้ไหม: ใช้ได้เต็มที่ การเปลี่ยนมาใช้การสื่อสารแบบ 1 ต่อ 1 ไม่มีข้อจำกัดใดๆ
เคล็ดลับที่ 6: ใช้ของเดิมซ้ำก่อนสร้างใหม่
การสร้าง Bot ใหม่ทุกครั้งต้องเสียเวลาใส่ prompt และทดสอบการเรียกใช้เครื่องมือ โควตาสำหรับมือใหม่ที่ทางการให้มานั้นมีจำกัด งานใหญ่ๆ อาจสูบหมดในคราวเดียวโดยเติมไม่ได้
วิศวกรทางการแนะนำว่า "ใช้ของเดิมซ้ำก่อนสร้างใหม่ อย่าสร้างเสียงรบกวนโดยไม่จำเป็น" ควรมี Bot หลักติดตัวไว้แค่ 2-3 ตัว และเมื่อมีความต้องการใหม่ๆ ให้เพิ่มกฎเข้าไปใน Bot ที่มีอยู่ก่อนเป็นอันดับแรก
Prompt สำหรับก๊อปปี้ไปวางให้ Bot:
"ก่อนจะสร้าง Bot ใหม่สำหรับความต้องการใดๆ ให้ทบทวน workflow และการตั้งค่าเครื่องมือที่เราใช้อยู่ปัจจุบันก่อน หาก Bot ที่มีอยู่มีความสามารถพื้นฐานใกล้เคียงกันแล้ว ให้เน้นเพิ่มกฎหรือขยายฟังก์ชันในการตั้งค่าเดิม เพื่อหลีกเลี่ยงการสร้าง Bot ใหม่แยกต่างหาก"
- ประหยัดตรงไหน: ประหยัดต้นทุนการ debug ทดสอบ และตั้งค่าเริ่มต้นที่ต้องเสียไปกับการสร้าง Bot ใหม่
- แพ็กเกจเริ่มต้นใช้ได้ไหม: ใช้ได้เต็มที่ในทุกแพ็กเกจ
กระจายงานหนักไปยังบริการที่สมัครสมาชิกไว้แล้ว
เคล็ดลับที่ 7: เบี่ยงเบนโควตา โดย Scheduler ≠ Executor
นี่คือแนวคิดหลักที่ผมแชร์ไปในหางโจวเมื่อเดือนกันยายน: ให้ Grok Bot รับหน้าที่จัดการตารางเวลา ส่วนงานหนักๆ ให้ดึงออกไปใช้โควตาจากบริการที่สมัครไว้แล้ว
การเขียนโค้ดหลายร้อยบรรทัดหรือการอ่าน repo ทั้งหมดเพื่อ refactor ในกล่องแชทจะทำให้โควตาหมดอย่างรวดเร็ว
ให้ติดตั้ง Grok Build ใน cloud computer แล้วล็อกอินเข้าไป สั่งให้ Bot ส่งคำสั่งไปทำงานเบื้องหลังเพื่อให้มันเขียนโค้ด ส่วนตัว Bot เองมีหน้าที่แค่รายงานผลลัพธ์
จากการทดสอบพบว่า หลังจากโยนงานเขียนโค้ดไปให้ Grok Build แล้ว pool ของ Bot ถูกใช้ไป 70% ในเวลาสองวันครึ่ง ในขณะที่ pool นักพัฒนาภายนอกถูกใช้ไปแค่ 6%
ผู้ใช้อีกคนสั่งให้ Bot จัดตารางการพัฒนาใน Cursor เท่านั้น หลังทำงานต่อเนื่อง 3 ชั่วโมง โควตารายสัปดาห์ถูกใช้ไปแค่ 3%
Prompt สำหรับก๊อปปี้ไปวางให้ Bot:
"บทบาทของคุณคือผู้จัดการตารางงาน มีหน้าที่แบ่งแผนงาน จัดระเบียบตรรกะ และกระจายงานไปยังเครื่องมือต่างๆ ห้ามเขียนโค้ดยาวๆ หรือแก้ไขไฟล์ขนาดใหญ่โดยตรงในหน้าต่างแชท ให้รวมศูนย์งานเขียนโค้ดและ refactor โปรเจกต์ทั้งหมดโดยการเรียกใช้ Grok Build ที่ได้รับอนุญาตแล้วในเบื้องหลัง และซิงค์เฉพาะข้อสรุปสุดท้ายของการดำเนินงานมาให้ฉัน"
- ประหยัดตรงไหน: ย้ายงานเขียนโค้ดที่กินทรัพยากรสูงไปยัง pool นักพัฒนาของบริการที่สมัครไว้แล้ว ให้ Bot เป็นคนส่งคำสั่งสั้นๆ เท่านั้น
- แพ็กเกจเริ่มต้นใช้ได้ไหม: ใช้ได้ เพียงติดตั้ง Grok Build ใน cloud computer แล้วล็อกอินด้วยบัญชีที่มีอยู่
เคล็ดลับที่ 8: ใช้โควตาฟรีในตัวสำหรับการค้นหา X และเก็บไว้แค่ประเด็นสำคัญ
การค้นหาบนแพลตฟอร์ม X ของ Grok Bot ในปัจจุบันใช้โควตาฟรีที่มีอยู่ในตัว ซึ่งจำกัดไว้ที่ 30 ครั้ง/นาที และ 1,000 ครั้ง/วัน
การค้นหานี้ไม่หักโควตารายสัปดาห์ของ Bot และไม่หักเครดิต X API
ปัญหาอยู่ที่การไหลกลับของผลลัพธ์: การแปะทวีตจำนวนมากลงในแชทจะทำให้บทสนทนาบวมเป่ง บังคับให้ระบบต้องอ่านย้อนหลังใหม่และเสียเงินในทุกขั้นตอนที่ตามมา
สั่งให้ Bot บันทึกทวีตดิบจำนวนมากลงไฟล์ แล้วตอบกลับมาในแชทแค่ประเด็นสำคัญกับลิงก์ รวมถึงอย่าลืมระวังเรื่องขีดจำกัดความถี่ด้วย
Prompt สำหรับก๊อปปี้ไปวางให้ Bot:
"เมื่อดึงข้อมูลทวีต ความคิดเห็น หรืออัปเดตจากแพลตฟอร์ม X ให้ใช้ความสามารถในการค้นหาฟรีที่มีอยู่ในตัวคุณ บันทึกทวีตดิบที่ดึงมาได้จำนวนมากเป็นไฟล์ไว้ใต้ /workspace/ โดยตรง และรายงานเฉพาะประเด็นหลักที่กลั่นกรองแล้วพร้อมลิงก์ที่เกี่ยวข้องในบทสนทนา ห้ามแปะข้อความต้นฉบับของทวีตเป็นก้อนใหญ่ลงในแชท"
- ประหยัดตรงไหน: ใช้โควตาฟรีในตัวสำหรับการค้นหา และเก็บทวีตไว้ภายนอก ป้องกันไม่ให้บทสนทนาบวม
- แพ็กเกจเริ่มต้นใช้ได้ไหม: ใช้ได้เต็มที่ ทุกแพ็กเกจมีโควตาการค้นหานี้มาให้ในตัวอยู่แล้ว
API ฟรี: ประหยัดโควตาและเพิ่มขีดความสามารถ
นอกจากบริการที่สมัครไว้แล้ว การเชื่อมต่อ API สาธารณะแบบฟรียังช่วยเบี่ยงเบนงานเบาๆ อย่างข้อความ การจดจำภาพ และการสร้างภาพออกไปได้
OpenRouter: ข้อความแบบเบาๆ และการจดจำภาพฟรี
OpenRouter มีโมเดลฟรีชุดหนึ่งที่ลงท้ายด้วย :free เหมาะสำหรับการเรียบเรียงข้อความสั้นๆ การสรุป และการจดจำภาพแบบฟรีๆ
ขีดจำกัดทางการคือ 20 ครั้ง/นาที และ 50 ครั้ง/วัน แต่ในอดีตหากสะสมเครดิตได้ถึง $10 ขีดจำกัดรายวันจะเพิ่มขึ้นเป็น 1,000 ครั้ง
ข้อควรระวัง 3 ข้อในการใช้งาน:
ข้อแรก ตั้งวงเงินเครดิตเป็น 0 ตอนสร้าง API Keys เพื่อป้องกันการถูกชาร์จจากโมเดลแบบเสียเงินโดยไม่ได้ตั้งใจ
ข้อสอง อย่าส่งข้อมูลที่ละเอียดอ่อน เพราะผู้ให้บริการบางรายระบุว่าข้อมูลอินพุตอาจถูกนำไปเทรนโมเดล
ข้อสาม เก็บ Keys ไว้ใน cloud computer เพื่อให้ Bot ทุกตัวในเครื่องนั้นอ่านไฟล์นี้ได้
ลิงก์ที่เกี่ยวข้อง:
- การจัดการ API Key: https://openrouter.ai/settings/keys
- เอกสาร Rate Limit: https://openrouter.ai/docs/api-reference/limits
- เอกสารโมเดลฟรี: https://openrouter.ai/docs/guides/routing/model-variants/free
Prompt สำหรับก๊อปปี้ไปวางให้ Bot:
"ตั้งค่า environment สำหรับการเรียกใช้โมเดลฟรีของ OpenRouter ขั้นตอน:
1. ขอ API Key จากฉันผ่านกล่องรับข้อมูลลับในแชท ห้ามให้ฉันแปะ key ลงในแชทโดยตรง;
2. บันทึก Key ที่ได้รับไปที่ ~/.agents/secrets/openrouter.env โดยใช้ชื่อตัวแปร OPENROUTER_API_KEY;
3. รันคำสั่ง chmod 600 กับไฟล์นั้น;
4. ห้ามพิมพ์ key แสดงบน terminal หรือหน้าต่างแชทระหว่างดำเนินการอย่างเด็ดขาด;
5. รันทดสอบขั้นต่ำ: เรียกใช้โมเดลที่ลงท้ายด้วย :free เพื่อตอบกลับมาหนึ่งประโยค ยืนยันว่าต้นทุนเป็น 0 แล้วรายงานผล"
ไอเดียขั้นสูง: ขีดจำกัดและความเสี่ยงของ FreeToken-Bots
skill โอเพนซอร์สชื่อ FreeToken-Bots (https://github.com/limin112/min-skill/tree/main/skills/FreeToken-Bots) ทำหน้าที่สแกนหาโมเดลฟรีบน OpenRouter
ผู้สร้างระบุชัดเจนว่าอย่าคาดหวังการสลับใช้งานอัตโนมัติแบบไม่ต้องดูแลเลย จากการทดลองของผม สแกนเจอโมเดลฟรี 20 ตัว ใช้ได้โดยตรง 0 ตัว และอีก 17 ตัวต้องตรวจสอบพารามิเตอร์ก่อน
Keys จะมองเห็นได้โดย Bot ทุกตัวใน cloud computer และโมเดลฟรีก็มี rate limits รวมถึงเงื่อนไขการนำไปเทรน ผู้ใช้แพ็กเกจเริ่มต้นไม่ควรเสียเวลากับจุดนี้
ModelScope: ใช้เฉพาะการสร้าง/แก้ไขภาพเท่านั้น
ผมแนะนำให้ใช้ ModelScope API-Inference เฉพาะงานสร้างหรือแก้ไขภาพเท่านั้น
จากการทดสอบพบว่า interface ประเภทข้อความ วิชั่น และ AV ของมันมักเกิด error 429/400 ซึ่งแปลว่าไม่มีบริการว่าง ความเสถียรค่อนข้างต่ำ
ข้อควรระวัง 3 ข้อในการใช้งาน:
ข้อแรก ต้องผูกบัญชี Aliyun และยืนยันตัวตนด้วยชื่อจริง
ข้อสอง จะหักผ่านเครดิต 'Magic Cube' โดยมีโควตารายวันตามที่ระบุในหน้าทางการ
ข้อสาม สั่งให้ Bot ติดตั้ง skill สร้างภาพสาธารณะนี้: https://github.com/RongleCat/tiezhu-modelscope-api-inference
ลิงก์ที่เกี่ยวข้อง:
- การจัดการ Access Token: https://modelscope.cn/my/myaccesstoken
- แนะนำ API-Inference: https://modelscope.cn/docs/model-service/API-Inference/intro
- ขีดจำกัดและกฎเกณฑ์: https://modelscope.cn/docs/model-service/API-Inference/limits
Prompt สำหรับก๊อปปี้ไปวางให้ Bot:
"ตั้งค่า environment สำหรับสร้างภาพของ ModelScope ขั้นตอน:
1. ขอ Access Token จากฉันผ่านกล่องรับข้อมูลลับในแชท ห้ามให้ฉันแปะ token ลงในแชทโดยตรง;
2. บันทึก Token ที่ได้รับไปที่ ~/.agents/secrets/modelscope.env โดยใช้ชื่อตัวแปร MODELSCOPE_API_KEY;
3. รันคำสั่ง chmod 600 กับไฟล์นั้น;
4. ห้ามพิมพ์ token แสดงบน terminal หรือหน้าต่างแชทระหว่างดำเนินการอย่างเด็ดขาด;
5. รันทดสอบขั้นต่ำ: เรียกใช้ Tongyi-MAI/Z-Image-Turbo เพื่อสร้างภาพ 1 ภาพ แล้วรายงาน path ในเครื่อง"
ปกป้องกระเป๋าเงินของคุณ
เคล็ดลับที่ 9: ทดสอบทีละนิด และหมั่นเช็ก Dashboard
การสั่งงานจำนวนมากแบบหลับหูหลับตาทำให้โควตาหมดได้ง่ายๆ ถ้า Bot เข้าใจผิดตั้งแต่ขั้นตอนที่สอง การพยายามซ้ำๆ จะเผาโควตาทั้งสัปดาห์ทิ้งไปเลย
ผู้ใช้คนหนึ่งสูญเสียโควตารายสัปดาห์ไปกว่าครึ่งภายใน 2 ชั่วโมง เพียงเพราะการลองผิดลองถูกในงานที่ทำต่อเนื่องกัน
สำหรับงานที่ซับซ้อน ให้ทดสอบทีละขั้นตอนด้วยตัวอย่าง 1-2 ชิ้นก่อน แล้วหยุดรอการยืนยัน
หลังจากยืนยันแล้ว ให้เข้าไปเช็กเปอร์เซ็นต์ที่ถูกหักใน Settings → Usage & Billing ก่อนดำเนินการต่อ
Prompt สำหรับก๊อปปี้ไปวางให้ Bot:
"สำหรับงานประมวลผลแบบแบตช์ การแก้ปัญหา flow ยาวๆ หรืองานหลายขั้นตอนที่ซับซ้อน ให้ใช้ตัวอย่างขั้นต่ำ 1-2 ชิ้นเพื่อทดสอบทีละขั้นตอนก่อน เมื่อทำขั้นตอนเดียวเสร็จต้องหยุดทันทีเพื่อรอการยืนยันจากฉัน ห้ามดำเนินการขั้นตอนถัดไปโดยอัตโนมัติก่อนได้รับไฟเขียวอย่างเด็ดขาด"
- ประหยัดตรงไหน: ดักจับข้อผิดพลาดด้านทิศทางด้วยตัวอย่างทีละขั้นตอน ป้องกันไม่ให้ตรรกะที่ผิดเพี้ยนเผาโควตารายสัปดาห์ทิ้ง
- แพ็กเกจเริ่มต้นใช้ได้ไหม: ใช้ได้เต็มที่ คุณสามารถดูการใช้งานและเวลารีเซ็ตได้ในแผงตั้งค่าตลอดเวลา
เคล็ดลับที่ 10: กำหนดขอบเขต Loop และถามเมื่อไม่แน่ใจ
การลองใหม่เมื่อเกิด error คือกับดักที่มองไม่เห็น เมื่อเจอปัญหา env/permission ที่แก้ไม่ได้ Bot มักจะตกอยู่ในวงจรการลองใหม่ไม่รู้จบ
death loop แค่สิบนาทีก็สูบโควตารายสัปดาห์หมดได้ ต้องจำกัดการลองใหม่ของแต่ละการดำเนินการไว้ที่ 2 ครั้ง หากล้มเหลวติดกัน 2 ครั้งให้ถามคนทันที
Prompt สำหรับก๊อปปี้ไปวางให้ Bot:
"ปฏิบัติตามกฎป้องกัน loop อย่างเคร่งครัดขณะรันสคริปต์อัตโนมัติ เรียกใช้ API หรือแก้ปัญหา: จำกัดการลองใหม่ของการดำเนินการเดียวกันไว้ที่ 2 ครั้ง หากพยายาม 2 ครั้งติดกันแล้วล้มเหลวหรือผลลัพธ์ยังไม่แน่นอน ให้หยุดการทำงานทันทีแล้วมาถามฉัน ห้ามลองใหม่ด้วยตัวเองแบบไม่รู้จบอย่างเด็ดขาด"
- ประหยัดตรงไหน: ตัดวงจร error death loops ทิ้ง ป้องกันการกินทรัพยากรเงียบๆ ในเบื้องหลัง
- แพ็กเกจเริ่มต้นใช้ได้ไหม: ใช้ได้เต็มที่ เป็นการบังคับด้วย prompt ล้วนๆ ไม่มีต้นทุน
เคล็ดลับที่ 11: ปิด On-Demand Billing และซื้อแพ็กเกจให้ถูกประเภท
ปิด on-demand billing ในการตั้งค่าบัญชี Cursor หรือตั้งวงเงินไว้ต่ำๆ
ระบบ on-demand คิดเงินตามราคา unit ของ token จริงๆ ซึ่งแพงมาก มีผู้ใช้รายงานว่าถูกชาร์จ $26 ภายใน 30 นาที และยอดบิลสุดท้ายคือ $51
บางคนเสียเงินเพิ่ม $190 ข้ามคืน ขณะที่ทีมเล็กๆ เจอบิล on-demand เกือบ $1,500 ต่อสัปดาห์
ศูนย์ช่วยเหลือทางการระบุว่าวงเงินรายเดือนไม่ใช่เบรกฉุกเฉิน งานที่กำลังรันอยู่อาจเกินวงเงินได้ หากไม่เปิด on-demand เมื่อโควตาหมดก็แค่หยุดทำงานจนกว่าจะรีเซ็ต
ห้ามซื้อแพ็กเกจเสริมที่ grok.com เด็ดขาด เพราะเป็นคนละระบบบัญชีกัน เงินโอนข้ามไม่ได้ มีผู้ใช้ซื้อแพ็กเกจ $100 แต่กลับนำมาใช้ไม่ได้
Prompt สำหรับก๊อปปี้ไปวางให้ Bot:
"ตรวจสอบกฎการทำงานของ env ปัจจุบัน เมื่อโควตาใกล้หมดให้หยุดและแจ้งเตือนฉัน พร้อมเตือนให้ฉันไปเช็กสวิตช์ on-demand ในหน้า billing ของ Cursor"
- ประหยัดตรงไหน: รักษาฐานกระเป๋าเงิน ป้องกันต้นทุนที่บานปลายจากงานที่ควบคุมไม่ได้
- แพ็กเกจเริ่มต้นใช้ได้ไหม: ใช้ได้เต็มที่ ปิดสวิตช์ได้ในหน้า billing ของ Cursor
เคล็ดลับที่ 12: เชื่อมต่อ Cloud Computer ด้วยตัวเองเมื่อโควตาหมด
เมื่องานยาวๆ ทำให้โควตาถูกใช้ไป 90% หน้าแชทจะถูกล็อก
ผู้ใช้จากแหล่งอื่นบอกว่าเรายังสามารถเชื่อมต่อ cloud computer เพื่อดาวน์โหลดงานที่ทำค้างไว้หรือทำต่อด้วยตัวเองได้ แต่ควรทดสอบด้วยตัวเองก่อน
Prompt สำหรับก๊อปปี้ไปวางให้ Bot:
"เมื่อระบบเตือนว่าโควตารายสัปดาห์ใกล้หมด ก่อนที่ session จะสิ้นสุดลง ให้บันทึก path ไฟล์ที่ใช้งานอยู่ ผลลัพธ์ชั่วคราว และ breakpoint การทำงานทั้งหมดลงในโฟลเดอร์เก็บข้อมูลชั่วคราวใน workspace พร้อมสร้างคำแนะนำสำหรับการรับช่วงต่อแบบกระชับ"
- ประหยัดตรงไหน: ป้องกันการถูกบังคับจ่ายแบบ on-demand เพื่อช่วยชีวิตงานที่เหลืออีกไม่กี่ขั้นตอน
- แพ็กเกจเริ่มต้นใช้ได้ไหม: ใช้ได้ ต้องมีความรู้พื้นฐานเรื่อง terminal ถือเป็นมาตรการฉุกเฉิน
3 เทคนิคที่ไม่ตรงกับความเป็นจริง
1. สลับไปใช้โมเดลที่เบากว่าเพื่อประหยัดโควตา
เอกสารทางการระบุว่าปัจจุบันยังไม่มีตัวเลือกให้เปลี่ยนโมเดล
ระบบจะเลือกโมเดลให้อัตโนมัติตามความยากของงาน ไม่สามารถสลับเองได้ และไม่มีระบบสลับลงระดับล่าง
2. สมัครหลายแพ็กเกจซ้อนกัน
FAQ ทางการระบุชัดเจนว่าการผูกบัญชีไม่สามารถซ้อนกันได้ (แผน Cursor + ลิงก์ SuperGrok/X Premium+ ไม่สามารถรวมโควตากันได้)
การสมัครสมาชิกสองระบบจะใช้โควตาของตัวที่สูงกว่าเท่านั้น ส่วนอีกตัวจะว่างเปล่า ไม่สามารถนำมารวมกันได้
3. ซื้อแพ็กเกจเสริมที่ grok.com
grok.com เน้นไปที่การแชทผ่านเว็บ ส่วน Grok Bot ใช้ระบบของ Cursor ซึ่งเป็นคนละบัญชีกัน การเติมเงินจึงไม่ช่วยเพิ่มโควตาให้ Bot
ข้อควรทราบเรื่องขอบเขต
เคล็ดลับเหล่านี้ช่วยประหยัดโควตารายสัปดาห์ของ Grok Bot แต่ทางการไม่เคยเผยแพร่จำนวน token หรือขีดจำกัดงานที่แน่ชัดของแต่ละแพ็กเกจ
สัดส่วนการใช้งานและข้อมูลการเรียกเก็บเงินในบทความนี้ส่วนใหญ่มาจากตัวอย่างส่วนตัวของบุคคลภายนอก การใช้งานจริงจะแตกต่างกันไปตามประเภทของงาน
ส่วนเรื่องการเชื่อมต่อ cloud computer ด้วยตัวเองหลังโควตาหมดก็เป็นข้อมูลจากบุคคลภายนอก ควรทดสอบด้วยตัวเองก่อนนำไปใช้จริง
บทสรุป
ทางการไม่ได้เผยแพร่จำนวน token หรือความจุงานรายสัปดาห์ของแต่ละแพ็กเกจ มีแค่การจัดอันดับเปรียบเทียบเท่านั้น
ในฐานะสมาชิกที่จ่ายเงิน เราหวังว่าจะได้เห็นรายละเอียดการบริโภคของงานและเครื่องมือที่โปร่งใสกว่านี้ จะได้ไม่ต้องมานั่งเดาเอาเองทุกวัน
บทความนี้พูดถึงปัญหาโควตาภายใต้โครงสร้างการสมัครสมาชิกรูปแบบเดิม ปัจจุบันทางการกำลังควบรวมระบบการสมัครสมาชิกเข้าด้วยกัน เมื่อแพ็กเกจใหม่ออกมา ผมจะมาตีความให้อ่านกัน หวังว่า Musk จะให้เราอยู่กันแบบไม่ต้องรัดเข็มขัดขนาดนี้ อุดมสมบูรณ์และเต็มอิ่มกว่านี้
อะไรคือสิ่งที่สูบโควตา Grok Bot ของคุณหมดเร็วที่สุด? มาคุยกันในคอมเมนต์ได้เลย
ผู้สร้างแอป Grok Bot แบบโอเพนซอร์ส (GitHub 1400+ Stars) ผู้ลงมือทำโปรเจกต์ AI ระดับล้านดอลลาร์ในพื้นที่จริง
อัปเดตคู่มือการใช้งานจริงและ prompt แบบก๊อปปี้ไปวางของ Grok Bot อย่างต่อเนื่อง กดติดตาม @cgnot996 ไว้ จะได้ไม่พลาดตกหลุมพรางเดียวกับผม
