ปัญหาแพ็กเกจ Claude Code Pro Max 5x ใช้โควตาหมดภายใน 1.5 ชั่วโมง แม้ใช้งานในระดับพอประมาณ

 (github.com/anthropics)
7 คะแนน โดย GN⁺ 18 일 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในแพ็กเกจ Pro Max 5x(1M context) มีรายงานว่าแม้จะใช้งานถามตอบและงานพัฒนาในระดับพอประมาณ ก็ยังเกิด โทเค็นเกินลิมิตภายใน 1.5 ชั่วโมง
  • สาเหตุที่ถูกชี้คือบั๊กที่คำนวณโทเค็น cache_read ด้วยอัตราเต็ม (1.0x) ทำให้ผลของแคชหายไปและโควตาถูกใช้เร็วผิดปกติ
  • การเรียกอัตโนมัติจาก background session, auto-compact, และ การป้อน context ขนาดใหญ่ ทำให้ความเร็วในการใช้โควตาสูงขึ้นร่วมกัน
  • ชุมชนวิเคราะห์ว่า การลด cache TTL (1 ชั่วโมง→5 นาที) และอาการ cache busting เป็นสาเหตุหลัก
  • Anthropic กำลังดำเนินการ ลด context เริ่มต้น (400k), ปรับปรุง UX, และ เพิ่มประสิทธิภาพการเรียกที่ไม่ active พร้อมเก็บฟีดแบ็กจากผู้ใช้

ปัญหาโควตาหมดอย่างรวดเร็วในแพ็กเกจ Pro Max 5x

  • มีรายงานว่าในแพ็กเกจ Pro Max 5x(claude-opus-4-6, 1M context) แม้ใช้งานถามตอบระดับกลางและงานพัฒนาแบบเบา ๆ ก็ยังเกิด โควตาหมดภายใน 1.5 ชั่วโมง
    • ก่อนหน้านี้ในช่วงพัฒนาอย่างหนัก 5 ชั่วโมง การใช้โควตายังเป็นปกติ แต่หลังรีเซ็ตกลับหมดอย่างรวดเร็ว
    • สภาพแวดล้อมคือ Claude Code CLI on WSL2 และเกิดในเซสชันเดียว (มี auto-compact 2 ครั้ง)
  • บั๊กที่คำนวณโทเค็น cache_read ด้วยอัตราเต็ม (1.0x) ถูกชี้ว่าเป็นสาเหตุสำคัญ
    • ตามปกติ cache_read ควรถูกคำนวณที่อัตรา 1/10 มิฉะนั้นประโยชน์ของแคชจะหายไป
    • มีการวิเคราะห์การใช้โทเค็นผ่านออบเจ็กต์ usage ใน session log (~/.claude/projects/.../*.jsonl)
  • การเรียกอัตโนมัติจาก background session, การประมวลผล auto-compact ที่มีต้นทุนสูง, และ อินพุตขนาดใหญ่จากหน้าต่าง context 1M ทำงานร่วมกันจนเร่งการใช้โควตา
  • จากการวิเคราะห์ของชุมชน ผู้ใช้บางส่วนชี้ว่า การลด cache TTL (1 ชั่วโมง→5 นาที) และอาการ cache busting คือสาเหตุหลัก
  • ทีม Anthropic กำลังดำเนินการ ลด context เริ่มต้น (400k), ปรับปรุง UX, และ เพิ่มประสิทธิภาพการเรียกที่ไม่ active พร้อมขอข้อมูลเพิ่มเติมผ่านฟีดแบ็กจากผู้ใช้

ปริมาณการใช้โทเค็นที่วัดได้

  • ช่วงที่ 1 (15:00–20:00, 5 ชั่วโมง, พัฒนาอย่างหนัก)

    • API 2,715 ครั้ง, Cache read 1,044M, Cache create 16.8M, เอาต์พุต 1.15M โทเค็น
    • อินพุตที่มีผลจริง (เมื่อใช้อัตรา 1/10) 121.8M โทเค็น
    • ดำเนินการ Express server + iOS app, graphify pipeline, และ การประสาน multi-agent ตาม SPEC

  • ช่วงที่ 2 (20:00–21:30, 1.5 ชั่วโมง, ใช้งานระดับกลาง)

    • เมนเซสชัน (vibehq): API 222 ครั้ง, Cache read 23.2M, Cache create 1.4M, เอาต์พุต 91k
    • background session (รวม token-analysis, career-ops): เรียกรวม 691 ครั้ง, Cache read 103.9M, เอาต์พุต 387k
    • รวม effective token 13.1M (เมื่อใช้อัตรา 1/10) → ถ้าปกติไม่ควรเกินโควตา
    • แต่ในความเป็นจริงคือ 105.7M โทเค็น (เมื่อคำนวณแบบ 1.0x) → เทียบเท่า 70.5M ต่อชั่วโมง ซึ่งสอดคล้องกับอาการโควตาหมด

สรุปปัญหาหลัก

  • 1. ความผิดพลาดในการคำนวณลิมิตค่าบริการของโทเค็น Cache read

    • ที่คาดหวัง: cache_read ควรถูกคำนวณที่อัตรา 1/10
    • ที่เกิดขึ้นจริง: ถูกคำนวณที่อัตราเต็ม ทำให้ ผลของแคชถูกทำให้ไร้ผล
    • ในสภาพแวดล้อม 1M context มีการส่ง 100~960k โทเค็นต่อการเรียกหนึ่งครั้ง ทำให้ เกิน 200 ครั้งก็หมดได้ภายในไม่กี่นาที

  • 2. การใช้โควตาร่วมจาก background session

    • แม้เป็นเซสชันที่ไม่ active (เช่น token-analysis, career-ops) ก็ยัง ใช้โควตาร่วมต่อเนื่อง ผ่านการเรียก auto-compact และ post-processing

  • 3. การเรียก auto-compact ที่มีต้นทุนสูง

    • ก่อนบีบอัด จะส่ง context ทั้งหมด (~966k โทเค็น) ไปเป็น cache_creation ทำให้ เกิดการเรียกที่แพงที่สุดโดยอัตโนมัติ

  • 4. ผลข้างเคียงของหน้าต่าง context 1M

    • context ขนาดใหญ่ทำให้จำนวนโทเค็นต่อการเรียกพุ่งสูงและ เร่งความเร็วในการใช้โควตา

ขั้นตอนการทำซ้ำ

  1. รัน Claude Code ด้วยโมเดล Opus บนแพ็กเกจ Pro Max 5x
  2. ใส่ไฟล์กฎราว 30 ไฟล์ไว้ใน ~/.claude/rules/ (มี overhead 19k โทเค็น)
  3. ทำงานที่เน้นเครื่องมือ เช่น อ่านไฟล์, build, test
  4. ใช้คำสั่ง /context เพื่อตรวจว่าขนาด context เพิ่มขึ้น
  5. หลังเรียก 200~300 ครั้ง ให้ตรวจว่าโควตาลดลงรวดเร็ว
  6. เปิดค้างไว้ 2~3 เซสชันในเทอร์มินัลอื่น
  7. หลังรีเซ็ต ให้ตรวจว่าโควตายังหมดในเวลาอันสั้น

เปรียบเทียบพฤติกรรมที่คาดหวังกับที่เกิดขึ้นจริง

  • ที่คาดหวัง:

    • cache_read ถูกคำนวณที่อัตรา 1/10
    • เซสชันที่ไม่ active ใช้โควตาน้อยที่สุด
    • auto-compact ไม่ทำให้เกิดการใช้โควตาสูงเกินไป
    • หากใช้งานระดับกลางควรใช้งานได้ต่อเนื่อง 2~3 ชั่วโมง

  • ที่เกิดขึ้นจริง:

    • โควตาหมดภายใน 1.5 ชั่วโมง
    • background session ใช้ไป 78%
    • มีการส่งรวม 105.7M โทเค็น จึงคาดว่า cache_read ถูกคำนวณแบบอัตราเต็ม

ข้อเสนอเพื่อการปรับปรุง

  1. ทำให้วิธีคำนวณ cache_read ชัดเจน — ระบุอัตราที่ใช้คำนวณลิมิตค่าบริการจริงไว้ในเอกสาร
  2. จำกัดตาม effective token — แก้ให้ cache_read ถูกคำนวณที่อัตรา 1/10
  3. ตรวจจับเซสชันว่าง — ป้องกันการเรียกอัตโนมัติของเซสชันที่ไม่ active หรือแสดงคำเตือน
  4. แสดงภาพการใช้โทเค็นแบบเรียลไทม์ — แสดงปริมาณ cache_read, cache_create, อินพุต และเอาต์พุตแยกกัน
  5. คาดการณ์ต้นทุนตาม context — แสดงต้นทุนโทเค็นโดยประมาณก่อนเริ่มงาน

การวิเคราะห์และการอภิปรายของชุมชน

  • cnighswonger

    • เก็บข้อมูลการเรียก 1,500 ครั้งตลอด 24 ชั่วโมงด้วยอินเตอร์เซปเตอร์ claude-code-cache-fix
    • เมื่อทดสอบสมมติฐาน 3 แบบ (cache_read 0.0x, 0.1x, 1.0x) พบว่า มีเพียงโมเดล 0.0x ที่ให้ผลสอดคล้องกันในหน้าต่าง 5 ชั่วโมง (CV 34.4%)
    • ข้อสรุป: cache_read แทบไม่ส่งผลต่อโควตาในทางปฏิบัติ และแคชยังทำงานตามปกติ
    • อย่างไรก็ตาม ยังต้องมีการตรวจสอบเพิ่มเติมเพราะข้อมูลมาจากบัญชีเดียว

  • henu-wang

    • หลังเกิด regression ที่ cache TTL ถูกลดจาก 1 ชั่วโมงเหลือ 5 นาที ทุกครั้งที่พักเซสชันจะเกิด cache_create และทำให้ ต้นทุนสูงขึ้น 12.5 เท่า
    • ยิ่ง context ยาว ต้นทุนก็เพิ่มขึ้นแบบไม่เชิงเส้น
    • แนวทางแก้ชั่วคราวที่เสนอคือ คงเซสชันให้สั้น, ใช้คำสั่ง /compact อย่างกระตือรือร้น, และ preload context สำคัญไว้ใน CLAUDE.md

  • bcherny (ทีม Anthropic)

    • ยอมรับว่าเมื่อใช้หน้าต่าง context 1M prompt cache miss มีต้นทุนสูง
    • กำลังทดลองปรับปรุง UX (เช่น แนะนำให้ใช้ /clear เมื่อต่อเซสชันระยะยาว) และ ลด context เริ่มต้นเป็น 400k
    • พบกรณีที่งานไม่ active ใช้โทเค็นเกินความจำเป็นเมื่อใช้ multi-agent หรือปลั๊กอิน และกำลังปรับปรุง การ cleanup อัตโนมัติและการจัดตาราง

  • wadabum

    • ชี้ถึงบั๊กที่ทำให้แคชไม่ hit เลยในเซสชันใหม่ (#47098, #47107)
    • system prompt ที่อิง git status และบล็อก CLAUDE.md เปลี่ยนทุกเซสชัน จึงทำให้เกิด cache busting
    • cnighswonger ตอบว่าอินเตอร์เซปเตอร์มีการทำให้ลำดับคงที่บางส่วนแล้ว แต่ปัญหา git-status ยังต้องแก้แยกต่างหาก

สรุปข้อเสนอจากชุมชน

  • RockyMM: เมื่อเซสชันถึงลิมิต ให้สรุปอัตโนมัติแล้วค่อยกลับมาทำต่อ และลด TTL เหลือ 10 นาที
  • mikebutash: รายงานว่าแพ็กเกจ Pro ใช้ได้เพียง 2 prompt ต่อ 5 ชั่วโมง และยืนยันว่า rollback ไป v2.1.81 พร้อมติดตั้ง cache-fix แล้วดีขึ้น 3~4 เท่า
  • wutlu: รีเซ็ตเซสชันตามงานแต่ละชิ้นเพื่อลดปัญหา
  • dprkh: แชร์ debug mode skill (Skill.md) เพื่อช่วยหาสาเหตุ

บทสรุป

  • ปัญหา โควตาหมดอย่างรวดเร็วในแพ็กเกจ Pro Max 5x ยืนยันได้ว่าเกิดจากผลรวมของพฤติกรรมแคช, regression ของ TTL, context ที่พองตัว, และการเรียกจากเบื้องหลัง
  • ชุมชนเสนอว่าต้นเหตุหลักคือ cache busting และการลด TTL มากกว่าความผิดพลาดในการคำนวณ cache_read
  • ทีม Anthropic กำลังดำเนินการ ลดค่า context เริ่มต้น, ปรับปรุง UX ของแคช, และเพิ่มประสิทธิภาพการเรียกที่ไม่ active พร้อมขอข้อมูลเพิ่มเติมผ่านฟีดแบ็กจากผู้ใช้ (/feedback)

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

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

 
kimjoin2 17 일 전

ถ้าวัดกันที่คุณภาพก็แทบไม่มีอะไรมาแทนได้
ถ้าใช้แพตช์ง่าย ๆ แล้วทำให้ใช้งานได้นานขึ้นก็คงจะดีนะครับ
 
GN⁺ 18 일 전
ความคิดเห็นจาก Hacker News

  • ผมคือ Boris จากทีม Claude Code หลังจากตรวจสอบปัญหาที่มีรายงานเข้ามาเมื่อเร็ว ๆ นี้ พบว่าสาเหตุหลักมีอยู่สองข้อ

    1. เมื่อใช้ หน้าต่างคอนเท็กซ์ 1M โทเค็น การพลาดแคชของพรอมป์ต์มีต้นทุนสูง ปัจจุบันแคชมี TTL 1 ชั่วโมง ดังนั้นถ้าคุณลุกไปนานเกินหนึ่งชั่วโมง เซสชันจะหมดอายุและต้องโหลดแคชทั้งหมดใหม่ เพื่อปรับปรุงเรื่องนี้เราได้ปล่อยการปรับปรุง UX แล้ว และกำลังพิจารณาตัวเลือกในการลดค่าเริ่มต้นลงเป็น 400k หากต้องการทดสอบตอนนี้ทันที สามารถใช้คำสั่ง CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude ได้
    2. หากรัน ปลั๊กอินหรือเอเจนต์ มากเกินไปพร้อมกัน จะเกิดการสิ้นเปลืองโทเค็น เพื่อแก้ปัญหานี้ เรากำลังดำเนินการปรับปรุง UX รวมถึงการล้างและจัดตารางงานที่ไม่สำคัญโดยอัตโนมัติ
      หากผู้ใช้คนใดกำลังประสบปัญหา การส่งฟีดแบ็กด้วยคำสั่ง /feedback จะช่วยในการดีบักได้
    • Boris ตอนนี้ ประสบการณ์จากผู้ใช้ ที่โพสต์ในชุมชนไม่ใช่แค่ข้อยกเว้นเฉพาะราย อย่างที่ Jeff Bezos เคยพูดไว้ บางครั้ง เรื่องเล่าจากประสบการณ์จริงต่างหากที่บอกความจริง ไม่ใช่ข้อมูลตัวเลข คุณควรตรวจสอบอย่างจริงจังว่าเมตริกอาจผิดพลาดหรือไม่
    • ผมสงสัยว่าทำไมจู่ ๆ ปัญหานี้ถึงเกิดขึ้น พอตรวจดูก็พบว่าสาเหตุมาจาก TTL ของแคชพรอมป์ต์ถูกลดจาก 1 ชั่วโมงเหลือ 5 นาที ถึงจะเริ่มเซสชันใหม่ สุดท้ายก็ยังต้องสร้างทุกอย่างขึ้นมาใหม่อยู่ดีจึงไม่มีประสิทธิภาพ โครงสร้างที่ต้องคอยเฝ้าดูว่าแคชหมดอายุหรือยังนั้นขัดกับแนวคิดของ CC
    • สำหรับผม regression ที่ร้ายแรงที่สุดคือส่วนที่ system prompt พยายาม สแกนมัลแวร์ ในไฟล์ทุกครั้ง ทำให้โทเค็นหมดเร็วมาก และมีคำตอบ “not a malware” โผล่มาซ้ำ ๆ การออกแบบแบบนี้เป็นการตัดสินใจที่ผิดพลาด สุดท้ายผมหยุดโปรเจ็กต์แล้วเปลี่ยนไปใช้ Qwen ซึ่งก็ใช้ได้ดีทีเดียว
    • การแจ้งเตือน /clear ไม่ใช่วิธีแก้ ถ้าล้างแคชก็ต้องสร้างใหม่อยู่ดี ต้นทุนจึงเท่าเดิม การใช้ UX เพื่อ ชี้นำให้ผู้ใช้ใช้คอนเท็กซ์เล็กลง เท่ากับลดคุณภาพบริการ ถ้าเป็นปัญหาเรื่องต้นทุนก็ควรแก้ที่ราคาหรือสถาปัตยกรรม
    • เวลา OpenAI มีปัญหา พวกเขาจะ รีเซ็ตลิมิตการใช้งาน ให้ แต่ Anthropic ไม่มีมาตรการแบบนั้น เรื่องนี้ให้ความรู้สึกเหมือนตั้งใจทำ

  • ช่วงหลัง Claude ช้าลงและไม่มีประสิทธิภาพอย่างเห็นได้ชัด แม้จะระบุไฟล์ให้แล้วก็ยังวนลูปสำรวจนานเกิน 5 นาที และแตะลิมิตเซสชันอย่างรวดเร็ว ใช้วันละแค่สามครั้งก็เสียโควตารายสัปดาห์ไป 25% แล้ว เลยย้ายไปใช้แผน Codex ราคา $100 ซึ่ง ทั้งแม่นยำกว่าและให้เผื่อมากกว่า เพียงแต่สไตล์การพูดของ Codex ค่อนข้างน่ารำคาญ เลยเพิ่มคำสั่งแยกไว้ใน Agents.md ความรู้สึกด้าน UI นั้น Claude Code เมื่อก่อนดีกว่า แต่ในด้าน ดีบักแบ็กเอนด์และแก้ปัญหาซับซ้อน Codex เหนือกว่า ตอนนี้ผมแนะนำให้ลองเทียบ Codex กับแผน $20 ของ Cursor ดู

    • ผมก็เจอคล้ายกัน Claude เหมือนค้างไปเฉย ๆ เมื่อไม่กี่วันก่อน แต่วันถัดมาก็กลับมาทำงานปกติ
    • ผมใช้แผน Codex Business (30 ยูโร) อยู่ ช่วงนี้รู้สึกว่า โควตาลดลง เหมือนกัน ถึงอย่างนั้นเงื่อนไขก็ยังดีกว่า Claude Code มาก
    • ตอนนี้กำลังเปรียบเทียบพฤติกรรมของ confidence score ในโมเดล Opus, Haiku และ Sonnet อยู่ Opus มีประสิทธิภาพดีที่สุดกับงานระดับความยากปานกลาง
    • ผมลองใช้ CC, Gemini-cli และ Codex แล้ว แต่ CC ยังดีที่สุดอยู่ดี สงสัยว่า Cursor หรือชุดผสมกับ Aider จะดีกว่าหรือไม่
    • การเขียนโค้ดด้วย AI มี การสิ้นเปลืองคอนเท็กซ์ สูงมาก ดังนั้นถ้าจำกัดขอบเขตด้วย sandbox แบบคัสตอมจะทำให้มีประสิทธิภาพขึ้น

  • พอไล่ดูอีชูแล้วก็เข้าใจว่าทำไม Anthropic ถึงปิดตั๋วเร็ว ส่วนใหญ่ดูเหมือนเป็น noise ที่ AI สร้างขึ้นมา วิธีแก้ของผมมีดังนี้

    1. เปิด max thinking ในทุกเซสชันเพื่อลดการสำรวจเส้นทางที่ไม่จำเป็น
    2. ทำให้เซสชันคงสถานะ active ตลอดเวลา ถ้าแคชหมดอายุใน 5 นาที ก็ต้องสร้างโทเค็นใหม่อีก
    3. หลัง 200k โทเค็นให้สั่ง compact ทันที
      สิ่งที่ไม่พอใจที่สุดคือ Anthropic บังคับใช้โมเดล 1M
    • ผมก็เห็นอีชูนั้นแล้วขำเลย คงเป็นผลจากสั่ง Claude Code ว่า “ไปตรวจดูสิว่าทำไมโทเค็นถึงหมด”
    • บางคนบอกให้เปิด thinking บางคนบอกให้ปิด ทั้งคู่ต่างก็อ้างว่า ช่วยประหยัดโทเค็น ฟังดูประชดดี
    • บั๊กที่แคช ถูกทำให้ใช้ไม่ได้แบบสุ่ม นี่แหละคือประเด็นหลัก ดูเหมือน API client จะทำให้แคชของผู้สมัครสมาชิกจบก่อนเวลา แถมยังแอบขึ้นต้นทุน input token อีก
    • ผมก็ยืนยันได้ max effort ช่วยได้ สำคัญคือต้องรักษาคอนเท็กซ์ให้อยู่ต่ำกว่า 25% สงสัยว่ามีวิธีตรวจสอบสถานะการหมดอายุของแคชไหม
    • สามารถปิดโมเดล 1M ได้ด้วยคำสั่ง /model opus หรือ /model sonnet

  • ตอนนี้เริ่มรู้สึกเหมือน ยุคของการอุดหนุนกำลังจะจบลง แม้แต่ในชุมชน Google Gemini ก็มีเสียงบ่นถล่มเรื่อง การลดโควตา ในช่วงหลัง (ลิงก์อีชู) สุดท้ายผมก็ย้ายไปใช้คู่ Kiro IDE กับ Codex CLI และพอใจมาก

    • การเปลี่ยนแปลงแบบนี้คาดการณ์ได้อยู่แล้ว กลยุทธ์ที่ฉลาดคือรีบ สร้างไลบรารีที่จำเป็นไว้ล่วงหน้า ตั้งแต่ยุคโทเค็นฟรี
    • ตอนนี้ Anthropic กำลัง เปลี่ยนไปโฟกัสลูกค้าองค์กร และ OpenAI ก็เดินในทางคล้ายกัน ใน Reddit กับ Discord มีการเคลื่อนไหวไปหาโอเพนโมเดลหรือทางเลือกจากจีน แต่ก็ยังไม่มีอะไรแทนได้เต็มรูปแบบ
    • antigravity ใช้โปรโควตาเร็ว แต่ โหมด flash ใจกว้างกว่ามาก ตอนทำโปรเจ็กต์ STM32 ผมได้ผลิตภาพเพิ่มขึ้น 3 เท่า
    • สุดท้ายปลายทางของกระแสนี้อาจเป็น ยุคที่เอาต์พุตมีโฆษณาติดมาด้วย
    • มันทำให้นึกถึง Uber ราคา $3 ในอดีต

  • อีชู ที่ชี้ถึงสาเหตุรากของปัญหาถูกปิดเป็น “Not planned” ทำให้น่ากังวล

    • เนื้อหาคำตอบ ดูไม่เป็นธรรมชาติเหมือน AI เขียน ตรรกะที่ว่า “TTL 1 ชั่วโมงแพงกว่า” ก็แปลก ๆ เช่นกัน การบอกว่าไม่ให้สวิตช์เปิดปิดเพราะต้นทุนยิ่งฟังยากจะเชื่อ
    • ไม่เห็นต้องกลัวขนาดนั้น ถ้าคุณภาพแย่ลงก็แค่เลิกใช้
    • ผมมองว่า Anthropic ขายโทเค็นเหมือนคาสิโน และไม่สนใจว่าผู้ใช้จะเสียเงิน ถ้าไม่ชอบโมเดลแบบนี้ก็ควรใช้ local LLM น่าจะดีกว่า

  • พอลอง ย้อนกลับไปใช้เวอร์ชัน 2.1.34 ปัญหาโควตาและปัญหาแคชส่วนใหญ่ก็หายไป
    เพิ่ม "effortLevel": "high", "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": 1 เป็นต้น ไว้ใน ~/.claude/settings.json และลบเวอร์ชันอื่นออก
    Adaptive thinking ยังไม่สมบูรณ์ แต่ถ้าปรับปรุงได้ในอนาคตก็น่าจะช่วยได้ ถึงอย่างนั้นก็ยังลังเลว่าจะย้ายไป Codex ดีไหม

    • ผมก็ใส่ CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000, DISABLE_AUTOUPDATER=1 ไว้ใน ~/.bashrc เหมือนกัน

  • โมเดลระดับล่างก็มีปัญหาคล้ายกัน ผมคิดว่า การซื้อขายอย่างเป็นธรรมเริ่มจากการวัดผลที่โปร่งใส ผมจะยกเลิกการสมัครเดือนนี้

    • มีบางครั้งที่เซสชันเริ่มทำงานตอนคอมพิวเตอร์อยู่ในโหมดสลีปจน โทเค็นถูกใช้ไป แม้แต่คำถามง่าย ๆ อย่าง “ตอนนี้กี่โมง?” ก็ใช้ไป 10%

  • ปีนี้ผมลองใช้ AI agent มาช่วยยื่นภาษี โดยใช้ Opus 4.6, Codex 5.4 และ Antigravity 3.1 อย่างละแผน $20
    Codex จัดการได้สมบูรณ์แบบใน 12 นาที ส่วน Antigravity พลาดไปหนึ่งหน้าแต่ก็แก้ได้เร็ว Claude Code กลับ หยุดเพราะเกินลิมิตการใช้งาน และถึงลองใหม่ก็ยังมีความคลาดเคลื่อน ต่ำกว่าที่คาดไว้มาก

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

  • หลังจาก ประกาศอัปเดต บน Reddit Claude ก็ เปลี่ยนไปจนใช้เขียนโค้ดในชีวิตประจำวันไม่ได้อีกต่อไป เครดิตของบัญชี Pro หมดในชั่วโมงเดียวจนต้องกลับไปใช้ Gemini หรือ ChatGPT

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