Claude Code จำกัดการใช้งานรายสัปดาห์

 (news.ycombinator.com)
1 คะแนน โดย GN⁺ 2025-07-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการนำ ข้อจำกัดการใช้งานรายสัปดาห์ มาใช้กับบริการ Claude Code ของ Anthropic
  • มีผลกับผู้ใช้ฟรีและผู้ใช้แบบชำระเงินทั้งหมด
  • ผู้ใช้จะถูกจำกัดด้วย จำนวนคำขอสูงสุดหรือปริมาณโทเคนที่ประมวลผลได้ ภายในหนึ่งสัปดาห์
  • การนำข้อจำกัดนี้มาใช้มีเป้าหมายเพื่อป้องกันการใช้งานบริการในทางที่ผิดและ รักษาเสถียรภาพของทรัพยากรระบบ
  • นักพัฒนาและสตาร์ทอัพต้องให้ความสำคัญกับ การจัดการทรัพยากร เพิ่มมากขึ้นเมื่อใช้งาน API

ภาพรวมการนำข้อจำกัดการใช้งานรายสัปดาห์ของ Claude Code มาใช้

มีการใช้นโยบาย ข้อจำกัดการใช้งานรายสัปดาห์ ใหม่กับบริการ Claude Code ที่ Anthropic ให้บริการ

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

ผลกระทบสำคัญต่อกลุ่มนักพัฒนาและสตาร์ทอัพ

  • การใช้ Claude Code ในการพัฒนาผลิตภัณฑ์จำเป็นต้องมี การวางแผนการใช้งาน มากขึ้น
  • บริการที่เชื่อมต่อกับ API มีความจำเป็นต้องเพิ่มตรรกะสำหรับ การจัดการอัตโนมัติหรือการแจ้งเตือนเมื่อเกินขีดจำกัด
  • หากมีการสร้างโค้ดจำนวนมาก การวิเคราะห์ หรือการเรียกใช้งานซ้ำ ๆ ความสำคัญของ การเพิ่มประสิทธิภาพการใช้ทรัพยากร จะยิ่งสูงขึ้น

บทสรุป

  • การนำข้อจำกัดการใช้งานรายสัปดาห์ของ Claude Code มาใช้มีเป้าหมายเพื่อ ความยั่งยืน และยกระดับคุณภาพของบริการ
  • สตาร์ทอัพและผู้เชี่ยวชาญด้าน IT ควรตรวจสอบ ข้อจำกัดรายสัปดาห์ และวางแผนการใช้งานเมื่อต้องเชื่อมต่อกับระบบเดิมหรือออกแบบบริการ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-07-29
ความคิดเห็นจาก Hacker News

  • คิดว่าตัวเองคงไม่ถึงลิมิตรายสัปดาห์หรอก แต่ที่น่ากังวลคือลิมิตนี้เป็นแบบรายสัปดาห์ ไม่ใช่แบบช่วงละ 36 ชั่วโมง
    ถ้าชนลิมิต ก็จะใช้งานไม่ได้ไปทั้งสัปดาห์นั้น
    การใช้เครื่องมือที่คุ้นมือไม่ได้เป็นเวลานานแบบนี้มันไม่สะดวก
    อาจมีคนบอกว่าฉันพึ่งพา Claude มากเกินไป แต่กับเครื่องมืออื่นอย่าง ripgrep ก็เหมือนกัน
    ถ้าใช้ไม่ได้ไม่กี่วันยังพอรับได้ แต่ทั้งสัปดาห์มันนานเกินไป
    แล้วที่บอกว่ามีผลกับ “ผู้ใช้น้อยกว่า 5%” ก็สะดุดตาเหมือนกัน
    ปกติประกาศแนวนี้มักจะบอกว่ากระทบไม่ถึง 1% แต่ Anthropic กำลังบอกว่า 1 ใน 20 คนจะชนลิมิต

    • ความรู้สึกมันเหมือนกับลิมิต o3 100 ครั้ง/สัปดาห์ในแผน ChatGPT Plus เป๊ะ
      เราไม่รู้ด้วยซ้ำว่าใช้ไปเท่าไรแล้ว พอเป็นทรัพยากรสำคัญก็เลยเผลอประหยัดโดยสัญชาตญาณ
      สุดท้ายก็ใช้แผนได้ไม่คุ้ม แล้วหันไปใช้โมเดลอย่าง o4-mini แทน
      จริง ๆ ลิมิตรายวันยังดีกว่า
      แต่ก็ไม่แน่ว่าการทำให้คนใช้แบบกั๊ก ๆ เพราะกลัวไม่พอ อาจเป็นจุดประสงค์ของลิมิตรายสัปดาห์ก็ได้

    • มันน่าเศร้าที่นักพัฒนาต้องพึ่งบริการออนไลน์แบบผูกขาดมากขึ้นเรื่อย ๆ
      เมื่อก่อนทำทุกอย่างได้ด้วยเครื่องมือ FOSS และไม่ต้องผูกติดกับบริษัทหรือบริการไหนด้วยค่าสมาชิกรายเดือน
      ตอนนี้บางคนก็เหมือนเกษตรกรของ Monsanto ที่ต้องจ่ายเงินทุกเดือนเพื่อใช้เครื่องมือ จนลืมวิธีทำงานถ้าไม่มีมัน

    • ฉันชนลิมิต Pro ด้วย sonnet บ่อยมาก วันละ 3 ครั้ง
      ถ้าใช้ Claude code กับ claude พร้อมกัน ก็หมดใน 30 นาที
      ทั้งที่ไม่ได้รัน multi-agent 24/7 หรือเปิดหลายหน้าต่างเลย
      ฉันก็ไม่คิดว่าตัวเองเป็นผู้ใช้ระดับท็อป 5% นะ แต่ถ้าลิมิตหมดตั้งแต่วันพุธก็ไม่แปลกใจ
      เพิ่งคิดจะใช้งานแชต Claude ให้มากขึ้น แต่ถ้าต้องใช้อย่างไม่มั่นใจไปอีกหลายวันก็ไม่มีความหมาย

    • Anthropic บอกว่า 1 ใน 20 คนจะชนลิมิต แต่ก็ดูไม่น่าเป็นไปได้ว่าจะมีคนแชร์บัญชีหรือใช้อัตโนมัติ 24/7 มากขนาดนั้น

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

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

    • คำว่าไม่จำกัดนั้นใช้ได้ดีกับบริการที่ “ต้นทุนถูกจนแทบวัดไม่ได้” ทุกประเภท
      อินเทอร์เน็ต, SMS และอื่น ๆ ทำได้เพราะต้นทุนตรงนั้นถูกมาก
      แต่ LLM ตอนนี้ยังมีต้นทุนตรงต่อการรันแต่ละครั้งค่อนข้างสูง

    • ฉันไม่เห็นด้วยกับโครงสร้างที่คาดหวังให้การใช้งานกระจายสม่ำเสมอทั้งเดือน
      ปกติฉันอาจใช้ทั้งเดือนเรื่อย ๆ แต่บางทีก็มีช่วงที่ใช้หนักวันละ 11 ชั่วโมงอยู่หลายวัน และตอนนั้นแหละที่มีโอกาสชนลิมิตมากที่สุด
      เพราะแบบนี้ใช้ API เองยังรู้สึกดีกว่า เพราะลิมิตจะขึ้นกับความลึกกระเป๋าของตัวเอง
      ใช้ OpenRouter ก็ช่วยเลี่ยงข้อจำกัดของระบบสมาชิกได้
      ช่วงนี้ Gemini 2.5 Pro เหมาะกับงานเขียนโค้ดมากกว่า Claude สำหรับฉัน
      ก็เลยสงสัยว่ามีตัวเลือกอื่นที่คุ้มต้นทุนอีกไหม
      https://docs.anthropic.com/en/api/rate-limits#rate-limits

    • ความเห็นของฉันคือเครื่องมือพวกนี้ควรเลิกโมเดลแบบ “20 ดอลลาร์/เดือน” หรือ “200 ดอลลาร์/เดือน” ที่ให้เข้าถึงปริมาณจำกัดและคำนวณลิมิตยาก ๆ ไปเลย
      ควรเปลี่ยนเป็นคิดตามการใช้งานทั้งหมดถึงจะเป็นมิตรกับผู้ใช้จริง
      อาจให้ free tier แบบใช้ฟรี 20 ครั้งแรกสำหรับทดลอง หรือคิดราคาเป็นขั้นบันไดตามปริมาณการใช้ แล้วผู้ใช้สายโหดมากค่อยจ่ายตามต้นทุนจริง
      แบบนี้ผู้ใช้ที่ใช้ไม่มากก็จ่ายถูกลง และยังช่วยรักษาส่วนแบ่งตลาดได้
      ถ้าตั้งราคาดีกว่า OpenRouter คนก็จะอยู่ใน ecosystem นี้แทนที่จะย้ายไปใช้เครื่องมือคนนอก
      ถ้าเครื่องมือดีจริง ต่อให้คิดตามการใช้งาน ผู้ใช้ก็ยังอยู่
      ปัญหาคือผู้ให้บริการอยากอุดหนุนผู้ใช้เพื่อแย่งส่วนแบ่งตลาด แต่ก็อยากกันการใช้งานแบบสุดโต่งหรือการ abuse ไปพร้อมกัน
      คำตอบที่แก้ได้ 100% คือคิดตามการใช้งานแบบเต็มรูปแบบ ไม่มีค่าแรกเข้า
      แต่ถ้าทำแบบนี้ คนที่สมัครไว้แต่ใช้น้อยอาจเสียประโยชน์ ทีมขายก็คงไม่ชอบ
      อีกอย่าง ผู้ใช้ก็จะย้ายค่ายง่ายขึ้นเพราะเทียบกันไปมาได้ตลอด และความรู้สึกว่าถูกผูกไว้หนึ่งถึงสองเดือนก็จะหายไป

    • ระยะยาวฉันคิดว่า local LLM จะเก่งกว่าคลาวด์ LLM ที่ดีที่สุดของปี 2025 จนงานประจำวัน 99% ทำได้แบบไม่จำกัด
      แล้วค่อยต่อคลาวด์เฉพาะปัญหาที่ซับซ้อนจริง ๆ
      LLM จะพัฒนาให้มีประสิทธิภาพขึ้นเรื่อย ๆ และต้นทุน GPU, หน่วยความจำ, ที่เก็บข้อมูล ก็จะถูกลงและเข้าถึงง่ายขึ้นต่อเนื่อง
      ตอนนี้แค่ยังอยู่ในช่วงเปลี่ยนผ่าน เลยดูขัด ๆ อยู่บ้าง

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

  • ฉันสับสนเรื่องความต่างระหว่าง Max 5x กับ Max 20x
    ในอีเมลของฉันเขียนว่า “ผู้ใช้ Max 20x ส่วนใหญ่จะใช้ Sonnet 4 ได้ 240~480 ชั่วโมงต่อสัปดาห์ และ Opus 4 ได้ 24~40 ชั่วโมง”
    แต่ประกาศทางการบอกว่า “ผู้ใช้ Max 5x ส่วนใหญ่จะใช้ Sonnet 4 ได้ 140~280 ชั่วโมงต่อสัปดาห์ และ Opus 4 ได้ 15~35 ชั่วโมง”
    ถ้าอย่างนั้นอย่างน้อยลิมิตก็น่าจะมากกว่าตามราคาสักเกิน 2 เท่า แต่ Opus 4 ต่างกันแค่ 5~9 ชั่วโมงเอง
    อย่างน้อยไม่ควรได้ 2 เท่าหรือ? ในเมื่อจ่ายแพงเป็นสองเท่า

    • ถ้าเป็นแบบนี้จริง ฉันคงลดจาก Max 20x ลงแผนต่ำกว่านี้ทันที
      ที่ออสเตรเลียฉันจ่ายเดือนละ 350 ดอลลาร์

    • ฉันอัปเกรดไป 20x เพราะชนลิมิต Opus ตลอด แต่ตอนนี้ดูแล้ว 20x กับ 5x แทบไม่ต่างกันเลย

    • เพราะงั้นฉันเลยเลิกใช้ MAX แล้วดาวน์เกรดเป็น Pro จากนั้นไปใช้ o3 กับโมเดลอื่นผ่าน API
      ช่วงแรก ๆ ไม่ต้องใช้เยอะขนาดนั้น ดังนั้นโปรเจกต์หนึ่งใช้เงินราว 10 ดอลลาร์ก็ใช้ o3, Gemini, Opus ได้หมด
      ทุกไม่กี่วันก็มีโมเดลใหม่ออกมา ฉันไม่อยากผูกกับผู้ให้บริการรายเดียว

    • ในทางปฏิบัติมันไม่ได้เพิ่มปริมาณการใช้เป็น 2 เท่า แต่เป็นการได้ priority สูงขึ้นตอนทราฟฟิกแน่นมากกว่า

    • ถ้าเนื้อหาในเอกสารการตลาดไม่ตรงกับความจริง ก็หวังว่าจะมีใครสักคนเอาข้อมูลจริงไปตรวจสอบแล้วฟ้องแบบกลุ่ม

  • เข้าใจนะว่าแม้จ่ายเดือนละ 200 ดอลลาร์ก็ยังไม่พอ
    ถ้าอย่างนั้นก็ควรมีแผนที่แพงพอให้คนใช้ได้แบบไม่ต้องกังวลเรื่องลิมิตด้วย
    ไม่มีอะไรทำลาย flow ไปมากกว่าข้อความแนว “หมดเวลา!”
    อย่างน้อยถ้าเป็นระบบเครดิต เราก็เห็นว่าใช้ไปเท่าไรและจ่ายเพิ่มได้
    แต่แนวคิดแบบ “รอ GPU เย็นก่อน” ไม่ช่วยเรื่อง productivity เลย
    ถ้ารัน agent หลายตัว “35 ชั่วโมง” นี่ไม่พออย่างแรง
    แปลกด้วยที่ตัวเครื่องมือถูกออกแบบมาให้รองรับการใช้งานลักษณะนี้

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

    • ฉันไม่คิดว่า “รัน agent หลายตัว” จะเป็น use case ปกติของแผนส่วนบุคคล
      กรณีแบบนี้ปกติต้องจ่ายตามการใช้ผ่าน API อยู่แล้ว
      ที่ fixed plan เคยยอมให้ทำได้ถือว่าบริการใจกว้าง และเดิมทีเขาก็โฆษณาว่าเป็น “ลิมิตที่สูงขึ้น” ไม่ใช่ “ไม่จำกัด” อยู่แล้ว

    • API มีความยืดหยุ่นเรื่องลิมิตมากกว่าเยอะ และในทางปฏิบัติก็แทบไม่มีข้อจำกัด
      Claude ใช้ได้ผ่าน Aws, gcp ด้วย ทำให้ลิมิตและเครดิตต่างกัน และอัตราค่าบริการก็ไม่เหมือนกัน

    • ควรออกแบบนโยบายโดยยึด “ผู้ใช้ที่ดี” เป็นหลัก ไม่ใช่ตั้งตาม “ผู้ใช้ที่แย่”

    • ก็ใช้ API ไปเลยสิ

  • โดยรวมแล้ว ฉันคิดว่านี่เป็นการเปลี่ยนแปลงเชิงบวกที่ช่วยปกป้องระบบจากผู้ใช้บางรายที่รันหลาย agent ตลอด 24/7
    เพื่อให้ผู้ใช้อีกจำนวนมากยังใช้งานได้ต่อเนื่อง
    แต่สิ่งที่น่าหงุดหงิดคือไม่แสดงว่า “เหลือการใช้งานอีกเท่าไร”
    จะกี่เปอร์เซ็นต์ก็ไม่เป็นไร อย่างน้อยถ้ามีการเตือนเป็นระยะ ๆ เช่น ตอนใช้ไปครึ่งหนึ่ง ก็จะวางแผนได้ง่ายขึ้น
    การไม่ให้ข้อมูลนี้ทำให้อดคิดไม่ได้ว่า “หรือเขาไม่อยากให้เราวัดมัน?”
    ไม่ใช่ว่าฉันอยากติดตามแบบละเอียด แค่อยากรู้คร่าว ๆ ว่าตัวเองอยู่ตรงไหนแล้ว

  • ตามบัญชี Reddit ของ Anthropic
    มีผู้ใช้คนหนึ่งใช้ LLM มูลค่าหลายหมื่นดอลลาร์ด้วยแผนราคา $200
    ทางบริษัทกำลังพัฒนาโซลูชันแยกสำหรับผู้ใช้ขั้นสูง
    แต่ลิมิตใหม่ครั้งนี้มีเป้าหมายเพื่อให้ประสบการณ์ยุติธรรมขึ้น และป้องกันการแชร์บัญชีกับการนำไปขายต่อ
    เพราะแบบนี้นี่เองที่เราถึงไม่ได้ “บริการดี ๆ” แบบเดิม

    • สตาร์ตอัปเก่าที่ฉันเคยทำงานก็เคยมีตัวเลือกแบบไม่จำกัด
      ตอนแรกเราคิดว่าไม่มีใครใช้หนักขนาดนั้นหรอก แต่ในความเป็นจริงมีผู้ใช้จำนวนมากที่หาวิธีรีดขีดจำกัดของบริการได้อย่างสร้างสรรค์
      มีบัญชีที่เชื่อมต่อบริการไว้ตลอด 24/7 แล้วไล่ยิงคำขอจนถึง 95% ของ request limit ตลอดเวลา
      ใช้ IP หลายแบบ และมีรูปแบบการใช้งานที่ดูไม่เหมือนมนุษย์ด้วย
      ช่วงแรกเรามองว่าเป็นแค่ outlier แต่พอบัญชีแบบนี้เพิ่มขึ้นแบบทวีคูณ
      ก็พบว่าจริง ๆ เป็นหลายบริษัทที่สร้างหลายบัญชีไว้ทำ load balancing กันเอง
      ถ้าดูกราฟกำไร-ขาดทุนเฉลี่ยต่อผู้ใช้ บัญชีพวกนี้สร้างแต่การขาดทุนมหาศาลและกินทรัพยากรเต็มเพดาน จนสุดท้ายนโยบายต้องเปลี่ยน
      แม้จะเสีย “ลูกค้า” กลุ่มนั้นไป แต่ผู้ใช้ทั่วไปส่วนใหญ่ไม่ได้รับผลกระทบ
      กลับทำให้บริการโดยรวมลื่นขึ้นด้วย
      สตาร์ตอัปที่มีผู้ใช้ใช้หนักทุกแห่งต้องเจอประสบการณ์แบบนี้

    • จริง ๆ แล้วบริษัทอาจกำลังขายบริการแบบขาดทุนอยู่ก็ได้

    • แม้แต่ลิมิตปัจจุบันก็ยังกันการ abuse แบบนี้ไม่ได้หรือ? ฉันไม่ค่อยเข้าใจ

    • เมื่อวานมีคนไปอวดบน Twitter
      ว่าใช้บัญชี $200 ไปมูลค่า $13,200 และรัน agent เฉพาะ Opus 4~5 ตัวแบบ 24/7 ให้เรียกกันเองแบบ recursive
      อันนี้ถือว่าเป็นการ abuse ชัดเจนและควรถูกจัดการ
      แต่ก็ไม่รู้จริง ๆ ว่าผู้ให้บริการ inference ควรหยุดมันอย่างไร
      Cursor ตอนนี้ลำบากกว่าเดิมเพราะบวก premium เพิ่มจาก Anthropc/OpenAI
      Anthropic เองก็เจอสถานการณ์คล้ายกัน แต่ที่นี่ไม่มีตัวเลือก premium
      ถ้าปล่อยให้ใช้ได้ถึงต้นทุนจริงเดือนละ 500 ดอลลาร์ในราคา 20 ดอลลาร์ เท่ากับลดให้ 95% ซึ่งไม่มีทางแบกได้
      การอุดหนุนแบบนี้นานไปก็ยิ่งสร้างบรรยากาศในชุมชนที่รู้สึกว่าตัวเอง “มีสิทธิ์ได้” มากขึ้น
      มันให้ความรู้สึกเหมือนถูกแย่งของที่เคยชินไป แต่เอาเข้าจริงแค่ capex/opex ก็หนักแล้ว ยังไม่รวมต้นทุน R&D ด้วย ดังนั้นโครงสร้างแบบนี้รักษาโมเดลไว้แทบไม่ได้
      สุดท้ายสิ่งที่ทำได้จริงก็คือ “ปรับโครงสร้างราคาไปเรื่อย ๆ แล้วให้ผู้ใช้ย้ายไปหาบริษัทที่อุดหนุนหนักกว่าในรอบถัดไป”
      ถ้าจะให้ดี นโยบายแบบนี้ควรประกาศแต่แรกว่าเป็น trial และพูดให้โปร่งใสไปเลยว่ามีการ subsidize อยู่ประมาณไหน
      คนจะได้ลองใช้โมเดลและยังมีบางส่วนอยู่ต่อ ถึงจะมีคนหลุดไปบ้างแต่ความไม่พอใจก็น่าจะน้อยกว่า
      ถ้าเปิดเผยโครงสร้าง capex/opex/ต้นทุนพัฒนาอย่างตรงไปตรงมา
      คนก็น่าจะเข้าใจได้ว่า “มันระดับเดียวกับการจ้าง senior engineer ที่ไม่รู้จักเหน็ดเหนื่อยคนหนึ่ง”

  • ถ้าอีเมลนี้มีข้อมูลรายเดือนด้วยว่า “เดือนไหนเคยชนลิมิตบ้าง (Aug 2024, Jan 2025, May 2025 ฯลฯ)” มันจะมีประโยชน์กว่านี้มาก
    ฉันไม่รู้เลยว่าตัวเองอยู่ในกลุ่มท็อป 5% หรือเปล่า
    จริง ๆ ลิมิตแบบ 1% ยังพอเข้าใจได้ แต่ในวงการ SaaS ตัวเลข 5% นี่ถือว่าเป็นผู้ใช้จริงจำนวนมากแล้ว

  • บริการแบบนี้ต้องมีแผนคิดเงินตามการใช้งาน
    บริษัท AI ทุกเจ้ากำลังชนปัญหาเดียวกัน
    ระบบสมาชิกแบบคิดราคาเหมาจ่ายถูกออกแบบมาให้ผู้ใช้ไม่ต้องคิดเรื่องต้นทุน
    แต่พอมี power user จำนวนน้อยมากใช้จนสุดเพดานของ subscription
    ก็เกิดบริการอย่าง Terragon ที่ถูกพัฒนามาเพื่อ optimize การใช้ปริมาณนั้นโดยเฉพาะ
    ผลคือบริษัทต้องคอยลดลิมิตลงเรื่อย ๆ และผู้ใช้กลับยิ่งต้องคิดเรื่องค่าใช้จ่ายมากขึ้น
    Cursor ก็ปรับลิมิตมาหลายรอบแล้ว และตอนนี้ Anthropic ก็กำลังตามมา
    ท้ายที่สุดคือไม่อยากอุดหนุนผู้ใช้สายโหดระดับท็อป 10% อีกต่อไป
    อยากให้มีแผนคิดตามการใช้งานที่ใช้ได้ตรงจากเว็บอินเทอร์เฟซ

    • มี API อยู่แล้ว แค่สร้าง token เองก็ใช้ Claude Code ได้ทันทีโดยไม่ต้องมีแผนแยก

    • ทำให้นึกถึงยุค shared hosting ในทศวรรษ 1990

    • ถ้ามี web plan แบบคิดตามการใช้งาน ก็ต้องเปิดเผยว่าต้นทุนจริงของการรองรับ inference แพงแค่ไหน ซึ่งคงลำบากใจ
      ตอนนี้การรัน AI ในระดับใช้งานจริงที่ให้ productivity สูงยังแพงมากอยู่

  • เพราะ “รูปแบบการใช้งานขั้นสูงที่รัน Claude เป็น background ตลอด 24/7” พวกเราถึงไม่ได้ใช้บริการดี ๆ แบบเดิม

    • แต่เวลาโฆษณา บริการ AI ทั้งหลายก็มักพูดว่า “AI จะทำงานให้เอง นักพัฒนาจะได้ไปดื่มกาแฟหรือหลับไปก็ยังงานเสร็จ” และก็มีนักพัฒนาที่ใช้งานตามนั้นอย่างสมเหตุสมผลจริง ๆ
      พอมาตอนนี้กลับบอกว่าผู้ใช้แบบนั้นเป็นปัญหา ก็ดูแปลกอยู่

    • อ่านตรงนั้นแล้วขำเลย
      ให้ความรู้สึกเหมือน ‘ผู้ทำลายโลกผู้หวังดี’ ที่กำลังเร่งให้จักรวาลเข้าสู่ภาวะความร้อนตายเร็วขึ้นอีกหน่อย

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

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

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

  • อาจเป็นข้อเสนอแปลก ๆ แต่ฉันนึกถึงลิมิตแบบ adaptive
    ตัวเลือก 1: ช่วงแรกให้ใช้ได้แบบ burst ในระยะสั้น แล้วค่อย ๆ ลดความเร็วลง และหลัง cooldown ค่อยกลับมาบูสต์ได้อีก
    แบบนี้ผู้ใช้จะเร่ง productivity ได้ในช่วงสั้น ๆ และเซิร์ฟเวอร์ก็ได้พัก
    ตัวเลือก 2: เหมือนแพ็กเกจ data มือถือ คือช่วงแรกใช้ request ได้เร็ว แล้วหลังจากนั้นค่อย throttle ถ้าต้องการเพิ่มก็จ่ายซื้อเพิ่ม
    แบบนี้ก็เป็นโมเดลที่มีรายได้เพิ่มด้วย
    ตัวเลือก 3: จัดสรรทรัพยากรแบบ adaptive ในระดับ infrastructure และ network
    งานที่ไม่ใช่ GPU ก็อาจลด priority, ทำให้คำขอเครือข่ายช้าลง หรือกระจายงานไปยังเซิร์ฟเวอร์ต่างกันตามการใช้ใน k8s เป็นต้น
    และนอกเหนือจากการถกเรื่องลิมิต ก็ควรไล่ดูด้วยว่าคำขอแบบไหนที่กินต้นทุนจริงมาก เพื่อจะได้ปรับปรุง code path หรือโครงสร้าง infrastructure ที่ไม่มีประสิทธิภาพ
    อยากเน้นว่าการ optimize โค้ดเพียงเล็กน้อยก็อาจเพิ่ม headroom ให้ระบบได้มาก