ติดลิมิต AI ย้ายค่ายแล้วจะหนีพ้นหรือไม่?

 

ใช้ AI ทำงานมาสักพัก จะเจออาการหนึ่งเป็นครั้งคราว
กำลังทำงานอยู่ดี ๆ หน้าจอก็ขึ้นว่าใช้เกินโควตาแล้ว รอถึงอีกกี่โมงถึงจะใช้ต่อได้

ไม่ได้เจอบ่อย แต่พอเจอทีไรก็มักเป็นจังหวะที่งานยังไม่จบ

หงุดหงิดครับ ยอมรับตรง ๆ

แรก ๆ ก็แค่หงุดหงิดแล้วผ่านไป จนเจอซ้ำเข้าหลายครั้ง ถึงเริ่มสงสัยขึ้นมาจริงจัง
ไม่ใช่ว่าทำไมถึงติด แต่เป็นว่า ถ้าย้ายไปใช้ค่ายอื่น จะเจอเรื่องเดียวกันไหม

สงสัยแล้วก็ปล่อยผ่านมาพักใหญ่
สุดท้ายเลยไปนั่งค้นคว้าจริง ๆ จัง ๆ อยู่พักใหญ่
แล้วก็พบว่าความเข้าใจเดิมของตัวเองผิดอยู่หลายเรื่องเหมือนกัน

1. Claude คิดโควตายังไง

เรื่องแรกที่ต้องปรับความเข้าใจคือ Claude ไม่ได้นับเป็นจำนวนข้อความ
มันนับเป็นปริมาณงานที่ใช้ไปจริง

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

พอเป็นแบบนี้ ก็เลยเกิดเรื่องที่ผู้เขียนงงมานาน
คือยิ่งคุยยาว โควตายิ่งหมดเร็วขึ้นเรื่อย ๆ

วิธีนึกภาพที่ง่ายที่สุดคือ ให้คิดว่าเรากำลังคุยกับที่ปรึกษาที่ความจำสั้นมาก จำอะไรไม่ได้เลย
ทุกครั้งที่เราพูดประโยคใหม่ เขาต้องอ่านบันทึกการสนทนาทั้งหมดตั้งแต่ต้นซ้ำอีกรอบ ถึงจะตอบเราได้

ประโยคแรก เขาอ่านบรรทัดเดียว
ประโยคที่สามสิบ เขาต้องไล่ย้อนสามสิบรอบ

แชตยาว ๆ ที่ลากมาทั้งวันจึงกินโควตาหนักกว่าการเปิดแชตใหม่สิบครั้งเสียอีก ซึ่งขัดกับสัญชาตญาณพอสมควร

โครงสร้างลิมิตมีสองชั้น ชั้นแรกคือรอบ 5 ชั่วโมง เริ่มนับจากข้อความแรกที่เราพิมพ์ ไม่ใช่นาฬิกาตายตัว พิมพ์ครั้งแรกบ่ายสอง รอบก็ปิดทุ่มนึง ชั้นที่สองคือเพดานรายสัปดาห์ ซึ่งรีเซ็ตตามวันเวลาที่ระบบกำหนดให้แต่ละบัญชี ไม่ได้ตรงกันทุกคน

อีกจุดที่ผู้เขียนไม่เคยคิดถึงมาก่อน คือ โควตานี้ใช้ร่วมกันข้ามผลิตภัณฑ์
เว็บ แอปเดสก์ท็อป และ Claude Code ดึงจากถังเดียวกันหมด

ตรงนี้อธิบายอาการที่เคยเจอได้พอดี วันไหนที่รันงานหนักตอนเช้า พอบ่ายเปิดแชตธรรมดาแล้วเจอว่าเหลือนิดเดียว ก็เพราะแบบนี้เอง

ส่วนตัวเลขที่แน่นอน อย่าไปจำครับ มันเปลี่ยนบ่อยมาก แค่เดือนพฤษภาคมที่ผ่านมา Anthropic ก็เพิ่งเพิ่มโควตารอบ 5 ชั่วโมงเป็นสองเท่า และเลิกลดโควตาช่วงคนใช้เยอะที่เคยมีอยู่
ที่ควรจำคือหน้า Settings แล้วเข้าไปที่ Usage นั่นคือของจริง 

2. แล้วค่ายอื่นล่ะ

สั้น ๆ คือเจอเหมือนกันหมดครับ แต่คนละอาการ จนหลายคนไม่รู้ตัวว่ากำลังเจออยู่

ChatGPT ยังนับเป็นจำนวนข้อความเป็นหลัก และแยกโควตาตามโมเดล แต่ที่ต่างจากเพื่อนชัดที่สุดคือเวลาชนเพดานแล้วมันไม่หยุด ระบบจะสลับไปใช้โมเดลรุ่นเล็กกว่าให้เงียบ ๆ แล้วคุยต่อได้เหมือนไม่มีอะไรเกิดขึ้น

ความรู้สึกที่ได้จึงไม่ใช่การติดลิมิต แต่เป็น เอ๊ะ วันนี้มันตอบแย่ลงนะ

ส่วน Gemini คือจุดที่ทำให้ผู้เขียนต้องดูแล้วดูอีกหลายรอบเพื่อให้แน่ใจว่าเข้าใจไม่ผิด

เดิม Google นับเป็นจำนวนคำถามต่อวันแบบตายตัว ห้าคำถามบ้าง ร้อยคำถามบ้าง แล้วแต่แพ็กเกจ คนใช้ไม่หนักก็แทบไม่มีวันแตะเพดาน
นี่คือภาพที่คนส่วนใหญ่ยังจำกันอยู่ และเป็นภาพที่ผู้เขียนจำอยู่เหมือนกัน

แต่ในงาน Google I/O เมื่อพฤษภาคมที่ผ่านมา Google ประกาศเปลี่ยนไปใช้การนับตามปริมาณงาน รอบ 5 ชั่วโมง บวกเพดานรายสัปดาห์ โดยระบุตรง ๆ ว่าความซับซ้อนของคำถาม ฟังก์ชันที่เรียกใช้ และความยาวของบทสนทนา มีผลต่อโควตาทั้งหมด

ซึ่งก็คือกลไกเดียวกับ Claude ทุกประการ

ประเด็น	Claude	ChatGPT	Gemini
หน่วยที่ใช้นับ	ปริมาณงานที่ใช้จริง	จำนวนข้อความ แยกโควตาตามโมเดล	ปริมาณงานที่ใช้จริง
รอบรีเซ็ต	5 ชั่วโมง + รายสัปดาห์	3 ชั่วโมง + รายสัปดาห์บางโมเดล	5 ชั่วโมง + รายสัปดาห์
เมื่อชนเพดาน	โมเดลหนักหมดก่อน สลับไปตัวเบาทำต่อได้ ถ้าหมดทั้งถังคือหยุด	สลับไปโมเดลรุ่นเล็กอัตโนมัติแบบเงียบ ๆ	สลับไปโมเดลรุ่นเบาทำต่อ
มีหน้าดูโควตาคงเหลือ	มี	ไม่มี	มี
ความจุต่อหนึ่งบทสนทนา	ราว 200,000 tokens	32,000 (โมเดลเร็ว) ถึง 256,000 (โมเดลคิดลึก)	ถึง 1,000,000 (แพ็กเกจเสียเงิน)

* ข้อมูลปรับปรุงล่าสุดเมื่อ 02/09/2569 อ้างอิงจากเอกสารทางการของแต่ละค่าย ตัวเลขเหล่านี้เปลี่ยนแปลงบ่อยมาก ควรตรวจสอบจากหน้าทางการก่อนนำไปอ้างอิงต่อ

สิ่งที่ตารางนี้บอก ไม่ใช่ว่าค่ายไหนดีกว่ากัน
มันบอกว่าทั้งอุตสาหกรรมกำลังเดินมาบรรจบที่วิธีคิดเดียวกัน

พอโมเดลระดับสูงมีต้นทุนคำนวณมหาศาล การนับหัวข้อความก็ไม่ยุติธรรมกับใครเลย คนถามสั้น ๆ วันละสิบคำถาม กับคนโยนเอกสารเข้าไปวันละสิบไฟล์ ไม่ควรถูกคิดเท่ากัน ทุกค่ายเลยทยอยย้ายมานับตามงานจริง

ความต่างที่เหลืออยู่จริง ๆ อยู่ที่ว่ามันเลือกจะบอกเราตอนไหน และบอกด้วยวิธีไหน

3. เรื่องที่คนสับสนมากที่สุด

ระหว่างที่กำลังค้นคว้า ผู้เขียนเจอความสับสนหนึ่งที่แพร่หลายมาก และเป็นเรื่องที่ตัวเองก็เคยสับสนด้วย

คือการเอาสองอย่างที่คนละเรื่องกันมาปนกัน

อย่างแรกคือความจุต่อหนึ่งบทสนทนา ศัพท์เทคนิคเรียก context window แปลง่าย ๆ ว่าอ่านได้ทีละกี่หน้า
อย่างที่สองคือโควตารวมต่อช่วงเวลา แปลว่าใช้ได้นานแค่ไหนก่อนต้องพัก

สองอย่างนี้ไม่เกี่ยวกันเลย แต่ถูกพูดปนกันจนกลายเป็นข้อสรุปที่ผิด

ที่ได้ยินบ่อยที่สุดคือประโยคทำนองว่า Claude ใส่เอกสารยาว ๆ ไม่ค่อยได้ ซึ่งไม่จริง ความจุ 200,000 tokens นั้นใหญ่กว่าโมเดลใช้งานประจำวันของ ChatGPT หลายเท่า

ความจริงคือใส่ได้ แต่ใส่แล้วกินโควตาเร็ว

ทำไมเรื่องนี้ถึงสำคัญ เพราะมันทำให้เราแก้ปัญหาผิดจุด
คนที่คิดว่าปัญหาคือความจุไม่พอ จะไปหาเครื่องมือที่ความจุใหญ่กว่า ทั้งที่ปัญหาจริงคือนิสัยการใช้ที่กินโควตาเปลือง ซึ่งย้ายไปค่ายไหนมันก็ตามไปด้วย

แล้วความจุใหญ่ก็ไม่ได้แปลว่าอ่านแม่นเท่าเดิมด้วย เอกสารของ Google เองยังเขียนไว้ตรง ๆ ว่าเมื่อเนื้อหาเกินความจุ โมเดลอาจมองข้ามรายละเอียดหรือพลาดความเชื่อมโยงบางจุด

คำถามที่ควรถามจึงเป็น อ่านแล้วสรุปได้ตรงแค่ไหน มากกว่าจะถามว่าใส่ได้กี่หน้า

4. ใช้ยังไงให้ชนน้อยลง

พอรู้ว่าทุกค่ายเดินมาทางเดียวกัน คำถามในหัวก็เปลี่ยนไปเองครับ
จากที่เคยคิดว่าค่ายไหนใจดีกว่า กลายเป็นว่าเราใช้มันคุ้มกับที่จ่ายไปหรือเปล่า

เรื่องแรกที่ผู้เขียนปรับคือการวางงานให้ถูกที่
งานอ่านเอกสารหนา ๆ รอบเดียวจบ เหมาะกับเครื่องมือที่ความจุใหญ่ ส่วนงานที่ต้องคิดต่อเนื่อง แก้ไปแก้มาหลายรอบ กลั่นความคิดไปเรื่อย ๆ เหมาะกับเครื่องมือที่ตามบริบทได้ลึกและเถียงกับเราได้ ส่วนงานถามสั้นตอบไว ไม่ต้องใช้ของแพงเลย

การพยายามใช้เครื่องมือเดียวทำทุกอย่าง คือสาเหตุอันดับหนึ่งของการชนลิมิต

ส่วนนิสัยการใช้ที่ช่วยได้จริง มีอยู่ไม่กี่ข้อ

หนึ่งแชต หนึ่งงาน พองานจบ ให้สรุปผลออกมาเป็นบันทึกสั้น ๆ แล้วเปิดแชตใหม่ ใช้บันทึกนั้นเป็นจุดตั้งต้น วิธีนี้ตัดต้นทุนสะสมทิ้งทั้งก้อน
ของแถมคือเราได้ความคิดที่ผ่านการกลั่นมาแล้วหนึ่งชั้น ซึ่งบางทีมีค่ากว่าตัวบทสนทนาเดิมเสียอีก

เอกสารอ้างอิงที่ใช้ประจำ วางไว้ที่เดียว อย่าแนบไฟล์เดิมซ้ำทุกแชต ทุกค่ายมีที่เก็บบริบทถาวรให้ใช้แล้ว

เลือกน้ำหนักโมเดลให้ตรงกับน้ำหนักงาน อย่าเอาโมเดลคิดหนักที่สุดมาช่วยแก้คำผิด

ถามให้ครบในรอบเดียว ถามยาวหนึ่งรอบถูกกว่าถามทีละบรรทัดสิบรอบมาก เพราะสิบรอบนั้นต้องไล่อ่านย้อนหลังทุกครั้ง

ดูมาตรวัดให้เป็นนิสัย เหมือนเหลือบมองเข็มน้ำมันตอนขับรถ ดีกว่ารอจนรถดับกลางทาง

เรื่องสุดท้ายเป็นความคิดล้วน ๆ ไม่ใช่เทคนิค

โควตาไม่ใช่ศัตรู มันคือข้อมูลที่บอกว่าเรากำลังใช้ทรัพยากรไปกับอะไร

ผู้เขียนลองสังเกตตัวเองอยู่พักหนึ่ง แล้วพบว่าวันที่ชนลิมิตเร็วผิดปกติ มักไม่ใช่วันที่ทำงานหนักที่สุด
แต่เป็นวันที่ทำงานกระจัดกระจายที่สุด ถามไปเรื่อย ไม่มีเป้า ลากแชตเดียวตั้งแต่เช้าจนเย็นโดยเปลี่ยนเรื่องไปห้ารอบ

วันที่รู้ว่าจะเอาอะไร เตรียมคำถามมาดี ทำเสร็จเป็นเรื่อง ๆ โควตาแทบไม่ขยับ

5. ทำไมเรื่องนี้ถึงดังจากฝั่ง Claude เป็นพิเศษ

ถ้าทุกค่ายมีลิมิตเหมือนกัน แล้วทำไมเราถึงได้ยินเรื่องนี้จากฝั่ง Claude มากกว่าเพื่อน

ส่วนหนึ่งเป็นเรื่องของคนใช้ ผู้ใช้หนักของ Claude กระจุกอยู่ที่งานเขียนโปรแกรมและงานเอกสารยาว ซึ่งกินทรัพยากรมากที่สุด และคนกลุ่มนี้อยู่บนเวทีสาธารณะที่ค้นเจอง่าย ขณะที่ผู้ใช้ทั่วไปของค่ายอื่นถามวันละไม่กี่คำถาม ไม่เคยเข้าใกล้เพดาน ก็ไม่มีอะไรให้พูดถึง

แต่เรื่องที่น่าคิดกว่าคือวิธีที่ระบบเลือกจะแจ้งเรา

ระบบที่หยุดแล้วบอกตรง ๆ ว่าหมดโควตา จะถูกบ่นทันที
ระบบที่สลับไปโมเดลเล็กกว่าให้เงียบ ๆ จะไม่ถูกบ่น เพราะไม่มีใครรู้ตัว

ตอนแรกผู้เขียนคิดว่าแบบตรงไปตรงมาย่อมดีกว่า แต่คิดไปคิดมาก็ไม่แน่ใจนัก

การบอกตรง ๆ จะดีก็ต่อเมื่อมันบอกล่วงหน้าและคาดเดาได้ ถ้ามาบอกเอาตอนชนแล้วโดยที่เราไม่เคยรู้เลยว่าใกล้หมด มันก็ไม่ได้ดีกว่าการเงียบเท่าไหร่ ความโปร่งใสที่ไม่มีเครื่องมือให้วางแผน ก็ยังไม่ใช่ความโปร่งใสที่ดีพอ

อีกเรื่องคือหน่วยนับ

บอกว่าส่งได้ 160 ข้อความต่อสามชั่วโมง คนนับเองได้ วางแผนได้ ยอมรับได้ ถึงจะไม่แฟร์กับคนถามสั้นก็ตาม
แต่พอบอกว่านับตามปริมาณงาน ขึ้นกับความยาวแชต ไฟล์แนบ โมเดล และระดับการคิด อันนี้ยุติธรรมกว่ามาก แต่คาดเดาไม่ได้เลย

ผลคือความรู้สึกว่าอยู่ ๆ ก็โดนตัด
ระบบที่ยุติธรรมกว่ากลับอธิบายยากกว่า และสิ่งที่อธิบายยาก มักถูกตัดสินไปก่อนว่าไม่ยุติธรรม

บทส่งท้าย

กลับมาที่คำถามที่ค้างอยู่ในหัวมานาน

ย้ายไปค่ายอื่นแล้วจะเจอเรื่องเดียวกันไหม

เจอครับ และกำลังจะเหมือนกันมากขึ้นเรื่อย ๆ เพราะทุกค่ายกำลังเดินมาเจอความจริงข้อเดียวกัน คือสติปัญญาที่ดีมีต้นทุน และต้นทุนนั้นไม่มีทางฟรี

สิ่งที่เราคุมไม่ได้คือเพดานของเครื่องมือ สิ่งที่เราคุมได้คือวิธีที่เราใช้มัน

อ่านจบแล้วผู้เขียนไม่ได้คำตอบว่าควรย้ายค่ายหรือไม่
ได้มาแค่คำถามที่ตรงกว่านั้น

วันที่ชนลิมิต เราใช้มันหมดไปกับงานที่สำคัญจริง ๆ หรือเปล่า

---

เขียนเมื่อ 2 กันยายน 2569 | ที่มาของข้อมูล: support.claude.com, help.openai.com, support.google.com, ประกาศจาก Google I/O 2026