เหตุผลที่ยกเลิก Claude: ปัญหาโทเค็น คุณภาพลดลง และการซัพพอร์ตที่ย่ำแย่
(nickyreinert.de)- ในช่วงไม่กี่สัปดาห์แรกพึงพอใจมากกับ โควตาโทเค็น ที่รู้สึกว่าเร็วและยุติธรรม รวมถึงคุณภาพผลลัพธ์ที่ดี แต่ราว 3 สัปดาห์ก่อนความรู้สึกที่สัมผัสได้เปลี่ยนไปอย่างมาก
- หลังพักไป 10 ชั่วโมงแล้วกลับมา ส่งคำถามสั้น ๆ เพียงสองข้อให้ Claude Haiku แต่การใช้งานกลับพุ่งถึง 100% และช่องทางซัพพอร์ตหลังจากตอบแบบอัตโนมัติที่ไม่แตะประเด็นหลักแล้วก็แทบปิดตายไปเลย
- ช่วงหลังแม้แต่โปรเจกต์เดียวก็ใช้ ลิมิตโทเค็น หมดภายในสองชั่วโมง จากเดิมที่เคยรันหลายโปรเจกต์พร้อมกันได้ และในกระบวนการรีแฟกเตอร์ก็เสียหน้าต่างเวลา 5 ชั่วโมงไปราวครึ่งหนึ่งเพียงเพื่อแก้ทางลัดราคาถูก
- เมื่อเวลาผ่านไป แคชบทสนทนา หายไป ทำให้ต้องเสียค่าใช้จ่ายในการให้อ่าน codebase ใหม่ซ้ำ ๆ อีกทั้งยังมีทั้งการเปลี่ยนจุดอ้างอิงรายสัปดาห์และคำเตือนลิมิตรายเดือนที่ไม่มีคำอธิบาย ทำให้ระบบลิมิตดูไม่สม่ำเสมอ
- แม้จะยอมรับอย่างมากถึงการเพิ่มประสิทธิภาพการทำงานและศักยภาพของผลิตภัณฑ์ แต่เมื่อ การซัพพอร์ตที่ย่ำแย่ คุณภาพที่ลดลง และความสับสนเรื่องข้อจำกัดการใช้งานสะสมเข้าด้วยกัน สุดท้ายก็ยกเลิกบัญชี Anthropic
ความพึงพอใจในช่วงแรกและการเปลี่ยนแปลงภายหลัง
- ในช่วงไม่กี่สัปดาห์แรกของการสมัคร Claude Code ใช้งานได้รวดเร็ว, โควตาโทเค็น ก็รู้สึกว่ายุติธรรม และคุณภาพผลลัพธ์ก็ดี
- ยังสามารถดู ประกาศ ที่ระบุว่าเพิ่มโควตาโทเค็นในช่วงเวลาที่ไม่แออัดได้ด้วย
- ยิ่งเมื่อมีท่าทีคัดค้านกฎเกณฑ์บางอย่างของภาครัฐ ก็ยิ่งทำให้รู้สึกอยากสนับสนุนผลิตภัณฑ์นี้
- ราว 3 สัปดาห์ก่อน ความพึงพอใจในช่วงแรกเริ่มหายไปอย่างรวดเร็ว
- ในหัวข้อต่อจากนี้จะเจอปัญหาต่อเนื่องทั้งด้านการซัพพอร์ต คุณภาพ และข้อจำกัดการใช้งาน
ปัญหาคุณภาพการซัพพอร์ต
- พักไปประมาณ 10 ชั่วโมงและคิดว่าโทเค็นน่าจะเติมกลับมาแล้ว จึงเริ่มงานในตอนเช้า แต่ทันทีที่ส่งคำถามสั้น ๆ สองข้อซึ่งไม่เกี่ยวกับ repository ให้ Claude Haiku การใช้โทเค็นก็พุ่งถึง 100%
- คำถามนั้นเรียบง่ายและมีขนาดเล็กมาก
- การรีเฟรชโทเค็นที่คาดหวังไว้ไม่สอดคล้องกับการใช้งานที่เพิ่มขึ้นจริง
- ลองติดต่อ AI support bot แต่ได้รับเพียงคำแนะนำพื้นฐาน และมันก็ไม่เข้าใจปัญหาจริงอย่างถูกต้อง
- หลังจากนั้นจึงขอให้ส่งต่อไปยังเจ้าหน้าที่จริง
- แต่คำตอบที่มาถึงในอีกหลายวันต่อมาก็ดูเป็นคำตอบคนละเรื่องกับปัญหาจริง
- คำตอบที่ได้รับเริ่มต้นด้วยข้อความว่า “ระบบตรวจพบว่าเป็นคำถามเกี่ยวกับลิมิตการใช้งานของแพ็กเกจ Pro หรือ Max” แต่ในความเป็นจริงตอนนั้นก็ใช้งาน Pro plan อยู่แล้ว และคำตอบก็ยังไม่แตะประเด็นหลักของคำถาม
- เนื้อหาต่อมายังเป็นข้อความเชิงเอกสารยาว ๆ ที่อธิบายลิมิตรายวันและรายสัปดาห์
- ไม่เห็นแนวทางที่จะช่วยแก้หรือรับมือกับปัญหาที่ถามไปโดยตรง
- ตอนท้ายอีเมลยังมีข้อความว่าคำตอบเพิ่มเติมอาจไม่ได้รับการติดตาม และให้ไปที่หน้าช่วยเหลือแทน ทำให้ช่องทางสอบถามแทบถูกปิดไปโดยปริยาย
- เท่ากับว่าเจอทั้งคำตอบอัตโนมัติที่ไม่สะท้อนปัญหาจริง และเส้นทางการขอความช่วยเหลือก็ถูกปิดตามมา
- ความผิดหวังต่อคุณภาพการซัพพอร์ตจึงเริ่มรุนแรงขึ้นอย่างจริงจัง
คุณภาพที่ลดลง
- ในช่วงหลายวันและหลายสัปดาห์ถัดมา คุณภาพผลลัพธ์ไม่น่าพอใจเมื่อเทียบกับประสบการณ์ช่วงแรก และเวลาที่ทำงานได้จริงก็ลดลงอย่างมาก
- เมื่อก่อนสามารถทำได้พร้อมกันสูงสุดสามโปรเจกต์ แต่ตอนนี้แม้แต่โปรเจกต์เดียวก็ใช้ ลิมิตโทเค็น หมดภายในสองชั่วโมง
- ทั้งปริมาณที่ใช้งานได้และประสิทธิภาพการทำงานที่สัมผัสได้แย่ลงพร้อมกัน
- ผู้เขียนยังชี้ด้วยว่าการประเมินคุณภาพอาจเป็นเรื่องอัตวิสัย และประสิทธิภาพของ agent ก็ได้รับอิทธิพลจากผู้ใช้มาก
- พร้อมกันนั้นก็ระบุว่าใช้งาน GitHub Copilot, OpenAI Codex, OMLX, Continue, Qwen3.5-9B ควบคู่กันอยู่ด้วย ทำให้เห็นว่ามีประสบการณ์ใช้งานเปรียบเทียบหลายเครื่องมือ
- แม้จะไม่ได้อ้างว่าตนมีความเชี่ยวชาญแบบสัมบูรณ์ แต่ก็เป็นความเห็นจากคนที่ลองใช้มาหลายเครื่องมือแล้ว
- ในกรณีที่มอบหมายงานรีแฟกเตอร์โปรเจกต์ให้ Claude Opus บันทึกการคิดของโมเดลแสดงทิศทางว่าจะเพิ่มตัว initialiser แบบทั่วไปใน
ui-events.jsเพื่อ inject การแสดงค่าอัตโนมัติ แทนที่จะแก้ slider ทุกตัวใน JSX โดยตรง- วิธีดังกล่าวเป็นการอ้อมด้วยการแทรกการแสดงค่าให้อัตโนมัติหากแต่ละ range input ไม่มีส่วนแสดงค่าอยู่
- log ลักษณะนี้ทำให้รู้สึกว่าจำเป็นต้องคอยตรวจดูบ่อย ๆ ไม่ใช่แค่นาน ๆ ครั้ง
- วิธีนี้ถูกประเมินว่าไม่ใช่แนวปฏิบัติที่ดี แต่เป็นทางลัดราคาถูก และเมื่อทักท้วงไป Opus ก็ยอมรับว่าเป็นแนวทางที่ขี้เกียจ ก่อนจะเปลี่ยนไปเพิ่ม label ใน JSX โดยตรงและเชื่อมโยงอย่างชัดเจน
- เพียงแค่แก้ทิศทางที่ผิดตั้งแต่แรกก็ใช้โควตาในหน้าต่าง 5 ชั่วโมงไปราว 50% แล้ว
- คุณภาพที่ลดลงจึงไม่ได้เป็นแค่ความรู้สึก แต่แปลเป็นต้นทุนที่สูญเปล่าจริง
ความสับสนเรื่องแคชและการแสดงลิมิต
- ปัญหาเรื่องแคชบทสนทนาก็ปะทุขึ้นมาใหม่ โดยมีลิงก์ไปยัง postmortem ของ Anthropic และ การถกเถียงบน Hacker News ประกอบ
- การที่บริษัทออกมาพูดถึงปัญหานี้ต่อสาธารณะถือเป็นเรื่องที่มองในแง่บวก
- แต่ภาระในมุมประสบการณ์ผู้ใช้ก็ยังคงอยู่
- เมื่อเวลาผ่านไปแล้วกลับมาทำงานอีกครั้ง แคชบทสนทนา จะหายไป ทำให้โมเดลเริ่มอ่าน codebase ใหม่ตั้งแต่ต้น
- ในมุมต้นทุนอาจถือว่าฉลาด แต่ในมุมผู้ใช้มันกลายเป็นว่าจ่ายโทเค็นไปแล้วหนึ่งรอบกับการโหลดเริ่มต้น จากนั้นพอถูกบังคับให้พักก็ต้องกลับมาจ่ายค่าโหลดเดิมอีกครั้ง
- โดยเฉพาะเมื่อถูกจำกัดด้วยหน้าต่างโทเค็น 5 ชั่วโมง พอกลับมาหลังพักก็ต้องจ่ายต้นทุนเดิมซ้ำ
- ยังมีเหตุการณ์ที่หน้าต่างรายสัปดาห์เปลี่ยนจากการนับตามวันปัจจุบันไปเป็นนับจากวันจันทร์แบบกะทันหัน และการเปลี่ยนนั้นก็มาพร้อมกับการรีเซ็ตการใช้งานเป็น 0
- ตัวการรีเซ็ตเองถือว่าเป็นข่าวดี
- แต่ก็ไม่รู้ว่าทำไมการเปลี่ยนแปลงนี้จึงเกิดขึ้น
- มันยิ่งทำให้รู้สึกว่าระบบลิมิตไม่มีความสม่ำเสมอ
- ระหว่างที่คอยจับตาการใช้โทเค็นระหว่างทำงานโปรเจกต์ จู่ ๆ ก็มีคำเตือนโผล่มาว่าต้องกังวลเรื่อง ลิมิตการใช้งานรายเดือน ทั้งที่ไม่ได้เป็นผู้ใช้องค์กร
- ณ ตอนนั้นก็ยังไม่ได้ใช้เกินลิมิตรายชั่วโมงหรือรายสัปดาห์ด้วยซ้ำ
- และบนหน้าจอก็ไม่ได้อธิบายที่มาของคำเตือนนี้ไว้
- คำเตือนนั้นหายไปในราวสองชั่วโมงต่อมา และก็กลับมาทำงานต่อได้อีกครั้ง
- ในเอกสาร ก็ไม่มีการพูดถึงลิมิตการใช้งานรายเดือน
- และในหน้าการตั้งค่าก็เขียนว่าจะแสดงเพียง session ปัจจุบันกับลิมิตรายสัปดาห์ จึงทำให้ตัวตนของลิมิตรายเดือนยังคงไม่ชัดเจนจนถึงที่สุด
ผลด้านประสิทธิภาพการทำงานและการยกเลิกในท้ายที่สุด
- ผู้เขียนยังคงชอบตัวผลิตภัณฑ์มาก และมองว่าในทางทฤษฎีแล้วทุกอย่างทำงานได้ดีมากพร้อมมีโอกาสอีกมาก
- ได้สร้าง harness ของตัวเองบน Claude และยังชื่นชม Claude Caude ที่จัดการ GitHub issue อยู่เบื้องหลังอย่างมาก
- รวมถึงยังใช้ Claude Cowork เขียน Nerd Enzyklopädie ต่อไป
- ประสิทธิภาพการทำงานไม่ได้เพิ่มขึ้นแค่หลักเท่าตัว แต่เพิ่มขึ้นถึงระดับ หนึ่งลำดับขั้น และทำให้สามารถนำไอเดียในหัวไปสร้างจริงได้เร็วและง่ายกว่าหลายปีก่อนมาก
- ศักยภาพของผลิตภัณฑ์และประโยชน์ใช้สอยจริงจึงเห็นได้อย่างชัดเจน
- พร้อมกันนั้นก็มีคำชมว่าองค์ประกอบของฟีเจอร์ต่าง ๆ ถูกออกแบบมาอย่างใส่ใจ
- ขณะเดียวกันก็เข้าใจถึงความยากทั้งในเชิงเทคนิคและเชิงองค์กรของการให้บริการผลิตภัณฑ์แบบนี้ และการขายงาน inference นั้นมีโครงสร้างแบบ ต้นทุนส่วนเพิ่ม ที่ต้องใช้ทรัพยากรคอมพิวต์ในระดับใกล้เคียงกันทุกครั้งที่เพิ่มเวลาใช้งานหรือลูกค้าใหม่
- ทำให้เป็นโครงสร้างที่ได้รับประโยชน์จาก economy of scale ได้ยาก
- ไม่ได้ปฏิเสธว่าการเดินระบบบริการเช่นนี้มีความยากจริง
- สุดท้ายแล้ว ผู้เขียนมองว่า Anthropic ดูเหมือนจะรับลูกค้าใหม่จำนวนมากพร้อมกันไม่ไหว และเพื่อช่วยลดภาระนั้นจึงยกเลิกบัญชี
- ช่องว่างระหว่างความชอบในตัวผลิตภัณฑ์กับปัญหาการให้บริการที่เจอจริงระหว่างใช้งานนำไปสู่การตัดสินใจยกเลิก
- เป็นผลสะสมจากการซัพพอร์ตที่ย่ำแย่ คุณภาพที่ลดลง และความสับสนเรื่องลิมิต
10 ความคิดเห็น
“ในช่วงไม่กี่สัปดาห์แรก ความเร็วก็เร็วและโควตาโทเคนก็ดูยุติธรรม”??
ใครเป็นคนกำหนดว่ายุติธรรมล่ะ?
บริการราคา 220 ดอลลาร์ต่อเดือนยังทำเวลาใช้งานได้ไม่ถึง 99.5% แบบนี้ก็ชวนให้คิดว่าผู้ใช้ถูกมองเป็นหมูในอวยหรือเปล่า ส่วน Claude.ai นั้นยังทำได้ไม่ถึง 99% ด้วยซ้ำ
ตอนนี้คุณใช้บริการอะไรแทนอยู่ครับ? Codex เหรอ? ผมยังใช้อยู่ต่อเพราะมองไม่เห็นทางเลือกอื่น...
ก็จริงที่ว่าไม่มีทางเลือกอื่น แต่ผมเพิ่งเคยใช้บริการที่ยังรักษา uptime 99% ไว้ไม่ได้เป็นครั้งแรกในชีวิตนี่แหละ..
GitHub คงไม่ใช่แค่ต้องสู้กับ 99 แล้ว น่าจะต้องสู้กับ 95 ด้วย
Claude ai มีปัญหาเรื่องการซิงก์ข้อมูลโปรเจกต์ เลยย้ายออกได้ไม่ง่าย และในช่วงนี้ผมน่าจะใช้ Claude Code, Codex และ Gemini CLI ควบคู่กันไปก่อน
ถ้ามีทางเลือกอื่น ผมก็อยากรู้เหมือนกัน
ขีดจำกัดการใช้งานรายเดือน
ขีดจำกัดการใช้งานรายปี
ฮ่าๆๆ...
ถ้า Claude กับ ChatGPT แข่งกัน ผู้บริโภคก็ได้ประโยชน์ครับ 555 หวังว่า Gemini จะเข้ามาร่วมวงเร็ว ๆ ด้วย แล้วโมเดลจากจีนก็กำลังพัฒนาแบบก้าวกระโดดมาก ๆ หวังว่าทุกเจ้าจะสู้กันอย่างดุเดือดนะครับ
ความคิดเห็นจาก Hacker News
ต่อให้เขียนเอกสารสเปกละเอียดเป็นหลายไฟล์พร้อม Markdown และโค้ดตัวอย่างแล้วส่งให้ Claude Sonnet ก็ยังมีกรณีที่มันตกหล่นข้อกำหนด สร้างโค้ดซ้ำ หรือใส่การแปลงข้อมูลที่ไม่จำเป็นเข้ามา
ยังเห็นลักษณะเหมือนฝืนแต่งให้แค่เทสต์ผ่านเท่านั้น สุดท้ายเลยกลายเป็นต้องอ่านโค้ดจำนวนมหาศาลแทนที่จะได้เขียนโค้ด
เดิมทีพอลงมือทำจริงก็รู้แล้วว่า การอ่านโค้ดและการสร้าง mental model ยากกว่าการเขียนโค้ดมาก และพอใช้ Gen AI ภาระส่วนนั้นยิ่งหนักขึ้น
เลยมองว่าในระดับราคาของ Anthropic ตอนนี้ ขาดทุนสุทธิ
เพราะไม่ได้ทำ vibe coding แต่กำลังสร้างซอฟต์แวร์ที่ผู้ใช้จริงต้องพึ่งพาอยู่ จึงคิดว่าจะยกเลิกการสมัครเร็ว ๆ นี้
ให้มันช่วยตรวจในวงจรเทสต์·ลินต์ตามปกติ ประเมินไลบรารีจาก third-party ได้เร็วขึ้น ค้นคว้าหัวข้อใหม่ ร่าง RFC·เอกสารออกแบบ หรือใช้เป็นคู่สนทนาเวลาติดปัญหายาก ๆ วิธีนี้เหมาะกว่า
โดยรวมยังไม่ค่อยชอบบริษัท AI และยังรู้สึกติดใจกับเรื่องที่มันตั้งอยู่บนการละเมิดลิขสิทธิ์ แต่โมเดลรุ่นล่าสุดก็ฉลาดจนน่าเหลือเชื่อในบางด้าน
ไม่จำเป็นต้องรับเอา vibecoding hype แบบเกินจริง แค่ใช้เป็นเครื่องมือเพิ่มประสิทธิภาพก็มีคุณค่ามากพอแล้ว
จะไม่ใช้เลยก็ได้ และไม่ได้มีหน้าที่ต้องจ่ายเงินให้บริษัทไหน แต่ก็มองว่าไม่ควรปัดเทคโนโลยีนี้ทิ้งทั้งก้อนเพียงเพราะดูจาก vibe coding
อย่ามอบสเปกระบบทั้งหมดให้มัน ออกแบบเอง แล้วถ้าจำเป็นค่อยให้ช่วยด้านการออกแบบ ส่วนการ implement ก็สั่งทีละอย่างจะได้ความแม่นยำสูงกว่า
ถ้าตรวจและให้แก้ในแต่ละขั้นก่อนค่อยไปต่อ ก็ยังเร็วกว่าเขียนเองทั้งหมด และควบคุมได้มากกว่ามาก
มันใกล้เคียงกับ vibecoding ที่มีขั้นเอกสารเพิ่มเข้ามาอีกชั้นหนึ่ง และถ้าอยากลดงานจัดระเบียบ ก็ควรใช้โมเดลที่ดีที่สุดของช่วงนั้นมากกว่า Sonnet
ถึงอย่างนั้น ไม่ว่าโมเดลไหนก็ไม่ได้จัดการทุกอย่างได้สมบูรณ์แบบอยู่ดี จึงไม่ควรใช้แบบทั้งหมดหรือไม่ใช้เลย
ทางที่เป็นจริงกว่าคือยังตัดสินใจด้วยตัวเองต่อไป และใช้ AI เฉพาะช่วงที่มันช่วยเร่งงานได้
วิศวกรที่ไม่ใช่ระดับจูเนียร์ส่วนใหญ่ก็มักลงตัวแบบนั้น และควรมองข้ามคำโฆษณาเรื่องการสร้างแอปอัตโนมัติบน LinkedIn หรือ SNS ไปเสีย
แม้ใช้ในลักษณะคล้ายกันก็ยังเขียนโค้ดได้เร็วขึ้นและคุณภาพดีขึ้น แถมภาระที่ข้อมือก็ลดลงมาก
ความต่างน่าจะอยู่ที่มอบหมายแค่ส่วนที่ AI ทำได้ และควบคุมขอบเขตให้แคบและค่อยเป็นค่อยไป
การเปลี่ยนแปลงเล็ก ๆ ที่ชัดเจนนั้นรีวิวได้ง่าย แต่ถ้าต้องรับ กองโค้ด 10,000 บรรทัด ทุกวันก็ประเมินยาก
อาจกำลังกดมันหนักเกินไป เร็วเกินไป และเร็วเกินจังหวะที่ควร
ถ้าจูนสมดุลได้ก็จะเห็นคุณค่า แม้อาจไม่เร็วแบบก้าวกระโดดเท่าที่คาดหวัง แต่ก็น่าจะยังเร็วกว่า ทำคนเดียว
ยังต้องตรวจสอบและยืนยันบ่อย และแผนก็ต้องแก้หลายรอบ แต่ตอน implement ก็ยังใช้ Opus ต่อ
ตอนนี้โมเดลเหมือนจับแคชไว้ จนมีคำเตือนว่าอย่า implement ด้วย Sonnet
แม้ต้องใช้เวลาอ่านทำความเข้าใจและแก้มือเองบ่อย แต่โดยรวมก็ยังจัดการได้ภายใน Pro subscription
ใช้ Claude Opus ได้ค่อนข้างมีประสิทธิภาพ และในแพ็กเกจระดับกลางก็ไม่ได้ชนลิมิตบ่อยนัก
วิธีทำงานใกล้กับ copilot มากกว่า autopilot คือโยนให้แค่งานขอบเขตจำกัดผ่านพรอมป์ต์ แล้วตรวจแทบทั้งหมด
สำหรับการใช้งานแบบนี้ รู้สึกว่าโมเดลแถวหน้าตอนนี้เกือบจะ ดีพอใช้งานจริง แล้ว
อยากให้มีโมเดลโอเพนซอร์สที่เทรนบนโค้ดที่มีไลเซนส์ถูกต้อง เพื่อให้ LLM-assisted coding กลายเป็นของทั่วไป
ทั้งอยากให้ใช้โทเคนมากขึ้นเพื่อจะได้เก็บเงินเพิ่ม และในขณะเดียวกันก็ดูเหมือนผู้ใช้ใช้เกินคาดจนโครงสร้างราคาปัจจุบันทนไม่ไหว
ถ้าทางออกสุดท้ายคือให้ขยับไปแพ็กเกจแพงขึ้น มันก็ไม่ได้ขัดกันเสียทีเดียว
เดือนละ 100 ดอลลาร์ก็พอ และในประเทศพัฒนาแล้วก็ไม่ใช่ว่าจะหาบ้านที่ค่าไฟถูกกว่านี้ได้ง่าย
สำหรับฉัน LLM-assisted coding คือการเข้าใจทุกการเปลี่ยนแปลงและทุกบรรทัดอย่างครบถ้วน ถ้าไม่ใช่ก็เป็น vibe coding
ถ้ายึดหลักนี้จริงจัง ก็มองว่าใช้โควตา $100 tier ให้หมดได้ยาก
ในหลายโมเดลนี่คืออันที่ดีที่สุดเท่าที่รู้สึก และไม่ได้ใช้ให้มันทำงานจริงเป็นหลัก แต่ใช้เป็น ตัวแทน search engine เป็นครั้งคราวมากกว่า
ไม่เคยรู้สึกว่า LLM มีประสิทธิภาพในการทำงานแทนจริง ๆ และคิดถึงยุคที่เอกสารเทคนิคยังใช้งานได้ดี
ท้ายที่สุด Claude ดูใกล้เคียงกับ ไม้ค้ำที่คอยอุดช่องว่างของ developer experience มากกว่า
ใช้ให้หมดโควตานี่ยากมาก และแม้จะโยนงานจริงให้เยอะ โดยเฉลี่ยต่อสัปดาห์ก็จบที่ราว 30%
แต่ตอนอยู่ Pro กลับชนลิมิตบ่อยแบบน่าขำ และบางทีคำขอเดียวก็เกิน 100% ของเซสชันจนต้องจ่ายเพิ่ม
Max 5x ให้ความรู้สึกมากกว่า 5 เท่าค่อนข้างเยอะ แต่ Anthropic จัดการเรื่องอย่าง surge rate ไว้คลุมเครือมาก เลยไม่มั่นใจ
พวกโพสต์แนว Opus พังแล้ว ไป Codex กันเถอะ ที่ล้น HN ช่วงนี้ ฉันมองอย่างระแวงพอสมควร
บางอันอาจเป็นแค่การระบายอารมณ์ แต่บางส่วนก็มีกลิ่น astroturfing
ใช้กับงานจริงเยอะมากแต่ไม่เคยชนลิมิตเลย
การปล่อย LLM วิ่งเป็นชั่วโมง ๆ ดูเหมือนสูตรสำเร็จในการเสียเวลาตัวเองไปกับการไล่ว่ามันทำอะไรและทำไมถึงทำแบบนั้น
สิ่งที่น่ากังวลคือผู้คนกำลังพึ่งพา GenAI แบบสมัครสมาชิกที่ผูกขาดและไม่โปร่งใส มากขึ้น
พวกเขาสร้างของทับลงไปเหมือนมันเป็นฐานที่มั่นคง แต่วันหนึ่งเจ้าของอาจดึงฐานนั้นออกไปกะทันหันก็ได้
ช่วงหลัง rate limit ค่อนข้างน่ารำคาญ เลยชอบ Codex มากกว่า CC แต่รูปแบบการทำงานแทบไม่ต้องเปลี่ยน
อยากทุ่มเงินให้เหนือคู่แข่งจนเกิดช่องว่างที่ไล่ไม่ทัน แล้วค่อยตั้งราคาได้ตามใจ
แต่ตอนนี้การแข่งขันยังดุเดือด และในฐานะเครื่องมือเขียนโค้ด Anthropic ยังดีที่สุดก็จริง แต่ความได้เปรียบนี้เล็กลงกว่าเดิม
พูดตรง ๆ แค่ Opus 4.5 ก็ไปถึงระดับที่ใช้งานได้ดีพอแล้ว และตอนนี้มีหลายโมเดลที่อยู่ระดับนั้น
Gemini Pro 3.1 ก็คล้ายกัน และ Codex ตอนนี้ก็ดีกว่า Opus 4.5 และใกล้ 4.7
ฉันเองก็สลับโมเดลและเอเจนต์บ่อยในโปรเจกต์เดียวกัน โดยแทบไม่มีต้นทุนการย้ายเลย
แค่รัน
claudeแทนด้วยgemini,copilot,hermesก็พอ จึงไม่ได้ผูกกับโมเดลใดลึกมากผู้ให้บริการคงพยายามใส่ฟีเจอร์เพื่อสร้างการผูกติด แต่โมเดลชั้นนำฉลาดมากจนหลายครั้งแค่บอกสิ่งที่ต้องการก็พอ
ตอนนี้ moat ที่สม่ำเสมอเพียงอย่างเดียว น่าจะเป็นความสามารถในการสร้างโมเดลที่ดีที่สุด และแม้กระทั่งสิ่งนั้นก็ยังตื้นพอที่ถ้า Claude Code หายไปพรุ่งนี้ก็ไม่ถึงกับร้ายแรง
โมเดลโอเพนที่โฮสต์เองได้ก็ใกล้มากแล้วเช่นกัน
การแข่งขันระหว่าง OpenAI กับ Anthropic ก็น่าสนใจ และถ้ากระแสโอเพนซอร์สเสริมเข้ามาด้วย ก็น่าจะไปถึงจุดนั้นในไม่ช้า
Claude ใช้ลิมิตเซสชัน 100% พร้อมค่าใช้จ่ายเพิ่มไปกับ Sonnet medium effort แล้วนั่งคิดอยู่ 53 นาที ก่อนจะตอบแค่ว่า
API Error: Claude's response exceeded the 32000 output token maximum...API Error: Claude's response exceeded the 32000 output token maximumก็เข้ากันเป๊ะเห็นแบบนี้มาหลายครั้งในช่วงหลายเดือนที่ผ่านมา ตอนแรกคิดว่าเป็นปัญหา AWS Bedrock แต่ดูเหมือนจะไม่ใช่แค่นั้น
ฉันกับเพื่อนร่วมงานหลายคนเจอ ความสามารถด้านการรับรู้ลดลง ของ Claude อย่างชัดเจนในช่วงสองเดือนที่ผ่านมา
4.5 ใช้ได้ 4.6 ดีมากจริง ๆ และถ้าวัดจาก benchmark ส่วนตัว 4.5 แทบจะตามแค่ 2-way pointer merge loop ได้ ส่วน 4.6 ได้ถึง 3-way และ 1M context ไปถึง k-way
ความสามารถในการไล่ตามแบบนี้ทำให้มันมีประโยชน์กับการเข้าใจและแก้โค้ด production จริง
แต่ตั้งแต่สองเดือนก่อน 4.6 เริ่มลืมง่ายและตัดสินใจโง่ ๆ บ่อยขึ้น และพอเทียบกันแล้วก็พบว่าไม่ได้เป็นแค่ฉันคนเดียว
4.7 ก็ไม่ได้ดีขึ้นมาก และช่วงไม่กี่สัปดาห์หลังเหมือนกำลังสู้กับ auto level of effort downgrade ตลอดเวลา
เวลาเริ่มรู้สึกว่ามันโง่ พอไปดูการตั้งค่าก็พบว่ามันถูกลดลงเงียบ ๆ เลยสร้างแรงเสียดทานมาก
เรารู้แล้วว่าโมเดลที่ดีแบบช่วงแรกของ 4.6 นั้นเป็นไปได้ ปัญหาคือระหว่างเอาไปปล่อยสู่ตลาดมวลชน Anthropic ไป throttle และ downgrade จนใช้งานจริงได้น้อยลง
ฉันคิดว่าอีกไม่นานถ้า DeepSeek ไปถึงระดับ more-than-good-enough แบบ 4.6+ ได้ ผู้คนก็คงหนีจากแนวทางของ Claude ที่จ่ายมากขึ้นแต่ได้กลับมาน้อยลง
ไม่ได้ต้องการอะไรที่ยิ่งใหญ่กว่าเดิม แค่อยากใช้สิ่งที่ทำได้อยู่แล้วอย่างเสถียร ควบคุมได้ และเป็นแบบ provisioned ไม่ใช่แบบ meter
เวลาบริษัทพลาดแบบนี้ก็แน่นอนว่าน่าหงุดหงิด แต่เขาก็ผ่อนข้อจำกัดอยู่ช่วงหนึ่งจนแทบเป็นการชดเชย และที่สำคัญคือรับมือค่อนข้างโปร่งใส
ไม่แน่ใจว่าบริษัท AI รายใหญ่อื่นจะโปร่งใสได้ระดับนี้หรือเปล่า เลยถึงจะหงุดหงิดกับ Claude ก็ยังเคารพวิธีจัดการของเขา
การสมัคร max20 ของฉันแทบไม่ได้ใช้งานเลยตั้งแต่เดือนเมษายน และ Codex 5.4 รวมถึง 5.5 ตอนนี้ให้ความรู้สึกต่างกันสุดขั้วแม้ใช้ fast mode
Opus ล้มเหลวแบบดูน่าเชื่อถือ ลืมรายละเอียดสำคัญไปครึ่งหนึ่ง หรือแอบแปะพลาสเตอร์หนี้เทคนิคในนามของ pragmatic แล้วอ้างว่าสำเร็จ
ทั้งที่จริงระบบพังหลังแก้ และพอชี้ข้อผิดพลาดมันก็ยิ่งทำให้เละกว่าเดิม
Opus ดีสำหรับทำของขอบเขต greenfield แบบวันช็อต แต่ถ้าต้องแก้ซ้ำภายหลังหรือทำงาน integration ที่ซับซ้อน มัน แย่จนเป็นโทษ
ในทางกลับกัน GPT 5.4+ จะยอมใช้เวลาเพื่อคิด edge case ก่อน และมันมักถูกจริง จึงลดจำนวนรอบ debug ต่อเนื่องแล้วค่อยส่งผลลัพธ์ที่ถูกต้อง
ไม่มีอาการหลุดเข้า loop คิดอย่าง "ไม่น่าใช่มัลแวร์" หรือ "เดี๋ยวก่อน" เป็นหลายนาที แม้แค่แก้สคริปต์บรรทัดเดียว
การเก็บกวาดโค้ดกับการทำฟีเจอร์ใหม่เป็นคนละงาน และพวกตระกูล GLM ถึงจะดูฉลาดกว่าบนผิวหน้า แต่พอรีวิวโค้ดจริงก็ยังต้องมี build/prune cycle อยู่ดี
"นี่มันเต็มไปด้วย race condition ไม่ใช่เหรอ"
ตอนนี้ใช้แค่ Codex เพราะ Claude เชื่อถือยาก และชอบปล่อย data race หรือเงื่อนไขปฏิเสธที่ตกหล่นไว้บ่อยเกินไป
ตอนนี้ใช้ Aider อยู่ และเพราะนโยบายการเทรนใหม่ก็คงจะยกเลิก Github multi AI bundle subscription ด้วย
การใช้ Aider คู่กับโมเดลโอเพนใหม่ ๆ และคุย requirement กันด้วย Open Spec ก่อนส่งต่อ ช่วยได้มากทีเดียว
บริการ AI มี แรงจูงใจต่ำในการลดการใช้โทเคน
ยิ่งทำให้ใช้โทเคนมากก็ยิ่งเก็บเงินได้มาก จึงน่าจะคอยทดสอบว่าจะดันได้ไกลแค่ไหนก่อนผู้ใช้จะโกรธ
ทุกบริษัท AI จะคอยสลับตำแหน่งระหว่างปริมาณโทเคนกับราคาไปตามต้นทุนที่สูงขึ้น
และเราก็ดูเหมือน กบในน้ำอุ่น ที่ใกล้จะเดือดอยู่แล้ว แต่ยังถูกบอกว่านี่ยังเป็นแค่น้ำอาบ
บริษัท AI ก็มีแรงจูงใจแบบเดียวกัน
ถ้าถูกลงคนก็จะใช้มากขึ้น และตราบใดที่ราคายังสูงกว่าต้นทุน สุดท้ายรายได้รวมก็อาจเพิ่มขึ้น
แน่นอนว่าพวกเขาก็มีเหตุผลมากพอที่จะลดต้นทุนตัวเองเช่นกัน
เพราะแบบนั้นจึงสร้าง https://github.com/dirac-run/dirac ซึ่งเป็นโอเพนซอร์ส (cline fork) โดยตั้งเป้าเรื่อง ประสิทธิภาพด้านโทเคน เพียงอย่างเดียว
คาดว่าผู้ให้บริการแบบปิดที่สร้าง lock-in จะทำให้ผู้ใช้หงุดหงิดพอในท้ายที่สุด และตอนนี้ก็กำลังหาผู้ร่วมพัฒนาอยู่ด้วย
ฟังดูเหมือนทฤษฎีสมคบคิด แต่บริษัทอย่าง Anthropic ได้ประโยชน์แม้ตอนที่โมเดลทำงานไม่เสร็จ
เพิ่งอ่านเรื่อง over editing phenomenon มาเหมือนกัน และดูเหมือนเครื่องจักรไม่เคยอยากทำให้จบจริง ๆ
คล้ายกับแอปหาคู่ที่ไม่อยากจับคู่ให้ดีนัก
เพราะถ้าสำเร็จ ผู้ใช้ก็จะยกเลิกการสมัคร
เมื่อวานเป็นช่วงที่ทำให้ตาสว่าง
ลองให้ Claude Code ที่ต่อกับ local LLM ทำงาน extract ง่าย ๆ แต่มันกลับนั่งครางอยู่ 10 นาที
พอเอาข้อมูลและพรอมป์ต์ชุดเดียวกันไปใส่โมเดลโดยตรงผ่าน UI แชตของ
llama_cppกลับจบแบบ single-shot ได้ในไม่ถึง 1 นาทีเพราะงั้นคงต้องมีอะไรผิดสักอย่างทั้งในตัว coding agent เอง หรือในวิธีพูดคุยกับ LLM
ตอนนี้กำลังหา coding agent โอเพนซอร์สที่เรียบง่ายมาก ๆ อยู่ Nanocoder ติดตั้งบน Mac ก็ไม่ค่อยได้ แถม node-modules ก็ใหญ่เกินจนไม่ชอบ ส่วน Opencode ก็ดูไม่โอเพนซอร์สเต็มที่
ช่วงนี้เลยเล่นบท coding agent เอง พร้อมใช้เว็บ UI ของ
llama_cppแล้วมันก็ไปได้ดีพอสมควรใน repository มี MIT License อยู่
ถ้าอยากได้ coding agent ที่ "เรียบง่ายสุด ๆ" แบบเฉพาะทาง นี่กลับยิ่งเหมาะ
สัปดาห์นี้ฉันก็ทำแบบนั้นจริงเพราะหงุดหงิดกับพฤติกรรมแปลก ๆ ของ Anthropic และใช้เวลาไม่กี่วันก็ได้ของที่พอใช้
ในกรณีของฉัน Claude Code ไม่มีบน BeOS หรือ Mac เก่า ๆ อยู่แล้ว การ bootstrap เองแล้วเอามาต่อกันจึงง่ายกว่า
ผ่านกระบวนการนี้แล้วจะได้เรียนรู้เยอะมากว่าโมเดลทำงานจริงอย่างไร และใน Claude Code มี แพตช์พลาสเตอร์สุดเหลือเชื่อ วิ่งอยู่มากแค่ไหน
แน่นอนว่าก็ทำให้เข้าใจความยากที่เอเจนต์หรือ harness ต้องแก้ด้วยในระดับหนึ่ง
และเรื่องที่ Claude Code ช้ากว่า
llama_cppฉันก็เจอเหมือนกัน เดาว่า ทราฟฟิก API น่าจะได้ลำดับความสำคัญสูงกว่าทราฟฟิกจาก subscriptionAPI รู้สึกเร็วกว่าเยอะ แต่ก็แพงกว่าเยอะตามไปด้วย
โครงสร้างจริง ๆ เรียบง่ายกว่าที่คิดมาก
เคยลองจริงโดยเอา shim บาง ๆ ไปครอบ vLLM ให้เปลี่ยนแค่รูปแบบ endpoint
บางครั้ง Claude โมเดลเดียวกันก็มีรอบที่ทำพลาดด้านตรรกะ และมีรอบที่ไม่พลาด
ดูเหมือนว่า ประสิทธิภาพของ Claude ขึ้นกับเวลา ค่อนข้างมาก และมีกราฟที่แสดงเรื่องนี้อยู่
https://marginlab.ai/trackers/claude-code/
อีกเรื่องที่ไม่ค่อยมีใครพูดกันในที่สาธารณะคือ แม้เป็นโมเดลเดียวกัน ผลลัพธ์ก็เหมือนต่างกันพอสมควรตาม quantization
4-bit กับ 8-bit ใช้ทรัพยากรคำนวณต่างกัน และคุณภาพเอาต์พุตก็ต่างกัน
https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-quantization
รู้ดีว่า frontier model ไม่ได้ทำงานเหมือนกันเป๊ะอยู่แล้ว แต่ช่วงพีก ๆ ก็อดสงสัยไม่ได้ว่ามี fidelity dial อยู่ที่ไหนสักแห่งเพื่อกดใช้หน่วยความจำหรือทรัพยากรให้น้อยลงแล้วทำให้ประสิทธิภาพลดลงหรือเปล่า
เส้น 60% ยังอยู่ในช่วงความเชื่อมั่น 95% ถ้าอย่างนั้นมันอาจเป็นแค่ noise จากการวัดก็ได้