1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตั้งแต่วันที่ 31 กรกฎาคม 2026 หน้า Usage ของ แพ็กเกจแบบ self-service เช่น Individual และ Teams จะเปลี่ยนเป็นแสดงเฉพาะโทเค็น โดยตัวชี้วัด Spend, คอลัมน์ Cost และค่าใช้จ่ายหน่วยดอลลาร์ใน CSV จะหายไป
  • เหตุผลคือมูลค่าต้นทุนที่คำนวณจากโควตาการใช้งานที่รวมมาอาจแสดงสูงกว่าราคาแพ็กเกจจริงมากและทำให้สับสน ขณะที่ แพ็กเกจ Enterprise ซึ่งมีโครงสร้างการรวมการใช้งานต่างออกไปจะยังคงแสดงเป็นดอลลาร์ต่อไป
  • การเปลี่ยนแปลงนี้ถูกใช้ตอนดึงข้อมูล ทำให้แม้แต่คำขอในอดีตก็จะคืนค่าเป็น chargedCents: 0, usageBasedCosts: "$0.00" และไม่สามารถดู ต้นทุนรายคำขอ ได้แม้เป็นคำขอแบบ on-demand ที่ถูกเรียกเก็บเงินจริง
  • ผู้ดูแล Teams ยังดูข้อมูลการใช้จ่ายบางส่วนได้จาก Dashboard และ Admin API แต่สำหรับแพ็กเกจ self-service จะไม่มี รายละเอียดดอลลาร์แยกตามโมเดล แบบเดิมอีกต่อไป
  • ผู้ใช้ระบุว่าราคาโทเค็นของแต่ละโมเดลต่างกัน ทำให้เปรียบเทียบต้นทุน ประสิทธิภาพ และงบประมาณได้ยาก จึงเรียกร้องกราฟดอลลาร์ที่แยกระหว่างโควตาที่รวมมาและยอดเรียกเก็บจริง หรือ ตัวเลือกสลับการแสดงผล

การแสดงค่าใช้จ่ายที่หายไปจากแพ็กเกจ self-service

  • การเปลี่ยนแปลงที่ปล่อยเมื่อวันที่ 31 กรกฎาคม 2026 ทำให้หน้า Usage ของ แพ็กเกจแบบ self-service รวมถึง Individual และ Teams เปลี่ยนเป็นแสดงเฉพาะโทเค็น
    • ตัวชี้วัด Spend และคอลัมน์ Cost ถูกลบออก
    • CSV ของ Usage ก็ไม่แสดงค่าใช้จ่ายเป็นดอลลาร์เช่นกัน และค่า Cost ที่ยังเหลืออยู่จะถูกตั้งเป็น 0.0 สำหรับทุกเรคอร์ด
    • ไม่มีตัวเลือกใน Settings สำหรับสลับระหว่างโทเค็นกับดอลลาร์ หรือย้อนกลับไปใช้หน้าจอเดิม
  • แพ็กเกจ Enterprise ที่มีโครงสร้างรวมการใช้งานยังสามารถดู จำนวนเงินดอลลาร์ บนหน้าจอ Usage ได้ต่อไป

เหตุผลที่เปลี่ยนไปใช้เกณฑ์โทเค็น

  • แพ็กเกจ Individual มีโควตาที่รวมมาให้ค่อนข้างมาก จึงมีกรณีที่มูลค่าซึ่งคำนวณคำขอตามราคา API ดูสูงกว่าค่าแพ็กเกจจริง
  • เพื่อลดความสับสนนี้ จึงเปลี่ยนเกณฑ์รายงานการใช้งานของแพ็กเกจ self-service จาก ดอลลาร์เป็นโทเค็น
  • โควตาที่รวมมากับ Ultra จะแสดงเป็นจำนวนโทเค็นและ Included โดยจะไม่มีการคิดค่าใช้จ่ายเพิ่มเติมภายในช่วงดังกล่าว
  • ตอนแรกมีการแจ้งว่า on-demand usage ที่เกินโควตารวมจะยังคงแสดงเป็นดอลลาร์ในคอลัมน์ Cost และใน CSV แต่ภายหลังมีการแก้ไขว่า ทั้งหน้าจอ Usage และ CSV ของแพ็กเกจ self-service จะไม่ให้ข้อมูลค่าใช้จ่ายเป็นดอลลาร์แล้ว

ช่องทางดูข้อมูลค่าใช้จ่ายที่ยังใช้ได้ตอนนี้

  • ใน Dashboard > Spending จะแสดงยอดรวม On-Demand Spending ของรอบบิลปัจจุบัน ซึ่งตรงกับยอดที่ถูกเรียกเก็บจริง
  • ผู้ดูแล Teams สามารถดูยอด on-demand แยกตามผู้ใช้ได้ที่ Dashboard > Members > On-Demand
  • ในแพ็กเกจ Teams แบบ self-service และ Individual จะไม่สามารถดู รายละเอียดดอลลาร์แยกตามโมเดล ที่เคยมีในหน้าจอ Usage เดิมได้
  • ผู้ดูแล Teams สามารถรับข้อมูลการใช้จ่ายและฟิลด์ต้นทุนของ usage events ผ่าน Admin API ที่รองรับ
    • ผู้ใช้ในฟอรัมเรียกร้อง endpoint ที่ดึงต้นทุนตามผู้ใช้และช่วงเวลาได้โดยตรง รวมถึงหน้าจอจัดการที่ง่ายกว่านี้

Endpoint ของ Usage และข้อมูลย้อนหลัง

  • https://cursor.com/api/dashboard/get-filtered-usage-events เคยคืนค่า ฟิลด์ต้นทุนรายคำขอ ต่อไปนี้ก่อนมีการเปลี่ยนแปลง
    • chargedCents
    • usageBasedCosts
    • tokenUsage.totalCents
  • ตั้งแต่วันที่ 31 กรกฎาคม 2026 chargedCents จะเป็น 0, usageBasedCosts จะเป็น "$0.00" และ totalCents จะถูกละไว้
  • การลบข้อมูลต้นทุนถูกใช้ตอนอ่านข้อมูล จึงมีผลย้อนหลังกับ usage events ในอดีต และแม้แต่คำขอ on-demand ที่ถูกเรียกเก็บเงินจริงก็จะไม่เห็นต้นทุนใน Usage endpoint อีก
  • มีการยืนยันแล้วว่านี่ไม่ใช่ข้อผิดพลาดชั่วคราวของรายงาน แต่เป็น การเปลี่ยนแปลงโดยตั้งใจ
  • แม้ยอดเรียกเก็บรวมตามช่วงเวลาจะยังอยู่ แต่ระบบรายงานต้นทุนรายคำขอแบบอิสระที่สร้างบนฟิลด์เดิมจะไม่สามารถทำงานแบบเดิมได้อีก

วิธีที่ผู้ใช้เคยใช้ข้อมูลค่าใช้จ่าย

  • ผู้ใช้หลายคนเปิดแท็บ Usage ค้างไว้ตลอดหรือเช็กวันละหลายครั้งเพื่อติดตามงบประมาณ รายวัน รายสัปดาห์ และรายเดือน
  • ผู้ใช้ Teams เคยตรวจสอบยอดใช้งานของแต่ละสมาชิกภายใต้โควตา on-demand ร่วมกัน และวิเคราะห์ต้นทุนตามผู้ใช้ โมเดล และคำขอ
    • ผู้ใช้ Teams รายหนึ่งระบุว่าต้นทุนการใช้งานรวมของรอบบิลปัจจุบันอยู่ที่ 30,000 ดอลลาร์ และส่วนใหญ่คำนวณตามราคา API
  • บางคนรีเฟรชหน้า Usage ก่อนและหลังส่งคำขอเพื่อเปรียบเทียบต้นทุนและประสิทธิภาพของแต่ละโมเดล
    • หลังคำขอ Cursor Grok 4.5 เพิ่มขึ้นราว $0.32
    • หลังใช้ Opus 5 เพิ่มขึ้นราว $2.56
  • ผู้ใช้บางส่วนใช้ตัวเลขที่แสดงไม่ใช่เพื่อดูยอดเรียกเก็บจริง แต่เพื่อประเมิน มูลค่าการใช้งานและเงินที่ประหยัดได้ จากค่าสมาชิก
  • เนื่องจากราคาโทเค็นของแต่ละโมเดลต่างกัน การดูแค่จำนวนโทเค็นจึงทำให้เปรียบเทียบต้นทุนและความคุ้มค่าได้ยากโดยตรง

ทางเลือกที่ผู้ใช้เรียกร้อง

  • มีข้อเรียกร้องว่าแม้จะคงค่าเริ่มต้นเป็น Tokens ก็ควรมี ปุ่มสลับหรือดรอปดาวน์ ให้เลือกดูกราฟดอลลาร์แบบเดิมได้
  • หากแยกมูลค่าของโควตาที่รวมมากับยอด on-demand ที่เรียกเก็บจริงออกจากกันในกราฟ ก็จะช่วยลดความสับสนและยังคงข้อมูลดอลลาร์ไว้ได้
  • หลายเสียงมองว่ายอดรวมต่อผู้ใช้ไม่สามารถทดแทนการวิเคราะห์รายวัน รายโมเดล และรายคำขอได้ จึงเรียกร้องให้คืนคอลัมน์ต้นทุนและ API fields ระดับคำขอ
  • หากมีแผนจะเปลี่ยนระยะยาวไปสู่ระบบคิดราคาแบบอิงโทเค็น ก็ควรเปิดเผยให้ชัดเจน และมีความเห็นจำนวนมากว่าการเปลี่ยนแปลงครั้งนี้ทำให้ การประเมินรายจ่ายรายเดือนและการควบคุมต้นทุน ยากขึ้น

ประเด็นแยกต่างหากเรื่องการเลือก sub-agent

  • ยังมีการยกปัญหาที่โมเดลอื่นถูกเลือกอัตโนมัติ ทั้งที่ตั้งค่า sub-agent เริ่มต้นไว้ต่างออกไป
  • explore เป็น sub-agent ประเภทหนึ่ง และ Agent สามารถรัน sub-agent ประเภทอื่นที่ใช้โมเดลต่างกันได้
  • ดูพฤติกรรมที่เกี่ยวข้องเพิ่มเติมได้ที่ Sub agents triggers even when disabled and uses Opus for no reason

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

 
GN⁺ 1 시간 전
ความคิดเห็นบน Hacker News
  • แนะนำให้วัด ปริมาณการใช้โทเค็นแยกตามชุด harness และโมเดล สำหรับงานเฉพาะอย่างสม่ำเสมอ
    แม้จะทำงานเดียวกันด้วยโมเดลและสภาพแวดล้อมเดียวกัน แต่ประสิทธิภาพการใช้โทเค็นและความสิ้นเปลืองของแต่ละเอเจนต์ต่างกันมาก
    ผลจากการรันงานเอเจนต์ 10 งานซ้ำในหลาย harness บน Ubuntu 26.04 VM ด้วย GPT 5.6 Sol เป็นดังนี้

    Harness API total Input Cached Uncached Output
    smol 172,807 142,334 8,704 133,630 30,473
    Pi 427,211 392,767 137,216 255,551 34,444
    OpenCode 1,564,429 1,523,957 1,204,736 319,221 40,472
    Codex 3,005,744 2,953,154 2,649,344 303,810 52,590
    Hermes 3,856,611 3,808,231 3,167,232 640,999 48,380
    Claude Code 5,073,137 5,029,969 4,587,008 442,961 43,168

    https://x.com/__tosh/status/2083593799872237680
    คาดไว้แล้วว่า Claude Code ไม่ได้ปรับแต่งมาสำหรับโมเดลของ OpenAI แต่ก็น่าตกใจที่แค่ harness อย่างเดียวทำให้ต่างกันได้ขนาดนี้
    smol ที่กำลังพัฒนาเองเป็น harness แบบเรียบง่าย ใช้แค่ system prompt ขั้นต่ำกับเครื่องมือเชลล์หนึ่งตัว และไม่มีไฟล์ฟีเจอร์
    ไม่ควรประเมินต่ำไปว่า harness ยอดนิยมยัดข้อมูลเข้าไปใน context window มากแค่ไหน

    • สงสัยว่ามีข้อมูลสำหรับตัดสินไหมว่านั่นเป็นเนื้อหาที่ไร้ประโยชน์จริง ๆ หรือเป็น บริบทที่มีประโยชน์ ซึ่งเฉพาะเจาะจงกับโปรเจกต์หรือภาษาโปรแกรม
    • สงสัยว่าใช้ smol ทำงานซับซ้อนแค่ไหน อยากรู้ว่าเอเจนต์จัดการทุกอย่างด้วย sed หรือสร้างเครื่องมือเอง และทำไมถึงไม่ใช้ Pi
      ความต่างของโทเค็นระหว่างสอง harness นี้ก็น่าสนใจ system prompt ไม่น่าต่างกันมาก และ Pi อาจจะสั้นกว่าด้วยซ้ำ อีกทั้งเครื่องมือแค่สี่ตัวก็คงอธิบายความต่างนี้ได้ยาก จึงอยากลองทดสอบเอง
    • Claude Code อัดเครื่องมือจำนวนมากเข้าไปใน system prompt และ เฉพาะระบบ memory ก็กินไปมากกว่า 10,000 โทเค็น
      ในงานอย่าง monitoring loop ที่ใช้บริบทไม่มากแต่ทำซ้ำหลายรอบ ต้นทุนอาจเพิ่มเป็นสองเท่าได้ง่าย
      ควรใช้ --disallowed-tools เพื่อตัดเครื่องมือที่ไม่จำเป็นออก แต่ก็กลายเป็นเกมตีตัวตุ่นไม่รู้จบ เพราะมีเครื่องมือใหม่เพิ่มเข้ามาเรื่อย ๆ
    • context window ไม่ใช่แค่สำคัญ แต่เป็นทุกอย่าง หากต้องการใช้ Claude Code อย่างมีประสิทธิภาพ ต้องตัดสินใจเองว่าจะบีบอัดเมื่อใด
      โดยค่าเริ่มต้นมันใช้ บริบท 1 ล้านโทเค็น และไม่จำกัดตัวเอง ในทางกลับกัน การอ่านแคชของ smol ที่น้อยเกินไปอาจเป็นปัญหาการตั้งค่าก็ได้
    • สงสัยว่าใช้เครื่องมืออะไรในการเปรียบเทียบ หรือรัน prompt แล้วตรวจด้วยเครื่องมืออย่าง ccusage
      กำลังมองหาเครื่องมือเปรียบเทียบ agent harness และอยากเห็นไม่ใช่แค่อินพุต/เอาต์พุต แต่รวมถึง system prompt, execution trace, tool call ด้วย
      โทเค็นน้อยไม่ได้แปลว่าผลดี หากข้ามการตรวจสอบสำคัญไป และโทเค็นมากก็ไม่ได้แปลว่าดีกว่าเสมอ อาจไตร่ตรองมากเกินไปก็ได้ การดู execution trace ทั้งหมดของงานเดียวกันจะช่วยให้เข้าใจว่าทำไม Codex ใช้เยอะ ส่วน Pi ใช้น้อย
  • ใช้และจ่ายเงินให้ Cursor อย่างกระตือรือร้นมาตั้งแต่ปี 2023 แต่ในช่วง 6 เดือนที่ผ่านมาแทบไม่ได้เปิดเลย
    ช่วงนี้เขียนโค้ดด้วย Claude Code และ Codex อ่านและรีวิวบน GitHub และเมื่อดูในเครื่องก็ใช้ text editor ทั่วไป
    สงสัยว่า คุณค่าของ Cursor ในปี 2026 คืออะไร

    • เคยใช้ Windsurf และ Cursor และให้ฟีดแบ็กผลิตภัณฑ์กับทีม Cursor ด้วย แต่คุณค่าหายไปเพราะค่าใช้จ่าย ดูเหมือนข้อดีของ Cursor คือเอาเงินผู้ใช้ไปได้เร็วกว่า Claude
    • ข้อดีของ Cursor มีสองอย่าง คือยังเป็น IDE อยู่ จึงทำงานได้โดยไม่ต้องเปิด VSCode/Cursor แยกจาก Codex ให้ยุ่งยาก และ รีวิวการเปลี่ยนแปลงเชิงลึกใน IDE ได้สะดวกกว่าการดู diff บน GitHub
      อีกทั้งยังรองรับทุกโมเดล จึงเหมาะสำหรับลองโมเดลอื่นเมื่อไม่พอใจกับผลลัพธ์แรก
    • เวลาแก้ไขเอง Cursor Tab มีประโยชน์ แต่ไม่แน่ใจว่าคุ้มเดือนละ 20 ดอลลาร์ หากเดือนละ 5 ดอลลาร์ ก็น่าจะสมัครไว้เพื่อ Cursor Tab อย่างเดียวแล้วลืมไปได้
      ระดับราคา 20 ดอลลาร์แข่งขันกันดุเดือดเกินไป จึงชอบปลั๊กอิน Claude หรือ Codex มากกว่า sidebar เขียนโค้ดแบบเอเจนต์ของ Cursor
    • การเปลี่ยนแปลงล่าสุดดูเหมือนทำให้การแก้โค้ดโดยตรงใน Cursor แย่ลง ไม่รู้ว่ากำลังมุ่งไปทางไหน และไม่รู้สึกเหมือนเป็น fork ของ VSCode อีกแล้ว จึงกำลังพิจารณาทางเลือกอื่น
      อย่างไรก็ดี workflow ที่สลับไปมาระหว่าง Claude Code กับ Codex แล้วรีวิวบน GitHub ดูยุ่งยาก ส่วนฝั่ง Cursor ผสานรวมมากกว่าและมีแรงเสียดทานน้อยกว่า
    • Cursor CLI ก็น่าลองดู: https://cursor.com/cli
  • ในฐานะพนักงาน Cursor ขอยืนยันว่า ยังดูยอดเรียกเก็บเงินจริงได้ในหน้า Spending
    ระหว่างเก็บกวาด feature flag เก่า ๆ เมื่อวันก่อน ได้ทำให้การแสดงต้นทุนเป็นดอลลาร์ใน Usage CSV export เสียโดยไม่ตั้งใจ และตอนนี้แก้แล้ว
    flag ดังกล่าวยังแสดงกราฟการใช้เป็นดอลลาร์ให้ผู้ใช้ self-service บางส่วนด้วย แต่ทำให้สับสนเพราะแสดงเป็นดอลลาร์แม้แต่การใช้งานที่รวมอยู่ในแพ็กเกจซึ่งไม่ได้ถูกเรียกเก็บเงินจริง มีผู้ใช้เข้าใจผิดว่าเป็นค่าใช้จ่ายจริง จึงลบกราฟออก

    • ตัวบ่งชี้ต้นทุนแบบวงกลม ข้างการแสดงปริมาณการใช้บริบทก็ถูกลบออกด้วย ตอนนี้จึงเป็นไปได้ง่ายขึ้นที่จะเปิดโมเดลราคาแพงทิ้งไว้โดยไม่รู้ตัวจนกว่าเครดิตที่รวมไว้จะหมด และยากจะเชื่อว่านี่ไม่ใช่จุดประสงค์ของการเปลี่ยนแปลง
    • หน้าจอที่บอกว่าดูในหน้า Spending ไม่ได้คืออันนี้: https://www.pasteboard.co/dNXUdT-h8Giy.png
      ถ้าคำตอบคือมีแต่แอดมินที่ดูได้ ก็ไม่มีความหมาย คงไปถามแอดมินทุกวันว่าใช้ไปถึงไหนแล้ว หรือให้ช่วยตรวจ ความคุ้มค่าต้นทุน ของโมเดลในแต่ละเซสชันไม่ได้
    • สงสัยจริง ๆ ว่าคิดหรือว่าผู้ใช้แบบสมัครสมาชิกเห็นตัวเลขดอลลาร์แล้วจะไม่เข้าใจแม้กระทั่งว่านั่นคือราคา API ที่จะใช้หากไม่ได้สมัครสมาชิกอยู่ และนี่เป็นการเปลี่ยนแปลงที่แย่มาก
  • Cursor แพร่หลายอย่างรวดเร็วเพราะทำให้ย้ายมาจาก Visual Studio Code ได้ง่าย แต่นี่ก็เป็น ดาบสองคม การกลับไปใช้ VS Code กับส่วนขยายเอเจนต์ก็ทำได้ง่ายเช่นกัน

    • ผมย้ายจาก VS Code ไป Cursor ในปี 2023 แล้วกลับไปใช้ Claude Code กับ VSCode เมื่อ Opus 4.7 หรือ 4.6 พัฒนาไปมากในเดือนธันวาคม 2025
      ผมมาจาก Sublime Text เลยคุ้นกับคีย์ลัดพื้นฐานของ VSCode อยู่แล้ว แต่ Cursor ดักจับชุดคำสั่ง CMD แทบทั้งหมดจนผมเบื่อหน่าย
      ตอนนี้ต้องการแค่ตัวดูโค้ดที่รวดเร็ว จึงน่าจะ กลับไปใช้ Sublime Text ได้
    • Cursor มีตัวช่วยนำเข้าการตั้งค่าจาก VS Code แต่ไม่มี เครื่องมือย้ายกลับในทิศทางตรงกันข้าม อย่างน้อยเมื่อไม่กี่เดือนก่อน แม้แต่เครื่องมือย้ายระหว่างคอมพิวเตอร์ก็ยังไม่มี
  • ต่อไป Elon อาจจ่ายเงินเดือนพนักงานเป็นโทเคน และร้านขายของชำก็อาจแสดงราคาตามดีมานด์แบบโทเคน ทำให้ราคาตอนหยิบของกับตอนจ่ายเงินไม่เท่ากัน แต่ก็ไม่เป็นไร เพราะอย่างไร Elon ก็บอกว่าเงินจะหายไปในไม่ช้า

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

  • เมื่อผู้ใช้เริ่มคำนวณ ROI ของผลิตภัณฑ์ AI ปัญหาก็แก้ได้ด้วยการ ซ่อน I ของเงินลงทุน

    • บริษัทเหล่านี้ดูเหมือนต้องการทำให้การใช้โทเคนไม่โปร่งใส คล้ายกับบิล AWS ของหลายองค์กร
      ถ้ามีวินัยเข้มงวดและใช้แท็กที่เหมาะสม ก็พอจะรู้ได้ว่าเงินไหลไปไหน แต่ในความเป็นจริงมีน้อยแห่งที่ทำเช่นนั้น
      ดูเหมือนมีเจตนาทำให้แยกได้ยากมากระหว่างวิศวกรที่ใช้ AI สิ้นเปลืองกับวิศวกรที่สร้าง มูลค่าสูงต่อโทเคน
  • Cursor เป็นจุดเริ่มต้นที่ยอดเยี่ยมสำหรับการสัมผัสวิศวกรรมแบบใช้เอเจนต์ แต่ความสามารถในการแข่งขันด้านราคาของ Claude ดูเหมือนจะมาจากการซื้อจำนวนมากเป็นหลัก
    เกราะป้องกันที่แท้จริงคือ Composer 2.5 และผมเห็นว่าประสบการณ์ใช้งานเอเจนต์กับ IDE ยังสู้ Codex และ Claude Desktop ไม่ได้
    ในแง่ความคุ้มค่า Cursor อาจสมเหตุสมผลที่สุด แต่เมื่อส่วนต่างราคาไม่มาก ความสามารถย่อมสำคัญกว่าต้นทุน
    ช่วงนี้ผมใช้ Codex กับ Claude Desktop และใช้ Zen เมื่อต้องตรวจโค้ด ฟีเจอร์สนทนาด้วยเสียงแบบเรียลไทม์ของ Codex ที่ไม่ใช่การถอดคำพูด เมื่อผสานกับเวิร์กโฟลว์เอเจนต์แล้วถือว่าไม่มีใครเทียบได้

    • ตอนนี้อยู่ในเครือ SpaceX แล้ว จึงมองว่า Grok 4.5 อยู่ในสายเดียวกันได้ด้วย Grok 4.5 คือ Sonnet ส่วน Composer ให้ความรู้สึกเหมือนโมเดลที่เร็วและเก่งในระดับ Haiku
  • Cursor เคยเป็นผู้ให้บริการของบริษัทสำหรับเข้าถึงโมเดลที่ไม่ใช่ Anthropic แต่เมื่อ ข้อมูลต้นทุนหายไปและไม่สามารถพร็อกซีคำขอ API ได้อีก คุณค่าก็ลดลงอย่างมาก
    พวกเขากดดันอย่างหนักให้ต่ออายุภายใต้แพ็กเกจเดิม แล้วก็ผิดสัญญาทันทีหลังจากนั้น ดังนั้นผมจะบอกผู้บริหารให้ชัดเจนว่าควรลดการใช้ Cursor ให้เหลือน้อยที่สุดและไม่ต่ออายุ
    โดยเฉพาะหากไม่ใช่ลูกค้าองค์กรขนาดใหญ่ ก็ไม่ควรฝากทรัพย์สินทางปัญญาไว้กับ Cursor และผู้ใช้รายอื่นก็ควรไม่ไว้วางใจเช่นกัน

  • เป็นกระบวนการตามแบบฉบับของบริษัทที่เริ่มโลภ ผมเก็บเธรดนั้นไว้แล้ว และสงสัยว่า Cursor จะปิดหรือลบมันหรือไม่