FUTURE LIFESTYLE · OpenClaw v2026.10.2 · ออก 12 ตุลาคม 2026 · ตรวจต้นทาง 13 ตุลาคม
Quick Answer: OpenClaw 2026.10.2 แก้สองจุดที่เกี่ยวกับการใช้ Agent ในชีวิตประจำวัน: ใน Telegram เก็บ preview ระหว่างทางไว้เมื่อข้อความแทนยังไม่ถูกยอมรับ ส่วนใน Control UI การพิมพ์ /stop ขณะออนไลน์ใช้การหยุดระดับ session เพื่อไม่ให้คิวเดิมของ session ปกติเดินงานต่อทันที
สองเรื่องนี้อยู่คนละหน้าการใช้งาน ข้อความที่ยังเห็นไม่ได้แปลว่างานจบ และ พิมพ์ /stop ต่างจากกดปุ่ม Stop เมื่อปุ่มระบุรอบงานได้ การหยุดไม่ใช่การย้อนสิ่งที่ส่งหรือเปลี่ยนไปแล้ว ข่าวนี้ตรวจประกาศกับซอร์ส ไม่ได้รัน OpenClaw หรือทดสอบบัญชีจริง
การใช้ Agent ต้องรู้ทั้ง “ถึงไหนแล้ว” และ “หยุดอะไร”
เวลาให้ผู้ช่วยวางแผนอาหารทั้งสัปดาห์ เราอาจถามข้อจำกัดก่อน ให้ค้นข้อมูล แล้วขอปรับเมนูต่อ หรือกำลังดูเส้นทางเที่ยวแล้วเปลี่ยนใจระหว่างที่ Agent ทำงาน หากข้อความระหว่างทางหายไป หรือบอกหยุดแล้วคำถามที่ค้างยังเริ่มงานอีก ผู้ใช้ย่อมตัดสินใจยากว่าควรรอ สั่งซ้ำ หรือออกคำขอใหม่ ตัวอย่างอาหารและทริปในบทความเป็นสถานการณ์สมมติ ไม่มีการซื้อ จอง หรือใช้ข้อมูลส่วนตัว
Stable release v2026.10.2 เผยแพร่วันที่ 12 ตุลาคม เวลา 12:34:44 น. ไทย หรือ 05:34:44 UTC การตรวจต้นทางวันที่ 13 ตุลาคมยังพบรุ่นนี้เป็นรุ่นล่าสุด เมื่อเทียบกับ v2026.10.1 ข่าวนี้เลือกเฉพาะการเก็บ Telegram preview และการพิมพ์คำสั่งหยุดใน Control UI เพราะมีผลใหม่ต่อการควบคุมงาน ไม่ได้หมายความว่ารุ่นนี้เพิ่งมี Agent หรือเครื่องมือเป็นครั้งแรก
Telegram: ข้อความระหว่างทาง
เมื่อสลับไป preview ใหม่ในกรณีที่แก้ไข preview เก่ายังอยู่จนมีข้อความแทนที่ระบบยอมรับ หรือเจ้าของ stream สั่งล้าง ไม่ได้เก็บตลอดไป
Control UI: คำสั่งหยุด
พิมพ์ /stop ขณะเชื่อมต่อใน session ปกติเลือกการหยุดระดับ session และล้างคิว ส่วนปุ่ม Stop ที่รู้รอบงานยังหยุดเฉพาะรอบนั้น
Telegram: รักษาข้อความที่เห็นไว้จนข้อความแทนพร้อม
ผู้พัฒนาอธิบายปัญหาในโหมด partial streaming ว่า preview ที่คนเห็นอาจหายเมื่อเปลี่ยนเป็นข้อความใหม่ซึ่งยังมาไม่ถึงหรือถูกปฏิเสธ เดิมการลบ preview เก่าถูกตั้งด้วยเวลาเพียงอย่างเดียว รุ่นใหม่เก็บรายการที่ถูกแทนไว้ แล้วเริ่มกระบวนการลบหลังข้อความใหม่ได้รับการยอมรับ หรือเมื่อเจ้าของ stream เรียก cleanup แบบ clear() การเทียบไฟล์รุ่นเก่ากับใหม่รองรับความเปลี่ยนแปลงนี้โดยตรง
ลองนึกว่า Agent กำลังค้นตัวเลือกเส้นทางเที่ยวและแสดงคำตอบบางส่วน ถ้าการส่ง preview ถัดไปยังรอ การแก้ไขนี้ลดกรณีที่หน้าคุยไม่มีข้อความให้ติดตามเลย แต่ข้อความที่เหลือยังเป็นงานระหว่างทาง ไม่รับรองว่าการค้นถูกต้อง ทุกเครื่องมือทำเสร็จ หรือแผนพร้อมใช้ เมื่อ cleanup ถูกเรียก preview ก็ถูกนำออกได้ และเส้นทางส่งคำตอบสุดท้ายยังมี fallback ของตัวเอง
คำว่า “ยอมรับ” หมายถึงระดับ API: โค้ดตรวจ message ID และการตอบรับจากผู้ให้บริการ ก่อนเลิกเก็บ preview ที่ถูกแทน ไม่ได้หมายถึงคนเปิดอ่านแล้ว เอกสาร Telegram ระบุว่า Bot API ไม่มี read receipt จึงใช้ฟองข้อความหรือการตอบรับนั้นเป็นหลักฐานว่าผู้รับอ่านหรือเข้าใจไม่ได้
สิ่งที่ยืนยันได้คือกติกาในซอร์สและการทดสอบที่ผู้พัฒนารายงานใน PR ไม่ใช่ผลทดลองบัญชีของ Hybrid Mind เราไม่ได้ยืนยันว่าการแก้ไขนี้ครอบคลุมความล้มเหลวเครือข่ายหรือการส่งข้อความทุกชนิด และไม่ได้ใช้เวลาจาก fixture ของผู้พัฒนามาอ้างว่าผู้ใช้จริงจะได้ผลเร็วเท่านั้น
Control UI: พิมพ์ /stop กับกด Stop หยุดคนละขอบเขต
อีกปัญหาคือการพิมพ์ /stop อาจหยุดรอบที่กำลังทำ แต่ข้อความที่เข้าคิวไว้หรือเหตุการณ์จบงานทำให้ session เริ่มต่อทันที เช่น กำลังให้ Agent เปรียบเทียบเมนูและถามเรื่องของที่ต้องซื้อไว้ต่อแล้ว ผู้ใช้อยากหยุดชุดสนทนานี้ แต่คำถามค้างยังถูกประมวลผล การแก้ไขเปลี่ยนทางเลือกของ Control UI ไปใช้การยกเลิกระดับ session ที่มีอยู่แล้ว
เมื่อออนไลน์และเป็น session ปกติที่ไม่ใช่ global คำขอหยุดนี้ล้างงานที่ค้างของ session ที่เลือกก่อนหยุดงานปัจจุบัน ตามโค้ดคำขอคือ sessions.abort พร้อม clearQueued: true จึงต่างจากเดิมที่ไคลเอนต์เลือกหยุดเฉพาะรอบเมื่อรู้ run ID ไม่ได้เพิ่มสิทธิ์ใหม่ให้ Agent และไม่ได้เลือกหยุดทุก session อื่นด้วย
ปุ่ม Stop ยังมีงานของมัน: ถ้าระบุรอบงานได้ ปุ่มคงขอบเขต exact-run และปล่อยคิวระดับ session ไว้ งานค้างจึงยังอาจเดินต่อหลังรอบนั้นหยุด การกดปุ่มจึงไม่ควรถูกตีความว่า “ยกเลิกทุกคำขอในบทสนทนานี้” กรณีไม่รู้รอบงานมีทางเลือกระดับ session เดิมอยู่แล้ว ไม่ใช่สิ่งที่เพิ่งเกิดจากการเปลี่ยน typed stop ครั้งนี้
ข้อยกเว้นที่ต้องรักษา: ตอนขาดการเชื่อมต่อ ระบบเก็บคำขอหยุดที่ผูกกับรอบงานเดิมเพื่อส่งใหม่เมื่อกลับมาเชื่อม ไม่ใช่การยกเลิกทั้ง session ทันที และต้องมีตัวตนรอบงานที่ปลอดภัยให้ระบุ ส่วน global session หรือ alias ที่เข้าขอบเขต global ยังไม่เพิ่มการล้างคิวแบบ session ปกติ การตั้งคิวหยุด offline ไม่ควรถูกแสดงเหมือน Gateway รับคำขอไปแล้ว
ข้อวิเคราะห์ของเรา: แยกสามสิ่งก่อนออกคำขอใหม่ ได้แก่ งานที่กำลังทำ คำขอที่ยังเข้าคิว และสิ่งที่เปลี่ยนในระบบภายนอกไปแล้ว การยกเลิกงานต่อไม่ได้ย้อนข้อความที่ส่ง การจอง หรือการแก้ไฟล์ที่สำเร็จก่อนหน้า และหลักฐานนี้ไม่พอรับรองว่าทุก process เครื่องมือ หรือบริการภายนอกหยุดทันที
Agent มีหลายขั้นตอน และสิทธิ์ไม่ใช่แค่คุยกับบอตได้
OpenClaw มี Gateway ประสาน session โมเดล เครื่องมือและช่องสนทนา คำขอหนึ่งจึงอาจผ่านการอ่านบริบท ให้โมเดลตัดสินใจเลือกเครื่องมือ รับผล แล้วค่อยตอบกลับ ความสามารถจริงขึ้นกับเครื่องมือ โมเดลและนโยบายที่ตั้งไว้ ไม่ใช่ทุกชุดจะเปิดความสามารถเหมือนกัน การเก็บ preview เป็นส่วนของการแสดงความคืบหน้า ส่วนการหยุดเป็นส่วนควบคุมงานที่มีเจ้าของและขอบเขต
การเชื่อม Telegram ต้องมีบอตและนโยบายอนุญาตคนคุย เช่น pairing หรือ allowlist ส่วนการอนุมัติรันคำสั่ง exec approval ต้องตรวจแยก เอกสารให้ใช้ ID ผู้อนุมัติที่เป็นตัวเลขและมีทางอ้างอิงเจ้าของตามการตั้งค่า คนที่คุยกับบอตได้จึงไม่ได้รับประกันว่ามีสิทธิ์อนุมัติรันคำสั่งทั้งหมด ที่ส่ง prompt อนุมัติเริ่มต้นคือ DM และเลือกส่งในแชตหรือทั้งสองที่ได้ ซึ่งอาจเผยข้อความคำสั่งต่อคนในกลุ่มที่เลือก
จุดอนุมัติของมนุษย์ขึ้นกับ policy ของเครื่องมือและงาน ไม่ควรสรุปว่าทุกการกระทำถามเสมอหรือทุกอย่างทำได้ทันที การแก้ /stop ไม่เปลี่ยนการจับคู่ผู้ใช้ให้เป็นใบอนุญาตรันเครื่องมือ และไม่ควรใช้เป็นเหตุผลเพิ่มสิทธิ์ระบบโดยไม่อ่านนโยบายที่ใช้อยู่
Visual Lab: หกแนวคิดที่ควรแยก
เลือกโหนดเพื่ออ่าน preview การตอบรับ typed stop ปุ่ม/offline ขอบเขตคิว และสิทธิ์/ข้อมูล ฉากเป็น ภาพฉาย 2.5D ของแนวคิด โหนดเรียงเพื่ออ่านความสัมพันธ์ของสองกรณี ไม่ใช่ mesh, runtime หรือเส้นทาง Telegram ผ่าน Control UI ไม่มีการส่งคำขอจริง
OpenClaw: ความคืบหน้ากับขอบเขตหยุดงาน
ภาพฉาย 2.5D ของแนวคิดสำหรับ v2026.10.2 โหนดเรียงเพื่ออ่านสองผิวใช้งาน Telegram preview กับ Control UI stop แยกกัน ไม่ใช่ mesh, runtime หรือ pipeline จาก Telegram ไป Control UI ไม่เรียกบอต เครื่องมือ หรือ API จริง
Telegram: preview ยังอยู่
ในกรณี partial preview ถูกหมุนไปข้อความใหม่ รุ่นนี้เก็บ preview เก่าจนข้อความแทนได้รับการยอมรับ หรือ owner เรียก clear ไม่ลบด้วยเวลาอย่างเดียวระหว่างรอหรือถูกปฏิเสธ
ไม่ได้เก็บตลอดไป และไม่รับรองว่าทุกความล้มเหลวการส่งครอบคลุมแล้ว
อ่านข้อมูลทั้งหมดแบบข้อความ
- Telegram: preview ยังอยู่ — ในกรณี partial preview ถูกหมุนไปข้อความใหม่ รุ่นนี้เก็บ preview เก่าจนข้อความแทนได้รับการยอมรับ หรือ owner เรียก clear ไม่ลบด้วยเวลาอย่างเดียวระหว่างรอหรือถูกปฏิเสธ ตรวจรับ: ไม่ได้เก็บตลอดไป และไม่รับรองว่าทุกความล้มเหลวการส่งครอบคลุมแล้ว
- การตอบรับไม่ใช่คนอ่าน — โค้ดตรวจ message ID กับการยอมรับข้อความจากผู้ให้บริการก่อนนำ preview ที่ถูกแทนออก Telegram Bot API ไม่มี read receipt และ owner cleanup ยังล้าง preview ได้ ตรวจรับ: ข้อความที่เห็นไม่ยืนยันว่างาน Agent จบหรือเนื้อหาถูกต้อง
- Control UI: typed stop — พิมพ์ /stop ขณะออนไลน์เลือกหยุดระดับ session สำหรับ session ปกติที่ไม่ใช่ global ขอ clearQueued:true เพื่อไม่ให้คิวเดิมเดินต่อทันที เป็นการเลือก operation เดิมที่มีอยู่ ตรวจรับ: ไม่ใช่การเปลี่ยนเส้นทาง /stop ของ Telegram และไม่เพิ่มสิทธิ์เครื่องมือ
- ปุ่มและ offline ผูกกับ run — ปุ่ม Stop ที่รู้รอบงานคง exact-run และรักษาคิว session ส่วน offline เก็บคำขอหยุดรอบเดิมที่รู้ตัวตนเพื่อส่งเมื่อเชื่อมใหม่ ไม่ใช่หยุดทันทีหรือหยุดรอบใหม่แทน ตรวจรับ: แบบจำลองสมมติว่ามี run ID ที่ปลอดภัย; กรณีปุ่มไม่รู้ run ใช้ session path เดิมได้
- คิวมีเจ้าของและขอบเขต — Session อื่นไม่ถูกเลือกด้วย typed stop ของ session นี้ Global session/alias ยังมีข้อจำกัดและไม่เพิ่ม clearQueued แบบ session ปกติ การหยุดไม่ย้อนการส่งหรือเปลี่ยนแปลงที่สำเร็จไปแล้ว ตรวจรับ: ไม่รับรองทุกเครื่องมือ process หรือบริการภายนอกหยุดทันที
- สิทธิ์กับโมเดลต้องแยก — ตรวจสิทธิ์คุยและ exec approver ตามนโยบายแยกกัน Local state อยู่บนฮาร์ดแวร์แต่ prompt ยังไปโมเดลและแชตที่ตั้งไว้ MIT และไม่มี paid tier ของโครงการไม่แปลว่าโมเดลหรือโฮสต์ฟรี ตรวจรับ: ไม่มีผลทดลองคุณภาพไทย บิลจริง หรือการบังคับใช้สิทธิ์ในบัญชีผู้อ่าน
คำอธิบายฉากที่อ่านได้เป็นข้อความ
- Telegram preview: เก็บข้อความเก่าระหว่างรอข้อความแทนในกรณีที่แก้ไข
- การตอบรับ: API ยอมรับข้อความไม่เท่ากับคนอ่าน; owner clear ยังนำ preview ออกได้
- Typed stop: Control UI ออนไลน์เลือกการหยุดระดับ session ปกติและล้างคิว
- ปุ่มกับ offline: exact-run รักษาคิว; offline รอส่งคำขอรอบเดิมเมื่อเชื่อมใหม่
- ขอบเขต: global ยังมีข้อจำกัดและ session อื่นไม่ถูกเลือก; ไม่ย้อนผลภายนอก
- สิทธิ์กับข้อมูล: การคุย การอนุมัติ exec และการส่งบริบทไปโมเดลต้องแยกตรวจ
ลองแยก “ข้อความยังอยู่” จาก “งานหยุดตรงไหน”
เลือกหน้าการใช้งาน แล้วเปลี่ยนสถานการณ์
แบบจำลองจากกติกาซอร์ส ไม่ใช่ OpenClaw ที่กำลังรัน ไม่มี API เครือข่าย storage บอต หรือเครื่องมือจริง ใช้ Tab และคีย์บอร์ดเลือกค่าได้ ช่องของอีกหน้าจะหยุดไว้เพื่อไม่รวมสองกรณีเป็น pipeline เดียว
Telegram: ยังรอข้อความแทน
ตัวอย่างคง preview เก่าไว้ระหว่างที่ข้อความแทนยังไม่ได้รับการยอมรับ
คิวการหยุดงานไม่ใช่ผลที่ประเมินในกรณี Telegram นี้
ข้อความที่เห็นไม่รับรองว่างานจบหรือคนอ่านแล้ว อ่าน fallback ด้านล่างได้เสมอ
สมมติ Telegram อยู่ในกรณี preview ถูกหมุนไปข้อความใหม่ และ owner ยังไม่ล้างนอกจากเมื่อเลือก clear ส่วน Control UI มีรอบงานที่รู้ตัวตน คำขอค้าง และ session อื่นแยกกัน ผลคือคำอธิบายคำขอ/ขอบเขต ไม่ใช่ผลการยกเลิกจริง
Fallback: กติกาครบโดยไม่ต้องใช้ JavaScript
- Telegram รอหรือถูกปฏิเสธ → ยังไม่ลบ preview เก่าด้วยเวลาอย่างเดียว ตราบใดที่ยังไม่มี replacement ที่ยอมรับหรือ owner clear
- Telegram ยอมรับข้อความแทน → เริ่มนำ preview เก่าออกตาม cleanup; ไม่ใช่ read receipt
- Telegram owner clear → ล้าง preview ตามเส้นทาง cleanup ได้ แม้ไม่ได้เลือกว่า replacement ยอมรับ
- Control UI typed online ใน session ปกติ → ขอหยุด session ที่เลือกพร้อมล้างคิว
- ปุ่ม Stop ที่รู้ run → ขอหยุดรอบนั้น คิว session ยังอยู่และอาจเดินต่อ
- Offline ที่รู้ run → เก็บ stop ผูกกับรอบเดิมเพื่อส่งหลังเชื่อมใหม่ ไม่ใช่หยุดทันทีหรือกวาดคิวใหม่
- Global → คงข้อจำกัดการล้างคิว ไม่เพิ่ม clearQueued แบบ session ปกติ
JavaScript ปิดอยู่ ปุ่มหยุดไว้ และคำอธิบายทุกเงื่อนไขยังอ่านได้จากข้อความด้านบน
รันเองยังมีข้อมูลที่ส่งออก และต้นทุนโมเดลแยก
README รุ่นที่อ้างอิง ระบุว่า state ความจำและ credentials อยู่บนฮาร์ดแวร์ของผู้ใช้ แต่ prompt ไปยังผู้ให้บริการโมเดลและแพลตฟอร์มแชตที่ตั้งไว้ รวมถึง diagnostic export ที่เปิดเอง การวาง Gateway ในเครื่องจึงไม่ได้แปลว่าประมวลผลทุกส่วนในเครื่องเสมอไป รุ่นนี้ไม่ได้ทำให้แผนอาหารหรือทริปที่ส่งเข้าคลาวด์ย้อนกลับมาเป็นข้อมูล local ทั้งหมด
ซอฟต์แวร์มีใบอนุญาต MIT และโครงการระบุว่าไม่มี paid tier หรือ hosted service ของ OpenClaw เอง แต่ค่าโมเดล โฮสต์ ฮาร์ดแวร์และเครือข่ายต้องแยกกัน ดูการใช้จากผู้ให้บริการที่เลือก ไม่ตีความคำว่า open source ว่า API ทุกตัวฟรี เราไม่ได้ตรวจบิลไทยหรือทดลองความคุ้มค่าของชุดใด
เอกสาร Usage ยังแยกยอดหรือโควตาที่ผู้ให้บริการรายงานออกจากค่าประมาณต้นทุนใน session ของ OpenClaw ตัวเลขประมาณในแชตไม่ใช่ใบแจ้งหนี้สุดท้าย หากปล่อยงานหลายรอบหรือเครื่องมือหลายขั้น ค่าใช้จ่ายจริงขึ้นกับโมเดลและช่องทางที่ตั้ง ไม่ควรเอาการกดหยุดมาเป็นคำรับรองว่าไม่เกิดค่าใช้จ่ายส่วนที่ทำไปแล้ว
ควรตัดสินใจใช้อย่างไร และหลักฐานยังขาดอะไร
ข้อวิเคราะห์ของเรา: ข่าวนี้มีประโยชน์กับคนที่มี OpenClaw อยู่แล้ว ใช้ Telegram ติดตามงาน หรือใช้ Control UI จัดคำขอหลายรอบใน session เดียว มากกว่าคนที่ต้องการเพียงคำตอบข้อความครั้งเดียว ประโยชน์ที่อนุมานได้คืออ่านความคืบหน้าและเลือกขอบเขตหยุดได้ตรงเจตนาขึ้น ไม่มีตัวเลขเวลาที่ประหยัด ความแม่นยำหรือคะแนนความปลอดภัยจากการทดลองของเรา
ก่อนเปลี่ยนชุดที่ใช้อยู่ ให้เทียบรุ่นกับ release notes และอ่านเอกสารการตั้งช่องทาง ตรวจว่าใช้ผิวไหน โหมด preview ใด และการหยุดเป้าหมายอะไร โดยเฉพาะ session ปกติเทียบกับ global คำแนะนำนี้เป็นการอ่านเงื่อนไข ไม่ใช่สูตรติดตั้งที่เรารันแล้ว งานข่าวนี้ไม่ติดตั้ง ไม่ใช้ bot token ไม่เปลี่ยน Gateway และไม่ออกคำสั่ง /stop ให้ระบบของผู้อ่าน
ภาษาไทย คุณภาพแผน การบังคับใช้สิทธิ์บัญชี และผลหยุดเครื่องมือจริงในสภาพแวดล้อมของผู้อ่านยังไม่ยืนยัน PR มีผลทดสอบของผู้พัฒนา แต่ไม่เท่ากับทุกแพลตฟอร์มผ่าน: ระหว่างตรวจ ลิงก์รายงาน CI เต็มจาก release เปิดไม่ได้ และ release ระบุว่าไม่มีผล Telegram beta E2E กับข้าม Android APK ในขอบเขตนั้น จึงไม่เรียกข่าวนี้ว่าได้ทดลอง Android หรือ Telegram จริงครบแล้ว
อ่านเรื่องการแยกงานร่างกับสิทธิ์ส่งใน Pally กับนัดใหม่จาก Calendly เพื่อเทียบหลักคิดเรื่องอำนาจตัดสินใจของคนได้ แต่กลไกของสองผลิตภัณฑ์ต่างกัน ไม่ควรนำสิทธิ์หรือผลตรวจของเรื่องหนึ่งมาใช้แทนอีกเรื่อง
คำถามที่พบบ่อย
เห็น preview อยู่ แปลว่างานทำเสร็จหรือส่งสำเร็จแล้วไหม?
ไม่ใช่ เป็นข้อความระหว่างทางที่กติกาเก็บไว้จนข้อความแทนได้รับการยอมรับหรือ owner cleanup การตอบรับ API ไม่ใช่คนอ่าน และเนื้อหาที่เห็นยังไม่รับรองผลเครื่องมือหรือความถูกต้อง
พิมพ์ /stop ใน Telegram ได้ผลใหม่แบบ Control UI ด้วยไหม?
หลักฐานข่าวนี้ยืนยันการเปลี่ยน typed stop ใน Control UI โดยเฉพาะ ไม่ได้ยืนยันว่าเส้นทางคำสั่งใน Telegram เปลี่ยนตาม อย่านำสองผิวมารวมกัน
กด Stop แล้วทำไมคิวยังอาจเดินต่อ?
เมื่อปุ่มรู้ run ID ขอบเขตเดิมคือหยุดรอบงานนั้นและรักษาคิว ส่วน typed stop ออนไลน์ใน session ปกติเลือกการหยุดระดับ session ที่ล้างคิวได้ มีข้อยกเว้น offline และ global
หยุดแล้วไฟล์หรือข้อความที่เปลี่ยนไปจะย้อนกลับไหม?
ไม่มีหลักฐานเช่นนั้น การยกเลิกงานต่อไม่ใช่ Undo สิ่งที่สำเร็จไปแล้ว และไม่รับรองว่าทุกเครื่องมือหรือบริการภายนอกหยุดทันที
Self-host หมายถึงข้อมูลอยู่ในเครื่องและ AI ฟรีทั้งหมดไหม?
ไม่ใช่ ต้องดูโมเดล แพลตฟอร์มแชตและ diagnostic ที่ตั้งไว้ ค่าประมวลผลและโฮสต์แยกจากใบอนุญาตซอฟต์แวร์ เราไม่ได้ทดลองค่าใช้จ่ายหรือคุณภาพไทยจริง
หลักฐานต้นทาง
- Release v2026.10.2 และ รุ่นเปรียบเทียบ v2026.10.1 — วันเผยแพร่และขอบเขตการเปลี่ยนแปลง
- PR 164649 กับ draft-stream รุ่นที่อ้างอิง — เก็บ preview จน replacement ยอมรับหรือ owner clear
- PR 167860, typed stop และ abort request — ขอบเขต session/run และข้อจำกัด global
- Telegram messaging, Setup และ Approvals — preview, ไม่มี read receipt และสิทธิ์ผู้อนุมัติ
- README และ Usage tracking — โมเดล ที่เก็บและค่าใช้จ่ายที่ต้องแยก
อ้างอิง v2026.10.2 commit b8952d477f0c932d8ddc6da5c89cab5a169b6ff1 · อ่านหลักฐานต้นฉบับ ไม่มีผลทดลองผลิตภัณฑ์จริงของเรา
ใส่ความเห็น