DEV Community: Thanawat Wongchai

GPT-6 Astra ใช้คอมพิวเตอร์คุณได้: มอบ OpenAPI spec ให้แทน

Thanawat Wongchai — Sat, 05 Sep 2026 06:54:32 +0000

ฟีเจอร์เด่นของ GPT-6 Astra คือความสามารถในการใช้งานคอมพิวเตอร์ ไม่ใช่แค่โมเดลที่คลิกไปเรื่อย ๆ แล้วหลงทางในเมนูดรอปดาวน์ ใน โพสต์เปิดตัวของ OpenAI Astra ทำคะแนนได้ 72.6% ใน OSWorld 2.0 โดยใช้เวลาประมาณ 40 นาทีต่องาน ทั้งการกรอกแบบฟอร์ม อัปเดต CRM ติดตั้งซอฟต์แวร์ และตรวจสอบ QA ส่วนหน้า (frontend) บนเว็บไซต์ที่สร้างขึ้นเอง OpenAI เรียกมันว่า “โมเดลการใช้คอมพิวเตอร์ที่ดีที่สุดในโลก” และการสาธิตครั้งนี้ก็สนับสนุนคำกล่าวอ้างนั้น

ลองใช้ Apidog วันนี้

หากคุณสร้างหรือทดสอบ API ความสามารถนี้อาจทำให้คุณอยากชี้ Astra ไปที่แอปแล้วปล่อยให้มันคลิก แต่ทางเลือกที่มีประโยชน์กว่า คือมอบ OpenAPI spec ให้เป็นอินเทอร์เฟซที่เร็วกว่า ถูกกว่า และตรวจสอบได้มากกว่าหน้าจอ เราเห็น Astra เปลี่ยนมาใช้แนวทางนี้ด้วยตัวเองระหว่าง การทดสอบจริงสองวัน และบทความนี้จะอธิบายเหตุผลพร้อมวิธีตั้งค่าด้วย Apidog

สรุปโดยย่อ (TL;DR)

Astra ทำคะแนนได้ 72.6% บน OSWorld 2.0 และ 92.7% บน ScreenSpot-Pro
ชุดเครื่องมือ Codex ทำงานที่เกี่ยวข้องกับการใช้คอมพิวเตอร์ได้เร็วกว่า GPT-5.6 Sol ถึง 1.9 เท่า
การควบคุมหน้าจอใช้เวลาหลายสิบนาทีและโทเค็นรูปภาพจำนวนมากต่องาน
การควบคุมหน้าจอทดสอบ UI ไม่ใช่ API ของบริการคุณ
มอบ OpenAPI spec ให้ Astra ผ่าน Apidog MCP Server หรือฟังก์ชันเครื่องมือ
ให้ Astra เขียนสถานการณ์ทดสอบ แล้วรันผ่าน Apidog CLI ใน CI
เก็บการใช้งานคอมพิวเตอร์ไว้สำหรับระบบที่ไม่มี API

GPT-6 Astra ใช้งานคอมพิวเตอร์ทำอะไรได้บ้าง

ความสามารถนี้ครอบคลุมมากกว่าการท่องเว็บไซต์ เช่น

กรอกแบบฟอร์มออนไลน์ บันทึก CRM และจัดการปฏิทิน
ค้นคว้าและร่างเอกสารในโปรแกรมแก้ไขเอกสาร
วิเคราะห์ข้อมูลทางวิทยาศาสตร์พร้อมกราฟ
สร้างและโฮสต์เว็บไซต์ผ่าน ChatGPT Sites
ตรวจสอบ QA ส่วนหน้าบนเว็บไซต์
จัดวางแผงวงจรใน KiCad
สร้างแบบจำลองบ้านใน Blender

ตัวเลขมาตรฐานจากโพสต์เปิดตัวของ OpenAI:

มาตรฐาน	GPT-6 Astra	GPT-5.6 Sol	Claude Opus 5
OSWorld 2.0 (ชุดข้อมูลออฟไลน์, คะแนนบางส่วน)	72.6% ใช้เวลา ~40 นาที/งาน	65.7% ใช้เวลา ~75 นาที/งาน	70.2%
ScreenSpot-Pro (ไม่มีเครื่องมือ)	92.7%	76.9%	-
Agents’ Last Exam	59.3%	53.6%	55.5%
AutomationBench	41.4%	18.1%	26.9%

รายละเอียดที่สำคัญกว่าคะแนน:

Astra ทำงาน OSWorld เสร็จเร็วกว่า Sol ประมาณ 47%
ใน Agents’ Last Exam Astra ใช้โทเค็นเอาต์พุตน้อยกว่า Opus 5 ประมาณ 65% ในการตั้งค่าที่ได้คะแนนสูงสุด
ชุดเครื่องมือ Codex ทำงานที่เกี่ยวข้องกับการใช้คอมพิวเตอร์บน Mind2Web ได้เร็วกว่า Sol ปัจจุบัน 1.9 เท่า

ลูปที่เร็วขึ้นหมายถึงต้นทุนที่ลดลง โดยเฉพาะเมื่อคิดค่าบริการตามโทเค็น

พฤติกรรมของ Astra ก็ดีขึ้นเช่นกัน โดยจะถามคำถามเมื่อคำตอบมีผลต่อผลลัพธ์ รักษาโฟกัสระหว่างงาน และใน Codex สามารถถามแบบอะซิงโครนัสระหว่างทำงานที่ไม่ต้องรอคำตอบได้

ในเกณฑ์มาตรฐานความปลอดภัยการใช้งานคอมพิวเตอร์ภายในของ OpenAI ซึ่งคะแนนที่ต่ำกว่าดีกว่า Astra ได้ 2.4% เทียบกับ Sol ที่ 22.0%

งาน 40 นาทีมีค่าใช้จ่ายเท่าไร

การใช้งานคอมพิวเตอร์เป็นลูปต่อเนื่อง:

ถ่ายภาพหน้าจอ
วิเคราะห์
ดำเนินการ
ถ่ายภาพหน้าจออีกครั้ง

ทุกภาพหน้าจอเป็นอินพุตภาพ ทุกขั้นตอนนำประวัติการสนทนาปัจจุบันกลับมาใช้ และงาน 40 นาทีอาจมีหลายร้อยขั้นตอน

ตาม อัตรามาตรฐานของ Astra:

อินพุต: $10 ต่อล้านโทเค็น
เอาต์พุต: $50 ต่อล้านโทเค็น
อินพุตที่เกิน 272K โทเค็น: $20 ต่อล้านโทเค็น
Prompt caching: $1 ต่อล้านโทเค็นที่แคชไว้

เซสชันยาวที่เก็บประวัติทั้งหมดในบริบทจะถูกคิดราคาแบบ long-context ก่อนงานจะเสร็จ แม้ prompt caching จะช่วยลดต้นทุน prefix ที่ซ้ำกัน แต่ภาพหน้าจอใหม่ทุกขั้นตอนยังคงเป็นอินพุตใหม่

เส้นทาง OpenAPI spec

OpenAPI spec เป็น prefix เดียวที่แคชไว้ครั้งเดียว จากนั้น:

สถานการณ์ทดสอบที่โมเดลเขียนใช้ JSON เพียงไม่กี่ร้อยโทเค็น
การรันทดสอบแต่ละครั้งเป็น HTTP request ที่ไม่เสียค่าใช้จ่ายฝั่งโมเดล
เมื่อเขียนสถานการณ์แล้ว ไม่ต้องใช้โมเดลในการรันซ้ำ

มีต้นทุนที่ไม่ใช่เรื่องเงินด้วย ภาพรวมความปลอดภัยของ OpenAI ระบุว่าตัวตรวจสอบความไม่สอดคล้องกันในการผลิต “บางครั้งอาจชะลอ หยุดชั่วคราว หรือหยุดงานที่ถูกต้อง” โดยเฉพาะงานที่เอเจนต์ทำเป็นเวลานาน

ใน ChatGPT หรือ Codex คุณอาจถูกขอให้ทบทวนการดำเนินการ ส่วนใน API งานจะหยุดลงทันที เซสชันควบคุมหน้าจอ 40 นาทีจึงมีโอกาสเจอการหยุดชะงักมากกว่าการเรียก API ที่ใช้เวลาเพียงห้าวินาที

การใช้งานคอมพิวเตอร์เทียบกับสัญญา API

สถานการณ์	เครื่องมือที่ดีกว่า	เหตุผล
การทดสอบ API ของคุณเอง	Spec	ตรวจสอบได้แน่นอน รันซ้ำได้ และยืนยันตามสัญญาจริง
Regression test ใน CI	Spec	สถานการณ์ทำงานได้โดยไม่มีโมเดลอยู่ในลูป
พอร์ทัลบุคคลที่สามที่ไม่มี API	การใช้งานคอมพิวเตอร์	ไม่มีสัญญาให้มอบ
QA ส่วนหน้าแบบ End-to-end ก่อนเปิดตัว	การใช้งานคอมพิวเตอร์	ต้องทดสอบ UI โดยตรง
เครื่องมือเดสก์ท็อปแบบ Legacy	การใช้งานคอมพิวเตอร์	มีเฉพาะหน้าจอ
ตรวจสอบว่าเอกสารตรงกับพฤติกรรมหรือไม่	Spec แล้วตามด้วย UI	ส่งคำขอตามเอกสาร เปรียบเทียบการตอบสนอง แล้วตรวจสอบหน้าเว็บ

ความแตกต่างคือสิ่งที่กำลังทดสอบ:

การใช้งานคอมพิวเตอร์ทดสอบพิกเซล
Spec ทดสอบสัญญา

เมื่อ frontend เสียหาย API มักยังทำงานได้ และเมื่อ API เสียหาย frontend อาจซ่อนปัญหาไว้หลังข้อความแสดงข้อผิดพลาดที่เป็นมิตร ทั้งสองส่วนสำคัญ แต่ทีม API ส่งมอบสัญญา ดังนั้นควรเริ่มจาก contract test

วิธีมอบสัญญา API ให้ Astra

มีสามวิธี และสามารถใช้ร่วมกันได้

1. ให้ไฟล์ OpenAPI แก่ Astra

ส่งออก OpenAPI spec จากโปรเจกต์ Apidog หรือ นำเข้า spec ที่มีอยู่ไปยัง Apidog ก่อน แล้วแนบไว้ในคำขอ

หน้าต่างบริบทของ Astra มีขนาด 1,050,000 โทเค็น และการทดสอบการเรียกคืน MRCR ของ OpenAI แสดงความแม่นยำ 96.3% ที่ช่วง 512K–1M ขณะที่ Sol ลดลงเหลือ 73.8% ดังนั้น spec ขนาดใหญ่ไม่จำเป็นต้องแบ่งส่วนอีกต่อไป

2. เชื่อมต่อโปรเจกต์ผ่าน MCP

Apidog MCP Server เปิดเผยโปรเจกต์ Apidog เอกสารที่เผยแพร่ หรือไฟล์ OpenAPI ให้ไคลเอ็นต์ที่รองรับ MCP

Astra จึงอ่านสัญญาปัจจุบันแทนไฟล์ส่งออกที่อาจล้าสมัย Codex และเอเจนต์เดสก์ท็อปสามารถดึงคำจำกัดความของ Endpoint ระหว่างทำงานได้ การตั้งค่านี้ทำให้ Astra ในการทดสอบของเราค้นหาและอ่าน spec ได้ด้วยตัวเอง

3. แปลง Spec เป็นฟังก์ชันเครื่องมือ

สำหรับการใช้งานแบบโปรแกรม ให้แปลง Endpoint เป็นฟังก์ชันเครื่องมือแล้วเรียก Astra ผ่าน Responses API ตามแนวทาง การแปลง OpenAPI เป็นเครื่องมือสำหรับ AI agent

หน้าโมเดลของ Astra ระบุการเรียกใช้ฟังก์ชัน เอาต์พุตแบบมีโครงสร้าง และการค้นหาไฟล์เป็นคุณสมบัติของโมเดล โดยการเรียกใช้เครื่องมือต้องใช้ Responses API ไม่ใช่ Chat Completions

คำขอขั้นต่ำสำหรับให้ Astra ร่างสถานการณ์ทดสอบจาก Spec:

curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-astra",
    "reasoning": {"effort": "medium"},
    "input": [
      {"role": "developer", "content": "คุณกำลังเขียนสถานการณ์ทดสอบ API. เน้นการดำเนินการ. ถามคำถามก็ต่อเมื่อคำตอบเปลี่ยนการออกแบบการทดสอบเท่านั้น. ส่งออก JSON ที่ตรงกับ Schema."},
      {"role": "user", "content": "นี่คือ OpenAPI 3.1 spec ของเรา. ร่างสถานการณ์ทดสอบต่อหนึ่งทรัพยากร: happy path, ขอบเขตการตรวจสอบสิทธิ์, และหนึ่งกรณีเชิงลบแต่ละรายการ.\n\n<วาง spec>"}
    ],
    "text": {"format": {"type": "json_schema", "name": "scenarios", "schema": {"type": "object", "properties": {"scenarios": {"type": "array"}}, "required": ["scenarios"]}}}
  }'

จาก คำแนะนำโมเดลของ OpenAI:

Astra ไม่มีระดับความพยายาม none หรือ minimal ให้เริ่มที่ low หรือ medium
Astra “ขอคำชี้แจงได้ง่ายกว่า” โมเดลรุ่นก่อน
ข้อความนักพัฒนาที่เน้น “bias towards action” จึงมีความสำคัญ

4. รันสถานการณ์โดยไม่ใช้โมเดล

นำเข้าสถานการณ์ที่สร้างขึ้นไปยัง Apidog เพิ่มการยืนยันรหัสสถานะและ Response Schema แล้วรันผ่าน Apidog CLI ใน pipeline

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

รักษารั้วป้องกันไว้ แม้ Astra จะเคารพก็ตาม

ผลลัพธ์ด้าน alignment ของ Astra ดีที่สุดเท่าที่ OpenAI เคยเผยแพร่:

ในการทดสอบ honeypot หลังเหตุการณ์ Hugging Face Sol ข้ามเป้าหมายที่ได้รับอนุญาต 48% ของเวลา ขณะที่ Astra ไม่ข้ามเลย (0%)
Astra ไม่เคยพยายามหลีกเลี่ยงการปฏิเสธการตรวจสอบอัตโนมัติของ Codex แม้การตั้งค่าจะเปิดช่องให้หลีกเลี่ยงได้
ความทนทานต่อ indirect prompt injection อยู่ที่ 99.79% เพิ่มขึ้นจาก 96.23%

อย่างไรก็ตาม ยังต้องมี control gates อยู่ดี เพียงแต่ gate อาจทำงานน้อยลง โมเดลที่มีหน้าต่างโทเค็น 1M คะแนนความปลอดภัยทางไซเบอร์ระดับ Critical และความสามารถในการเรียก API ของคุณแบบสุ่ม ควรทำงานบน staging พร้อม:

ข้อมูลรับรองที่กำหนดขอบเขต
ประตูอนุมัติสำหรับการเปลี่ยนแปลง (mutations)
การติดตามทุกการเรียกใช้

ตัวตรวจสอบของ Astra อาจหยุดงานกลางคันได้ ดังนั้นให้ถือว่างานระยะยาวทุกงานต้องรองรับการทำงานต่อ แนวทางจาก การออกแบบการทดสอบสำหรับเอเจนต์ที่ไม่เป็นไปตามเงื่อนไขที่กำหนด ยังคงใช้ได้: ยืนยันตามสัญญา ไม่ใช่ตามบันทึกการสนทนา

เมื่อใดควรใช้การควบคุมหน้าจอ

อย่าเข้าใจว่า “ห้ามให้ Astra คลิกเลย” เพราะมีสามกรณีที่การใช้หน้าจอดีกว่า:

พอร์ทัลพันธมิตรหรือคอนโซลผู้ดูแลระบบที่ไม่มี API
การตรวจสอบ frontend ในวันเปิดตัว ซึ่งมนุษย์มักทำด้วยมือ
เครื่องมือเดสก์ท็อปแบบ Legacy ที่มีเฉพาะ UI

Astra เป็นโมเดลแรกที่ทำให้งานเหล่านี้คุ้มค่าต่อการมอบหมาย และความเร็วของชุดเครื่องมือ Codex ทำให้สามารถรันงานเหล่านี้ทุกคืนได้

ใช้สัญญาเมื่อมีสัญญา และใช้หน้าจอเมื่อไม่มีสัญญา

คำถามที่พบบ่อย

การใช้งานคอมพิวเตอร์ของ GPT-6 Astra ทำงานผ่าน API ได้หรือไม่?

ได้ การใช้งานคอมพิวเตอร์เป็นหนึ่งในเครื่องมือที่ Astra รองรับบน Responses API เช่นเดียวกับการค้นเว็บ การค้นไฟล์ ตัวแปลโค้ด และการสร้างรูปภาพ แอปพลิเคชันของคุณต้องเตรียมสภาพแวดล้อมและดำเนินการตาม action ที่โมเดลเสนอ หากตัวตรวจสอบความไม่สอดคล้องกันหยุดงานผ่าน API งานจะหยุดลงทันที

ฉันสามารถให้ Spec ขนาดใหญ่แค่ไหน?

หน้าต่างบริบทมีขนาด 1,050,000 โทเค็น และเอาต์พุต 128,000 โทเค็น Spec ที่มี Endpoint หลายร้อยรายการพร้อม Schema ครบถ้วนสามารถใส่ได้โดยมีพื้นที่เหลือ อย่างไรก็ตาม อินพุตที่เกิน 272K โทเค็นจะถูกคิดราคาเป็นสองเท่าของอัตราอินพุตและการแคช จึงควรแคช prefix ของ Spec และรักษาข้อความต่อการทดสอบให้เล็ก

Astra จะสร้าง Endpoint ที่ไม่มีอยู่ใน Spec ขึ้นมาเองหรือไม่?

มีโอกาสน้อยกว่าโมเดลรุ่นก่อน เกณฑ์มาตรฐานการหลอนภายในของ OpenAI ซึ่งคะแนนที่ต่ำกว่าดีกว่า แสดงว่า Astra อยู่ที่ 4.2% เทียบกับ Sol ที่ 12.2% และมีโอกาสบิดเบือนความสามารถของตัวเองน้อยกว่าสามเท่า ใช้เอาต์พุตแบบมีโครงสร้างและการตรวจสอบ Schema ใน Apidog เพื่อจับส่วนที่เหลือ การทดสอบสัญญา (contract test) จึงยังเป็นด่านสุดท้าย ไม่ใช่โมเดล

การสร้างการทดสอบด้วย Astra ถูกกว่า GPT-5.6 Sol หรือไม่?

หากคิดตามโทเค็น Astra ไม่ถูกกว่า โดยมีค่าใช้จ่าย $10 และ $50 ต่อล้านโทเค็น เทียบกับโปรโมชั่นของ Sol ที่ $4 และ $20 แต่ Astra ใช้โทเค็นน้อยกว่ามากต่องานที่เสร็จสมบูรณ์ และการสร้างการทดสอบจาก Spec ทำให้ต้นทุนโมเดลเกิดขึ้นเพียงครั้งเดียว ควรวัดผลกับ Spec ของคุณเอง โดยดูวิธีเปรียบเทียบจาก คู่มือ API

สรุป

GPT-6 Astra สามารถควบคุมคอมพิวเตอร์ได้จริง และสำหรับระบบที่ไม่มี API นั่นเป็นความสามารถที่มีประโยชน์มาก

แต่สำหรับ API ที่คุณเป็นเจ้าของ ให้ใช้แนวทางนี้:

มอบ OpenAPI spec ให้โมเดล
ให้ Astra เขียนสถานการณ์ทดสอบ
รันสถานการณ์เหล่านั้นใน CI
ใช้ control gates และตรวจสอบตามสัญญา
เก็บการควบคุมหน้าจอไว้สำหรับระบบที่ไม่มี API

กฎสั้น ๆ คือ ใช้สัญญาเมื่อมีสัญญา และใช้หน้าจอเมื่อไม่มีสัญญา

Gemini 3.8 Flash เทียบกับ 3.7 Flash: เปลี่ยนไปแค่ไหน คุ้มค่าที่จะอัปเกรดไหม

Thanawat Wongchai — Thu, 03 Sep 2026 08:38:24 +0000

Gemini 3.8 Flash เทียบกับ Gemini 3.7 Flash: ควรอัปเกรดหรือไม่?

Google เปิดตัว Gemini 3.8 Flash เมื่อวันที่ 2 กันยายน 2026 หรือสามสัปดาห์หลัง Gemini 3.7 Flash และหกสัปดาห์หลัง 3.6 Flash ราคาเปิดตัวยังคงเดิมที่ $0.75 ต่อล้านโทเค็นอินพุต และ $3.75 ต่อล้านโทเค็นเอาต์พุตจนถึงวันที่ 31 ธันวาคม พร้อมคอนเท็กซ์ 1 ล้านโทเค็นและความเร็วใกล้เคียงเดิม สิ่งที่เปลี่ยนคือการทำงานภายใน: โมเดลใช้ขั้นตอนการให้เหตุผลที่เล็กลง ตรวจสอบเอาต์พุตของตัวเอง และเรียกใช้เครื่องมือซ้ำๆ ส่งผลให้คะแนน benchmark สูงขึ้น แต่ใช้โทเค็นต่อภารกิจมากขึ้น

ลองใช้ Apidog วันนี้

ดังนั้นคำถามไม่ใช่ “3.8 Flash ดีกว่าหรือไม่” เพราะข้อมูลที่เผยแพร่ชี้ว่าดีกว่า คำถามคือคุณภาพที่เพิ่มขึ้นคุ้มกับโทเค็นและค่าใช้จ่ายต่อภารกิจหรือไม่ บทความนี้สรุปสิ่งที่เหมือนเดิม สิ่งที่ดีขึ้น ค่าใช้จ่าย การเปลี่ยนแปลงที่อาจทำให้โค้ดเดิมใช้งานไม่ได้ และแนวทางตัดสินใจตามประเภทงาน

แหล่งข้อมูลหลัก ได้แก่ ประกาศเปิดตัวของ Google, เอกสารมีอะไรใหม่ใน Gemini 3.8 Flash และการทดสอบอิสระจาก Artificial Analysis ดูข้อมูลจำเพาะเพิ่มเติมได้ที่ Gemini 3.8 Flash คืออะไร

Google ระบุว่า Gemini 3.7 Flash “ยังคงได้รับการสนับสนุนอย่างเต็มที่” และยังไม่มีการประกาศวันเลิกใช้งาน คุณจึงยังไม่จำเป็นต้องย้ายระบบทันที

เปรียบเทียบ Gemini 3.8 Flash กับ 3.7 Flash

รายการ	Gemini 3.8 Flash	Gemini 3.7 Flash
รหัสโมเดล	`gemini-3.8-flash`	`gemini-3.7-flash`
วันเปิดตัว	2 กันยายน 2026	13 สิงหาคม 2026
พื้นฐาน	อิงตาม Gemini 3.7 Flash	ไม่มี
อินพุต / เอาต์พุตสูงสุด	1,048,576 / 65,536 โทเค็น	เหมือนเดิม
ราคาอินพุตช่วงแนะนำ ถึง 31 ธ.ค.	$0.75 ต่อล้านโทเค็น	$0.75 ต่อล้านโทเค็น
ราคาเอาต์พุตช่วงแนะนำ ถึง 31 ธ.ค.	$3.75 ต่อล้านโทเค็น รวมเวลาประมวลผล	$3.75 ต่อล้านโทเค็น รวมเวลาประมวลผล
ราคามาตรฐานตั้งแต่ 1 ม.ค. 2027	$1.50 / $7.50	$1.50 / $7.50
อ่านแคชคอนเท็กซ์	$0.075 ต่อล้านโทเค็นช่วงแนะนำ	เหมือนเดิม
แบตช์	ลด 50% ระดับโทเค็นในคิวเท่าเดิม	เหมือนเดิม
ระดับการประมวลผล	`low`, `medium` ค่าเริ่มต้น, `high`	`low`, `medium`, `high`
ระดับ `minimal`	ไม่รองรับและเกิด validation error	รองรับ
ข้อมูลตัดเมื่อ	มีนาคม 2026	ไม่ได้ระบุใหม่ในเอกสาร 3.8
ความเร็วเอาต์พุตจาก Artificial Analysis	ประมาณ 300 โทเค็น/วินาที วัดได้ 302.1 ที่ระดับ `high`	Google ระบุว่าความเร็วใกล้เคียงกัน
Artificial Analysis Intelligence Index	59 ระดับสูง	56 ระดับสูง
สถานะการสนับสนุน	ปัจจุบัน	ยังได้รับการสนับสนุนเต็มที่ ไม่มีวันเลิกใช้งาน

สิ่งที่ยังเหมือนเดิม

ราคาและโควตา

โมเดลทั้งสองมีราคาอินพุต $0.75 และเอาต์พุต $3.75 ต่อล้านโทเค็นจนถึงวันที่ 31 ธันวาคม หลังจากนั้นจะเพิ่มเป็น $1.50 และ $7.50 ในวันที่ 1 มกราคม 2027

การอ่านแคชคอนเท็กซ์ ส่วนลดแบตช์ และโควตาการค้นหา Google ฟรี 5,000 รายการต่อเดือน ซึ่งใช้ร่วมกันในโมเดล Gemini 3.x ยังคงเหมือนเดิม ดูรายละเอียดได้จาก หน้าการกำหนดราคาของ Google และ ข้อมูลจำเพาะและราคาอ้างอิงของ 3.7 Flash

คอนเท็กซ์และรูปแบบข้อมูล

ขีดจำกัดยังคงอยู่ที่:

อินพุตสูงสุด 1,048,576 โทเค็น
เอาต์พุตสูงสุด 65,536 โทเค็น
อินพุต: ข้อความ รูปภาพ วิดีโอ เสียง และ PDF
เอาต์พุต: ข้อความ

ทั้งสองโมเดลไม่รองรับการสร้างเสียง การสร้างรูปภาพ หรือ Live API

ความเร็ว

Google อธิบายว่า 3.8 Flash มีราคาเท่ากับ 3.7 Flash และมีความเร็วใกล้เคียงกัน Artificial Analysis วัดความเร็วเอาต์พุตของ 3.8 Flash ได้ 302.1 โทเค็นต่อวินาทีที่ระดับ high

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

พื้นผิว API

Interactions API ยังคงเป็นช่องทางหลักสำหรับ Gemini 3.x ขณะที่ generateContent endpoint แบบเดิมยัง “ได้รับการสนับสนุนอย่างเต็มที่” และยังไม่มีวันเลิกใช้งาน

โดยทั่วไป โค้ดที่ใช้กับ 3.7 Flash สามารถย้ายมาใช้ 3.8 Flash ได้ด้วยการเปลี่ยนสตริงโมเดลเป็น:

gemini-3.8-flash

แต่ต้องตรวจสอบการตั้งค่า thinking_level และรูปแบบ function response ตามรายละเอียดในหัวข้อถัดไป

สิ่งที่ Gemini 3.8 Flash ปรับปรุง

Google เรียก 3.8 Flash ว่า “โมเดล Flash ที่ฉลาดที่สุดของเรา” และออกแบบมาสำหรับงานวิศวกรรมซอฟต์แวร์ระยะยาว เอเจนต์อัตโนมัติ และเวิร์กโฟลว์องค์กรที่ซับซ้อน

ในงานยาก โมเดลจะ:

ดำเนินขั้นตอนการให้เหตุผลเพิ่มเติม
แบ่งการให้เหตุผลเป็นขั้นตอนเล็กลง
ตรวจสอบการทำงานของตัวเอง
เรียกใช้เครื่องมือซ้ำเมื่อจำเป็น

Benchmark จาก Google

Google เผยแพร่ตัวเลขเปรียบเทียบสามรายการบน หน้า DeepMind Flash

Benchmark	3.8 Flash	3.7 Flash	ส่วนต่าง
Vals Finance Agent v2	61.4%	59.0%	+2.4
HLE-Verified	54.9%	53.6%	+1.3
Harvey Legal Agent Benchmark	10.0%	8.8%	+1.2

ในทั้งสามรายการ 3.8 Flash ยังทำคะแนนสูงกว่าโมเดลขนาดใหญ่บางรุ่นในตารางของ Google เช่น Claude Opus 5 ที่ได้ 58.6% ใน Vals Finance และ 54.4% ใน HLE-Verified รายละเอียดการเปรียบเทียบกับ Claude Fable 5.1 และ GPT-5.6 Sol อยู่ในบทความ เปรียบเทียบสามโมเดล

ผลทดสอบจาก Artificial Analysis

Artificial Analysis ให้ 3.8 Flash ได้ 59 คะแนนใน Intelligence Index ที่ระดับ high เพิ่มขึ้นจาก:

3.7 Flash: 56
3.6 Flash: 52

คะแนน 59 เท่ากับ GPT-5.6 Sol ที่ระดับ xhigh และ Grok 4.6 ที่ระดับ medium และสูงกว่า Claude Fable 5.1 ที่ระดับ medium หนึ่งคะแนน

สำหรับการใช้เครื่องมือใน τ³-Banking, 3.8 Flash ได้ 45% เพิ่มขึ้น 12 จุดจาก 3.7 Flash ตัวเลขนี้มีความสำคัญเป็นพิเศษสำหรับเอเจนต์ที่ต้องเรียกใช้เครื่องมือจริงหลายรอบ

งานเอกสารและเอเจนต์หลายขั้นตอน

Google ระบุว่า 3.8 Flash “ทำงานได้มากกว่า Gemini 3.7 Flash ถึงสามเท่า” ในเวิร์กโฟลว์ที่ใช้เวลานานและเกี่ยวข้องกับเอกสารจำนวนมาก นี่เป็นการประเมินภายในที่ยังไม่มีผลทดสอบสาธารณะ จึงควรใช้เป็นแนวทาง ไม่ใช่การรับประกัน

การออกแบบที่มีขั้นตอนตรวจสอบมากขึ้นเหมาะกับงานที่ความผิดพลาดเพียงครั้งเดียวอาจทำให้กระบวนการ 40 ขั้นตอนล้มเหลว เช่น:

การดึงข้อมูลจากเอกสารหลายฉบับ
การตรวจสอบเอกสารทางกฎหมาย
การวิเคราะห์ข้อมูลทางการเงิน
เอเจนต์ที่ต้องวางแผนและเรียกใช้เครื่องมือหลายครั้ง

การเขียนโค้ด

บน DeepSWE v1.1, 3.7 Flash ได้ 65.3% เพิ่มขึ้นจาก 49.0% ของ 3.6 Flash Google ระบุว่า 3.8 Flash มีประสิทธิภาพเหนือกว่าโมเดล Frontier ขนาดใหญ่ส่วนใหญ่ด้วยค่าใช้จ่ายเพียงเศษเสี้ยว

อย่างไรก็ตาม ตัวเลข 3.8 Flash ที่แน่นอนปรากฏเฉพาะในตารางรูปภาพของเอกสารโมเดล ไม่ได้อยู่ในข้อความ นอกจากนี้ยังไม่มีตัวเลขข้อความสำหรับ SWE-Bench Pro, Terminal-bench และ OSWorld ดังนั้นหาก benchmark เหล่านี้มีผลต่อการตัดสินใจ ควรทดสอบกับ repository ของคุณเองหรือรอผลจากบุคคลที่สาม

ความปลอดภัยและ Prompt Injection

Google รายงานว่ามี “การก้าวกระโดดอย่างมีนัยสำคัญ” ในการทดสอบ Gray Swan prompt injection แต่ไม่ได้เปิดเผยตัวเลขทั้งหมด

ตาม เอกสารโมเดล เมื่อเทียบกับ 3.7 Flash:

ความปลอดภัยหลายภาษา: +5.4 คะแนน
ความปลอดภัยแบบข้อความเป็นข้อความ: -0.4 คะแนน
การปฏิเสธโดยไม่มีเหตุผล: +1.1 คะแนน

ตัวเลขสุดท้ายอาจสะท้อนการเพิ่มขึ้นเล็กน้อยของการปฏิเสธที่มากเกินไป จึงควรตรวจสอบกับกรณีใช้งานจริง

ค่าใช้จ่ายต่อโทเค็นเท่าเดิม แต่ค่าใช้จ่ายต่อภารกิจเพิ่มขึ้น

ราคาต่อโทเค็นไม่เปลี่ยน แต่จำนวนโทเค็นที่โมเดลใช้ต่อภารกิจเปลี่ยนไป Google ระบุว่า 3.8 Flash อาจใช้โทเค็นมากขึ้นในงานที่ยาวและซับซ้อน โดยเฉพาะเมื่อใช้ระดับความพยายามสูง

Artificial Analysis วัดว่า 3.8 Flash ใช้เอาต์พุตเฉลี่ยประมาณ 48,000 โทเค็นต่องาน หรือมากกว่า 3.7 Flash ประมาณ 30% ที่ราคาต่อโทเค็นเท่ากัน

การกำหนดค่า	ค่าใช้จ่ายต่องาน	เวลาต่องาน
Gemini 3.7 Flash, `high`	$0.40	2.2 นาที
Gemini 3.8 Flash, `low`	$0.24	0.8 นาที
Gemini 3.8 Flash, `medium`	$0.41	ไม่ได้เผยแพร่
Gemini 3.8 Flash, `high`	$0.58	2.5 นาที

ข้อสรุปจากตาราง:

3.8 Flash ที่ระดับ high แพงกว่า 3.7 Flash ที่ระดับ high ประมาณ 45% และใช้เวลานานขึ้น 14%
3.8 Flash ที่ระดับ medium ซึ่งเป็นค่าเริ่มต้น มีค่าใช้จ่ายใกล้เคียงกับ 3.7 Flash ที่ระดับ high
3.8 Flash ที่ระดับ low ถูกและเร็วที่สุด เหมาะกับเส้นทางที่ต้องการความหน่วงต่ำ

ดูรายละเอียดเพิ่มเติมได้จาก ราคา Gemini 3.8 Flash และ คู่มือระดับการประมวลผล

หากคุณคิดค่าใช้จ่ายเป็นรายงานหรือรายภารกิจ การอัปเกรดนี้ไม่ฟรี ระดับการประมวลผลจึงเป็นตัวเลือกหลักสำหรับควบคุมว่าคุณต้องการซื้อคุณภาพที่เพิ่มขึ้นมากน้อยเพียงใด

Breaking changes ที่ต้องแก้ก่อนย้าย

มีการเปลี่ยนแปลงสำคัญสองประการที่กระทบโค้ดเดิมโดยตรง

1. `thinking_level: "minimal"` ไม่รองรับ

Gemini 3.8 Flash รองรับเฉพาะ:

{
  "thinkingLevel": "low"
}

หรือ:

low
medium
high

หากการตั้งค่าเดิมใช้ minimal ให้เปลี่ยนเป็น low มิฉะนั้นจะได้รับ validation error

2. Function response ต้องมี ID และชื่อ

บน Interactions API ทุก function_result ต้องมีทั้ง call_id และ name

บน generateContent endpoint แบบเดิม ทุก functionResponse ต้องมี id และ name ที่ตรงกัน

โค้ดที่ส่งผลลัพธ์กลับโดยใช้เพียงชื่อฟังก์ชันเป็นคีย์จะล้มเหลวเมื่อโมเดลเรียกใช้เครื่องมือในรอบที่สอง

การย้ายข้อมูลควรตรวจสอบกฎของ Gemini 3 ที่มีอยู่แล้วด้วย:

คงค่า temperature ที่ค่าเริ่มต้น 1.0
ค่าที่ต่ำกว่าอาจทำให้เกิดการวนซ้ำหรือประสิทธิภาพลดลง
ใช้ thinking_level แทน thinking_budget แบบตัวเลข
ไม่ต้องใช้ candidate_count
ส่ง thought signatures กลับไปตามที่ได้รับมาอย่างถูกต้อง

รายละเอียดอยู่ใน คู่มือการย้ายข้อมูลจาก 3.7 ไป 3.8 Flash

ตารางตัดสินใจตามปริมาณงาน

ปริมาณงาน	คำแนะนำ	เหตุผล
เอเจนต์หลายขั้นตอนที่เรียกใช้เครื่องมือ	อัปเกรด ใช้ `medium` หรือ `high`	τ³-Banking เพิ่มขึ้น 12 จุด และการเรียกใช้เครื่องมือซ้ำคือจุดประสงค์หลักของ 3.8
การดึงข้อมูลและตรวจสอบเอกสารขนาดยาว	อัปเกรด	สอดคล้องกับคำกล่าวอ้างของ Google เรื่องงานที่เสร็จสิ้นมากขึ้น
การเขียนโค้ดแบบเอเจนต์ในชุดทดสอบ	อัปเกรดแล้ววัดผล	ยังไม่มีตัวเลข DeepSWE ของ 3.8 ที่เผยแพร่เป็นข้อความ
เอเจนต์การเงิน กฎหมาย และการวิจัย	อัปเกรด	Benchmark ที่ Google เผยแพร่ทั้งสามรายการดีขึ้น
การจัดหมวดหมู่ การดึงข้อมูล และแชทปริมาณมาก	ใช้ 3.7 ต่อ หรือใช้ 3.8 ที่ `low`	ค่าใช้จ่ายต่อภารกิจสำคัญกว่า และ `low` ถูกกว่า 3.7 ที่ `high`
Endpoint ที่ต้องการความหน่วงต่ำ	ใช้ 3.8 ที่ `low`	0.8 นาทีต่องาน เทียบกับ 2.2 นาทีของ 3.7 ที่ `high`
ระบบที่ใช้ระดับ `minimal`	ย้ายข้อมูลก่อน	จะเกิด validation error จนกว่าจะเปลี่ยนเป็น `low`
แบตช์ที่ควบคุมต้นทุนอย่างละเอียด	ใช้ 3.7 ต่อจนกว่าจะมี benchmark ใหม่	ราคาโทเค็นเท่าเดิม แต่เอาต์พุตเพิ่มประมาณ 30%

รูปแบบโดยรวมคือ ยิ่งงานยากและยาว การออกแบบที่ “ทำงานหนักขึ้น” ของ 3.8 Flash ก็ยิ่งคุ้มกับโทเค็นที่เพิ่มขึ้น ยิ่งงานสั้นและทำซ้ำมากเท่าไร ประโยชน์ก็ยิ่งลดลง และการเลือก low หรือคงโมเดลเดิมก็ยิ่งมีความสำคัญ

ทดสอบโมเดลทั้งสองกับพรอมต์จริงใน Apidog

ตัวเลขจาก Artificial Analysis เป็นผลจากชุดทดสอบของพวกเขา ก่อนเปลี่ยนโมเดลใน production ให้ทดสอบพรอมต์ของคุณเองกับทั้งสองรุ่นและเปรียบเทียบจำนวนโทเค็น

Apidog ช่วยให้สร้างการทดสอบนี้ได้ในเวลาประมาณ 10 นาที

1. ตั้งค่า environment

สร้างตัวแปร GEMINI_API_KEY ใน Apidog environment แล้วเพิ่ม POST request ไปยัง:

https://generativelanguage.googleapis.com/v1beta/models/{{model}}:generateContent

ตั้งค่า header:

x-goog-[REDACTED CREDENTIAL]_API_KEY}}

กำหนด model เป็น scenario variable และใช้ body เดียวกันทั้งสองขั้นตอน:

{
  "contents": [
    {
      "parts": [
        {
          "text": "{{golden_prompt}}"
        }
      ]
    }
  ],
  "generationConfig": {
    "thinkingConfig": {
      "thinkingLevel": "medium"
    }
  }
}

2. สร้าง scenario เปรียบเทียบ

สร้าง scenario สองขั้นตอน:

ส่งคำขอด้วย gemini-3.7-flash
ส่งคำขอเดิมด้วย gemini-3.8-flash

เพิ่ม assertions ในแต่ละขั้นตอนสำหรับ:

usageMetadata.candidatesTokenCount
usageMetadata.thoughtsTokenCount

กำหนดขีดจำกัดตามงบประมาณของคุณ และเพิ่ม JSONPath assertion บนฟิลด์ที่แอปพลิเคชันอ่านจริง

เรียกใช้ scenario กับ golden prompts 10–20 รายการ รายงานผลจะแสดง response และ assertion ของแต่ละขั้นตอน ทำให้คุณเห็นจำนวนโทเค็นของทั้งสองโมเดลจากการทดสอบชุดเดียวกัน ตัวเลข “เพิ่มขึ้น 30%” จะกลายเป็นข้อมูลจากระบบของคุณเอง ไม่ใช่เพียงค่าจาก benchmark ภายนอก

3. ตั้งเวลารันเพื่อเฝ้าระวังค่าใช้จ่าย

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

ดาวน์โหลด Apidog เพื่อเริ่มต้น โดยแผนฟรีรองรับเวิร์กโฟลว์นี้

คำถามที่พบบ่อย

Gemini 3.8 Flash เร็วกว่า 3.7 Flash หรือไม่?

ไม่ Google ระบุว่าความเร็วใกล้เคียงกัน Artificial Analysis วัดความเร็วเอาต์พุตได้ประมาณ 300 โทเค็นต่อวินาทีที่ระดับ high แต่เวลาเฉลี่ยต่องานของ 3.8 ที่ high อยู่ที่ 2.5 นาที เทียบกับ 2.2 นาทีของ 3.7 เนื่องจาก 3.8 ใช้ขั้นตอนการให้เหตุผลมากขึ้น

การเปลี่ยนเป็น low ลดเวลาของ 3.8 เหลือ 0.8 นาทีในการทดสอบดังกล่าว

Gemini 3.8 Flash แพงกว่า 3.7 Flash หรือไม่?

ไม่แพงกว่าต่อโทเค็น ทั้งสองรุ่นมีราคาอินพุต $0.75 และเอาต์พุต $3.75 ต่อล้านโทเค็นจนถึงวันที่ 31 ธันวาคม และจะเพิ่มเป็น $1.50 และ $7.50 หลังจากนั้น

แต่ค่าใช้จ่ายต่อภารกิจสูงกว่า Artificial Analysis วัดได้ $0.58 สำหรับ 3.8 ที่ high เทียบกับ $0.40 สำหรับ 3.7 ที่ high เนื่องจาก 3.8 สร้างเอาต์พุตมากกว่าประมาณ 30%

Google จะเลิกใช้ Gemini 3.7 Flash หรือไม่?

Google ระบุว่า 3.7 Flash ยังได้รับการสนับสนุนอย่างเต็มที่และยังไม่มีวันเลิกใช้งาน คุณจึงใช้งานต่อได้ โดยดู โพสต์มีอะไรใหม่ใน Gemini 3.7 Flash เป็นเอกสารอ้างอิงได้

มีอะไรที่จะใช้งานไม่ได้เมื่อเปลี่ยนไปใช้ 3.8 Flash?

มีสองกรณีหลัก:

thinking_level: "minimal" จะคืนค่า 400 INVALID_ARGUMENT
Function response ต้องมีทั้ง call ID และชื่อฟังก์ชัน
- Interactions API ใช้ call_id
- generateContent ใช้ id

ส่วนอื่นของ Gemini 3 API ยังคงเหมือนเดิม

การเปลี่ยนจาก 3.6 ไป 3.7 ใหญ่กว่าการเปลี่ยนเป็น 3.8 หรือไม่?

โดยรวม 3.7 Flash เป็นการก้าวกระโดดที่ใหญ่กว่า โดย DeepSWE เพิ่มจาก 49.0% เป็น 65.3% และ Artificial Analysis Intelligence Index เพิ่มจาก 52 เป็น 56

3.8 Flash เพิ่มอีก 3 คะแนนบนดัชนี และปรับวิธีใช้โทเค็นให้เหมาะกับงานที่ต้องให้เหตุผลและเรียกใช้เครื่องมือหลายรอบ หากต้องการดูภาพรวมรุ่นก่อนหน้า อ่าน Gemini 3.6 Flash เทียบกับ Gemini 3.5 Flash

สรุป

อัปเกรดเป็น Gemini 3.8 Flash หากปริมาณงานของคุณเป็น:

เอเจนต์หลายขั้นตอน
งานที่เรียกใช้เครื่องมือจำนวนมาก
การดึงข้อมูลและตรวจสอบเอกสารขนาดใหญ่
งานการเงิน กฎหมาย หรือการวิจัย

ใช้ Gemini 3.7 Flash ต่อ หรือเลือก 3.8 Flash ที่ระดับ low หากคุณรันคำสั่งสั้นๆ ซ้ำๆ และต้องควบคุมค่าใช้จ่ายต่อภารกิจอย่างละเอียด

ไม่ว่าจะเลือกแบบใด ให้แก้การตั้งค่า minimal และตรวจสอบ function response ให้ถูกต้องก่อน จากนั้นวัดจำนวนโทเค็นด้วยพรอมต์ของคุณเองใน Apidog ก่อนเชื่อถือผลจาก benchmark ใดๆ รวมถึง benchmark ที่เผยแพร่โดยผู้ให้บริการโมเดลเองด้วย

เจมิไน 3.8 แฟลช: เปรียบเทียบระดับการคิด ต่ำ ปานกลาง สูง พร้อมเหตุผลที่ระดับ Minimal หายไป

Thanawat Wongchai — Thu, 03 Sep 2026 08:36:14 +0000

ตั้งค่า `thinking_level` ของ Gemini 3.8 Flash ให้เหมาะกับแต่ละเส้นทาง

Gemini 3.8 Flash มีระดับการคิดสามระดับ ได้แก่ low, medium และ high การตั้งค่านี้ควบคุมปริมาณการให้เหตุผลภายในก่อนโมเดลตอบกลับ และส่งผลโดยตรงต่อความหน่วง โทเค็นเอาต์พุต และค่าใช้จ่าย Google ออกแบบ 3.8 Flash ให้ “ทำงานหนักขึ้น” กับงานซับซ้อน ดังนั้นการเลือกระดับจึงสำคัญกว่าเดิมเมื่อเทียบกับ 3.7 Flash หากต้องการดูภาพรวมการเปิดตัว โปรดอ่าน ภาพรวม Gemini 3.8 Flash ส่วนบทความนี้จะเน้นเฉพาะการตั้งค่าระดับการคิด

ลองใช้ Apidog วันนี้

มีสองประเด็นที่มักทำให้ทีมสับสน:

ค่าเริ่มต้นของ 3.8 Flash คือ medium ไม่ใช่ high โดย Gemini 3 Pro ใช้ high เป็นค่าเริ่มต้น
minimal ซึ่งเคยใช้กับ Gemini 3.7 Flash ไม่รองรับใน 3.8 Flash อีกต่อไป คำขอจะล้มเหลวตั้งแต่การตรวจสอบความถูกต้อง ก่อนสร้างโทเค็นใดๆ ดูรายละเอียดได้ที่ มีอะไรใหม่ใน Gemini 3.8 Flash

บทความนี้ครอบคลุมสิ่งที่แต่ละระดับทำ ค่าใช้จ่าย วิธีตั้งค่าใน API ทั้งสองแบบ กลยุทธ์การเลือกใช้ และการทดสอบที่ทำซ้ำได้ใน Apidog

ระดับการคิดโดยสรุป

ระดับ	คำแนะนำของ Google	ค่าใช้จ่ายต่อภารกิจ (AA)	เวลาต่อภารกิจ (AA)	เหมาะกับ
`low`	ลดความหน่วงและค่าใช้จ่าย เหมาะกับคำสั่งง่าย แชท และงานปริมาณสูง	$0.24	0.8 นาที	งานที่ผู้ใช้รอผลโดยตรง การค้นหาจากข้อความถอดเสียง การจัดหมวดหมู่
`medium` (ค่าเริ่มต้น)	สมดุลสำหรับโค้ดซับซ้อนและงานแบบเอเจนต์	$0.41	ไม่ระบุ	เส้นทางส่วนใหญ่ การถามตอบวิดีโอทั่วไป
`high`	ให้เหตุผลลึกที่สุดสำหรับปัญหาหลายขั้นตอน	$0.58	2.5 นาที	การถามตอบภาพหนาแน่น วิดีโอยาวกว่า 60 นาที และขั้นตอนวางแผนสำคัญ
`minimal`	ไม่รองรับใน 3.8 Flash	n/a	n/a	ห้ามใช้ ให้แมปเป็น `low`

ค่าใช้จ่ายและเวลาเป็นค่าเฉลี่ยจากการทดสอบ Intelligence Index ของ Artificial Analysis โดยใช้ราคาโทเค็นเบื้องต้นของ Google ตัวเลขนี้ไม่ใช่ข้อมูลจาก Google และไม่ได้อ้างอิงพรอมต์ของคุณโดยตรง ให้ใช้เพื่อดูอัตราส่วน แล้ววัดเส้นทางจริงของคุณเอง

แต่ละระดับควบคุมอะไร

คำตอบของ 3.8 Flash อาจมี thinking tokens ซึ่งเป็นการให้เหตุผลที่โมเดลสร้างขึ้นก่อนคำตอบที่ผู้ใช้มองเห็น โทเค็นเหล่านี้ถูกคิดเป็น output tokens:

$3.75 ต่อล้านโทเค็น ตามราคาแนะนำจนถึงวันที่ 2026-12-31
$7.50 ต่อล้านโทเค็น ตั้งแต่วันที่ 2027-01-01

API รายงานจำนวนดังกล่าวแยกต่างหากใน usageMetadata.thoughtsTokenCount

ระดับการคิดทำหน้าที่เป็นคำแนะนำว่าโมเดลควรใช้การให้เหตุผลมากน้อยเพียงใด:

low: ใช้กระบวนการคิดสั้นลง โทเค็นแรกมาถึงเร็ว และค่าใช้จ่ายเอาต์พุตต่ำ เหมาะกับแชท คำสั่งง่าย และระบบปริมาณสูง
medium: จุดสมดุลและเป็นค่าเริ่มต้น เหมาะกับโค้ดซับซ้อนและงานแบบเอเจนต์
high: ใช้การให้เหตุผลเชิงลึกที่สุด เหมาะกับปัญหาหลายขั้นตอนที่ยาก

พฤติกรรมที่ทำให้ 3.8 Flash แตกต่างคือ ในงานซับซ้อน โมเดลอาจ:

ดำเนินขั้นตอนการให้เหตุผลเพิ่มเติม
เรียกใช้เครื่องมือซ้ำหลายรอบ
ตรวจสอบการทำงานตลอดกระบวนการ
ใช้โทเค็นมากขึ้นตามความซับซ้อนของงาน โดยเฉพาะเมื่อเลือกระดับสูง

หากจำนวนโทเค็นเพิ่มขึ้นมาก คำแนะนำแรกของ Google คือ ลด thinking_level และคำแนะนำถัดมาคือใช้ 3.7 Flash ต่อไป ซึ่งยังได้รับการสนับสนุนอย่างเต็มที่

thinking_level เป็น enum ไม่ใช่งบประมาณโทเค็น

thinking_budget แบบจำนวนเต็มจากโมเดลรุ่นก่อนถูกนำออกใน Gemini 3 ดังนั้นคุณไม่สามารถกำหนดว่า “ใช้ thinking tokens สูงสุด 2,000 โทเค็น” ได้ ต้องเลือกระดับแล้ววัดผลจริง

ค่าเริ่มต้นคือ `medium` ไม่ใช่ `high`

หากไม่ส่งฟิลด์นี้ 3.8 Flash จะใช้ medium ซึ่งอาจสร้างปัญหาได้สองกรณี:

ทีมที่ย้ายจาก Gemini 3 Pro อาจคาดหวังว่าโมเดลจะใช้ high
ทีมที่ลบ thinking_budget ระหว่างย้ายจาก 3.7 Flash อาจใช้ medium โดยไม่ตั้งใจ แม้แต่ในเส้นทางแชทที่ควรใช้ low

วิธีแก้คือกำหนด thinking_level อย่างชัดเจนในทุกคำขอและทุกเส้นทาง ควรเก็บค่าไว้ในไฟล์กำหนดค่าหรือ routing config แทนการกระจายไว้ในโค้ด เพื่อให้โปรไฟล์ค่าใช้จ่ายไม่เปลี่ยนโดยไม่ตั้งใจเมื่อค่าเริ่มต้นของ Google เปลี่ยน

`minimal` ไม่รองรับแล้ว: วิธีแก้ข้อผิดพลาด

Gemini 3.8 Flash รองรับเฉพาะ low, medium และ high ตาม หน้าโมเดล

หากส่ง minimal ผ่าน REST API คำขอจะถูกปฏิเสธด้วยสถานะ 400 INVALID_ARGUMENT:

Thinking level MINIMAL is not supported for this model.
Please retry with other thinking level.

ข้อผิดพลาดนี้ตรวจสอบแล้วด้วยการเรียกใช้งานจริงเมื่อวันที่ 3 กันยายน 2026 SDK อาจห่อหุ้มข้อผิดพลาดไว้ใน exception ของตัวเอง ดังนั้นควรตรวจสอบสถานะ 400 หรือรหัส INVALID_ARGUMENT ไม่ควรผูกกับข้อความอย่างเดียว

ก่อนย้ายข้อมูล

{
  "model": "gemini-3.8-flash",
  "input": "Classify this ticket as billing, bug, or feature.",
  "generation_config": { "thinking_level": "minimal" }
}

หลังย้ายข้อมูล

{
  "model": "gemini-3.8-flash",
  "input": "Classify this ticket as billing, bug, or feature.",
  "generation_config": { "thinking_level": "low" }
}

Google แนะนำให้แมปโดยตรง:

minimal → low

อย่าพยายามใช้ thinking_budget เพื่อสร้างระดับที่ต่ำกว่า และอย่าลด temperature เพื่อให้โมเดล “ใจเย็นลง” Google แนะนำให้คงค่าเริ่มต้น 1.0 ในโมเดล Gemini 3 ทั้งหมด เพราะการลดค่าอาจทำให้เกิดการวนซ้ำหรือเอาต์พุตด้อยคุณภาพ

รายละเอียดเรื่อง thought signatures และข้อกำหนด call_id ใน function response อยู่ใน คู่มือการย้ายข้อมูล 3.7 ไป 3.8 Flash

เนื่องจากข้อผิดพลาดเกิดขึ้นตั้งแต่ขั้นตอน validation คุณสามารถเพิ่มคำขอทดสอบที่ใช้ minimal เพื่อจับการตั้งค่าที่ถอยกลับไปใช้ค่าที่ไม่รองรับได้โดยไม่ต้องรอให้เกิดการสร้างโทเค็น

ค่าใช้จ่ายของแต่ละระดับ

ราคาต่อโทเค็นไม่ได้เปลี่ยนตามระดับ ตาม หน้าการกำหนดราคา:

Input: $0.75 ต่อล้านโทเค็น ตามราคาแนะนำ
Output: $3.75 ต่อล้านโทเค็น ตามราคาแนะนำ
ตั้งแต่วันที่ 2027-01-01 ราคาเพิ่มเป็น $1.50 และ $7.50 ตามลำดับ

สิ่งที่แตกต่างระหว่างระดับคือจำนวน output tokens ที่โมเดลสร้างขึ้น

โมเดลและระดับ	ค่าใช้จ่ายต่อภารกิจ	เวลาต่อภารกิจ
Gemini 3.8 Flash `low`	$0.24	0.8 นาที
Gemini 3.8 Flash `medium`	$0.41	ไม่ระบุ
Gemini 3.8 Flash `high`	$0.58	2.5 นาที
Gemini 3.7 Flash `high`	$0.40	2.2 นาที

ที่มา: Artificial Analysis, การทดสอบ Intelligence Index โดยใช้ราคาแนะนำ

ข้อสังเกตสำคัญจากตาราง:

low มีค่าใช้จ่ายประมาณ 41% ของ high และใช้เวลาประมาณหนึ่งในสาม จึงเป็นตัวเลือกสำคัญสำหรับงานที่ไวต่อความหน่วง
medium บน 3.8 Flash มีค่าใช้จ่ายใกล้เคียงกับ high บน 3.7 Flash ($0.41 เทียบกับ $0.40)
high บน 3.8 Flash แพงกว่า high บน 3.7 Flash ประมาณ 45% แม้ราคาต่อโทเค็นเท่ากัน เนื่องจากสร้าง output tokens มากขึ้นประมาณ 30% หรือเฉลี่ยราว 48k โทเค็นต่อภารกิจในดัชนี

อย่าสรุปว่าคุณภาพจะเพิ่มหรือลดเป็นเส้นตรงตามค่าใช้จ่าย คะแนน Intelligence Index ของ Artificial Analysis ที่ 59 สำหรับ 3.8 Flash มาจากการรันด้วย high พวกเขาไม่ได้เผยแพร่คะแนนของ medium หรือ low ดังนั้นควรประเมินงานของคุณเองก่อนลดระดับ

สำหรับตัวอย่างการคำนวณค่าใช้จ่าย 1,000 ภารกิจต่อวัน และการเปลี่ยนราคาในวันที่ 31 ธันวาคม โปรดดู การกำหนดราคา Gemini 3.8 Flash

ตั้งค่า `thinking_level` ใน Interactions API

Interactions API เป็นอินเทอร์เฟซหลักของ Google สำหรับ Gemini 3.x ระดับจะอยู่ใน generation_config และใช้รูปแบบ snake_case

cURL

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "x-goog-[REDACTED CREDENTIAL] -H 'Content-Type: application/json' \
  -d '{"model":"gemini-3.8-flash","input":"Explain HTTP caching in 3 sentences.","generation_config":{"thinking_level":"low"}}'

Python

interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input="Explain HTTP caching in 3 sentences.",
    generation_config={"thinking_level": "low"},
)
print(interaction.output_text)

thinking_level เป็นฟิลด์ระดับคำขอ จึงต้องส่งทุกครั้ง รวมถึงการโต้ตอบต่อเนื่องที่ใช้ previous_interaction_id

การตอบกลับจะเป็นรายการขั้นตอน เช่น thoughts และ tool calls ก่อนจบด้วย model_output โดย SDK จะแสดงข้อความสุดท้ายผ่าน output_text ดูตัวอย่างการใช้งานแบบเต็ม รวมถึง multi-turn และ streaming ได้ที่ วิธีใช้ Gemini 3.8 Flash API

ตั้งค่าใน `generateContent` แบบดั้งเดิม

โค้ด Gemini ส่วนใหญ่ยังใช้ generateContent ซึ่ง Google เรียกว่า legacy API แต่ยังได้รับการสนับสนุนอย่างเต็มที่และยังไม่มีวันยุติการใช้งาน

ใน API นี้ ฟิลด์จะอยู่ลึกลงไปอีกหนึ่งระดับและใช้รูปแบบ camelCase

cURL

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.8-flash:generateContent" \
  -H "x-goog-[REDACTED CREDENTIAL]" -H 'Content-Type: application/json' -X POST \
  -d '{"contents":[{"parts":[{"text":"Explain HTTP caching in 3 sentences."}]}],
       "generationConfig":{"thinkingConfig":{"thinkingLevel":"low","includeThoughts":true}}}'

Python

from google.genai import types

response = client.models.generate_content(
    model="gemini-3.8-flash",
    contents="Explain HTTP caching in 3 sentences.",
    config=types.GenerateContentConfig(
        thinking_config=types.ThinkingConfig(thinking_level="low")
    ),
)
print(response.usage_metadata.thoughts_token_count)

includeThoughts: true จะเพิ่ม thought summaries เข้าไปใน response ซึ่งมีประโยชน์ตอนปรับระดับ แต่ไม่จำเป็นเมื่อใช้งานจริง

ฟิลด์ที่ควรเฝ้าดูคือ:

usageMetadata.thoughtsTokenCount

นี่คือจำนวน thinking tokens ที่ถูกเรียกเก็บเป็น output tokens และควรเป็นหนึ่งในตัวชี้วัดหลักของการทดสอบ

กลยุทธ์เลือกใช้ตามเส้นทาง

ให้มอง thinking_level เป็น การตัดสินใจระดับเส้นทาง ไม่ใช่การตั้งค่ากลางทั้งระบบ

แชทและ autocomplete: ใช้ low เมื่อผู้ใช้กำลังรอผลและ first-token latency สำคัญ
การจัดหมวดหมู่ การดึงข้อมูล และการค้นหาจากข้อความถอดเสียง: เริ่มด้วย low แล้วทำ evaluation เพื่อยืนยันความแม่นยำ ตัวอย่างวิดีโอของ Google ก็ใช้ low สำหรับการค้นหาจากข้อความถอดเสียง
Coding agents และ tool loops: ใช้ medium เป็นค่าเริ่มต้น ยกระดับเฉพาะขั้นตอนวางแผนที่กำหนดทุกขั้นตอนถัดไปเป็น high แล้วลดกลับลงมา การใช้ high ตลอด tool loop อาจเพิ่มค่าใช้จ่ายอย่างรวดเร็ว
เวิร์กโฟลว์เอกสารขนาดใหญ่และใช้เวลานาน: ใช้ high ร่วมกับ Batch API ซึ่งลดค่าใช้จ่ายได้ 50% เมื่อไม่ใช่งานแบบโต้ตอบ
วิดีโอ:
- high: การถามตอบภาพที่มีข้อมูลหนาแน่น หรือวิดีโอยาวกว่า 60 นาที
- medium: การถามตอบวิดีโอทั่วไป
- low: การค้นหาจากข้อความถอดเสียง

หากแม้แต่ low ของ 3.8 Flash ยังช้าหรือแพงเกินไป ให้พิจารณาตระกูล Flash-Lite คู่มือ Gemini 3.1 Flash-Lite ครอบคล้าดูจำนวนโทเค็นหลังอัปเกรด

ลดระดับหรือเปลี่ยนโมเดลได้โดยไม่ต้องดีพลอยโค้ดใหม่

ทดสอบทั้งสามระดับใน Apidog

ข้อมูลจาก Artificial Analysis ช่วยบอกอัตราส่วน แต่มีเพียงพรอมต์จริงของคุณเท่านั้นที่จะบอกค่า latency, token usage และค่าใช้จ่ายที่ใช้งานได้จริง

สร้างสถานการณ์ทดสอบใน Apidog โดยส่ง golden prompt เดียวกันด้วยทั้งสามระดับ:

เก็บคีย์เป็น environment variable สร้าง GEMINI_API_KEY ใน Apidog และอ้างอิงใน header เป็น {{GEMINI_API_KEY}}
สร้างตัวแปร THINKING_LEVEL เพื่อใช้ request เดียวกับทั้งสามขั้นตอน
บันทึก request แบบ POST ไปยัง /v1beta/models/gemini-3.8-flash:generateContent โดยกำหนดค่า:

   {
     "thinkingConfig": {
       "thinkingLevel": "{{THINKING_LEVEL}}"
     }
   }

สร้าง test scenario สามขั้นตอน โดยใช้ค่า THINKING_LEVEL เป็น low, medium และ high
ตรวจสอบผลลัพธ์ในทุกขั้นตอน:
- HTTP status เป็น 200
- มี usageMetadata.thoughtsTokenCount
- low อยู่ภายใต้ขีดจำกัด latency และ token ที่เส้นทางยอมรับได้
- high ใช้การให้เหตุผลอย่างน้อยเท่ากับ low

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

เพิ่ม negative test ด้วย:

   {
     "thinkingLevel": "minimal"
   }

จากนั้นยืนยันว่าการตอบกลับไม่ใช่ 200 เมื่อเปลี่ยน model ID ในอนาคต ขั้นตอนนี้ช่วยตรวจสอบว่าโมเดลใหม่ยังปฏิเสธค่าที่ไม่รองรับหรือไม่

ตั้งเวลาให้ scenario รันทุกวัน เพื่อให้การเปลี่ยนแปลงพฤติกรรมหรือ configuration regression ปรากฏเป็น failed run แทนที่จะไปปรากฏในใบแจ้งหนี้ ดูวิธีตั้งค่าได้ที่ วิธีตั้งเวลาทดสอบ API ใน Apidog

สำหรับ streaming response สามารถใช้แนวทางเดียวกันกับ SSE ได้ ดูรายละเอียดที่ วิธีทดสอบ LLM APIs ที่สตรีมผ่าน SSE

ดาวน์โหลด Apidog เพื่อเริ่มทดสอบ โดยแผนฟรีรองรับ scenario เหล่านี้

คำถามที่พบบ่อย

ระดับการคิดเปลี่ยนราคาต่อโทเค็นหรือไม่

ไม่ ราคาของ 3.8 Flash ยังคงเป็น $0.75 ต่อล้าน input tokens และ $3.75 ต่อล้าน output tokens ตามราคาแนะนำ โดยไม่ขึ้นกับระดับ

ระดับจะเปลี่ยนจำนวน output tokens ที่โมเดลสร้างขึ้นเพื่อการคิด และโทเค็นเหล่านั้นจะถูกคิดในราคา output รายละเอียดเรื่องการแคช การประมวลผลแบบแบตช์ และการขึ้นราคาในวันที่ 1 มกราคมอยู่ใน หน้าการกำหนดราคา

กำหนดงบประมาณ thinking tokens แบบตายตัวได้หรือไม่

ไม่ได้ ใน Gemini 3 thinking_budget ถูกแทนที่ด้วย enum thinking_level และ 3.8 Flash รองรับเฉพาะ low, medium และ high

หากต้องการจำกัดเพดาน ให้บังคับใช้ผ่าน evaluation, monitoring และ alerting แทนการกำหนดใน request

คะแนน Artificial Analysis ที่ 59 ใช้ระดับใด

ใช้ high Artificial Analysis รัน Intelligence Index ด้วยระดับ high เพื่อสร้างคะแนนหลัก และเผยแพร่ค่าใช้จ่ายกับเวลาของ low และ medium แต่ไม่ได้เผยแพร่คะแนนดัชนีของสองระดับนั้น

จึงควรถือว่าคุณภาพของ low และ medium ยังไม่ได้รับการยืนยันบน benchmark เดียวกัน จนกว่าคุณจะทดสอบเอง

ควรลด `temperature` เพื่อลดการคิดหรือไม่

ไม่ควร Google แนะนำให้คง temperature ที่ค่าเริ่มต้น 1.0 ในโมเดล Gemini 3 ทั้งหมด การลดค่าอาจทำให้เกิดการวนซ้ำหรือเอาต์พุตด้อยคุณภาพ

ใช้ thinking_level เพื่อควบคุมความลึกของการให้เหตุผล

ถ้าแม้แต่ `low` ยังช้าหรือแพงเกินไปควรทำอย่างไร

มีสองทางเลือก:

ใช้ Gemini 3.7 Flash ต่อไป ซึ่ง Google ระบุว่ายังได้รับการสนับสนุนอย่างเต็มที่และไม่มีวันยุติการใช้งาน
ย้ายเส้นทางไปยังโมเดล Flash-Lite

อ่านการเปรียบเทียบเพิ่มเติมได้ที่ การเปรียบเทียบ Gemini 3.8 Flash กับ Gemini 3.7 Flash

สรุป: เลือกระดับต่อเส้นทาง แล้ววัดผล

Gemini 3.8 Flash มีสามระดับการคิดและใช้ medium เป็นค่าเริ่มต้น โมเดลยังสามารถใช้โทเค็นมากขึ้นในงานซับซ้อนตามการออกแบบ

แนวทางที่ควรทำ:

กำหนด thinking_level อย่างชัดเจนในทุกเส้นทาง
แมปค่า minimal ที่ยังหลงเหลืออยู่เป็น low
อย่าใช้ thinking_budget กับ Gemini 3
คง temperature ไว้ที่ 1.0
ตรวจสอบ usageMetadata.thoughtsTokenCount
ทดสอบ low, medium และ high ด้วยพรอมต์จริงของคุณ
ใช้ Apidog ตั้ง scenario แบบทำซ้ำได้และรันตามเวลา

ตัวเลขจาก Artificial Analysis—$0.24, $0.41 และ $0.58 ต่อภารกิจ—ช่วยให้เห็นรูปแบบโดยรวม ส่วนการทดสอบสามขั้นตอนใน Apidog จะบอกต้นทุนและ latency ของระบบคุณเอง ก่อนการเปลี่ยนแปลงราคาในวันที่ 31 ธันวาคมจะทำให้ผลลัพธ์เหล่านี้สำคัญยิ่งขึ้น

วิธีใช้ Gemini 3.8 Flash API: Interactions API, ระดับการคิด และการเรียกใช้ครั้งแรกใน Apidog

Thanawat Wongchai — Thu, 03 Sep 2026 07:41:35 +0000

Gemini 3.8 Flash API: คู่มือเชื่อมต่อและควบคุมค่าใช้จ่าย

Google เปิดตัว Gemini 3.8 Flash เมื่อวันที่ 2 กันยายน 2026 โดยใช้รหัสโมเดล API gemini-3.8-flash โดยไม่มีส่วนต่อท้ายสำหรับรุ่นพรีวิว โมเดลนี้ยังคงราคาแนะนำของ 3.7 Flash ไว้ที่ 0.75 ดอลลาร์ต่อล้านอินพุตโทเค็น และ 3.75 ดอลลาร์ต่อล้านเอาต์พุตโทเค็นจนถึงวันที่ 31 ธันวาคม 2026 Google อธิบายว่าเป็นโมเดลที่ “ทำงานหนักขึ้น” โดยใช้ขั้นตอนการให้เหตุผลมากขึ้นและเรียกใช้เครื่องมือบ่อยขึ้นในงานซับซ้อน ซึ่งจะแสดงในบิลค่าโทเค็นของคุณ

ลองใช้ Apidog วันนี้

คู่มือนี้ครอบคลุมการผสานรวม Gemini 3.8 Flash ตั้งแต่การรับคีย์ใน AI Studio การส่งคำขอผ่าน Interactions API การใช้ generateContent แบบเดิม การกำหนด thinking_level การสตรีม และการอ่าน thoughtsTokenCount เพื่อควบคุมค่าใช้จ่าย ทุกคำขอเป็น HTTP พร้อม JSON จึงสามารถสร้างและตรวจสอบใน Apidog ก่อนนำไปใช้ในโค้ดจริงได้

สำหรับภาพรวมโมเดลและการวัดประสิทธิภาพ อ่าน Gemini 3.8 Flash คืออะไร และ โพสต์เปิดตัวของ Google

Gemini 3.8 Flash API โดยสังเขป

รายการ	ค่า
รหัสโมเดล	`gemini-3.8-flash`
เอนด์พอยต์หลัก	`POST /v1beta/interactions`
เอนด์พอยต์แบบเดิม	`POST /v1beta/models/gemini-3.8-flash:generateContent`
ส่วนหัวการยืนยันตัวตน	`x-goog-api-key`
บริบท / เอาต์พุต	อินพุต 1,048,576 โทเค็น / เอาต์พุต 65,536 โทเค็น
อินพุต	ข้อความ, รูปภาพ, วิดีโอ, เสียง, PDF
เอาต์พุต	ข้อความเท่านั้น
ระดับการคิด	`low`, `medium` (ค่าเริ่มต้น), `high`; `minimal` ใช้ไม่ได้
ราคาแนะนำถึง 31 ธันวาคม 2026	$0.75 / $3.75 ต่อ 1 ล้านโทเค็น
ราคาตั้งแต่ 1 มกราคม 2027	$1.50 / $7.50 ต่อ 1 ล้านโทเค็น

ระดับการคิดเริ่มต้นคือ medium ไม่ใช่ high เหมือน Gemini 3 Pro และโทเค็นสำหรับการคิดจะถูกเรียกเก็บในอัตราเอาต์พุตตาม หน้าราคาอย่างเป็นทางการ ดังนั้นการเลือกระดับจึงเป็นทั้งการตัดสินใจด้านคุณภาพและค่าใช้จ่าย ดูตัวเลขต่อภารกิจได้ใน รายละเอียดราคา

ขั้นตอนที่ 1: รับ API key ใน AI Studio

เปิด Google AI Studio ลงชื่อเข้าใช้ แล้วสร้าง API key จากหน้าคีย์ คีย์ใช้งานได้ทันทีใน free tier แต่มีข้อจำกัดอัตราการใช้งาน และ Google ระบุว่าข้อมูลในระดับฟรี “ใช้เพื่อปรับปรุงผลิตภัณฑ์ของเรา”

เชื่อมโยงบัญชีสำหรับการเรียกเก็บเงินเพื่อย้ายไป Tier 1 และเพิ่มข้อจำกัดสำหรับงานโปรดักชัน

ส่งออกคีย์แทนการใส่ไว้ในโค้ด:

export GEMINI_API_KEY="AIza..."

Python SDK อย่างเป็นทางการจะอ่าน GEMINI_API_KEY จาก environment ดังนั้น genai.Client() จึงไม่ต้องรับอาร์กิวเมนต์:

pip install google-genai

ขั้นตอนที่ 2: เรียกใช้ครั้งแรกด้วย Interactions API

ปัจจุบัน Google ถือว่า Interactions API เป็นวิธีหลักสำหรับโมเดล Gemini 3.x คำขอประกอบด้วย model, input และ generation_config ซึ่งเป็นที่อยู่ของ thinking_level

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "x-goog-[REDACTED CREDENTIAL] \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-3.8-flash",
    "input": "Explain HTTP caching in 3 sentences.",
    "generation_config": {"thinking_level": "medium"}
  }'

การตอบกลับเป็นรายการขั้นตอนการดำเนินการแทนข้อความเดียว ความคิดของโมเดลและการเรียกใช้เครื่องมือจะปรากฏเป็นขั้นตอน ส่วนขั้นตอนสุดท้ายคือ model_output ซึ่งเก็บข้อความ

Python SDK จัดการรูปแบบนี้ให้:

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input="Explain HTTP caching in 3 sentences.",
    generation_config={"thinking_level": "medium"},
)

print(interaction.output_text)

ปล่อย temperature, top_p และ top_k เป็นค่าเริ่มต้น Google แนะนำให้ใช้ temperature ที่ 1.0 สำหรับ Gemini 3 ทุกรุ่น เพราะการลดค่าอาจทำให้เกิดการวนซ้ำหรือประสิทธิภาพลดลง หากคัดลอกคอนฟิกจากโมเดลเก่า ให้ลบบรรทัดเหล่านี้ออกก่อน

ขั้นตอนที่ 3: สนทนาหลายรอบด้วย `previous_interaction_id`

โดยค่าเริ่มต้น Interactions API จะเก็บสถานะการสนทนาไว้บนเซิร์ฟเวอร์ หากต้องการสนทนาต่อ ให้ส่ง ID ของการตอบกลับก่อนหน้าเป็น previous_interaction_id พร้อมอินพุตใหม่ โดยไม่ต้องส่งประวัติทั้งหมดซ้ำ:

follow_up = client.interactions.create(
    model="gemini-3.8-flash",
    input="Now give one example of a Cache-Control header.",
    previous_interaction_id=interaction.id,
)

print(follow_up.output_text)

หากข้อกำหนดด้านการปฏิบัติตามกฎห้ามจัดเก็บข้อมูลฝั่งเซิร์ฟเวอร์ ให้ตั้งค่า store: false แต่คุณจะต้องจัดการสถานะเอง รวมถึงส่งบล็อกความคิดและลายเซ็นความคิดกลับไปในแต่ละรอบอย่างถูกต้อง กฎเดียวกันนี้มีผลต่อการใช้เครื่องมือ ดูรายละเอียดใน คู่มือการเรียกใช้ฟังก์ชันสำหรับ Gemini 3.8 Flash

ขั้นตอนที่ 4: ใช้ `generateContent` แบบเดิม

โค้ด Gemini ส่วนใหญ่ในโปรดักชันยังคงใช้ generateContent Google เรียกว่าเป็น API แบบเดิม แต่ยัง “รองรับอย่างเต็มที่” และยังไม่มีกำหนดเลิกใช้งาน คุณจึงไม่จำเป็นต้องเขียนโค้ดใหม่ทันที

คู่มือ Gemini 3.7 Flash API ครอบคลุมเส้นทางนี้ และรูปแบบของ Gemini 3.8 Flash เหมือนกัน เพียงแต่ตำแหน่งของคอนฟิกการคิดแตกต่างจาก Interactions API

ใน generateContent ให้กำหนดระดับผ่าน generationConfig.thinkingConfig.thinkingLevel:

curl -X POST "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.8-flash:generateContent" \
  -H "x-goog-[REDACTED CREDENTIAL] \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{"parts": [{"text": "Explain HTTP caching in 3 sentences."}]}],
    "generationConfig": {"thinkingConfig": {"thinkingLevel": "low"}}
  }'

Python ใช้ typed config objects:

from google import genai
from google.genai import types

client = genai.Client()

response = client.models.generate_content(
    model="gemini-3.8-flash",
    contents="Explain HTTP caching in 3 sentences.",
    config=types.GenerateContentConfig(
        thinking_config=types.ThinkingConfig(thinking_level="low")
    ),
)

print(response.text)

หากคอนฟิกเดิมใช้ thinking_budget เป็นจำนวนเต็ม ให้เปลี่ยนเป็น enum string และลบ candidate_count เพราะถูกยกเลิกใน Gemini 3 และรุ่นใหม่กว่า ดู JSON ก่อนและหลังการแก้ไขได้ใน คู่มือการย้ายจาก 3.7 ไป 3.8 Flash

เปรียบเทียบการตั้งค่าใน API ทั้งสองแบบ

ข้อกังวล	Interactions API	`generateContent` แบบเดิม
ระดับการคิด	`generation_config.thinking_level`	`generationConfig.thinkingConfig.thinkingLevel`
สถานะการสนทนา	`previous_interaction_id` ฝั่งเซิร์ฟเวอร์	ส่งอาร์เรย์ `contents` ทั้งหมดซ้ำ
ผลลัพธ์เครื่องมือ	`function_result` พร้อม `call_id` + `name`	`functionResponse` พร้อม `id` + `name`
ข้อความสุดท้าย	ขั้นตอน `model_output` หรือ `output_text` ใน SDK	`candidates[0].content.parts[].text`
ลายเซ็นความคิด	SDK จัดการให้ เว้นแต่ใช้ `store: false`	ส่งคืนทุกส่วนตามที่ได้รับอย่างครบถ้วน

ขั้นตอนที่ 5: สตรีมและอ่านค่าใช้จ่ายในการคิด

สำหรับแชต ให้เปลี่ยนเมธอดเป็น streamGenerateContent และเพิ่ม ?alt=sse เพื่อรับ Server-Sent Events:

curl -N "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.8-flash:streamGenerateContent?alt=sse" \
  -H "x-goog-[REDACTED CREDENTIAL] \
  -H "Content-Type: application/json" \
  -d '{"contents":[{"parts":[{"text":"List three HTTP caching headers."}]}]}'

ไม่ว่าจะสตรีมหรือไม่ การตอบกลับของ generateContent จะสิ้นสุดด้วย usageMetadata:

"usageMetadata": {
  "promptTokenCount": 12,
  "candidatesTokenCount": 84,
  "thoughtsTokenCount": 310,
  "totalTokenCount": 406
}

thoughtsTokenCount คือค่าที่ควรจับตาใน Gemini 3.8 Flash โทเค็นการคิดถูกคิดราคาในอัตราเอาต์พุตที่ 3.75 ดอลลาร์ต่อล้านโทเค็นในช่วงแนะนำ Google ระบุว่าโมเดลอาจใช้โทเค็นมากขึ้นเพื่อเพิ่มประสิทธิภาพ โดยเฉพาะระดับความพยายามสูง

Artificial Analysis วัดได้ประมาณ 48k เอาต์พุตโทเค็นต่อภารกิจเมื่อใช้ high มากกว่า 3.7 Flash ประมาณ 30% ทำให้ค่าใช้จ่ายต่อภารกิจเพิ่มจาก 0.40 ดอลลาร์เป็น 0.58 ดอลลาร์ แม้ราคาต่อโทเค็นจะเท่าเดิม ส่วน medium และ low มีค่าใช้จ่ายประมาณ 0.41 ดอลลาร์และ 0.24 ดอลลาร์ต่อภารกิจตามลำดับ อ่านกลยุทธ์เพิ่มเติมใน คู่มือระดับการคิด

หากต้องการดูเหตุผลของโมเดล ให้เพิ่ม includeThoughts: true ภายใน thinkingConfig สรุปความคิดจะถูกส่งกลับเป็นส่วนที่มี "thought": true ให้ข้ามส่วนเหล่านี้เมื่อประกอบคำตอบที่ผู้ใช้มองเห็น

ข้อผิดพลาดที่พบบ่อยในชั่วโมงแรก

thinking_level: "minimal" ใช้ไม่ได้

Gemini 3.8 Flash รองรับเฉพาะ low, medium และ high การส่ง minimal จะได้ข้อผิดพลาด 400 INVALID_ARGUMENT พร้อมข้อความ Thinking level MINIMAL is not supported for this model. Please retry with other thinking level. วิธีแก้คือเปลี่ยนเป็น low การตั้งค่าจาก Gemini 3.x รุ่นเก่ามักเป็นสาเหตุของปัญหานี้
429 หมายถึงถึงขีดจำกัดของ Tier

รายละเอียดข้อจำกัดอัตราการใช้งาน แบ่งเป็น free tier, Tier 1 เมื่อเชื่อมโยงบัญชีสำหรับเรียกเก็บเงิน, Tier 2 หลังมียอดใช้จ่ายอย่างน้อย 100 ดอลลาร์และใช้งานมาแล้ว 3 วัน และ Tier 3 หลังมียอดอย่างน้อย 1,000 ดอลลาร์และใช้งานมาแล้ว 30 วัน ตัวเลขคำขอต่อนาทีและโทเค็นต่อนาทีแตกต่างกันตามบัญชี จึงควรตรวจสอบใน AI Studio แทนการใช้ตัวเลขจากบล็อกโพสต์

เมื่อพบ 429 ให้รอสักครู่แล้วลองใหม่ หากเกิดซ้ำแม้ใช้งานไม่มาก ให้พิจารณาอัปเกรด Tier สำหรับงานออฟไลน์ Batch API เหมาะกว่า เพราะลดราคา 50% เหลือ 0.375 ดอลลาร์ / 1.875 ดอลลาร์ต่อล้านโทเค็นในช่วงแนะนำ และมีโควตาโทเค็นในคิวแยกกันที่ 3M สำหรับ Tier 1, 400M สำหรับ Tier 2 และ 1B สำหรับ Tier 3 ดูรูปแบบคำขอใน คู่มือโหมด Batch ของ Gemini

ผลลัพธ์ฟังก์ชันขาด call_id หรือ ID ที่ตรงกัน ใน Interactions API ทุก function_result ต้องมีทั้ง call_id และ name ส่วน functionResponse แบบเดิมต้องมี id ที่ตรงกันพร้อม name หากขาดฟิลด์ใดฟิลด์หนึ่ง การสนทนาจะล้มเหลว

ทดสอบทั้งสองเอนด์พอยต์ใน Apidog

เมื่อคำขอทำงานจากเทอร์มินัลแล้ว ให้ ดาวน์โหลด Apidog สร้างโปรเจกต์ และบันทึกทั้งสองเอนด์พอยต์ให้ทีมใช้งานร่วมกัน

1. เก็บ API key ไว้นอกคำขอ

เพิ่ม GEMINI_API_KEY เป็น environment variable แล้วอ้างอิงในส่วนหัว:

x-goog-[REDACTED CREDENTIAL]

คำขอที่บันทึกไว้จะไม่เก็บความลับ และการสลับจากคีย์ฟรีเป็นคีย์แบบชำระเงินทำได้ด้วยการเปลี่ยน environment เพียงครั้งเดียว

2. ยืนยันสถานะและการใช้โทเค็น

เพิ่มการยืนยันว่า HTTP status เป็น 200 และตรวจสอบ JSON path:

usageMetadata.thoughtsTokenCount

กำหนดเพดานต่อพรอมต์เพื่อให้การทดสอบล้มเหลวก่อนเกิดค่าใช้จ่ายที่ไม่คาดคิด หากพรอมต์หรือโมเดลเปลี่ยนแล้วใช้โทเค็นการคิดมากขึ้น

สำหรับการสตรีม อ่าน คู่มือการทดสอบ SSE โดย Apidog จะแสดงสตรีมเป็นเหตุการณ์ที่รวมกันแทนข้อมูลดิบแต่ละส่วน

3. เปรียบเทียบทั้งสามระดับ

ส่งพรอมต์เดียวกันด้วย low, medium และ high แล้วเปรียบเทียบ thoughtsTokenCount กับเวลาตอบสนอง วิธีนี้ให้ตัวเลขจริงของงานคุณ แทนการอ้างอิงค่าเฉลี่ย

4. ตั้งเวลาการทดสอบ

เปลี่ยนคำขอเป็น test scenario แล้วเรียกใช้ตามกำหนดเวลา เพื่อให้เห็นการเปลี่ยนแปลงของข้อจำกัด การตรวจสอบ เช่น การลบ minimal หรือการเพิ่มขึ้นของโทเค็นในรายงานก่อนกระทบโปรดักชัน ดูขั้นตอนได้จาก วิธีตั้งเวลาการทดสอบ API ใน Apidog

Apidog ไม่ได้รันโมเดลหรือแทนที่ SDK แต่ช่วยให้ทีมมีเวอร์ชัน HTTP request ที่บันทึก แชร์ และตรวจสอบได้ ซึ่งเป็นส่วนที่มักถูกข้ามจนกว่าจะเกิดปัญหา

คำถามที่พบบ่อย

โปรเจกต์ใหม่ควรใช้เอนด์พอยต์ใด?

ใช้ Interactions API เพราะ Google ถือว่าเป็น API หลัก ฟีเจอร์ใหม่จะปรากฏที่นี่ก่อน และสถานะฝั่งเซิร์ฟเวอร์ทำให้โค้ดหลายรอบสั้นลง อย่างไรก็ตาม generateContent ยังรองรับอย่างเต็มที่ จึงควรใช้ต่อในบริการเดิมจนกว่าจะมีเหตุผลต้องย้าย

ต้องมีบัญชีแบบชำระเงินหรือไม่?

ไม่จำเป็น คีย์ AI Studio แบบฟรีใช้งานได้ แต่มีข้อจำกัดอัตราการใช้งานและข้อกำหนดการใช้ข้อมูลของ Google อ่าน คู่มือการใช้งานฟรี สำหรับรายละเอียด รวมถึงข้อเท็จจริงว่าแอป Gemini ต้องการแผน AI Pro หรือ Ultra สำหรับ 3.8 Flash

3.8 Flash ช้ากว่า 3.7 Flash หรือไม่?

ไม่ช้ากว่าเมื่อวัดต่อโทเค็น Logan Kilpatrick จาก Google ระบุว่าความเร็วเท่ากัน และ Artificial Analysis วัดได้ประมาณ 300 เอาต์พุตโทเค็นต่อวินาที แต่การรันที่ high ใช้เวลาต่อภารกิจนานกว่า คือ 2.5 นาทีเทียบกับ 2.2 นาที เพราะสร้างโทเค็นมากขึ้น

ยังใช้ Gemini 3.7 Flash ได้หรือไม่?

ได้ Google ระบุว่า 3.7 Flash “ยังคงรองรับอย่างเต็มที่” และยังไม่ประกาศวันเลิกใช้งาน หากโทเค็นที่เพิ่มขึ้นของ 3.8 Flash ไม่ได้ให้ประโยชน์กับงานของคุณ การใช้ 3.7 Flash ต่อไปก็เป็นทางเลือกที่เหมาะสม

3.8 Flash รองรับ Live API หรือการสร้างรูปภาพหรือไม่?

ไม่รองรับ โมเดลนี้สร้างได้เฉพาะข้อความ การสร้างเสียง การสร้างรูปภาพ และ Live API ไม่ได้รับการสนับสนุน ดูข้อแตกต่างเพิ่มเติมใน การเปรียบเทียบ Gemini 3.8 กับ 3.7 Flash

ไปต่อที่ไหนดี

ตอนนี้คุณมีเส้นทางเรียกใช้สองแบบ การสนทนาหลายรอบ และการตรวจสอบการใช้โทเค็นแล้ว ขั้นตอนถัดไปคือ:

เชื่อมต่อเครื่องมือด้วย คู่มือการเรียกใช้ฟังก์ชัน
กำหนดระดับการคิดแยกตามเส้นทางด้วย คู่มือระดับการคิด
อ่าน คู่มือการย้ายจาก 3.7 ไป 3.8 Flash หากยังตัดสินใจไม่ได้ว่าจะย้ายหรือไม่
รัน Apidog scenario ต่อเนื่อง เพื่อให้ค่าใช้จ่ายที่เปลี่ยนแปลงปรากฏเป็นการทดสอบที่ล้มเหลวก่อนกระทบการใช้งานจริง

วิธีใช้ Gemini 3.8 Flash ฟรี?

Thanawat Wongchai — Thu, 03 Sep 2026 05:26:45 +0000

Gemini 3.8 Flash ฟรีจริงหรือไม่? คู่มือเริ่มใช้งาน Gemini API

Gemini 3.8 Flash เปิดตัวเมื่อวันที่ 2 กันยายน 2026 และแตกต่างจากผลิตภัณฑ์ใหม่ส่วนใหญ่ในปีนี้ เพราะมีช่องทางใช้งานฟรีอย่างแท้จริง คุณสามารถสนทนากับโมเดลได้ฟรีใน Google AI Studio หรือเรียกใช้ผ่าน Gemini API ด้วยคีย์ที่สร้างได้ภายในประมาณหนึ่งนาที Google เรียกโมเดลนี้ว่า “โมเดล Flash ที่ฉลาดที่สุดของเรา” และระดับฟรีใช้โมเดล ID เดียวกับลูกค้าที่ชำระเงิน (gemini-3.8-flash) ไม่ใช่เวอร์ชันที่ลดความสามารถ

ลองใช้ Apidog วันนี้

ก่อนเริ่ม มีข้อควรพิจารณาสามข้อ:

ระดับฟรีมีข้อจำกัดอัตราการใช้งาน
Google ระบุว่าข้อมูลจากระดับฟรีอาจถูกใช้เพื่อปรับปรุงผลิตภัณฑ์
แอป Gemini ไม่รวม 3.8 Flash ไว้ในแผนฟรี ต้องใช้ Google AI Pro หรือ Ultra

หากต้องการอ่านข้อมูลจำเพาะก่อน เริ่มจากบทความ Gemini 3.8 Flash คืออะไร แต่ถ้าต้องการส่งคำขอภายในไม่กี่นาที ให้ทำตามขั้นตอนด้านล่าง

การเข้าถึงฟรีโดยสรุป

ช่องทาง	ค่าใช้จ่าย	รวม Gemini 3.8 Flash หรือไม่?	ข้อจำกัด/เงื่อนไข
Google AI Studio (เว็บสำหรับทดลองใช้)	$0	ใช่	จำกัดอัตราการใช้งาน และข้อมูลถูกใช้เพื่อปรับปรุงผลิตภัณฑ์
Gemini API ระดับฟรี	$0	ใช่	ข้อจำกัดเดียวกัน แสดงในหน้าจำกัดอัตราการใช้งานของ AI Studio
แอป Gemini, แผนฟรี	$0	ไม่	3.8 Flash ต้องใช้ Google AI Pro หรือ Ultra
โหมด AI ใน Google Search	$0	ใช่ สำหรับผู้ใช้ทั่วไป	ไม่มี API และควบคุมระดับการคิดไม่ได้
Gemini ใน Google ชีต	ขึ้นอยู่กับแผน	ใช่ สำหรับผู้ใช้ทั่วไป	ไม่มี API
การอ้างอิงข้อมูลจาก Google Search	ฟรี 5,000 คำขอ/เดือน	ใช้ร่วมกันใน Gemini 3.x ทุกรุ่น	หลังจากนั้น $14 ต่อ 1,000 คำขอ
Batch API	ลด 50% จากอัตราปกติ	ใช่	ไม่ฟรี แต่เป็นเส้นทางแบบชำระเงินที่ถูกที่สุด
Gemini 3.8 Flash Cyber	ไม่มีจำหน่าย	ไม่	เฉพาะโครงการ Fairwind และไม่มี API สาธารณะ

ขั้นตอนที่ 1: เปิด AI Studio และเลือก `gemini-3.8-flash`

ไปที่ Google AI Studio และลงชื่อเข้าใช้ด้วยบัญชี Google คุณไม่จำเป็นต้องมีบัญชีเรียกเก็บเงินหรือบัตรเครดิต

ในตัวเลือกโมเดล ให้เลือก gemini-3.8-flash ซึ่งเป็น model ID หลักสำหรับเวอร์ชันใช้งานจริง ไม่ใช่เวอร์ชันพรีวิว

3.8 Flash มีระดับการคิดสามค่า:

low
medium — ค่าเริ่มต้น
high

โมเดลนี้ไม่มี minimal หากส่งค่าดังกล่าวผ่าน API จะได้รับข้อผิดพลาดในการตรวจสอบ แทนที่จะ fallback อย่างเงียบ ๆ อ่านรายละเอียดเพิ่มเติมได้จาก คู่มือระดับการคิดของ Gemini 3.8 Flash

สำหรับการใช้งานฟรี ให้ตั้งค่าดังนี้:

ใช้ temperature ค่าเริ่มต้นที่ 1.0 ตามคำแนะนำของ Google สำหรับ Gemini 3 ทุกรุ่น การลดค่านี้อาจทำให้เกิดลูปหรือผลลัพธ์ด้อยคุณภาพ
เริ่มต้นด้วย thinking_level: low เพื่อประหยัดโควต้า

Gemini 3.8 Flash ถูกออกแบบให้ใช้ขั้นตอนการให้เหตุผลที่เล็กลงและเรียกใช้เครื่องมือซ้ำ ๆ กับงานซับซ้อน Google ระบุว่าโมเดล “สามารถใช้โทเค็นมากขึ้นกับงานที่ใช้เวลานานและซับซ้อนตามการออกแบบ” ดังนั้นระดับ high อาจใช้โควต้าโทเค็นต่อนาทีหมดเร็วกว่าการใช้ Gemini 3.7 Flash

ขั้นตอนที่ 2: รับคีย์ API ฟรี

ใน AI Studio ให้เปิดหน้า API keys แล้วสร้างคีย์ในโปรเจกต์ใหม่หรือโปรเจกต์ที่มีอยู่ คีย์นี้ใช้งานได้ทันทีกับระดับฟรี และ หน้าการกำหนดราคา ระบุว่าอินพุตและเอาต์พุตของ 3.8 Flash เป็น “ฟรี” ในระดับดังกล่าว

หากไม่เคยสร้างคีย์มาก่อน ดู คู่มือการใช้งานคีย์ Gemini API

จัดเก็บคีย์เป็น environment variable อย่าใส่ไว้ในโค้ดหรือประวัติเชลล์:

export GEMINI_API_KEY="paste-your-key-here"

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

ขั้นตอนที่ 3: ส่งคำขอฟรีครั้งแรก

Gemini 3.x ส่วนใหญ่รองรับ Interactions API โดยไม่ต้องติดตั้ง SDK:

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"model":"gemini-3.8-flash","input":"Explain HTTP caching in 3 sentences.","generation_config":{"thinking_level":"low"}}'

การตอบกลับเป็นรายการขั้นตอนการทำงาน เช่น:

การคิดของโมเดล
การเรียกใช้เครื่องมือ หากมี
ขั้นตอน model_output ซึ่งมีข้อความตอบกลับ

หากมีโค้ดที่ใช้ generateContent อยู่แล้ว โค้ดนั้นยังใช้งานได้ Google เรียก API นี้ว่าเป็นเวอร์ชันเก่า แต่ยัง “รองรับอย่างเต็มที่” โดยไม่มีกำหนดสิ้นสุด ในเอนด์พอยต์ดังกล่าว ให้ตั้งระดับผ่าน generationConfig.thinkingConfig.thinkingLevel

ดูตัวอย่างทั้งสองรูปแบบ, Python และการสนทนาหลายรอบด้วย previous_interaction_id ได้จาก คู่มือ Gemini 3.8 Flash API

หากได้รับรหัส 429 แสดงว่าใช้ถึงขีดจำกัดอัตราการใช้งานของระดับฟรีแล้ว ให้รอจนโควต้ารีเซ็ตหรืออ่านส่วน Tier 1 ด้านล่าง

สิ่งที่ต้องแลกกับระดับฟรี

แม้ไม่มีค่าใช้จ่ายเป็นเงิน แต่มีข้อจำกัดสำคัญสามด้าน

1. ข้อจำกัดอัตราการใช้งาน

ระดับฟรีจำกัด:

คำขอต่อนาที
โทเค็นต่อนาที
คำขอต่อวันต่อโมเดล

Google แสดงตัวเลขล่าสุดใน หน้าจำกัดอัตราการใช้งานของ AI Studio ไม่ได้ระบุไว้ตายตัวในเอกสาร และตัวเลขอาจเปลี่ยนแปลงโดยไม่มี changelog ดังนั้นควรตรวจสอบหน้าดังกล่าวโดยตรง โปรดอ่าน เอกสารจำกัดอัตราการใช้งาน เพื่อทำความเข้าใจแต่ละระดับ

2. ข้อมูลของคุณ

Google ระบุว่าคำสั่งและผลลัพธ์จากระดับฟรีอาจถูกใช้เพื่อปรับปรุงผลิตภัณฑ์ เหมาะสำหรับการทดสอบประสิทธิภาพหรืองานต้นแบบ แต่ไม่เหมาะกับ:

ข้อมูลลูกค้า
ซอร์สโค้ดที่ยังไม่เผยแพร่
ข้อมูลภายใต้ข้อตกลง NDA

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

3. การใช้โทเค็น

Artificial Analysis วัด Gemini 3.8 Flash ที่ระดับ high และพบว่าใช้เอาต์พุตประมาณ 48,000 โทเค็นต่อภารกิจ ซึ่งมากกว่า Gemini 3.7 Flash ประมาณ 30%

โทเค็นการคิดถูกนับรวมในขีดจำกัดโทเค็นต่อนาทีเช่นเดียวกับเอาต์พุตที่มองเห็นได้ ดังนั้นโมเดลที่ให้เหตุผลซับซ้อนกว่าจะใช้โควต้าฟรีเร็วกว่า ในทางปฏิบัติ ควรเริ่มที่ low หรือ medium จนกว่าจะเพิ่มขีดจำกัดด้วยบัญชีชำระเงิน

แอป Gemini ไม่ใช่ช่องทางฟรี

ผลการค้นหา “Gemini 3.8 Flash ฟรี” จำนวนมากทำให้เกิดความเข้าใจผิด ในฝั่งผู้ใช้งานทั่วไป 3.8 Flash ในแอป Gemini มีให้เฉพาะสมาชิก Google AI Pro และ Ultra แผนฟรีของแอปไม่ได้รับสิทธิ์นี้ หากเปิดแอปโดยไม่มีสมาชิกและเห็นโมเดล Flash นั่นไม่ใช่ 3.8 Flash

ช่องทางสำหรับผู้ใช้ทั่วไปที่ใช้ 3.8 Flash ได้โดยไม่มีค่าใช้จ่ายเพิ่มเติมคือ:

โหมด AI ใน Google Search
Gemini ใน Google ชีต

ทั้งสองช่องทางเหมาะสำหรับอ่านคำตอบ แต่ไม่มี API ไม่สามารถควบคุมระดับการคิด และไม่สามารถนับโทเค็นได้ หากต้องการพัฒนาแอป AI ให้ใช้ AI Studio หรือ Gemini API ระดับฟรี

การอ้างอิงข้อมูลจาก Google Search ฟรี 5,000 คำขอต่อเดือน

ฟีเจอร์การอ้างอิงข้อมูลจาก Google Search ช่วยให้โมเดลดึงผลลัพธ์เว็บปัจจุบันมาประกอบคำตอบได้ฟรี 5,000 คำขอต่อเดือน และใช้โควต้าร่วมกันใน Gemini 3.x ทุกรุ่น

หลังจากนั้นมีค่าใช้จ่าย $14 ต่อ 1,000 คำขอ โควต้านี้เป็นโควต้ารวมรายเดือน ไม่ได้แยกตามโมเดล ดังนั้นการทดลอง Gemini 3 Pro และ Gemini 3.8 Flash ที่เปิดใช้การอ้างอิงข้อมูลจะใช้โควต้า 5,000 ครั้งเดียวกัน

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

เมื่อโควต้าฟรีหมด: เส้นทางแบบชำระเงินที่ถูกที่สุด

คุณจะสังเกตได้จากรหัส 429 ระหว่างเดโม หรือโควต้ารายวันหมดก่อนจบวัน เส้นทางแบบชำระเงินมีดังนี้

1. ผูกบัญชีเรียกเก็บเงินเพื่อใช้ Tier 1

การผูกบัญชีเรียกเก็บเงินกับโปรเจกต์ใน AI Studio จะย้ายคุณไป Tier 1 ซึ่งเพิ่มขีดจำกัดอัตราการใช้งานและกำหนดเพดานการใช้จ่ายที่ $250

Tier 2: เปิดใช้หลังใช้จ่าย $100 และผ่านไปอย่างน้อย 3 วัน เพดาน $2,000
Tier 3: เปิดใช้หลังใช้จ่าย $1,000 และผ่านไป 30 วัน

คุณไม่จำเป็นต้องใช้จ่ายเพื่อปลดล็อก Tier 1 เพียงผูกบัญชีเรียกเก็บเงินก็เพียงพอ

2. จ่ายตามอัตราปกติ

จนถึงวันที่ 31 ธันวาคม 2026 Gemini 3.8 Flash มีราคา:

อินพุต: $0.75 ต่อล้านโทเค็น
เอาต์พุต: $3.75 ต่อล้านโทเค็น

โทเค็นการคิดจะถูกคิดราคาเป็นเอาต์พุต ตั้งแต่วันที่ 1 มกราคม 2027 ราคาจะเพิ่มเป็นสองเท่า:

อินพุต: $1.50 ต่อล้านโทเค็น
เอาต์พุต: $7.50 ต่อล้านโทเค็น

ตัวอย่าง: 1,000 คำขอ โดยแต่ละคำขอมีอินพุต 2,000 โทเค็นและเอาต์พุต 500 โทเค็น จะมีค่าใช้จ่ายประมาณ $3.38 ตามอัตราปกติ ดูตัวอย่างการคำนวณเพิ่มเติมใน รายละเอียดราคา Gemini 3.8 Flash

3. ใช้ Batch API กับงานที่รอได้

Batch API ลดราคาเหลือครึ่งหนึ่ง:

อินพุต: $0.375 ต่อล้านโทเค็น
เอาต์พุต: $1.875 ต่อล้านโทเค็น

ราคานี้ใช้จนถึงสิ้นปี 2026 ตัวอย่าง 1,000 คำขอเดิมจะมีค่าใช้จ่ายประมาณ $1.69 บัญชี Tier 1 สามารถมีโทเค็นในคิวพร้อมกันได้สูงสุด 3 ล้านโทเค็น

เหมาะสำหรับ:

การประเมินผล
การเติมข้อมูลย้อนหลัง
งานประมวลผลช่วงกลางคืน

ดูรูปแบบคำขอได้จาก คู่มือ Gemini Batch Mode

4. แคชบริบทที่ใช้ซ้ำ

Context caching มีค่าใช้จ่าย $0.075 ต่อล้านโทเค็นที่แคช หรือประมาณหนึ่งในสิบของราคาอินพุตใหม่ เหมาะกับ:

system prompt ขนาดยาว
เอกสารที่ส่งซ้ำทุกคำขอ
บริบทคงที่ที่ใช้กับหลายงาน

สิ่งที่ระดับฟรีไม่มีให้

แอป Gemini: 3.8 Flash ใช้ได้เฉพาะสมาชิก Pro หรือ Ultra
ความเป็นส่วนตัว: ข้อมูลจากระดับฟรีอาจถูกใช้เพื่อปรับปรุงผลิตภัณฑ์ของ Google และไม่มีสวิตช์ปิดการใช้งาน
ขีดจำกัดสูง: ระดับฟรีเหมาะกับการประเมินและเครื่องมือขนาดเล็ก ไม่ใช่การเปิดตัวระบบจริง
Gemini 3.8 Flash Cyber: โมเดลที่ปรับแต่งด้านความปลอดภัยนี้จำกัดอยู่ในโครงการ Fairwind สำหรับหน่วยงานรัฐบาล ผู้ให้บริการโครงสร้างพื้นฐาน และผู้ดูแลซอฟต์แวร์ ไม่มี API สาธารณะ ไม่มีราคา และไม่มีตัวเลือก self-hosted
Live API, การสร้างภาพ และการสร้างเสียง: Gemini 3.8 Flash ไม่รองรับสิ่งเหล่านี้ในทุกระดับ อินพุตรองรับข้อความ รูปภาพ วิดีโอ เสียง และ PDF ส่วนเอาต์พุตเป็นข้อความ
ระดับ “ไม่จำกัด”: เว็บไซต์ที่โฆษณาการเข้าถึง Gemini แบบไม่จำกัดอาจใช้คีย์ของผู้อื่นหรือให้บริการโมเดลอื่น อ่าน คู่มือการเข้าถึง Gemini API ฟรี เพื่อแยกแยะข้อเสนอเหล่านี้ กลยุทธ์ระดับฟรีที่ใช้กับ Gemini 3.6 Flash ยังคงใช้ได้ที่นี่

ใช้ Apidog เพื่อยืดอายุโควต้าฟรี

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

แนวทางที่แนะนำ:

เก็บ GEMINI_API_KEY เป็น environment variable ใน Apidog เพื่อไม่ให้คีย์ปรากฏใน request หรือคอลเลกชันที่แชร์
บันทึก Interactions API และ generateContent เป็นคำขอที่มีชื่อ
เก็บ prompt, model และ thinking_level ไว้ในตัวแปร เพื่อสลับระดับโดยไม่ต้องแก้ JSON
เพิ่มการตรวจสอบ status code เพื่อให้ 429 ปรากฏเป็นข้อผิดพลาดในการทดสอบ แทนที่จะกลายเป็นผลลัพธ์ว่างเปล่า
สำหรับเอนด์พอยต์เก่า เพิ่มการตรวจสอบ usageMetadata.thoughtsTokenCount เพื่อดูว่าโควต้าถูกใช้กับการคิดไปเท่าไร
ตั้งเวลา smoke test ขนาดเล็ก เช่น คำขอระดับ low วันละหนึ่งครั้ง เพื่อแจ้งเตือนเมื่อพฤติกรรมของโมเดลหรือขีดจำกัดฟรีเปลี่ยนแปลง

ดาวน์โหลด Apidog เพื่อเริ่มตั้งค่า และอ่าน วิธีกำหนดเวลาการทดสอบ API ใน Apidog สำหรับตัวเลือกการตั้งเวลา

คำถามที่พบบ่อย

Gemini 3.8 Flash ฟรีหรือไม่?

ฟรีผ่าน Google AI Studio และ Gemini API ระดับฟรี โดยมีข้อจำกัดอัตราการใช้งาน และข้อมูลของคุณอาจถูกใช้เพื่อปรับปรุงผลิตภัณฑ์ของ Google โมเดลคือ gemini-3.8-flash เดียวกับที่ใช้ในระดับชำระเงิน

ใช้ Gemini 3.8 Flashสมัครสมาชิก

ข้อจำกัดอัตราการใช้งานระดับฟรีคือเท่าไร?

Google แสดงข้อจำกัดแยกตามโมเดลในหน้าจำกัดอัตราการใช้งานของ AI Studio ตัวเลขอาจเปลี่ยนแปลงได้ จึงควรตรวจสอบข้อมูลสำหรับโปรเจกต์ของคุณโดยตรง หากต้องการเพิ่มขีดจำกัด ให้ผูกบัญชีเรียกเก็บเงินเพื่อย้ายไป Tier 1 โดยไม่จำเป็นต้องใช้จ่ายก่อน

ระดับฟรีรวมการคิดหรือไม่?

รวม ทั้ง low, medium และ high ใช้งานได้ในระดับฟรี โดย medium เป็นค่าเริ่มต้น ส่วน minimal จะส่งคืนข้อผิดพลาดบน 3.8 Flash เพราะโทเค็นการคิดถูกนับรวมในขีดจำกัดโทเค็น การใช้ low ช่วยยืดโควต้าได้มากที่สุด

Gemini 3.8 Flash Cyber ฟรีหรือไม่?

ไม่มีให้ใช้งานนอกโครงการ Fairwind นักพัฒนาทั่วไปใช้ Gemini 3.8 Flash และทดสอบความปลอดภัยของ API ของตนเองได้ แต่ไม่สามารถเข้าถึง Flash Cyber ได้

เริ่มฟรี แล้วค่อยตัดสินใจ

ระดับฟรีเป็นสภาพแวดล้อมสำหรับประเมิน Gemini 3.8 Flash อย่างจริงจัง ไม่ใช่เพียงเดโมทดลอง ใช้คีย์ API ตั้งระดับการคิดเป็น low หลีกเลี่ยงข้อมูลละเอียดอ่อน และตรวจสอบหน้าจำกัดอัตราการใช้งานแทนการคาดเดา

เมื่อรหัส 429 เริ่มรบกวนการทำงาน ให้ผูกบัญชีเรียกเก็บเงินเพื่อใช้ Tier 1 และย้ายงานแบบอะซิงโครนัสไปยัง Batch API ด้วยราคาอินพุต $0.375 ต่อล้านโทเค็นจนถึงเดือนธันวาคม ค่าใช้จ่ายเดือนแรกอาจน้อยกว่ากาแฟที่คุณดื่มระหว่างรอให้โควต้าฟรีรีเซ็ต

วิธีใช้งาน Gemini Omni 1.1 Flash API

Thanawat Wongchai — Thu, 03 Sep 2026 05:22:59 +0000

เรียกใช้ Gemini Omni 1.1 Flash Video API ด้วย Interactions API

คุณเรียกใช้ Gemini Omni 1.1 Flash ด้วย model id gemini-omni-1.1-flash ผ่าน Google’s Interactions API ไม่ใช่ generateContent endpoint สำหรับโมเดลข้อความ หากคัดลอกตัวอย่างของ Gemini แล้วเปลี่ยนชื่อโมเดล คุณจะได้รับข้อผิดพลาด 404

ลองใช้ Apidog วันนี้

คู่มือนี้จะพาคุณตั้งแต่การเตรียมสภาพแวดล้อม ไปจนถึงการส่งคำขอสร้างวิดีโอด้วย curl, Python และ JavaScript รวมถึงการจัดการการตอบกลับแบบ base64 และ URI และการสร้างชุดทดสอบที่ทำซ้ำได้

โมเดลนี้เปิดตัวสู่สาธารณะ (GA) เมื่อวันที่ 27 สิงหาคม 2026 อ่านรายละเอียดเพิ่มเติมได้ที่ มีอะไรใหม่ใน Gemini Omni 1.1 Flash

สิ่งที่ต้องมีก่อนเริ่มต้น

บัญชี Google สำหรับลงชื่อเข้าใช้ AI Studio
คีย์ Gemini API จาก Google AI Studio
เปิดใช้งานการเรียกเก็บเงิน Omni ไม่มี free tier ต่างจาก ช่องทางฟรีสำหรับโมเดลข้อความ ดังนั้นคำขอแรกจะมีค่าใช้จ่าย
เครื่องมือส่งคำขอ HTTP เช่น curl, Python SDK หรือไคลเอนต์ API

เก็บคีย์ไว้ในตัวแปรสภาพแวดล้อมแทนการฝังไว้ในซอร์สโค้ด:

export GEMINI_API_KEY="your_key_here"

SDK อย่างเป็นทางการจะอ่านตัวแปรนี้เอง ช่วยป้องกันไม่ให้คีย์รั่วไหลไปยัง repository

ส่งคำขอสร้างวิดีโอครั้งแรก

ส่งคำขอแบบ POST ไปยัง /v1beta/interactions:

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions?key=$GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-omni-1.1-flash",
    "input": "A marble rolling fast on a chain reaction style track, continuous smooth shot."
  }'

คำขอขั้นต่ำมีเพียงสองฟิลด์คือ model และ input การตอบกลับจะมีวิดีโอในรูปแบบ base64 ที่ output_video.data

Python

ติดตั้ง SDK:

pip install google-genai

จากนั้นสร้างและบันทึกวิดีโอ:

import base64
from google import genai

client = genai.Client()  # reads GEMINI_API_KEY from the environment

interaction = client.interactions.create(
    model="gemini-omni-1.1-flash",
    input="A marble rolling fast on a chain reaction style track, continuous smooth shot.",
)

with open("marble.mp4", "wb") as f:
    f.write(base64.b64decode(interaction.output_video.data))

JavaScript

ใช้แพ็กเกจ @google/genai:

import { GoogleGenAI } from '@google/genai';
import * as fs from 'fs';

const ai = new GoogleGenAI({});

const interaction = await ai.interactions.create({
  model: 'gemini-omni-1.1-flash',
  input: 'A marble rolling fast on a chain reaction style track, continuous smooth shot.',
});

if (interaction.output_video?.data) {
  fs.writeFileSync('marble.mp4', Buffer.from(interaction.output_video.data, 'base64'));
}

การสร้างวิดีโอใช้เวลา โดยขึ้นอยู่กับระยะเวลา ความละเอียด และโหลด API ปัจจุบัน ควรกำหนด client timeout ให้ยาวพอ อย่าเพิ่งสรุปว่าคำขอล้มเหลวเพียงเพราะใช้เวลานาน

ควบคุมความละเอียดและอัตราส่วนภาพ

กำหนดรูปแบบเอาต์พุตผ่าน response_format:

interaction = client.interactions.create(
    model="gemini-omni-1.1-flash",
    input="A drone shot of a mountain landscape at sunrise.",
    response_format={
        "type": "video",
        "aspect_ratio": "16:9",
        "resolution": "1080p",
    },
)

ค่าที่รองรับ:

ฟิลด์	ค่า	ค่าเริ่มต้น
`type`	`video`	`video`
`aspect_ratio`	`16:9`, `9:16`	`16:9`
`resolution`	`360p`, `720p`, `1080p`, `4k`	`720p`
`delivery`	base64 แบบอินไลน์, `uri`	อินไลน์

การสร้างวิดีโอร่างที่ 360p เร็วกว่า 720p ได้ถึง 60% และมีค่าใช้จ่ายเพียงหนึ่งในสาม คุณจึงสามารถลองพรอมต์ 15 ครั้งด้วยต้นทุนใกล้เคียงกับการสร้าง 5 ครั้งในอดีต

ใช้ความละเอียดสูงขึ้นสำหรับวิดีโอฉบับสุดท้าย โดย 1080p และ 4k เป็นการเพิ่มสเกลของเฟรมที่สร้างขึ้น ไม่ใช่การเรนเดอร์แบบเนทีฟ ดู รายละเอียดราคา Gemini Omni 1.1 Flash เพื่อดูค่าใช้จ่ายต่อวินาทีของแต่ละระดับ

พารามิเตอร์ที่ไม่รองรับ

Gemini Omni 1.1 Flash ไม่มีพารามิเตอร์ต่อไปนี้:

System instructions
temperature
top_p
Stop sequences
Negative prompt

หากต้องการยกเว้นบางสิ่ง ให้เขียนไว้ในพรอมต์โดยตรง เช่น:

ใช้ภาพวาดเป็นเพียงแนวทางสำหรับการเคลื่อนไหวเท่านั้น ห้ามแสดงภาพวาดในวิดีโอสุดท้าย

อินพุตภาพ คีย์เฟรม และวิดีโออ้างอิง

เมื่อรวมสื่อ ให้ส่ง input เป็นรายการแทนสตริง ตัวอย่าง image-to-video:

interaction = client.interactions.create(
    model="gemini-omni-1.1-flash",
    input=[
        {"type": "image", "data": base64_image, "mime_type": "image/jpeg"},
        {"type": "text", "text": "turn this into realistic footage, using the drawing only as a guide for movement, do not show the drawing in the final video"},
    ],
)

ส่งภาพสองภาพเพื่อกำหนดเฟรมแรกและเฟรมสุดท้าย โมเดลจะสร้างการเคลื่อนไหวระหว่างภาพ:

interaction = client.interactions.create(
    model="gemini-omni-1.1-flash",
    input=[
        {"type": "image", "data": first_frame_b64, "mime_type": "image/jpeg"},
        {"type": "image", "data": last_frame_b64, "mime_type": "image/jpeg"},
        {"type": "text", "text": "A smooth cinematic transition from a lush green forest at sunrise to a snowy forest under a starry night sky."},
    ],
)

การอ้างอิงวิดีโอทำงานผ่าน Files API โดยรองรับสูงสุด 3 คลิป คลิปละ 3 วินาที เสียงในคลิปจะถูกละเว้น โมเดลจะใช้คลิปเพื่อทำความเข้าใจการเคลื่อนไหวและลักษณะที่ปรากฏ

แก้ไขวิดีโอแบบหลายขั้นตอน

Omni รองรับการแก้ไขแบบสนทนา โดยส่ง previous_interaction_id ของการโต้ตอบก่อนหน้า:

res1 = client.interactions.create(
    model="gemini-omni-1.1-flash",
    input="A woman playing violin outdoors.",
)

res2 = client.interactions.create(
    model="gemini-omni-1.1-flash",
    previous_interaction_id=res1.id,
    input="Make the violin invisible.",
)

ไม่ต้องอัปโหลดใหม่หรืออธิบายฉากทั้งหมดอีกครั้ง กลไกเดียวกันนี้ใช้กับการขยายฉาก ซึ่งอธิบายไว้ใน คู่มือการขยายฉาก 40 วินาที

จัดการวิดีโอที่มีขนาดเกิน 4MB

ไฟล์ที่มีขนาดใหญ่กว่า 4MB จะถูกส่งกลับเป็น URI แทน base64 แบบอินไลน์ และต้องรอให้ไฟล์ประมวลผลเสร็จก่อนดาวน์โหลด

ปัญหาที่พบบ่อยเมื่อใช้ 1080p คือโค้ดอ่านเฉพาะ output_video.data แล้วไม่พบข้อมูล ทำให้รายงานความล้มเหลวแบบเงียบๆ วิธีที่ชัดเจนกว่าคือขอให้ส่งแบบ URI และตรวจสอบสถานะ:

import time
from google import genai

client = genai.Client()

interaction = client.interactions.create(
    model="gemini-omni-1.1-flash",
    input="A beautiful sunset.",
    response_format={"type": "video", "delivery": "uri"},
)

video_output = interaction.output_video
file_name = video_output.uri.split("/")[-1]

while True:
    f_info = client.files.get(name=f"files/{file_name}")
    if f_info.state.name == "ACTIVE":
        break
    if f_info.state.name == "FAILED":
        raise RuntimeError("Generation failed.")
    time.sleep(5)

video_bytes = client.files.download(file=video_output.uri)
with open("output.mp4", "wb") as f:
    f.write(video_bytes)

ตัวจัดการการตอบกลับควรรองรับทั้ง output_video.data และ output_video.uri ตั้งแต่แรก เพราะความละเอียดอาจทำให้รูปแบบการส่งมอบเปลี่ยนไป

ทดสอบคำขอด้วย Apidog

เมื่อคำขอทำงานแล้ว สิ่งสำคัญคือการตรวจจับการเปลี่ยนแปลงของ endpoint ที่มีราคาแพง ใช้เวลานาน และให้ผลลัพธ์ไม่แน่นอน คำสั่ง curl ชั่วคราวใน shell history ไม่เพียงพอสำหรับงานนี้

ตั้งค่าใน Apidog:

สร้างโปรเจกต์และสภาพแวดล้อม เพิ่ม GEMINI_API_KEY และ MODEL_ID เป็นตัวแปรสภาพแวดล้อม เพื่อไม่ให้คีย์ถูกบันทึกไว้ในคำขอ
สร้างคำขอ POST ไปยัง https://generativelanguage.googleapis.com/v1beta/interactions
ใส่ JSON body ที่มี model และ input โดยอ้างอิงโมเดลด้วย {{MODEL_ID}}
เพิ่ม timeout ที่ยาวพอ เพราะการสร้างวิดีโอช้ากว่าการสร้างข้อความมาก
เพิ่ม assertions เพื่อตรวจสอบ status code, การมีอยู่ของ output_video และรูปแบบการตอบกลับที่คาดหวัง
สร้างชุดทดสอบแยกสำหรับ text-to-video, image-to-video และ extension

Assertions ควรตรวจจับได้ว่าการตอบกลับเปลี่ยนจาก inline เป็น URI หรือไม่ เมื่อ Google เปิดตัว Omni 1.2 คุณจะสามารถเรียกใช้ทั้งสามคำขอและตรวจสอบความเปลี่ยนแปลงได้ภายในไม่กี่นาที

Apidog ไม่ได้สร้างวิดีโอและไม่ใช่เฟรมเวิร์ก AI แต่เป็นเครื่องมือสำหรับสร้าง ส่ง และตรวจสอบคำขอให้เป็นไปตามมาตรฐานที่กำหนด หากต้องการเตรียมเครื่องมือก่อนขยายการใช้งาน ให้ ดาวน์โหลด Apidog

ข้อผิดพลาดที่พบบ่อย

404 จาก endpoint — คุณกำลังเรียก /v1beta/models/gemini-omni-1.1-flash:generateContent ให้เปลี่ยนเป็น /v1beta/interactions และใส่โมเดลไว้ใน body
output_video.data ว่างเปล่า — การตอบกลับใช้ URI เพราะวิดีโอมีขนาดเกิน 4MB ให้อ่าน output_video.uri แล้วดาวน์โหลดผ่าน Files API
ไม่พบโมเดล — ตรวจสอบการตั้งค่า gemini-omni-flash-preview ซึ่ง endpoint นี้จะเลิกใช้งานในวันที่ 30 กันยายน 2026
แก้ไขวิดีโอที่อัปโหลดไม่สำเร็จ — ฟีเจอร์นี้ไม่พร้อมใช้งานใน EEA, สวิตเซอร์แลนด์ และสหราชอาณาจักร แต่วิดีโอที่สร้างโดยโมเดลยังใช้งานได้
คำขอขยายถูกปฏิเสธ — วิดีโออินพุตจำกัดที่ 10 วินาที การขยายทำได้เฉพาะส่วนท้าย และไม่สามารถเพิ่มบทสนทนาเมื่อขยายวิดีโอที่อัปโหลด

คำถามที่พบบ่อย

Gemini Omni ใช้ endpoint ใด?

ใช้ POST https://generativelanguage.googleapis.com/v1beta/interactions โดยใส่ gemini-omni-1.1-flash ใน body

Gemini Omni API มี free tier หรือไม่?

ไม่มี การสร้างทุกครั้งมีค่าใช้จ่าย เฉพาะโมเดลข้อความเท่านั้นที่มีช่องทางฟรีใน AI Studio

ตั้งค่า temperature หรือ negative prompt ได้หรือไม่?

ไม่ได้ System instructions, temperature, top_p, stop sequences และ negative prompts ไม่รองรับ ให้ใส่ข้อจำกัดไว้ในพรอมต์

สร้างวิดีโอแนวตั้งได้อย่างไร?

ตั้งค่า aspect_ratio เป็น 9:16 ใน response_format

วิดีโอมีลายน้ำหรือไม่?

มี เอาต์พุตทั้งหมดมี SynthID ซึ่งผู้ชมมองไม่เห็น แต่สามารถตรวจจับได้ด้วยโปรแกรม

Gemini Omni เปรียบเทียบกับ Veo API อย่างไร?

เป็นคนละ endpoint มีราคาและจุดแข็งแตกต่างกัน อ่าน Omni 1.1 Flash vs Veo 3.1 สำหรับข้อดีข้อเสีย และดูรายละเอียดการผสานรวมใน คู่มือ Veo 3.1 API

การผสานรวมพื้นฐานมีเพียงสองฟิลด์ที่จำเป็น พร้อมตัวจัดการการตอบกลับที่รองรับทั้ง inline และ URI เริ่มจาก 360p ให้ทำงานได้ก่อน บันทึกคำขอพร้อม assertions แล้วจึงเพิ่มความละเอียดเมื่อระบบเสถียร

อ่าน เอกสารทางการของ Omni สำหรับรายการพารามิเตอร์ล่าสุดที่อาจมีการเปลี่ยนแปลง

Claude Fable 5.1 ระบบความคิดที่เก็บรักษา: วิธีแก้ไข บล็อกถูกผูกกับบทสนทนาอื่น

Thanawat Wongchai — Wed, 02 Sep 2026 04:52:02 +0000

แก้ข้อผิดพลาด `thinking block` ผูกกับบทสนทนาอื่นใน Claude Fable 5.1

หากย้าย Agent harness ไปใช้ Claude Fable 5.1 แล้วพบข้อผิดพลาด 400 ที่ระบุว่า thinking block “ผูกกับบทสนทนาอื่น” แสดงว่าโค้ดกำลังแก้ไขประวัติการสนทนาระหว่างคำขอ คู่มือนี้อธิบายการตรวจสอบดังกล่าว สาเหตุ วิธีแก้ฉุกเฉิน และรูปแบบ append-only ที่ช่วยรักษาทั้งการใช้เหตุผลและ prompt cache

ลองใช้ Apidog วันนี้

การตรวจสอบนี้มีเอกสารอ้างอิงในหัวข้อ preserved thinking และ มีอะไรใหม่ใน Claude Fable 5.1 โดยเป็นหนึ่งในสามการเปลี่ยนแปลงสำคัญของ Fable 5.1 และเป็นข้อเดียวที่อาจทำให้ harness ประสิทธิภาพลดลงโดยไม่แจ้งให้ทราบ สำหรับการเปลี่ยนแปลงอีกสองข้อ ดู คู่มือการย้ายระบบ

ข้อผิดพลาดที่พบ

messages.5.content.0: Invalid `signature` in `thinking` block. The block is bound to a different conversation. Remove the block, or set `thinking.block_binding.prefix_mismatch_behavior` to "drop_block". That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header.

นี่คือข้อผิดพลาด 400 invalid_request_error ซึ่งเกิดขึ้นก่อนที่โมเดลจะสร้างผลลัพธ์ การส่งคำขอเดิมซ้ำจะล้มเหลวเหมือนเดิม

Path messages.5.content.0 ชี้ไปยัง thinking block แรกที่ไม่ตรงกันอีกต่อไป และข้อความอาจระบุข้อความแรกที่มีการเปลี่ยนแปลง ซึ่งเป็นข้อมูลสำคัญสำหรับการวินิจฉัย Endpoint สำหรับนับโทเค็นจะทำการตรวจสอบเดียวกันนี้ด้วย

กรณีที่ดูคล้ายกันแต่ไม่ใช่ปัญหาเดียวกัน คือข้อความนำหน้าตรงกันแต่ไม่มีประโยคว่า “ผูกกับบทสนทนาอื่น” กรณีนั้นหมายถึงลายเซ็นถูกแก้ไขหรือถอดรหัสไม่ได้ และ prefix_mismatch_behavior ไม่สามารถแก้ไขได้

การตรวจสอบนี้ทำงานอย่างไร

thinking block ทุกอันของ Fable 5.1 จะมีลายเซ็นที่บันทึกไว้สองส่วน:

โมเดลที่สร้าง block
conversation prefix ที่อยู่ก่อนหน้า block แบบตรงกันทุกไบต์

Prefix ประกอบด้วย:

system prompt ระดับบนสุด
tools array
ทุกข้อความก่อนหน้า block
ความเชื่อมโยงกับ thinking block ก่อนหน้า

เมื่อส่ง transcript กลับไปยัง API ระบบจะตรวจสอบว่า prefix ตรงกับ prefix ตอนสร้าง block แบบ byte-identical หรือไม่

Anthropic ระบุเหตุผลหลักสองข้อ:

ป้องกันการบิดเบือนข้อมูล (anti-distillation): บัญชี API ใหม่จะไม่สามารถแก้ไขบริบทก่อนหน้าของ Claude เองในการสนทนาแบบหลายเทิร์น ขณะยังคงเก็บ transcript ของความคิดเดิมไว้ได้
รักษาพฤติกรรมของ prompt cache: การแก้ไขที่ทำให้การตรวจสอบล้มเหลวจะทำให้ cache เริ่มต้นใหม่ด้วย ดังนั้น harness ที่ผ่านการตรวจสอบจึงยังอ่าน cache ได้ในราคา $0.25 ต่อล้านโทเค็น ในแต่ละเทิร์น

ใครได้รับผลกระทบ

บังคับใช้โดยค่าเริ่มต้น

บัญชีที่สร้างในหรือหลังวันที่ 31 สิงหาคม 2026 บนแพลตฟอร์มต่อไปนี้:

Claude API
Amazon Bedrock
Google Cloud
Microsoft Foundry

บันทึกไว้แต่ยังไม่บังคับใช้

บัญชีที่สร้างก่อนหน้านี้จะบันทึกความไม่ตรงกัน แต่จะบังคับใช้เมื่อคำขอตั้งค่า thinking.block_binding.prefix_mismatch_behavior เป็นค่าใดค่าหนึ่ง รวมถึง "error"

Anthropic ระบุว่าโมเดลในอนาคตจะบังคับใช้การตรวจสอบนี้กับทุกบัญชี

ไม่ได้รับผลกระทบ

Claude Code
claude.ai
Claude Managed Agents
Claude Agent SDK

บริการเหล่านี้จะรักษา prefix ให้คงเดิม อย่างไรก็ตาม Claude Mythos 5.1 ไม่มีการตรวจสอบ conversation prefix แม้การแก้ไขประวัติยังทำให้ cache เริ่มต้นใหม่ได้

ได้รับผลกระทบโดยตรง

โค้ดใดก็ตามที่สร้าง messages array เอง เช่น:

custom agent loop
chat backend
framework ที่ครอบ Messages API

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

หากต้องการตรวจสอบว่าบัญชีถูกบังคับใช้หรือไม่ ให้ส่งคำขอที่แก้ไขประวัติโดยไม่ใส่ beta header หากได้รับข้อผิดพลาด 400 ที่ระบุว่าต้องใช้ header แสดงว่าบัญชีนั้นถูกบังคับใช้แล้ว

สิ่งที่ทำให้ thinking block ใช้ไม่ได้

การเปลี่ยนแปลงต่อไปนี้จะทำให้ block ที่ตามมาไม่ตรงกับ prefix เดิม:

แก้ไข จัดลำดับใหม่ หรือลบเทิร์นก่อนหน้า
ลบผลลัพธ์ของเครื่องมือเก่า
ตัดเทิร์นออกจากกลาง transcript
ใช้ client-side compaction ที่เก็บเทิร์นล่าสุดไว้หลัง summary
แทรกเนื้อหาที่ไม่ได้มีอยู่ในคำขอก่อนหน้า เช่น turn notification, status bar หรือจำนวนโทเค็นคงเหลือที่เปลี่ยนทุกเทิร์น
สร้างหรือเปลี่ยน system prompt หรือ tools ระหว่างคำขอ
อัปเดตวันที่ปัจจุบันใน system prompt
เพิ่มหรือลบเครื่องมือระหว่างเซสชัน
URL รูปภาพหรือเอกสารให้ไบต์ต่างกันในภายหลัง

ระบบผูกกับ ไบต์ของเนื้อหา ไม่ใช่ URL ดังนั้น signed URL ที่เปลี่ยนไปแต่ส่งไฟล์ไบต์เดิมจึงไม่ใช่ปัญหา

การลบ thinking block ทำได้เฉพาะจากด้านหน้า โดยเริ่มจาก block ที่เก่าที่สุด หากลบ block จากตรงกลาง block หลังจากนั้นจะไม่ถูกต้อง

สิ่งที่ยังทำได้โดยไม่ทำให้ prefix เสีย

ใช้ประวัติแบบ append-only
เพิ่มข้อความ role: "system" โดยไม่แก้ไขข้อความเดิม
ลบ thinking block ที่อยู่ด้านหน้า โดยเริ่มจาก block ที่เก่าที่สุด
เปลี่ยนพารามิเตอร์อื่นนอกเหนือจาก system, tools และ messages เช่น:
- max_tokens
- output_config
- effort
- tool_choice
- metadata
เพิ่ม ย้าย หรือลบ cache_control markers
ใช้ server-side compaction และ server-side context editing

การบีบอัดข้อมูลฝั่งเซิร์ฟเวอร์เกิดขึ้นหลังการตรวจสอบ โดย API จะเปรียบเทียบ transcript ที่คุณส่งเข้ามา ไม่ใช่สำเนาที่เซิร์ฟเวอร์แก้ไข หลัง compaction แล้ว prefix ที่ตรวจสอบจะเริ่มจาก compaction block

วิธีแก้ฉุกเฉินด้วย `drop_block`

ส่ง beta header และกำหนดค่าอย่างชัดเจน:

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={"type": "adaptive", "block_binding": {"prefix_mismatch_behavior": "drop_block"}},
    betas=["thinking-binding-controls-2026-08-01"],
    messages=history,
)
for t in response.input_transformations or []:
    print(t.type, t.path, t.reason)

เมื่อใช้ "drop_block" API จะละทิ้ง block ที่ไม่ตรงกันตัวแรก รวมถึง thinking block ที่ตามมา จากนั้นดำเนินการตามคำขอต่อ และรายงานแต่ละ block ใน input_transformations ระดับบนสุด:

"input_transformations": [
  {
    "type": "thinking_dropped",
    "path": "messages.1.content.0",
    "reason": "prefix_binding_mismatch"
  }
]

ข้อควรระวัง:

ค่านี้มีผลเฉพาะคำขอปัจจุบัน ควรส่งต่อเนื่องตลอดเซสชัน
บัญชีที่ถูกบังคับใช้จะเกิดข้อผิดพลาดหากไม่มี header ส่วนการส่ง header เพียงอย่างเดียวจะใช้ค่าเริ่มต้นของ beta ซึ่งคือ drop_block
ควรกำหนดค่าอย่างชัดเจน อย่าพึ่งพาค่าเริ่มต้น
การส่ง block_binding โดยไม่มี header จะทำให้เกิดข้อผิดพลาด:

block_binding: Extra inputs are not permitted

ค่า reason แยกได้สองกรณี:

prefix_binding_mismatch: ประวัติการสนทนาถูกเปลี่ยน
model_binding_mismatch: โมเดลเปลี่ยน เช่น router, retry หรือ fallback ทำให้โมเดลเป้าหมายอ่าน Fable 5.1 block ไม่ได้ กรณีนี้ไม่ใช่ข้อบกพร่องของการจัดการประวัติ

เมื่อส่ง header ทุก response จะมี input_transformations array ซึ่งจะเป็น array ว่างหากไม่มี block ถูกละทิ้ง

ใช้ drop_block เป็นเครื่องมือวินิจฉัยและ safety net ไม่ใช่รูปแบบการทำงานถาวร หากต้องละทิ้ง block ทุกเทิร์น โมเดลจะสูญเสียการใช้เหตุผลเดิม และ prompt cache จะเริ่มต้นใหม่ทุกเทิร์น ส่งผลให้ค่าใช้จ่ายต่อภารกิจเพิ่มขึ้น

การกู้คืนบนแพลตฟอร์มที่ไม่มี beta control

Microsoft Foundry ยังไม่มีตัวควบคุมนี้เมื่อเปิดตัว ส่วน Bedrock และ Google Cloud กำลังเพิ่มการรองรับตามโมเดล

วิธีกู้คืนคือ:

ลบ thinking และ redacted_thinking blocks ทั้งหมดออกจาก history
เก็บเฉพาะ text และ tool_use blocks ของแต่ละเทิร์น
ส่งคำขอเดิมอีกครั้งหนึ่งครั้ง

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

ขั้นตอนตรวจสอบก่อนเปลี่ยนทราฟฟิก

ทำการตรวจสอบก่อนนำ Fable 5.1 ไปใช้จริง:

1. บันทึกคำขอจริง

บันทึก request payload ที่ harness ส่งในเซสชันปกติหลายเทิร์น รวมถึง compaction และการเปลี่ยนเครื่องมือ หากผลิตภัณฑ์รองรับ

เปรียบเทียบคำขอที่ต่อเนื่องกันในส่วนต่อไปนี้:

system prompt
tools array
prefix ที่ใช้ร่วมกันของ messages

ข้อมูลเหล่านี้ควรตรงกันทุกไบต์จนถึงเทิร์นใหม่ที่ถูกเพิ่มเข้ามา

2. ทดสอบด้วย `drop_block`

รัน multi-turn session ด้วย claude-fable-5-1 และตั้งค่า:

beta header: thinking-binding-controls-2026-08-01
prefix_mismatch_behavior: "drop_block"

บันทึก input_transformations จากทุก response:

array ว่างทุกเทิร์น: history ยังคงสมบูรณ์
มี prefix_binding_mismatch: เนื้อหาก่อน block ที่ระบุใน path เปลี่ยนแปลง

วิธีนี้ใช้ได้กับทุกบัญชี เพราะการกำหนด field จะเปิดใช้การบังคับตรวจสอบ สำหรับ CI ให้ใช้ "error" เพื่อให้การแก้ไขประวัติทำให้การทดสอบล้มเหลวทันที

ใน Apidog ให้สร้างการทดสอบสองคำขอ:

ส่งหนึ่งเทิร์น
แก้ไข system prompt
ส่งเทิร์นถัดไปพร้อม header
ตรวจสอบ input_transformations

เก็บการทดสอบไว้ใน collection เพื่อให้รันซ้ำได้ทุกครั้งที่แก้ไข harness สามารถ ดาวน์โหลด Apidog เพื่อสร้างชุดทดสอบนี้

3. เลือก policy สำหรับ production

กำหนดค่าอย่างชัดเจนภายใต้ header:

"error" เมื่อ prefix mismatch ถือเป็นข้อบกพร่องที่ต้องหยุดการทำงาน
"drop_block" เมื่อต้องการให้ระบบทำงานต่อ แม้ประสิทธิภาพการใช้เหตุผลลดลง

ไม่ว่าจะเลือกค่าใด ให้ตรวจสอบทั้ง 400 errors และ input_transformations entries อย่าปล่อย field นี้ว่างในบัญชีเก่า เพราะระบบจะบันทึกความไม่ตรงกันไว้ฝั่งเซิร์ฟเวอร์เท่านั้น

ทำให้ harness เป็นแบบ `append-only`

สิ่งที่ควรหลีกเลี่ยง	วิธีทำแบบ append-only
แก้ system prompt กลางเซสชัน เช่น วันที่หรือโหมดใหม่	ตรึง system prompt ไว้ตอนเริ่มต้น แล้วเพิ่ม `{"role": "system", "content": "The current date is 2026-09-14."}` ณ จุดที่การเปลี่ยนแปลงมีผล ข้อความนี้จะกลายเป็นส่วนหนึ่งของ prefix หลังจากนั้น
แก้ `tools` array กลางเซสชัน	ประกาศเครื่องมือทั้งหมดตั้งแต่เริ่มต้น และใช้ `defer_loading: true` สำหรับเครื่องมือที่โหลดภายหลัง หรือส่ง `tool_addition` และ `tool_removal` blocks ใน system message ด้วย beta `mid-conversation-tool-changes-2026-07-01`
แทรก turn notification แล้วลบในคำขอถัดไป	ใช้ turn-scoped system message: `{"role": "system", "clear_at": "next_user_message", "content": "..."}` พร้อม beta `mid-conversation-system-clear-at-2026-08-21` หลัง tool result และเก็บสำเนาเดิมไว้ในตำแหน่งเดิม
ลบ tool result เก่าฝั่งไคลเอ็นต์	ใช้ server-side context editing พร้อมล้าง tool result
ใช้ client-side compaction	ใช้ server-side compaction ด้วย beta `compact-2026-01-12` และกำหนด `instructions` สำหรับ summary เอง หากจำเป็นต้องทำฝั่งไคลเอ็นต์ ให้แทนที่ history ทั้งหมดด้วย summary หนึ่งข้อความและ user message ใหม่เท่านั้น
อ้างอิงรูปภาพหรือเอกสารด้วย URL ข้ามเทิร์น	อัปโหลดผ่าน Files API ครั้งเดียว แล้วใช้ `file_id` หรือส่งข้อมูลแบบ base64

หากไม่มี beta สำหรับ system clear-at ให้ใส่ notification เป็น text block หลัง tool_result blocks ใน user message เดียวกัน โดยเก็บสำเนาเก่าไว้

ข้อจำกัดของ client-side compaction

client-side compaction สองรูปแบบต่อไปนี้ทำให้การตรวจสอบล้มเหลว:

Keep-tail compaction: สรุปเทิร์นเก่าแต่คงเทิร์นล่าสุดไว้ตามเดิม เนื่องจาก thinking ของเทิร์นเหล่านั้นสร้างจาก history ทั้งหมด
Background compaction: สร้าง summary นอกเส้นทางหลักแล้วสลับมาใช้ภายหลัง เทิร์นที่เกิดขึ้นระหว่างเริ่มสรุปและสลับจะไม่ตรงกัน

การตัดเทิร์นจากกลาง transcript ทำให้ block หลังจากนั้นทั้งหมดใช้ไม่ได้ ไม่มี client-side pattern ที่หลีกเลี่ยงปัญหานี้ได้ ให้ใช้ mid-conversation system message สำหรับการเปลี่ยนคำสั่ง หรือ server-side context editing สำหรับการลบแบบเลือก

ด้านค่าใช้จ่าย การอ่าน cache อยู่ที่ $0.25 ต่อล้านโทเค็น แล้ว การ compaction ตั้งแต่ต้นเพื่อประหยัดค่าใช้จ่ายอาจไม่คุ้มใน Fable 5.1 ควรทดลองเลื่อนจุด compaction ให้ช้าลง

เหตุใดเรื่องนี้จึงเกี่ยวกับ cache

ทุกสิ่งในตารางข้างต้นที่ทำให้ prefix เปลี่ยน ยังทำให้ prompt cache เริ่มต้นใหม่ด้วย

Fable 5.1 ทำให้ cache hit มีราคาถูกกว่า Fable 5 ถึงสี่เท่า แต่ cache miss มีต้นทุนสูงขึ้นตามสัดส่วน ดังนั้น harness แบบ append-only จึงได้ประโยชน์สองด้าน:

thinking เดิมยังคงใช้งานได้
ทุกเทิร์นอ่าน prefix ในราคา $0.25 แทนการเขียนใหม่ในราคา $12.50 ต่อล้านโทเค็น

ดูตัวเลขเพิ่มเติมใน รายละเอียดราคา ส่วน API walkthrough แสดงรูปแบบคำขอแบบ turn-scoped และ per-message effort ในบริบท คู่มือการ prompt อธิบายว่าคำสั่งต่อเทิร์นแบบใดเหมาะกับวิธีนี้ และ คู่มือ Claude Code อธิบายเหตุผลที่ผู้ใช้ Claude Code ไม่พบข้อผิดพลาดนี้

คำถามที่พบบ่อย

“The block is bound to a different conversation” หมายความว่าอย่างไร

หมายความว่า thinking block ของ Claude Fable 5.1 ถูกนำกลับมาใช้หลังจากข้อมูลก่อนหน้ามันเปลี่ยน เช่น system prompt, tools array หรือข้อความก่อนหน้า สำหรับบัญชีที่ถูกบังคับใช้ API จะปฏิเสธคำขอด้วยข้อผิดพลาด 400

บัญชีใดบังคับใช้การตรวจสอบนี้

บัญชีที่สร้างในหรือหลังวันที่ 31 สิงหาคม 2026 บนทุกแพลตฟอร์ม บัญชีเก่าจะบังคับใช้เมื่อคำขอตั้งค่า thinking.block_binding.prefix_mismatch_behavior เท่านั้น Anthropic มีแผนบังคับใช้กับทุกบัญชีในโมเดลอนาคต

แก้ข้อผิดพลาดอย่างรวดเร็วได้อย่างไร

ส่ง beta header thinking-binding-controls-2026-08-01 พร้อมตั้งค่า prefix_mismatch_behavior: "drop_block" API จะละทิ้ง block ที่ได้รับผลกระทบแล้วดำเนินการต่อ จากนั้นแก้ไขโค้ดที่กำลังแก้ไข history เพราะการละทิ้ง block ทุกเทิร์นจะลดการใช้เหตุผลและทำให้ cache เริ่มต้นใหม่

การเปลี่ยน `effort` หรือ `max_tokens` ทำให้ thinking block ใช้ไม่ได้หรือไม่

ไม่ การเปลี่ยนพารามิเตอร์ใดๆ นอกเหนือจาก system, tools และ messages ทำได้อย่างอิสระ รวมถึง cache_control markers

Server-side compaction ทำให้การตรวจสอบล้มเหลวหรือไม่

ไม่ การ compaction และ context editing ฝั่งเซิร์ฟเวอร์เกิดขึ้นหลังการตรวจสอบ ซึ่งเปรียบเทียบ conversation ตามที่ส่งเข้ามา ส่วน client-side compaction ที่คงเทิร์นล่าสุดไว้ตามเดิมจะทำให้การตรวจสอบล้มเหลว

Claude Mythos 5.1 มีการตรวจสอบเดียวกันหรือไม่

ไม่มี Mythos 5.1 ไม่มี conversation-prefix validation แม้ thinking blocks จะยังผูกกับโมเดลที่สร้างขึ้น และการแก้ไข history ยังทำให้ cache เริ่มต้นใหม่ได้

ลิงก์อ้างอิง

Claude Mythos 5.1 ปะทะ Fable 5.1: โมเดลเดียวกัน ระบบป้องกันต่างกัน

Thanawat Wongchai — Wed, 02 Sep 2026 04:28:10 +0000

Anthropic เปิดตัว Claude Fable 5.1 และ Claude Mythos 5.1 พร้อมกันเมื่อวันที่ 1 กันยายน 2026 โดยอธิบายว่าเป็น “โมเดลเดียวกันแต่มีระดับการป้องกันที่แตกต่างกัน” ทั้งสองใช้ weights, สเปก, ราคา ($10 และ $50) และ API เดียวกัน Claude Fable 5.1 เปิดให้ลูกค้าทั่วไปใช้งาน ส่วน Claude Mythos 5.1 ให้เฉพาะองค์กรที่ได้รับอนุมัติใน Project Glasswing ผ่านโปรแกรมตรวจสอบด้านความปลอดภัยทางไซเบอร์และวิทยาศาสตร์ชีวภาพ และเป็นโมเดลเบื้องหลัง Claude Security ของ Anthropic

ลองใช้ Apidog วันนี้

คู่มือนี้เปรียบเทียบสิ่งที่เหมือนกัน ความแตกต่าง 4 ด้าน วิธีเข้าถึง Mythos 5.1 และความหมายของช่องว่างด้านประสิทธิภาพจากเกณฑ์มาตรฐานที่เผยแพร่ โดยอ้างอิงจาก โพสต์เปิดตัว และ คู่มือการย้ายข้อมูล Fable 5.1 สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับระดับโมเดล ดู ความหมายของ “Mythos-class” และ Fable 5 เทียบกับ Mythos 5

เปรียบเทียบเคียงข้าง

รายการ	Claude Fable 5.1	Claude Mythos 5.1
รหัสโมเดล	`claude-fable-5-1`	`claude-mythos-5-1`
ความพร้อมใช้งาน	ลูกค้าทุกราย	ผู้เข้าร่วม Project Glasswing ที่ได้รับอนุมัติ
ช่องทางการเข้าถึง	ลงทะเบียน	โปรแกรมตรวจสอบความปลอดภัยทางไซเบอร์หรือวิทยาศาสตร์ชีวภาพ สำหรับองค์กรในสหรัฐฯ
ราคา	$10 / $50 ต่อ 1 ล้านโทเค็น; อ่านแคช $0.25	เหมือนกัน
บริบท / เอาต์พุตสูงสุด	1M / 128K	เหมือนกัน
ช่วงข้อมูล	มิถุนายน 2026	เหมือนกัน
การคิด	ปรับเปลี่ยนได้และเปิดใช้งานตลอดเวลา	เหมือนกัน
บังคับใช้ `tool_choice`	400	400
ตัวจัดประเภทความปลอดภัย	ชุด Fable เต็มรูปแบบ: ไซเบอร์, ชีวภาพ, `frontier_llm`, การสกัดเหตุผล และความเสียหายทั่วไป	ปรับตามโปรแกรมการเข้าถึง และผ่อนปรนมากขึ้นสำหรับงานป้องกันที่ได้รับอนุมัติ
งานด้านช่องโหว่	ระบุช่องโหว่ได้ แต่พัฒนาช่องโหว่ไม่ได้	ค้นพบเส้นทางช่องโหว่สำหรับการวิจัยเชิงป้องกันที่ได้รับอนุมัติ
อ่านบล็อกการคิดของ Fable 5.1	ได้	ได้
ตรวจสอบการแก้ไขประวัติ	มี	ไม่มี
แพลตฟอร์ม	Claude API, Bedrock, Claude Platform บน AWS, Google Cloud และ Foundry	Claude API, Bedrock, Google Cloud และ Foundry; ไม่มีบน Claude Platform บน AWS
Priority Tier	ไม่รองรับ	ไม่รองรับ
การเก็บรักษาข้อมูล	30 วัน; เป็น Covered Model	เหมือนกัน
Terminal-Bench 4.0	55.8%	60.9%

สิ่งที่เหมือนกัน

Anthropic ระบุว่าโมเดลทั้งสองมี:

ความสามารถและสเปกพื้นฐานเหมือนกัน
หน้าต่างบริบท 1M และเอาต์พุตสูงสุด 128K
การคิดแบบปรับเปลี่ยนได้ ระดับความพยายาม 5 ระดับ และเปิดใช้งานตลอดเวลา
ช่วงข้อมูลเดือนมิถุนายน 2026
ค่าอ่านแคช $0.25
การเปลี่ยนแปลงสำคัญ 3 รายการจาก Fable 5
การเก็บรักษาข้อมูล 30 วัน และเป็น Covered Models
ไม่รองรับ Zero Data Retention เว้นแต่ Anthropic อนุญาตอย่างชัดเจน
ไม่รองรับ Priority Tier
ลายน้ำข้อความเชิงสถิติของ Anthropic บนทุกแพลตฟอร์ม

เอกสารข้อมูลจำเพาะของ Fable 5.1 ยังใช้เป็นเอกสารข้อมูลจำเพาะของ Mythos 5.1 ด้วย โดยมีข้อยกเว้นด้านการตรวจสอบประวัติที่อธิบายด้านล่าง

ความแตกต่างที่ 1: ใครสามารถใช้งานได้

Fable 5.1 เปิดให้ใช้งานทั่วไปบน Claude API และแพลตฟอร์มพันธมิตรทั้งหมด

Mythos 5.1 จำกัดเฉพาะลูกค้าที่ได้รับอนุมัติใน Project Glasswing ซึ่งในช่วงเปิดตัวมี 2 ช่องทาง:

โปรแกรมตรวจสอบความปลอดภัยทางไซเบอร์สำหรับผู้เชี่ยวชาญด้านความปลอดภัยเชิงป้องกัน โดยสมัครผ่านพอร์ทัลของ Anthropic
โปรแกรมตรวจสอบวิทยาศาสตร์ชีวภาพสำหรับองค์กรด้านวิทยาศาสตร์ชีวภาพ ซึ่งดำเนินการร่วมกับรัฐบาลสหรัฐฯ

ทั้งสองโปรแกรมจำกัดเฉพาะองค์กรในสหรัฐฯ ในช่วงเปิดตัว การเข้าถึงจะจัดเตรียมผ่านทีมบัญชี Anthropic, AWS หรือ Google Cloud และยังไม่ยืนยันว่าการเข้าถึง Mythos 5 ที่มีอยู่เดิมจะได้รับการคงสิทธิ์โดยอัตโนมัติหรือไม่

นี่แตกต่างจาก Mythos 5 ซึ่งเปิดให้ใช้งานแบบเชิญเท่านั้นและไม่มีตัวจัดประเภทความปลอดภัย Mythos 5.1 ยังคงมีมาตรการป้องกัน แต่ปรับตามโปรแกรมการเข้าถึงแทนที่จะถอดออกทั้งหมด

ความแตกต่างที่ 2: มาตรการป้องกันอนุญาตอะไร

Fable 5.1 ใช้ชุดตัวจัดประเภทความปลอดภัยของ Fable อย่างเต็มรูปแบบ คำขอที่ถูกปฏิเสธจะส่งกลับเป็น HTTP 200 พร้อม:

{
  "stop_reason": "refusal"
}

Anthropic รายงานว่าอัตราผลบวกลวงลดลงจาก Fable 5 อย่างมาก:

ตัวจัดประเภทชีวภาพทำงานน้อยลง 85% สำหรับคำขอที่ไม่เป็นอันตราย
มาตรการป้องกันทางไซเบอร์แทรกแซงน้อยลงประมาณ 60% ต่อเซสชัน Claude Code
Fable 5.1 ระบุช่องโหว่ซอฟต์แวร์ได้ แต่ยังไม่สามารถพัฒนาช่องโหว่ได้

Mythos 5.1 ออกแบบมาสำหรับงานที่ Fable 5.1 อาจปฏิเสธ เช่น การค้นพบเส้นทางช่องโหว่เพื่อการวิจัยเชิงป้องกัน และงานวิทยาศาสตร์ชีวภาพที่กระตุ้นตัวจัดประเภทชีวภาพ อย่างไรก็ตาม Mythos 5.1 ยังคงมีมาตรการป้องกัน ดังนั้นควรจัดการการตอบกลับต่อไปนี้เช่นเดียวกับ Fable 5.1:

{
  "stop_reason": "refusal",
  "stop_details": {
    "category": "..."
  }
}

ควรตั้งค่า fallback สำหรับกรณีที่คำขอถูกปฏิเสธด้วย โพสต์เปิดตัวของ Anthropic และ การ์ดระบบ ระบุเพิ่มเติมว่า Mythos 5.1 มี:

ตัวจัดประเภทแบบเรียลไทม์สำหรับตรวจจับการโจมตีเฉพาะเจาะจงและการพยายามหลบหนีแซนด์บ็อกซ์
การแยกตัวที่เข้มงวดยิ่งขึ้นสำหรับงานไซเบอร์ความเสี่ยงสูง
ข้อกำหนดแยกเครือข่ายสำหรับผู้ประเมินภายนอก

มาตรการเหล่านี้เกิดขึ้นหลังการประเมินก่อนหน้านี้ที่โมเดลสามารถเข้าถึงระบบจริงได้

ความแตกต่างที่ 3: การตรวจสอบการแก้ไขประวัติ

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

Mythos 5.1 ไม่มีการตรวจสอบนี้ แต่ยังผูกบล็อกการคิดกับโมเดลที่สร้างบล็อกดังกล่าว:

Mythos 5.1 อ่านบล็อกการคิดของ Mythos 5 ได้
Mythos 5 อ่านบล็อกการคิดของ Mythos 5.1 ไม่ได้
การแก้ไขประวัติยังคงรีสตาร์ทพรอมต์แคช
จะไม่สร้างข้อผิดพลาด 400 bound to a different conversation

คู่มือการรักษาการคิด อธิบายรายละเอียดของ Fable 5.1 เพิ่มเติม

Mythos 5.1 เป็นโมเดลเดียว นอกเหนือจาก Fable 5.1 ที่สามารถอ่านบล็อกการคิดของ Fable 5.1 ได้ จึงสามารถย้ายบทสนทนาระหว่างสองโมเดลโดยไม่สูญเสียเหตุผล หากย้ายไปยัง Opus 5 ผ่าน API บล็อกเหล่านี้จะถูกทิ้ง

ความแตกต่างที่ 4: แพลตฟอร์มและขีดจำกัดอัตรา

Fable 5.1 ให้บริการบน Claude Platform บน AWS ส่วน Mythos 5.1 ไม่มีให้บริการบนแพลตฟอร์มดังกล่าว แต่ใช้งานได้ผ่าน:

Claude API
Amazon Bedrock ในชื่อ anthropic.claude-mythos-5-1 เฉพาะ us-east-1 และไม่แสดงในรายการสาธารณะ
Google Cloud
Microsoft Foundry

โมเดลทั้งสองใช้กลุ่มขีดจำกัดอัตราที่แตกต่างกัน:

Fable 5.1 ใช้กลุ่ม Fable 5.x ร่วมกับ Fable 5
Mythos 5.1 ใช้กลุ่ม Mythos ร่วมกับ Mythos 5

ช่องว่างของเกณฑ์มาตรฐานบอกอะไร

Anthropic เผยแพร่ผลการทดสอบ Mythos 5.1 บน Terminal-Bench 4.0 ที่ 60.9% เทียบกับ 55.8% ของ Fable 5.1

เนื่องจากทั้งสองเป็นโมเดลเดียวกัน ช่องว่างประมาณ 5 จุดจึงเป็นตัวชี้วัดสาธารณะที่ตรงที่สุดของต้นทุนจากมาตรการป้องกันของ Fable ในงาน agentic coding ที่ไม่เกี่ยวข้องกับไซเบอร์หรือชีวภาพ สาเหตุหนึ่งอาจเป็นตัวจัดประเภทที่แทรกแซงบางขั้นตอนที่ไม่เป็นอันตรายในเซสชันเทอร์มินัลระยะยาว

ผลลัพธ์นี้ยังชี้ว่า “โมเดลที่มีความสามารถสูงสุดและเปิดตัวอย่างกว้างขวาง” มีรุ่นพี่น้องที่ทำคะแนนได้ดีกว่าในงานเฉพาะทาง รายละเอียดเกณฑ์มาตรฐาน ครอบคลุมผลลัพธ์ส่วนที่เหลือ

ข้อค้นพบทางวิทยาศาสตร์ทั้งหมดที่ Anthropic อ้างถึงเป็นผลลัพธ์ของ Mythos 5.1 ได้แก่:

สารยึดติดโปรตีนที่มีความสัมพันธ์สูงกว่าผลงานคู่แข่งที่ดีที่สุดถึง 10 เท่าใน 3 เป้าหมาย
อัตราการเข้าเป้าเกือบ 50% ใน 12 เป้าหมาย เทียบกับค่าปกติ 10–15%
แผนที่ความสูงของดาวศุกร์ที่มีรายละเอียดระดับ 2–3 กิโลเมตร

งานเหล่านี้เป็นเหตุผลที่มีโปรแกรมตรวจสอบวิทยาศาสตร์ชีวภาพ และไม่ใช่ผลลัพธ์ของ Fable 5.1

ควรใช้โมเดลใด

สำหรับผู้ใช้ส่วนใหญ่ คำตอบคือ Fable 5.1 เพราะเป็นโมเดลที่เข้าถึงได้ทั่วไป

Mythos 5.1 เหมาะกับ:

องค์กรที่ทำวิจัยความปลอดภัยเชิงป้องกันและงานกระตุ้นตัวจัดประเภทไซเบอร์
องค์กรวิทยาศาสตร์ชีวภาพที่งานวิจัยที่ไม่เป็นอันตรายกระตุ้นตัวจัดประเภทชีวภาพ
องค์กรในสหรัฐฯ ที่ผ่านโปรแกรมตรวจสอบของ Project Glasswing

หากได้รับอนุมัติแล้ว การย้ายจาก Fable 5.1 ควรเป็นการเปลี่ยนรหัสโมเดลเป็นหลัก เนื่องจากพฤติกรรม API เหมือนกัน ยกเว้นการตรวจสอบประวัติ

หาก Fable 5.1 ปฏิเสธงานป้องกันที่ถูกต้องตามกฎหมาย ให้ลองทำตามแนวทางเหล่านี้ก่อนขอสิทธิ์ Mythos:

ใช้คำถามว่า “มีข้อผิดพลาดใด ๆ หรือไม่” แทน “คอมไพล์ได้หรือไม่”
เพิ่มเอกสารโมเดลสำหรับภาษาที่ไม่ค่อยเป็นที่รู้จัก
ลบเครื่องมือที่ส่งค่า base64 กลับเข้าสู่บริบท
ตั้งค่า fallbacks: "default" เพื่อส่งคำขอที่ถูกปฏิเสธต่อไปยัง Opus 5 หรือ Opus 4.8

ดูรายละเอียดเพิ่มเติมใน คู่มือการจัดการการปฏิเสธ

ทดสอบว่ากำลังคุยกับโมเดลใด

เนื่องจากโมเดลทั้งสองเหมือนกันในด้านอื่น ๆ วิธีที่ชัดเจนที่สุดคือส่งคำขอเดียวกันผ่าน Apidog ไปยังรหัสโมเดลทั้งสอง:

ส่งพรอมต์วิเคราะห์ช่องโหว่ที่ไม่เป็นอันตรายไปยัง claude-fable-5-1
หากมีสิทธิ์ ให้ส่งพรอมต์เดียวกันไปยัง claude-mythos-5-1
เปรียบเทียบ stop_reason และ stop_details.category
ส่งคำขอสองรอบโดยแก้ไขพรอมต์ระบบระหว่างรอบ และใช้ส่วนหัว thinking-binding-controls-2026-08-01

ผลที่คาดหวังคือ:

Fable 5.1 รายงาน prefix_binding_mismatch ใน input_transformations
Mythเดลเดียวกัน จึงมีความสามารถพื้นฐานเท่ากัน ผลทดสอบ Terminal-Bench 4.0 ที่ 60.9% เทียบกับ 55.8% สะท้อนผลกระทบจากมาตรการป้องกันของ Fable 5.1 ไม่ใช่ความแตกต่างของโมเดล

ฉันจะเข้าถึง Claude Mythos 5.1 ได้อย่างไร?

ผ่าน Project Glasswing ซึ่งมีโปรแกรมตรวจสอบความปลอดภัยทางไซเบอร์และวิทยาศาสตร์ชีวภาพ ทั้งสองจำกัดเฉพาะองค์กรในสหรัฐฯ ในช่วงเปิดตัว ให้ติดต่อทีมบัญชี Anthropic, AWS หรือ Google Cloud

Mythos 5.1 มีราคาแพงกว่า Fable 5.1 หรือไม่?

ไม่ ราคาเท่ากันที่ $10 และ $50 ต่อ 1 ล้านโทเค็น รวมถึงอัตราแคชและแบตช์

Claude Mythos 5.1 ปฏิเสธคำขอหรือไม่?

ใช่ ต่างจาก Mythos 5 ที่ไม่มีตัวจัดประเภท Mythos 5.1 ใช้มาตรการป้องกันตามโปรแกรมการเข้าถึง จึงควรจัดการ stop_reason: "refusal" เช่นเดียวกับ Fable 5.1

ฉันสามารถสลับบทสนทนาระหว่าง Fable 5.1 และ Mythos 5.1 ได้หรือไม่?

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

Mythos 5.1 พร้อมใช้งานบน Amazon Bedrock หรือไม่?

พร้อมใช้งานในชื่อ anthropic.claude-mythos-5-1 ที่ us-east-1 แม้จะไม่แสดงในรายการสาธารณะ แต่ไม่มีให้บริการบน Claude Platform บน AWS

วิธีใช้ Claude Fable 5.1 ใน Claude Code

Thanawat Wongchai — Wed, 02 Sep 2026 04:03:55 +0000

Claude Fable 5.1 พร้อมใช้งานใน Claude Code ตั้งแต่เวอร์ชัน 2.1.250 สำหรับแพ็คเกจ Claude แบบชำระเงินทั้งหมด แพ็คเกจ Max ใช้งานได้สูงสุด 50% ของขีดจำกัดรายสัปดาห์โดยไม่มีค่าใช้จ่ายเพิ่มเติม ส่วน Pro และ Team Standard ใช้เครดิตตั้งแต่ข้อความแรก นอกจากนี้ Anthropic รายงานว่าการแทรกแซงด้านไซเบอร์ใน Claude Code ลดลงประมาณ 60% ต่อเซสชันเมื่อเทียบกับ Fable 5 และโมเดลสามารถค้นหาช่องโหว่ในโค้ดของคุณเองได้แล้ว

ลองใช้ Apidog วันนี้

คู่มือนี้ครอบคลุมข้อกำหนดเวอร์ชัน การเลือกโมเดล ค่าใช้จ่ายตามแพ็คเกจ การตั้งค่า effort พฤติกรรมในเซสชันเขียนโค้ดยาว และบรรทัดพร้อมท์ที่ Anthropic แนะนำ แหล่งข้อมูลหลักคือ Fable models on your plan และ Fable 5.1 prompting guide ดูคำอธิบายโมเดลเพิ่มเติมได้ที่ what Claude Fable 5.1 is

ขั้นตอนที่ 1: อัปเดต Claude Code

Fable 5.1 ต้องใช้ Claude Code 2.1.250 ขึ้นไป ส่วน Fable 5 ต้องใช้ 2.1.170 ขึ้นไป ตรวจสอบและอัปเดตด้วยคำสั่ง:

claude --version
npm install -g @anthropic-ai/claude-code@latest

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

ขั้นตอนที่ 2: เลือกโมเดล

ในเซสชัน Claude Code ให้รัน /model แล้วเลือก Claude Fable 5.1 หรือเริ่มเซสชันโดยตรง:

claude --model claude-fable-5-1

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

ขั้นตอนที่ 3: ตรวจสอบค่าใช้จ่ายตามแพ็คเกจ

Fable 5 และ Fable 5.1 มีวิธีคิดค่าบริการเหมือนกัน ความแตกต่างอยู่ที่แพ็คเกจ:

แพ็คเกจ	วิธีเรียกเก็บเงิน Fable 5.1
ฟรี	ไม่พร้อมใช้งาน
Pro	ใช้เครดิตตั้งแต่ข้อความแรก และไม่รวมอยู่ในขีดจำกัดรายสัปดาห์ของแพ็คเกจ
Max (5x และ 20x)	รวมอยู่ในแพ็คเกจสูงสุด 50% ของขีดจำกัดรายสัปดาห์โดยไม่มีค่าใช้จ่ายเพิ่มเติม หลังจากนั้นใช้เครดิตหรือเปลี่ยนโมเดล
Team Standard	ใช้เครดิตเช่นเดียวกับ Pro
Team Premium	เงื่อนไขเดียวกับ Max
Enterprise Standard	ต้องเปิดใช้เครดิตสำหรับการใช้งานเกินขีดจำกัดแพ็คเกจ
Enterprise แบบคิดตามการใช้งาน	อัตรา API มาตรฐาน ($10 / $50 ต่อล้านโทเค็น)

มีรายละเอียดสำคัญสำหรับ Claude Code สองข้อ:

โควตา 50% ของ Max รวมอยู่ในขีดจำกัดรายสัปดาห์ ไม่ใช่โควตาแยก ดังนั้นการใช้ Fable 5.1 อย่างหนักจะลดพื้นที่ใช้งาน Opus 5 ด้วย
คำขอที่ระบบป้องกันเปลี่ยนเส้นทางไปยังโมเดลอื่นจะไม่ถูกคิดในราคา Fable การเปลี่ยนไปใช้โมเดลสำรองจึงไม่ใช้เครดิต Fable สำหรับคำขอส่วนนั้น

หากใช้ Pro แล้วเห็นข้อความ usage credits required สำหรับ Fable 5.1 นี่เป็นพฤติกรรมที่คาดไว้ตั้งแต่การเปลี่ยนแปลงวันที่ 20 กรกฎาคม ไม่ใช่ข้อผิดพลาด ดูรายละเอียดได้ที่ คำอธิบายเครดิตการใช้งาน และ การอัปเดตขีดจำกัดของ Claude Code

ขั้นตอนที่ 4: ตั้งค่า Effort

Claude Code ตั้งค่า effort เริ่มต้นเป็น high สำหรับโมเดลปัจจุบันทั้งหมด รวมถึง Fable 5.1 คุณเปลี่ยนค่าได้ด้วย /effort หรือในการตั้งค่า:

high: จุดเริ่มต้นที่แนะนำสำหรับงานเขียนโค้ดส่วนใหญ่
medium: คุณภาพใกล้เคียง Fable 5 แต่ใช้ต้นทุนต่ำกว่า เหมาะกับการแก้ไขและคำถามทั่วไป
xhigh / max: เหมาะกับงานยาก เช่น การปรับโครงสร้างครั้งใหญ่ การดีบักหลายชั่วโมง และฟีเจอร์ที่เกี่ยวข้องกับหลายไฟล์ โดยจะเพิ่มเวลาคิดก่อนตอบครั้งแรก
low: เหมาะกับงานโต้ตอบที่ต้องการความเร็ว Anthropic ระบุว่า Fable 5.1 ที่ low อาจแข่งขันกับ Opus และ Sonnet ได้ในด้านต้นทุนต่องาน แต่จะค้นหาน้อยลงและพึ่งพาความรู้เดิมมากขึ้น ควรเพิ่ม effort เมื่องานต้องอ่านโค้ดหรือเอกสารปัจจุบัน

สำหรับแพ็คเกจ Max การลด effort ยังช่วยยืดโควตา 50% ได้ เพราะแต่ละรอบใช้โทเค็นเอาต์พุตน้อยลง

พฤติกรรมของ Fable 5.1 ในเซสชันเขียนโค้ด

Claude Code จัดการคำนำของบทสนทนาให้แล้ว ประเด็นที่สังเกตได้จึงเป็นพฤติกรรมระหว่างทำงาน:

อ่านไฟล์แบบขนานน้อยลง

เมื่อมีไฟล์อิสระหลายไฟล์ที่ควรอ่านในลูปยาว Fable 5.1 อาจอ่านทีละไฟล์ ขณะที่ Fable 5 อ่านหลายไฟล์พร้อมกัน ผลลัพธ์อาจเหมือนเดิม แต่ใช้เวลานานขึ้น หากพบพฤติกรรมนี้ ให้ใช้คำแนะนำใน CLAUDE.md ด้านล่าง

รายงานความคืบหน้าน้อยลง

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

เขียนไฟล์ใหม่ทั้งไฟล์บ่อยขึ้น

Fable 5.1 มีแนวโน้มเขียนไฟล์ใหม่ทั้งหมดแม้เป็นการเปลี่ยนแปลงเล็กน้อย ซึ่งเพิ่มโทเค็นเอาต์พุตและเวลา คำแนะนำให้แก้ไขแบบเจาะจงช่วยลดปัญหานี้ได้

ขอบเขตงานและการทดสอบอาจขยายเกินจำเป็น

เมื่อสร้างฟีเจอร์ โมเดลอาจแก้โค้ดใกล้เคียง ขยายพฤติกรรมที่ไม่ได้ร้องขอ หรือเพิ่มไฟล์ทดสอบมากเกินไป ควรระบุสิ่งที่ไม่ควรแก้ไขให้ชัดเจน

ปฏิเสธคำขอผิดพลาดน้อยลง

Anthropic รายงานว่าการแทรกแซงด้านไซเบอร์ลดลงประมาณ 60% ต่อเซสชันเมื่อเทียบกับ Fable 5 และอนุญาตให้ค้นหาช่องโหว่ในซอร์สโค้ดของคุณเอง อย่างไรก็ตาม การพัฒนาการใช้ประโยชน์จากช่องโหว่ยังคงถูกปฏิเสธ

วลีที่อาจเพิ่มอัตราการปฏิเสธผิดพลาด ได้แก่:

ถามว่า “โค้ดนี้คอมไพล์โดยไม่มีข้อผิดพลาดหรือไม่” ควรเปลี่ยนเป็น “โค้ดนี้มีข้อบกพร่องหรือไม่”
ใช้ภาษาที่ไม่ค่อยเป็นที่รู้จักโดยไม่ให้เอกสารประกอบ
ใช้เครื่องมือที่ส่งค่า base64 กลับเข้าสู่บริบท

บรรทัด `CLAUDE.md` ที่ Anthropic แนะนำ

บรรทัดต่อไปนี้มาจากคู่มือพร้อมท์อย่างเป็นทางการ และสามารถเพิ่มลงใน CLAUDE.md ของโปรเจกต์ได้

สำหรับการแก้ไขแบบเจาะจงแทนการเขียนใหม่:

The number of tokens used to edit files is best minimized, all else being equal. Therefore, when it will not affect the end result, try to surgically edit a file rather than rewrite the entire thing.

สำหรับการควบคุมขอบเขตและการทดสอบ:

If, while working or testing, you find a pre-existing bug, a performance concern, or behavior the task doesn't mention, don't fix, optimize or extend it in this change unless the requested behavior cannot work without it; report it as a follow-up in your summary. Commit tests only where the task asks for them or this repository already keeps tests for this kind of change, sized like the neighboring test files. This is about extras only: implement every behavior the task asks for, completely.

สำหรับการทำงานอัตโนมัติ:

You are operating autonomously. The user is not watching in real time and cannot answer questions mid-task, so asking 'Want me to...?' or 'Shall I...?' will block the work. For reversible actions that follow from the original request, proceed without asking. Stop only for destructive actions or genuine scope changes the user must decide.

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

หาก CLAUDE.md กำหนดให้โมเดลทดสอบหรือตรวจสอบงานก่อนรายงาน ให้คงคำแนะนำนั้นไว้ คำแนะนำ Opus 5 ที่ให้ลบคำแนะนำการตรวจสอบ ไม่ได้ใช้กับ Fable 5.1

รายละเอียดการเปลี่ยนแปลงพฤติกรรมทั้งหมด รวมถึงการปรับการจัดกลุ่มและความหนาแน่นของการเขียน อยู่ใน Fable 5.1 prompting guide

ใช้ Fable 5.1 กับ Apidog จาก Claude Code

สำหรับงาน API การจับคู่ที่ช่วยประหยัดเวลาคือ Fable 5.1 ที่ขับเคลื่อน Apidog CLI:

โมเดลออกแบบหรือแก้ไข OpenAPI spec
CLI รันสถานการณ์ทดสอบ Apidog
โมเดลอ่านผลลัพธ์และปรับ spec ในรอบถัดไป

ความสามารถในการทำงานอัตโนมัติเป็นเวลานานของ Fable 5.1 เหมาะกับลูปนี้ เพราะสามารถวนซ้ำ spec, mock และ test ได้หลายชั่วโมงโดยไม่ต้องตรวจสอบตลอดเวลา

หากเพิ่งเริ่มต้น ให้ดู การสร้าง API ด้วย Claude Code และ Apidog Apidog เริ่มใช้งานได้ฟรี และสามารถ ดาวน์โหลด Apidog ได้จากเว็บไซต์

Fable 5.1 เทียบกับ Opus 5 ใน Claude Code

กฎของ Anthropic ใน ภาพรวมโมเดล คือเริ่มจาก Opus 5 และเลื่อนขึ้นเมื่อ Opus 5 ที่ effort สูงยังไม่เพียงพอ ใน Claude Code จึงแนะนำให้:

ใช้ Opus 5 สำหรับงานประจำวัน
เปลี่ยนเป็น Fable 5.1 สำหรับเซสชันยาว งานหลายไฟล์ และงานยาก

สำหรับแพ็คเกจ Max วิธีนี้ช่วยรักษาส่วนแบ่ง Fable 50% ไว้สำหรับงานที่จำเป็นจริงๆ อ่านรายละเอียดประสิทธิภาพและค่าใช้จ่ายได้จาก การเปรียบเทียบ Fable 5.1 กับ Opus 5 และดูการตั้งค่า Opus 5 ได้ใน คู่มือ Opus 5 ใน Claude Code

คำถามที่พบบ่อย

Claude Code เวอร์ชันใดรองรับ Fable 5.1?

เวอร์ชัน 2.1.250 ขึ้นไป ส่วน Fable 5 ต้องใช้ 2.1.170 ขึ้นไป บิลด์เก่าจะไม่แสดงโมเดล

Claude Fable 5.1 รวมอยู่ในแพ็คเกจ Claude Code หรือไม่?

รวมอยู่ใน Max และ Team Premium โดยใช้งานได้สูงสุด 50% ของขีดจำกัดรายสัปดาห์ จากนั้นจะใช้เครดิต ส่วน Pro และ Team Standard ใช้เครดิตตั้งแต่ข้อความแรก และแพ็คเกจฟรีไม่รองรับ

ค่า effort เริ่มต้นของ Fable 5.1 คือเท่าใด?

high เช่นเดียวกับโมเดลปัจจุบันทั้งหมด เปลี่ยนได้ด้วย /effort

Fable 5.1 ปฏิเสธงานด้านความปลอดภัยใน Claude Code หรือไม่?

ปฏิเสธน้อยกว่า Fable 5 โดย Anthropic รายงานว่าการแทรกแซงด้านไซเบอร์ลดลงประมาณ 60% ต่อเซสชัน และอนุญาตให้ค้นหาช่องโหว่ในโค้ดของคุณเอง การพัฒนาการใช้ประโยชน์จากช่องโหว่ยังคงถูกปฏิเสธ และคำขอที่เปลี่ยนเส้นทางจะไม่ถูกคิดในราคา Fable

ควรเก็บคำแนะนำ “ตรวจสอบงานของคุณ” ไว้หรือไม่?

ควรเก็บไว้ คำแนะนำที่ให้ลบข้อความนี้จัดทำขึ้นสำหรับ Opus 5 ซึ่งตรวจสอบมากเกินไป และไม่ควรนำมาใช้กับ Fable 5.1

ทำไม Fable 5.1 จึงเงียบระหว่างงานที่ใช้เวลานาน?

โมเดลรายงานความคืบหน้าน้อยกว่า Fable 5 ระหว่างเรียกใช้เครื่องมือ โดยเฉพาะเมื่อใช้ effort สูง งานยังคงดำเนินอยู่ เพียงแต่อธิบายระหว่างทางน้อยลง

วิธีใช้ โคล้ด เฟเบิล 5.1 ฟรี: คู่มือและทางเลือกเสียเงินที่คุ้มค่าที่สุด

Thanawat Wongchai — Wed, 02 Sep 2026 03:39:49 +0000

Claude Fable 5.1 ฟรีหรือไม่? วิธีทดลองใช้และลดค่าใช้จ่ายอย่างถูกต้อง

ไม่มีระดับฟรี (free tier) สำหรับ Claude Fable 5.1 โมเดลนี้ไม่อยู่ในแผนฟรี (Free plan) ของ claude.ai และ API ไม่มีโควตาฟรี นอกจากเครดิตสมัครใช้งานจำนวนเล็กน้อยที่บัญชีใหม่ได้รับ เว็บไซต์ที่โฆษณา “Fable 5.1 ฟรีไม่จำกัด” มักให้บริการโมเดลอื่นผ่านพร็อกซี หรือเป็นแผนเก็บเกี่ยวคีย์ (key-harvesting scheme) วิธีที่เชื่อถือได้คือทดลองใช้ด้วยต้นทุนต่ำ และลดค่าใช้จ่ายเมื่อเริ่มใช้งานจริง

ลองใช้ Apidog วันนี้

คู่มือนี้สรุปตัวเลือกพร้อมตัวเลขจริงจาก บทความการวัดการใช้งานแผน ของ Anthropic และ หน้าการกำหนดราคา ของโมเดล ดูเพิ่มเติมว่า Claude Fable 5.1 คืออะไร

“ฟรี” หมายถึงอะไรสำหรับ Fable 5.1

เส้นทาง	ค่าใช้จ่าย	สิ่งที่ได้รับ
Claude Free	$0	ไม่สามารถเข้าถึง Fable 5.1
เครดิตสมัคร API	$0	เครดิตครั้งเดียวจำนวนเล็กน้อย ที่ราคา $10 และ $50 ต่อล้านโทเค็น เพียงพอสำหรับคำขอสำคัญหลายสิบรายการ
Claude Pro	$20/เดือน	ใช้ Fable 5.1 ด้วยเครดิตการใช้งานตั้งแต่ข้อความแรก และไม่หักจากขีดจำกัดรายสัปดาห์
Claude Max 5x	$100/เดือน	รวม Fable 5.1 สูงสุด 50% ของขีดจำกัดรายสัปดาห์ จากนั้นใช้เครดิตการใช้งาน
Claude Max 20x	$200/เดือน	กฎ 50% เดียวกัน แต่มีขีดจำกัดรายสัปดาห์สูงกว่า
ทีมมาตรฐาน	ต่อที่นั่ง	เครดิตการใช้งาน คล้าย Pro
ทีมพรีเมียม	ต่อที่นั่ง	รวมสูงสุด 50% ของขีดจำกัดรายสัปดาห์ คล้าย Max
Claude Code	ต่อแผน	วัดการใช้งานตามแผน และต้องใช้เวอร์ชัน 2.1.250 ขึ้นไป
Batch API	ลด 50%	$5 และ $25 ต่อล้านโทเค็น สำหรับงานที่รอผลได้

เครดิตครั้งเดียวที่ผู้ใช้ Pro และที่นั่งทีมมาตรฐานได้รับเมื่อ Fable 5 เปลี่ยนไปใช้เครดิตการใช้งานในเดือนกรกฎาคม 2026 จะไม่ถูกออกซ้ำสำหรับ Fable 5.1 อ่านเพิ่มเติมเกี่ยวกับการเปลี่ยนแปลงได้ใน การเปลี่ยนไปใช้เครดิตการใช้งานในเดือนกรกฎาคม

เส้นทางที่ 1: ใช้เครดิตสมัคร API

บัญชี Claude API ใหม่จะได้รับเครดิตฟรีจำนวนเล็กน้อยสำหรับการทดสอบ คำขอที่มีโทเค็นอินพุต 5,000 และเอาต์พุต 2,000 มีค่าใช้จ่ายประมาณ $0.15 จึงเพียงพอสำหรับการประเมินโมเดลอย่างจริงจัง หากใช้กับพรอมต์ที่สำคัญเพียงไม่กี่รายการแทนการสนทนาที่ยาวต่อเนื่อง

มีข้อควรระวังสองประการ:

Fable 5.1 ต้องการการเก็บรักษาข้อมูล 30 วัน บัญชีใหม่ที่ใช้ค่าเริ่มต้นจึงใช้งานได้ แต่องค์กรที่เลือกไม่เก็บรักษาข้อมูลจะได้รับข้อผิดพลาด 400
เครดิตใช้ร่วมกันทุกโมเดล การเรียกใช้ Opus 5 หรือ Sonnet 5 จึงใช้เครดิตก้อนเดียวกัน

ดูวิธีทำงานของเครดิตได้ใน คู่มือการเข้าถึง Claude API ฟรี

เส้นทางที่ 2: ใช้โควตา Max บางส่วน

ตามข้อมูลของ Anthropic Fable 5 และ Fable 5.1 เป็น “ส่วนมาตรฐานของแผน” Max โดยใช้ได้สูงสุด 50% ของขีดจำกัดรายสัปดาห์โดยไม่มีค่าใช้จ่ายเพิ่ม หลังจากนั้นคุณเลือกใช้เครดิตต่อ หรือเปลี่ยนไปใช้โมเดลอื่นจนจบสัปดาห์ได้

ทำให้โควตาที่รวมอยู่ใช้งานได้นานขึ้นด้วยวิธีต่อไปนี้:

ลดระดับ Effort: ใน Claude และ Claude Code ค่าเริ่มต้นคือ high แต่ medium ของ Fable 5.1 ให้ประสิทธิภาพใกล้เคียง Fable 5 ในต้นทุนที่ต่ำกว่า ส่วน low มักแข่งขันกับ Opus และ Sonnet ได้ดีในด้านต้นทุนต่องาน เอาต์พุตที่สั้นลงช่วยเพิ่มจำนวนรอบภายในโควตา 50%
เลือกโมเดลให้เหมาะกับงาน: ใช้ Opus 5 กับงานประจำ และเก็บ Fable 5.1 ไว้สำหรับเซสชันที่ยาวหรือยาก ตามคำแนะนำของ Anthropic
ตรวจสอบการเปลี่ยนเส้นทาง: หากระบบเปลี่ยนเส้นทางคำขอไปยังโมเดลอื่น คุณจะไม่ถูกคิดค่าบริการในอัตรา Fable สำหรับคำขอนั้น

หากเลือกระหว่าง Max 5x และ Max 20x เพื่อเพิ่มพื้นที่สำหรับ Fable 5.1 ให้จำไว้ว่า 50% ของขีดจำกัดที่ใหญ่กว่าย่อมให้โควตาที่มากกว่า เปอร์เซ็นต์ไม่เปลี่ยนแปลง ดูรายละเอียดการวัดการใช้งานในเซสชันได้จาก คู่มือ Claude Code

เส้นทางที่ 3: ใช้ Pro พร้อมเครดิตการใช้งาน

ผู้ใช้ Pro ใช้ Fable 5.1 ได้ แต่โมเดลนี้ไม่รวมอยู่ในขีดจำกัดรายสัปดาห์ของแผน ระบบจะใช้เครดิตการใช้งานตั้งแต่ข้อความแรกตามอัตราของโมเดล

ตัวเลือกนี้เหมาะกับการใช้งานเป็นครั้งคราว เช่น ปรับโครงสร้างโค้ดที่ซับซ้อนสัปดาห์ละครั้ง หรืองานวิจัยยาวเดือนละครั้ง สำหรับการใช้งานรายวัน Max 5x ราคา $100 มักคุ้มค่ากว่า

ให้ประมาณจำนวนโทเค็น Fable 5.1 ที่ใช้ต่อเดือน แล้วเปรียบเทียบค่าเครดิตกับส่วนต่าง $80 ระหว่าง Pro และ Max 5x โดยจำไว้ว่าโควตา Max คิดเป็นส่วนแบ่งของขีดจำกัดรายสัปดาห์ ไม่ใช่จำนวนโทเค็นตายตัว

เส้นทางที่ 4: ลดราคา API ครึ่งหนึ่งด้วย Batch

Batch API ลดราคา 50%:

อินพุต: $5 ต่อล้านโทเค็น
เอาต์พุต: $25 ต่อล้านโทเค็น
อ่านแคช: $0.125 ต่อล้านโทเค็น

การประมวลผลเป็นชุดทำงานแบบอะซิงโครนัส โดยปกติใช้เวลาไม่กี่ชั่วโมง และไม่เกิน 24 ชั่วโมง เหมาะกับการประเมินโมเดล การเติมข้อมูลย้อนหลัง การประมวลผลเอกสาร การสร้างรายงานรายคืน และการทดสอบประสิทธิภาพทุกระดับ Effort

ข้อจำกัดที่ต้องรู้:

fallbacks ฝั่งเซิร์ฟเวอร์ไม่รองรับใน Batch คำขอที่ถูกปฏิเสธจะต้องส่งใหม่ด้วยตนเอง
เบต้าสำหรับ Batch ขนาด 300,000 โทเค็นยังไม่พร้อมใช้งานกับ Fable 5.1

เส้นทางที่ 5: ใช้ Prompt caching

ส่วนลดสำคัญของ Fable 5.1 คือการแคชพรอมต์ ค่าอ่านแคชอยู่ที่ $0.25 ต่อล้านโทเค็น หรือหนึ่งในสี่ของอัตรา Fable 5 และครึ่งหนึ่งของ Opus 5

เมื่อส่งคำนำหน้าเดิมซ้ำ เช่น system prompt เอกสาร หรือบริบทของเอเจนต์ อินพุตส่วนใหญ่จะคิดราคาเพียง 2.5% ของราคาปกติ Anthropic ประเมินว่าวิธีนี้ลดต้นทุนงานทั่วไปได้ประมาณ 25% เมื่อเทียบกับ Fable 5 และลดงานที่ซับซ้อนมากได้ถึงประมาณ 45%

แนวทางใช้งาน:

ใส่ cache_control บนคำนำหน้าที่ไม่เปลี่ยนแปลง
อย่าใส่ timestamp หรือ ID ต่อคำขอลงใน system prompt
อย่าสร้าง system หรือ tools ใหม่กลางเซสชัน ให้ใช้ข้อความระบบเดิมตลอดการสนทนา
ตรวจสอบ usage.cache_read_input_tokens ในคำขอที่สอง หากเป็นศูนย์ให้ถือว่าแคชทำงานผิดพลาด

ดูตัวอย่างการคำนวณได้จาก รายละเอียดการกำหนดราคา และดูรูปแบบคำขอจาก คำอธิบาย API

เส้นทางที่ 6: ควบคุมต้นทุนด้วย Effort

เอาต์พุตมีราคา $50 ต่อล้านโทเค็น จึงมักเป็นส่วนที่แพงที่สุดของบิล Fable 5.1 ตัวแปร output_config.effort เป็นเครื่องมือหลักในการควบคุมจำนวนโทเค็น

เริ่มที่ high แล้วลดระดับทีละขั้น หาก medium ยังคงคุณภาพตามผลประเมินของคุณได้ ต้นทุนการสนทนาประจำวันก็จะลดลงทันที เบต้าสำหรับ per-message effort ยังช่วยให้ใช้ low กับรอบง่ายและ high กับรอบยากในบทสนทนาเดียวกัน โดยไม่ต้องรีเซ็ตแคช

คู่มือความพยายามของ Opus 5 อธิบาย Effort ทั้งห้าระดับ ซึ่งทำงานในลักษณะเดียวกันกับ Fable 5.1

เส้นทางที่ 7: ตรวจสอบว่าจำเป็นต้องใช้ Fable 5.1 หรือไม่

เอกสารของ Anthropic แนะนำให้เริ่มด้วย Opus 5 และย้ายไป Fable 5.1 เมื่อ Opus 5 ที่ใช้ Effort ระดับสูงยังไม่เพียงพอ

เมื่อไม่มีการแคช Opus 5 มีราคาถูกกว่าครึ่งหนึ่ง มีโหมดเร็ว รองรับการไม่เก็บรักษาข้อมูล และใช้ตัวแยกประเภทน้อยกว่า สำหรับงานส่วนใหญ่ก็เพียงพอ การเปรียบเทียบ Fable 5.1 กับ Opus 5 แสดงให้เห็นว่าช่องว่างด้านประสิทธิภาพของงานส่วนใหญ่น้อยกว่าห้าคะแนน

หากต้องการรันโมเดลที่มีความสามารถสูงด้วยต้นทุนต่ำกว่า การเริ่มจาก Opus 5 คือทางเลือกที่ประหยัดที่สุดในรายการนี้

สิ่งที่ไม่ใช่เส้นทางฟรี

เว็บไซต์ “Fable 5.1 ฟรีไม่จำกัด”

Fable 5.1 ไม่มีระดับ API ฟรี และไม่อยู่ในแผนฟรี ดังนั้นบริการที่ให้การเข้าถึงฟรีไม่จำกัดอาจกำลังให้บริการโมเดลอื่น ใช้คีย์ของผู้อื่นเป็นพร็อกซี หรือเก็บรวบรวมคีย์ของคุณ

การเปลี่ยนเส้นทาง พฤติกรรมการคิดตลอดเวลา และลายน้ำข้อความช่วยตรวจสอบได้ว่าคุณกำลังสนทนากับโมเดลใด อ่านกรณีเดียวกันของ Fable 5 ได้จาก Claude Fable 5 โดยไม่มีข้อจำกัด

ปิดการคิดเพื่อประหยัดโทเค็น

Fable 5.1 ไม่รองรับการปิดการคิด thinking: {"type": "disabled"} จะส่งคืนข้อผิดพลาด 400 ในทุกระดับ Effort วิธีที่ทำได้คือเลือกระดับ Effort ที่ต่ำลง

Fast mode หรือ Priority Tier

Fable 5.1 ไม่รองรับทั้ง Fast mode และส่วนลด Priority Tier

เครดิต Bedrock หรือ Google Cloud

เครดิตผู้ให้บริการคลาวด์ใช้ชำระค่า Fable 5.1 บนแพลตฟอร์มเหล่านั้นได้ แต่แพลตฟอร์มจะกำหนดราคาเอง และอาจเพิ่มค่าใช้จ่าย 10% สำหรับเอนด์พอยต์ระดับภูมิภาค ตัวเลือกนี้มีอยู่จริง แต่ไม่ใช่การใช้งานฟรี ดูการตั้งค่าได้จาก คู่มือความพร้อมใช้งานบนคลาวด์

วัดต้นทุนของแต่ละคำขอ

คำขอ Fable 5.1 ที่ถูกที่สุดคือคำขอที่ไม่ต้องส่งซ้ำ ใน Apidog ให้สร้างคอลเลกชันขนาดเล็กจากพรอมต์จริงของคุณ แล้วเพิ่มสคริปต์หลังการตอบกลับเพื่อคูณฟิลด์ usage แต่ละรายการด้วยอัตราที่เกี่ยวข้อง:

อินพุต: $10 ต่อล้านโทเค็น
อ่านแคช: $0.25 ต่อล้านโทเค็น
เขียนแคช: $12.50 ต่อล้านโทเค็น
เอาต์พุต: $50 ต่อล้านโทเค็น

ทดสอบที่ high และ medium ทั้งแบบมีและไม่มี cache_control คุณจะได้ตัวเลขสี่ชุดเพื่อประเมินว่า Fable 5.1 เหมาะกับงบประมาณหรือไม่ก่อนเลือกแผน ดาวน์โหลด Apidog เพื่อเริ่มตั้งค่า

คำถามที่พบบ่อย

Claude Fable 5.1 ฟรีหรือไม่?

ไม่ใช่ โมเดลนี้ไม่อยู่ในแผนฟรี และ API ไม่มีระดับฟรีนอกจากเครดิตสมัครใช้งานจำนวนเล็กน้อย ตัวเลือกที่ถูกที่สุดคือ Pro แบบใช้เครดิตการใช้งาน หรือ Max ซึ่งรวม Fable 5.1 สูงสุด 50% ของขีดจำกัดรายสัปดาห์

Claude Max รวม Fable 5.1 หรือไม่?

ใช่ Max รวม Fable 5 และ Fable 5.1 สูงสุด 50% ของขีดจำกัดการใช้งานรายสัปดาห์โดยไม่มีค่าใช้จ่ายเพิ่ม หลังจากนั้นจะใช้เครดิตการใช้งาน

ฉันใช้ Fable 5.1 บน Claude Pro ได้หรือไม่?

ได้ แต่ระบบจะใช้เครดิตการใช้งานตั้งแต่ข้อความแรก และไม่หักจากขีดจำกัดรายสัปดาห์ของ Pro

วิธีที่ถูกที่สุดในการรัน Fable 5.1 บน API คืออะไร?

สำหรับงานที่รอได้ ให้ใช้ Batch API ($5 และ $25 ต่อล้านโทเค็น) ใช้ Prompt caching กับคำนำหน้าที่ไม่เปลี่ยนแปลง ($0.25 ต่อล้านโทเค็นเมื่ออ่านแคช) และเลือก Effort ระดับ medium หรือ low หากผลประเมินยังคงคุณภาพตามต้องการ

มี Fable 5.1 แบบทดลองใช้ฟรีหรือไม่?

มีเฉพาะเครดิตสมัคร API มาตรฐาน ซึ่งใช้ร่วมกันทุกโมเดล ผู้ใช้ Pro และ Team เคยได้รับเครดิตพิเศษครั้งเดียวเมื่อ Fable 5 เปลี่ยนไปใช้เครดิตการใช้งานในเดือนกรกฎาคม 2026 แต่ไม่มีการออกซ้ำสำหรับ Fable 5.1

เว็บไซต์ “API Fable 5.1 ฟรีไม่จำกัด” เป็นของจริงหรือไม่?

ไม่ใช่ Fable 5.1 ไม่มีระดับฟรีไม่จำกัด เว็บไซต์เหล่านั้นอาจให้บริการโมเดลอื่น หรือใช้คีย์ที่ไม่ได้เป็นของตนเอง

เทคนิคการป้อนพรอมต์ Claude Fable 5.1: จัดการทุกพฤติกรรมที่เปลี่ยนไปด้วยหนึ่งบรรทัด

Thanawat Wongchai — Wed, 02 Sep 2026 03:10:55 +0000

คู่มือปรับพรอมต์จาก Claude Fable 5 ให้เหมาะกับ Fable 5.1

Anthropic ระบุว่าพรอมต์ของ Claude Fable 5 ควรทำงานได้ดีบน Fable 5.1 โดยไม่ต้องแก้ไข แต่พฤติกรรมรอบ ๆ คำตอบเปลี่ยนไป เช่น จำนวนการเรียกใช้เครื่องมือ การอัปเดตความคืบหน้า ความหนาแน่นของสำนวน การจัดรูปแบบ การแก้ไขไฟล์ และการหยุดขออนุญาตระหว่างงาน ดูรายละเอียดจาก คู่มือการสร้างพรอมต์สำหรับ Claude Fable 5.1 และ Claude Fable 5.1 คืออะไร

ลองใช้ Apidog วันนี้

1. ปรับ Effort ก่อนแก้พรอมต์

Effort เป็นตัวควบคุมหลักของ Fable 5.1 สำหรับแลกเปลี่ยนระหว่างความฉลาด ความหน่วง และค่าใช้จ่าย

แนวทางเริ่มต้น:

เริ่มที่ high
ทดสอบระดับที่เหลือเทียบกับชุดประเมินของคุณ
ทดสอบใหม่แม้เคยทดสอบบน Fable 5 แล้ว เพราะระดับชื่อเดียวกันไม่ได้หมายถึงปริมาณการคิดเท่ากันในทุกโมเดล

ข้อสังเกตของ Anthropic ที่ควรตรวจสอบกับงานจริง:

medium อาจให้ผลลัพธ์ใกล้เคียง Fable 5 ด้วยค่าใช้จ่ายต่ำกว่า
low อาจแข่งขันกับ Opus และ Sonnet ได้ในด้านค่าใช้จ่ายต่องาน พร้อมคะแนนที่สูงกว่าในบางงาน
ประโยชน์จาก Fable 5.1 อาจเด่นที่สุดที่ xhigh และ max

คุณสามารถเปลี่ยนระดับความพยายามระหว่างการสนทนาโดยไม่รีเซ็ตแคช ผ่านข้อความระบบว่างร่วมกับ output_config และ beta header mid-conversation-output-config-2026-07-01 ดูรูปแบบได้จาก Effort และ คำแนะนำการใช้งาน Claude Fable 5.1 API

2. วางคำสั่งต่อรอบให้ถูกตำแหน่ง

นี่เป็นความแตกต่างสำคัญของ Fable 5.1

บล็อกความคิดจะใช้ได้เฉพาะกับบทสนทนาที่สร้างต่อเนื่องและรักษาความคิดไว้ การแทรกคำเตือนเข้าไปในประวัติรอบก่อน แล้วลบออกในคำขอถัดไป ถือเป็นการแก้ไขประวัติ ซึ่งจะ:

รีสตาร์ทพรอมต์แคช
ทำให้บล็อกความคิดถัดไปไม่ถูกต้องสำหรับบัญชีที่สร้างในหรือหลังวันที่ 31 สิงหาคม 2026

ใช้ system message แบบขอบเขตต่อรอบ

เปิด beta mid-conversation-system-clear-at-2026-08-21 แล้วเพิ่มคำสั่งหลังข้อความผลลัพธ์ของเครื่องมือ:

{
  "role": "system",
  "clear_at": "next_user_message",
  "content": "คำสั่งต่อรอบของคุณ"
}

เก็บสำเนาคำสั่งเก่าไว้ในอาร์เรย์ เมื่อมีข้อความผู้ใช้ใหม่ API จะลบสำเนาเก่าออกเอง จึงไม่เสียโทเค็นจากสำเนาที่ถูกลบ

หากไม่มี beta นี้ ให้ใส่คำสั่งไว้ในบล็อกข้อความหลัง tool_result ภายในข้อความผู้ใช้เดียวกัน และเก็บสำเนาเก่าไว้เสมอ ห้ามลบหรือเขียนข้อความที่ส่งไปแล้วใหม่

อ่านเพิ่มเติมจาก การรักษาความคิด, ข้อความระบบแบบขอบเขตต่อรอบ และ คู่มือการรักษาความคิดของ Claude Fable 5.1

คำสั่งระดับเซสชันควรอยู่ในพรอมต์ระบบหรือข้อความผู้ใช้รอบแรก โดย Anthropic ระบุว่าคำสั่งด้านรูปแบบในข้อความผู้ใช้รอบแรกมักถูกเก็บรักษาไว้ดีกว่าข้อความเดียวกันในพรอมต์ระบบ

3. จำกัดการเรียกใช้เครื่องมือไว้ครั้งเดียวต่อรอบ

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

คำตอบสุดท้ายอาจไม่เปลี่ยน แต่แต่ละรอบที่เพิ่มขึ้นทำให้เสีย:

โทเค็น
เวลาเดินทางไปกลับ
เวลาประมวลผลจริง

วัดผลก่อนแก้ไข โดยติดตามสัดส่วนรอบผู้ช่วยที่มี tool_use มากกว่าหนึ่งรายการ แล้วเพิ่มคำสั่งเฉพาะเมื่อพบว่าการรวมกลุ่มลดลง

เพิ่มข้อความนี้ต่อท้ายผลลัพธ์ของเครื่องมือแต่ละรายการใน system message แบบขอบเขตต่อรอบ:

First privately list what you need next; then request every item that doesn't depend on another's result in this one response.

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

4. ลดข้อความระหว่างการเรียกใช้เครื่องมือ

Fable 5.1 มักแสดงการอัปเดตระหว่างเรียกใช้เครื่องมือน้อยกว่า Fable 5 โดยเฉพาะที่ระดับความพยายามสูง ผู้ใช้อาจเห็นเอเจนต์เงียบไปหลายนาที หรือเห็นเฉพาะข้อความสุดท้าย

ลองแก้ตามลำดับนี้:

ตรวจสอบก่อนว่าการอัปเดตถูกส่งกลับมาหรือไม่ บล็อก thinking ที่ว่างเปล่าระหว่างการเรียกใช้เครื่องมือจะถูกซ่อนไว้เมื่อใช้ display: "omitted" ให้เปลี่ยนเป็น display: "updates" ด้วย beta header thinking-display-updates-2026-08-18
ลบคำสั่งจากโมเดลเก่าที่บังคับให้เก็บผลลัพธ์ทั้งหมดไว้ตอบตอนท้าย
หากยังต้องการการอัปเดต ให้เพิ่มข้อความนี้ในพรอมต์ระบบ:

Before you start, say in a line what you're about to do; brief updates while you work help the user follow along. Close with a short recap that stands on its own, covering what you found, what you did, and what's next, so a reader who only sees the last message has the full picture.

หากผลิตภัณฑ์ซ่อนผลลัพธ์ของเครื่องมือ ให้ระบุอย่างชัดเจนว่า:

คุณเท่านั้นที่เห็นผลลัพธ์ของคำสั่งนั้น หากผู้ใช้จำเป็นต้องอ่านส่วนใดส่วนหนึ่ง ให้ใส่ไว้ในคำตอบของคุณ

วิธีนี้ป้องกันไม่ให้โมเดลเรียกใช้คำสั่งเพิ่มเติมเพียงเพื่อ “แสดง” ผลลัพธ์ที่ผู้ใช้มองไม่เห็น

5. ป้องกันรอบจบก่อนงานเสร็จ

ในเวิร์กโหลดแบบอะซิงโครนัสที่ซับซ้อน Fable 5.1 อาจอธิบายสิ่งที่จะทำต่อไปแทนการลงมือทำ หรือขออนุญาตสำหรับขั้นตอนที่อยู่ในคำขอเดิมแล้ว

เพิ่มข้อความนี้ในพรอมต์ระบบ:

You are operating autonomously. The user is not watching in real time and cannot answer questions mid-task, so asking 'Want me to...?' or 'Shall I...?' will block the work. For reversible actions that follow from the original request, proceed without asking. Stop only for destructive actions or genuine scope changes the user must decide. Offering follow-ups after the task is done is fine; asking permission before doing the work is not.

Before ending your turn, check your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or a promise about work you have not done, do that work now with tool calls. End your turn only when the task is complete or you are blocked on input only the user can provide.

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

หากพรอมต์ขอให้โมเดลตรวจสอบงานก่อนรายงาน ให้คงคำสั่งนั้นไว้ ต่างจากคำแนะนำสำหรับ Opus 5 ที่ให้ลบคำสั่งตรวจสอบ อ่านรายละเอียดเพิ่มเติมจาก คำแนะนำของ Opus 5

6. จำกัดการแก้ไขที่ไม่ได้ร้องขอ

เมื่อได้รับคำขอแบบปลายเปิด Fable 5.1 อาจทำมากกว่างานที่ระบุ เช่น แก้บั๊กข้างเคียง เพิ่มพฤติกรรม หรือสร้างไฟล์ทดสอบที่เกินขอบเขต

ใช้กฎนี้เพื่อลดส่วนเกิน:

If, while working or testing, you find a pre-existing bug, a performance concern, or behavior the task doesn't mention, don't fix, optimize or extend it in this change unless the requested behavior cannot work without it; report it as a follow-up in your summary. Verify your work however you like; scratch scripts and quick checks need not be kept. Commit tests only where the task asks for them or this repository already keeps tests for this kind of change, sized like the neighboring test files. This is about extras only: implement every behavior the task asks for, completely.

กฎนี้ใช้ควบคุมเฉพาะงานส่วนเกิน ไม่ได้ลดทอนพฤติกรรมที่คำขอระบุไว้

7. แก้ไฟล์แบบเฉพาะเจาะจง

Fable 5.1 มีแนวโน้มเขียนไฟล์ทั้งหมดใหม่แม้ต้องเปลี่ยนเพียงบรรทัดเดียว ทำให้ใช้โทเค็นเอาต์พุตมากขึ้น

เพิ่มข้อความนี้ในพรอมต์ระบบหรือข้อความผู้ใช้รอบแรก:

The number of tokens used to edit files is best minimized, all else being equal. Therefore, when it will not affect the end result, try to surgically edit a file rather than rewrite the entire thing.

8. ลดสำนวนที่ยาวและหนาแน่น

โดยรวมการเขียนของ Fable 5.1 ดีขึ้นและมีวลีสำเร็จรูปน้อยลง แต่บางครั้งประโยคยาวขึ้นและแบ่งย่อหน้าน้อยลง

ระบุรูปแบบที่ไม่ต้องการโดยตรง:

โปรดลบสำนวนที่ใช้ภาษาเกินจริงทั้งหมดออก

Anthropic ใช้คำว่า “mannered prose” สำหรับการเขียนที่ใช้คำเปรียบเทียบหรือถ้อยคำหรูหราแทนการสื่อสารตรง ๆ และเน้นบุคลิกผู้เขียนมากกว่าแนวคิด หากมีคำตรงตัว ให้เลือกคำนั้น

9. ให้แชทมีโครงสร้างเท่าที่เนื้อหาต้องการ

โมเดลรุ่นก่อนมักใช้หัวข้อย่อยและตัวหนามากเกินไป จึงมีพรอมต์ที่ห้ามการจัดรูปแบบจำนวนมาก แต่ Fable 5.1 กลับใช้โครงสร้างน้อยเกินไป

แนวทางที่เหมาะกว่า:

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

10. ป้องกันการสร้างคำพูดจากแหล่งที่มาโดยไม่ระบุ

เมื่อสรุปเอกสาร Fable 5.1 มีแนวโน้มทำซ้ำข้อความจากต้นฉบับโดยไม่บอกว่าเป็นคำพูด

เพิ่มตัวอย่างสมบูรณ์หนึ่งตัวอย่างในพรอมต์ระบบ ประกอบด้วย:

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

เปลี่ยนตัวแทนการเรียกใช้เครื่องมือในตัวอย่างของ Anthropic เป็นชื่อเครื่องมือจริงของคุณ

11. บังคับให้ค้นหาเมื่อใช้ความพยายามต่ำ

ที่ระดับ low Fable 5.1 อาจเรียกใช้เครื่องมือค้นหาและเรียกข้อมูลน้อยกว่า Fable 5 โดยเฉพาะเมื่อถามถึงผลิตภัณฑ์หรือโมเดลที่รู้จักชื่อ แต่ข้อมูลอาจเปลี่ยนแปลงแล้ว

มีสองแนวทาง:

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

12. ควบคุมงานส่งมอบขนาดใหญ่ที่ `xhigh` และ `max`

ที่ xhigh และโดยเฉพาะ max Fable 5.1 อาจร่างงานส่งมอบส่วนใหญ่ระหว่างการคิด แล้วเขียนซ้ำในคำตอบ ส่งผลให้เวลาและโทเค็นเอาต์พุตเพิ่มขึ้นเกือบสองเท่า

แนวทางแก้ไข:

ใช้ high เป็นค่าเริ่มต้น และเลื่อนระดับเมื่อมีผลการวัดรองรับ
หากใช้ xhigh หรือ max ให้ตั้ง max_tokens เผื่อทั้งบล็อกความคิดและคำตอบ
ระบุในข้อความผู้ใช้ว่าเหตุผลและทุกสิ่งที่สร้างในคำตอบเดียวกันนับรวมอยู่ในขีดจำกัด max_tokens เดียวกัน
เก็บสำเนาบันทึกก่อนหน้าไว้ในคำขอถัดไป

การสร้างงานส่งมอบฉบับเต็มระหว่างการคิด แล้วสร้างซ้ำอีกครั้งในคำตอบ เพิ่มรอบโดยไม่ได้เพิ่มคุณภาพ

13. ลดผลบวกลวงจากการปฏิเสธคำขอโค้ด

ตัวแยกประเภทของ Fable 5.1 ให้ผลบวกลวงน้อยกว่า Fable 5 เมื่อเปิดตัว และอนุญาตให้ค้นหาช่องโหว่ในซอร์สโค้ดได้แล้ว แต่ยังอาจปฏิเสธคำขอที่ไม่เป็นอันตรายบางส่วน

ลองปรับสามจุดนี้:

ถามว่า Are there any bugs in this program? แทน Does this program compile without errors?
ให้เอกสารสำหรับภาษาที่โมเดลรู้จักน้อย
ลบเครื่องมือที่ส่งข้อมูลเข้ารหัส Base64 เข้าสู่บริบท หากไม่จำเป็น
คงค่า fallback ที่กำหนดไว้เสมอ

ดูแนวทางเพิ่มเติมจาก คู่มือการจัดการการปฏิเสธ

14. รักษารายละเอียดระหว่างการบีบอัดฝั่งไคลเอ็นต์

Fable 5.1 ตอบสนองได้ดีเมื่อระบุชัดเจนว่าสรุปต้องเก็บรายละเอียดใดไว้ การบีบอัดฝั่งเซิร์ฟเวอร์จัดการเรื่องนี้อยู่แล้ว แต่หากคุณบีบอัดฝั่งไคลเอ็นต์ ให้สั่งให้โมเดลสรุปภายในแท็ก <summary> ตามลำดับนี้:

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

ปิดท้ายด้วยข้อความนี้:

Do not call any tools while writing this summary; respond with text only

ข้อความนี้สำคัญเมื่อคำขอสรุปยังอยู่ในบทสนทนาที่มีเครื่องมือ

15. ออกแบบเอเจนต์ย่อยและการมองเห็น

การแก้ไขสองข้อนี้เป็นเรื่องสถาปัตยกรรมมากกว่าการเขียนพรอมต์

งานเขียนโค้ด

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

แผนภูมิและตารางหนาแน่น

ให้โมเดลมีเครื่องมือครอบตัดที่ส่งคืนพื้นที่ที่เลือกในขนาดใหญ่ขึ้น หรือมีคอนเทนเนอร์พร้อมไลบรารีรูปภาพพื้นฐาน

ที่ระดับ low โมเดลอาจข้ามการครอบตัด จึงควรตรวจสอบบันทึกการเรียกใช้เครื่องมือ

16. ทดสอบการเปลี่ยนแปลงใน Apidog

การปรับทั้งหมดควรทดสอบแบบก่อนและหลัง:

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

ตัวชี้วัดที่ควรดู:

จำนวนบล็อก tool_use ต่อรอบผู้ช่วย เพื่อวัดการรวมกลุ่มเครื่องมือ
usage.output_tokens เพื่อวัดการแก้ไขแบบเฉพาะเจาะจงและความหนาแน่นของข้อความ
การไม่มีวรรคสุดท้ายที่ขึ้นต้นด้วย Next, I เพื่อวัดความเป็นอิสระของเอเจนต์

ใช้ Apidog เพื่อสร้างและรันทดสอบ และอ่าน คู่มือ Claude Code เพื่อดูว่าควรเพิ่มบรรทัดใดใน CLAUDE.md

คำถามที่พบบ่อย

พรอมต์ Fable 5 ของฉันใช้งานบน Fable 5.1 ได้หรือไม่?

ได้ Anthropic ระบุว่าพรอมต์เดิมควรทำงานได้ดีโดยไม่ต้องเปลี่ยนแปลง ความแตกต่างหลักอยู่ที่พฤติกรรมโดยรอบ ได้แก่ การเรียกใช้เครื่องมือแบบกลุ่มที่น้อยลง การอัปเดตความคืบหน้าที่น้อยลง สำนวนที่หนาแน่นขึ้น การจัดรูปแบบแชทที่น้อยลง การเขียนไฟล์ใหม่ทั้งหมด และขอบเขตงานที่ขยายในงานปลายเปิด

ควรใช้ระดับความพยายามใด?

เริ่มที่ high แล้วทดสอบกับชุดประเมินของคุณ Anthropic ระบุว่า medium อาจให้ผลลัพธ์ใกล้เคียง Fable 5 ด้วยค่าใช้จ่ายต่ำกว่า ส่วน low อาจแข่งขันกับ Opus และ Sonnet ได้ในด้านค่าใช้จ่ายต่องาน

ควรวางคำสั่งต่อรอบไว้ที่ไหน?

ใช้ system message แบบขอบเขตต่อรอบที่มี clear_at: "next_user_message" หลังผลลัพธ์ของเครื่องมือ และเก็บสำเนาเก่าไว้ การแทรกหรือลบข้อความจากประวัติรอบก่อนจะทำให้บล็อกความคิดถัดไปไม่ถูกต้องและรีสตาร์ทแคช

ควรลบคำสั่ง “ตรวจสอบงานของคุณ” เหมือน Opus 5 หรือไม่?

ไม่ควรลบ คำแนะนำดังกล่าวเป็นกรณีเฉพาะของการตรวจสอบที่มากเกินไปใน Opus 5 ให้คงคำสั่งตรวจสอบไว้บน Fable 5.1

จะหยุดไม่ให้ Fable 5.1 เขียนไฟล์ทั้งหมดใหม่ได้อย่างไร?

เพิ่มข้อความนี้ในพรอมต์ระบบหรือข้อความผู้ใช้รอบแรก:

The number of tokens used to edit files is best minimized, all else being equal. Therefore, when it will not affect the end result, try to surgically edit a file rather than rewrite the entire thing.

ลิงก์อ้างอิง

Claude Fable 5.1 Benchmarks: ผลการทดสอบเผยความจริงของตัวเลข

Thanawat Wongchai — Wed, 02 Sep 2026 03:04:10 +0000

Claude Fable 5.1: วิเคราะห์ตัวเลข Benchmark และสิ่งที่ควรทดสอบเอง

Anthropic เปิดตัว Claude Fable 5.1 เมื่อวันที่ 1 กันยายน 2026 พร้อมผลการเปรียบเทียบกับ Fable 5, Opus 5 และ GPT-5.6 Sol ใน 9 การทดสอบ จุดเด่นคือ Terminal-Bench-Science ที่ Fable 5.1 ทำได้ 52.6% เทียบกับ 24.7% ของ Fable 5 ส่วนตัวเลขที่ถูกพูดถึงน้อยกว่าคือ CursorBench ซึ่งนำ Opus 5 เพียง 3.4 จุด แม้ Opus 5 จะมีราคาสูงกว่าถึงสองเท่า

ลองใช้ Apidog วันนี้

บทความนี้รวมตัวเลขทั้งหมดพร้อมแหล่งที่มา อธิบายว่าแต่ละ benchmark วัดอะไร แยกความแตกต่างที่มีนัยสำคัญออกจากความแตกต่างเล็กน้อย และชี้ให้เห็นข้อจำกัดของข้อมูล: ผลลัพธ์ทั้งหมดจัดทำโดยผู้ขาย, Mythos 5.1 ทำคะแนนได้ดีกว่า Fable 5.1 ในการทดสอบ agentic coding ที่เผยแพร่ทั้งสองรุ่น และวิธีตัดสินใจที่ถูกต้องคือการทดสอบกับงานจริงของคุณเอง แหล่งข้อมูลหลักคือ โพสต์เปิดตัวของ Anthropic ส่วนบริบทของโมเดลอยู่ในบทความ Claude Fable 5.1 คืออะไร

ตาราง benchmark ฉบับเต็ม

Benchmark	สิ่งที่วัดผล	Fable 5.1	Fable 5	Opus 5	GPT-5.6 Sol
Terminal-Bench-Science 0.1	การวิจัยทางวิทยาศาสตร์แบบ agentic ในเทอร์มินัล	52.6%	24.7%	29.0%	22.4%
Terminal-Bench 4.0	การเขียนโค้ดแบบ agentic ในเทอร์มินัล	55.8%	42.0%	52.3%	37.3%
GDPval-AA v2	งานความรู้ที่มีมูลค่าทางเศรษฐกิจ (Elo)	1853	1723	1824	1711
OSWorld 2.0 (partial credit)	การใช้งานคอมพิวเตอร์ในงานเดสก์ท็อปจริง	77.9%	72.9%	75.4%	ไม่ได้รายงาน
OSWorld 2.0 (strict)	งานแบบเดียวกัน โดยนับเฉพาะงานที่เสร็จสมบูรณ์	41.7%	36.1%	39.6%	ไม่ได้รายงาน
Humanity’s Last Exam (no tools)	คำถามการให้เหตุผลระดับผู้เชี่ยวชาญ	60.9%	57.8%	56.6%	ไม่ได้รายงาน
Humanity’s Last Exam (with tools)	งานเดียวกัน พร้อมการค้นหาและโค้ด	65.0%	63.8%	63.6%	ไม่ได้รายงาน
AutomationBench	เวิร์กโฟลว์ธุรกิจแบบครบวงจร	31.4%	17.1%	26.9%	19.6%
CursorBench 3.2.0	งานเขียนโค้ดสไตล์ IDE	73.4%	70.5%	70.0%	67.2%

Anthropic ยังเผยแพร่ตัวเลขของ Mythos 5.1 หนึ่งรายการ คือ 60.9% บน Terminal-Bench 4.0 ขณะที่ VentureBeat รายงานผล Browserbase ของ Fable 5.1 ที่ 82% เทียบกับ 74% ของ Opus 5 และ 57% ของ Fable 5 ในงาน browser-agent ที่ยากที่สุด ตัวเลข Browserbase มาจากข่าวประชาสัมพันธ์ ไม่ใช่โพสต์เปิดตัว จึงควรใช้ด้วยความระมัดระวัง

ความแตกต่างที่ชัดเจน

Terminal-Bench-Science 0.1

52.6% เทียบกับ 24.7% ของ Fable 5 และ 29.0% ของ Opus 5

นี่คือผลลัพธ์ที่โดดเด่นที่สุด Fable 5.1 ทำคะแนนได้มากกว่าสองเท่าของรุ่นก่อนหน้า และเกือบสองเท่าของ Opus 5 โดย benchmark นี้ให้โมเดลใช้เทอร์มินัลและเครื่องมือทางวิทยาศาสตร์เพื่อทำวิจัยหลายขั้นตอน

ผลลัพธ์นี้เป็นหลักฐานที่ชัดเจนที่สุดว่าการมุ่งเน้นของ Anthropic ในการ “แก้ปัญหาที่มีความซับซ้อนในระยะยาว” สร้างผลลัพธ์ที่วัดได้จริง อย่างไรก็ตาม นี่คือ benchmark เวอร์ชัน 0.1 ชุดงานยังใหม่ และคะแนนอาจเปลี่ยนแปลงในอนาคต

AutomationBench

31.4% เทียบกับ 17.1% ของ Fable 5 และ 26.9% ของ Opus 5

AutomationBench วัดเวิร์กโฟลว์ธุรกิจแบบครบวงจรที่ทำงานข้ามหลายแอปพลิเคชัน แม้คะแนนรวมของทุกโมเดลยังต่ำ แต่ Fable 5.1 ทำได้เกือบสองเท่าของ Fable 5 และนำ Opus 5 อยู่ 4.5 จุด

หากผลิตภัณฑ์ของคุณต้องทำงานอัตโนมัติข้ามหลายแอปพลิเคชัน แถวนี้ควรได้รับความสนใจเป็นพิเศษ

Terminal-Bench 4.0

55.8% เทียบกับ 42.0% ของ Fable 5

Fable 5.1 นำ Fable 5 อยู่ 13.8 จุดในงาน agentic coding ซึ่งเป็นตัวเลขหลักที่ Anthropic ใช้สื่อสารด้านการเขียนโค้ด เมื่อเทียบกับ Opus 5 ส่วนต่างอยู่ที่ 3.5 จุด

Opus 5 เคยนำ Fable 5 ใน benchmark นี้เมื่อเดือนกรกฎาคม ดังนั้นข้อได้เปรียบของ Fable เหนือ Opus จึงกลับมาอีกครั้ง แต่แคบลงเมื่อเทียบกับเดือนมิถุนายน ดูตัวเลขเพิ่มเติมได้ใน รายละเอียด benchmark ของ Opus 5

GDPval-AA v2

1853 เทียบกับ 1723 ของ Fable 5

Fable 5.1 เพิ่มขึ้น 130 Elo ในงานความรู้ และเป็น benchmark ที่ Anthropic ใช้อ้างอิงสำหรับงานเอกสาร สเปรดชีต และสไลด์ เมื่อเทียบกับ Opus 5 ส่วนต่างอยู่ที่ 29 Elo ซึ่งถือว่าไม่มาก

ความแตกต่างเล็กน้อย

CursorBench 3.2.0

73.4% เทียบกับ 70.5% ของ Fable 5 และ 70.0% ของ Opus 5

CursorBench วัดงานเขียนโค้ดสไตล์ IDE Fable 5.1 นำทั้งสองโมเดลประมาณ 3 จุด แต่เป็น benchmark ที่แสดงส่วนต่างน้อยที่สุด

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

OSWorld 2.0

77.9% / 41.7% เทียบกับ 75.4% / 39.6% ของ Opus 5

Fable 5.1 นำ Opus 5 อยู่ประมาณ 2 จุดทั้งใน partial credit และ strict scoring และนำ Fable 5 อยู่ประมาณ 5 จุด

อย่างไรก็ตาม strict score แสดงให้เห็นว่างานที่เสร็จสมบูรณ์มีไม่ถึงครึ่งในทุกโมเดล การใช้งานคอมพิวเตอร์จึงยังเป็นจุดอ่อนสำคัญของโมเดลชั้นนำ

Humanity’s Last Exam

60.9% / 65.0% เทียบกับ 56.6% / 63.6% ของ Opus 5

เมื่อไม่ใช้เครื่องมือ Fable 5.1 นำ Opus 5 อยู่ 4.3 จุด ซึ่งเป็นส่วนต่างที่มากที่สุดในกลุ่มความแตกต่างเล็กน้อย เมื่อเปิดใช้เครื่องมือ ส่วนต่างลดลงเหลือ 1.4 จุด เพราะการค้นหาและการรันโค้ดช่วยลดความแตกต่างระหว่างโมเดล

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

Fable 5.1 เทียบกับ GPT-5.6 Sol

Anthropic เผยแพร่ผลเปรียบเทียบที่มี GPT-5.6 Sol อยู่ 4 แถว และ Fable 5.1 เป็นผู้นำทั้งหมด:

Terminal-Bench-Science: นำ 30.2 จุด
Terminal-Bench 4.0: นำ 18.5 จุด
AutomationBench: นำ 11.8 จุด
CursorBench: นำ 6.2 จุด

GDPval-AA v2 อยู่ที่ 1853 เทียบกับ 1711

ควรพิจารณาข้อมูลนี้โดยคำนึงถึงข้อจำกัดสองประการ:

Anthropic เป็นผู้ดำเนินการทดสอบโมเดลของคู่แข่งเอง
GPT-5.6 Sol ไม่มีข้อมูลในอีก 5 จาก 9 benchmark โดย Anthropic ไม่ได้ระบุเหตุผล

การเปรียบเทียบ GPT-5.6 Sol กับ Fable 5 ครอบคลุมการแข่งขันในรุ่นก่อนหน้า จากตัวเลขชุดนี้ Fable 5.1 ขยายช่องว่างที่ Fable 5 เคยมีอยู่ทั้งหมด

สิ่งที่ข่าวเปิดตัวไม่ได้กล่าวถึง

ตัวเลขทั้งหมดดำเนินการโดยผู้ขาย

Anthropic เป็นผู้จัดทำผลลัพธ์ทั้งหมด รวมถึงคอลัมน์ของคู่แข่ง และยังไม่มีห้องปฏิบัติการอิสระทำซ้ำผลลัพธ์เหล่านี้ ณ วันที่เปิดตัว

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

Mythos 5.1 คือขีดจำกัดที่แท้จริง

ทั้ง system card และโพสต์เปิดตัวของ Anthropic ระบุว่า Fable 5.1 และ Mythos 5.1 เป็น “โมเดลเดียวกันแต่มีระดับการป้องกันที่แตกต่างกัน”

Mythos 5.1 ทำได้ 60.9% บน Terminal-Bench 4.0 เทียบกับ 55.8% ของ Fable 5.1 ช่องว่าง 5 จุดนี้สะท้อนต้นทุนของการป้องกันในงาน agentic coding และแสดงให้เห็นว่าโมเดลที่ Anthropic เปิดให้ใช้งานในวงกว้างยังมีรุ่นที่มีความสามารถสูงกว่า

การเปรียบเทียบ Mythos 5.1 กับ Fable 5.1 อธิบายเพิ่มเติมว่าใครเข้าถึง Mythos 5.1 ได้บ้าง

ไม่ระบุระดับความพยายาม

เอกสาร effort ของ Anthropic ระบุว่า Fable 5.1 ได้ประโยชน์มากที่สุดที่ระดับ xhigh และ max

แต่โพสต์เปิดตัวไม่ได้ระบุว่าคะแนนแต่ละรายการเกิดขึ้นที่ระดับใด หรือโมเดลที่นำมาเปรียบเทียบใช้ effort ระดับใด เนื่องจาก effort มีผลโดยตรงต่อคุณภาพ การขาดข้อมูลนี้ทำให้การทำซ้ำผลลัพธ์ทำได้ยาก

ภาษาต่างประเทศไม่ได้ดีขึ้น

Anthropic ระบุว่าประสิทธิภาพด้านภาษาต่างประเทศใกล้เคียงกับ Fable 5 ไม่ได้เพิ่มขึ้น หากภาระงานของคุณไม่ใช่ภาษาอังกฤษ ตารางเปิดตัวอาจทำให้ประเมินการปรับปรุงสูงเกินจริง

ตัวเลขด้านความปลอดภัยเป็น benchmark คนละประเภท

Anthropic รายงานว่า:

false positive ด้านชีววิทยาลดลง 85% ในคำขอที่ไม่เป็นอันตราย
การแทรกแซงด้านไซเบอร์ลดลงประมาณ 60% ต่อเซสชัน Claude Code เมื่อเทียบกับ Fable 5

ตัวเลขเหล่านี้มาจากทราฟฟิกของ Anthropic เองและไม่สามารถทำซ้ำจากภายนอกได้ แต่สำหรับผู้ใช้ Fable 5 ที่พบการปฏิเสธบ่อยครั้ง ตัวเลขดังกล่าวอาจสำคัญกว่าคะแนน benchmark ด้านประสิทธิภาพ

สิ่งที่ควรทดสอบด้วยตนเอง

ตาราง benchmark ช่วยบอกว่าควรตรวจสอบจุดใด แต่การประเมินจากงานจริงจะบอกว่าควรย้ายโมเดลหรือไม่ ลองทดสอบ 4 กรณีต่อไปนี้:

งาน agent ระยะยาวจากผลิตภัณฑ์จริง

รันงานจนเสร็จบน Fable 5.1 ที่ระดับ high, Opus 5 ที่ xhigh และ Fable 5 ที่ high เพื่อจำลอง Terminal-Bench-Science และ AutomationBench จากนั้นคำนวณว่าคุณภาพที่เพิ่มขึ้นคุ้มกับราคาที่สูงกว่าสองเท่าหรือไม่
พร้อมท์เขียนโค้ดที่ยากที่สุด 10 รายการ

รันด้วย effort ระดับเดียวกันบน Fable 5.1 และ Opus 5 หากผลลัพธ์ใกล้เคียงกัน คุณอาจได้ผลแบบเดียวกับ CursorBench และ Opus 5 อาจเป็นตัวเลือกที่คุ้มค่ากว่า
ทดสอบ effort ของ Fable 5.1

รันงานประจำตั้งแต่ low ถึง max Anthropic อ้างว่า medium ใกล้เคียงกับ Fable 5 และ low อาจแข่งขันกับ Opus 5 ได้ในด้านต้นทุนต่องาน ตรวจสอบข้ออ้างนี้กับข้อมูลของคุณเอง
วัดจำนวนการปฏิเสธ

ใช้ชุดพร้อมท์ด้านความปลอดภัยและชีววิทยาที่ไม่เป็นอันตราย เปรียบเทียบ Fable 5 กับ Fable 5.1 เพื่อทดสอบข้ออ้างเรื่องการลด false positive 60% และ 85%

สร้างการทดสอบทั้งสี่เป็นคำขอใน Apidog โดยกำหนด model และ effort เป็นตัวแปรสภาพแวดล้อม เพิ่มการตรวจสอบค่า stop_reason และตรวจสอบว่าสตริงที่คาดหวังปรากฏในคำตอบ จากนั้นเรียกใช้คอลเลกชันแยกตามโมเดล

ประวัติการเรียกใช้จะช่วยสร้างตารางประเมินผลที่ทำซ้ำได้โดยไม่ต้องเพิ่มโครงสร้างพื้นฐาน ดาวน์โหลด Apidog เพื่อเริ่มต้น และดู คำแนะนำการใช้งาน Claude API สำหรับรูปแบบคำขอ

Benchmark เหล่านี้เชื่อมโยงกับการตัดสินใจอย่างไร

Agent ระยะยาว การวิจัย และระบบอัตโนมัติ: ความแตกต่างมีขนาดใหญ่และสอดคล้องกัน Fable 5.1 เป็นตัวเลือกที่แนะนำ และ รายละเอียดราคา แสดงให้เห็นว่าราคา cache read ที่ลดลงช่วยลดต้นทุนของงานประเภทนี้
การเขียนโค้ดใน IDE, Q&A ด้านความรู้ และ reasoning ที่ใช้เครื่องมือ: ส่วนต่างกับ Opus 5 อยู่ที่ประมาณ 1–4 จุด ให้ใช้ Opus 5 ต่อ เว้นแต่จะล้มเหลวในการประเมินของคุณที่ effort สูงกว่า ดูรายละเอียดใน Fable 5.1 เทียบกับ Opus 5
ผู้ใช้ที่ย้ายจาก Fable 5: ทุก benchmark ดีขึ้น ราคาไม่เปลี่ยน และอัตรา false positive ลดลง การเปรียบเทียบ Fable 5.1 กับ Fable 5 ครอบคลุมต้นทุนการย้ายเพิ่มเติม

คำถามที่พบบ่อย

ผล benchmark ที่ดีที่สุดของ Claude Fable 5.1 คืออะไร?

Terminal-Bench-Science 0.1 ที่ 52.6% มากกว่าสองเท่าของ Fable 5 ที่ 24.7% และนำหน้า Opus 5 ที่ 29.0% กับ GPT-5.6 Sol ที่ 22.4% ตัวเลขทั้งหมดมาจาก Anthropic

Fable 5.1 เทียบกับ Opus 5 ในการเขียนโค้ดเป็นอย่างไร?

Fable 5.1 ทำได้ 55.8% เทียบกับ 52.3% บน Terminal-Bench 4.0 และ 73.4% เทียบกับ 70.0% บน CursorBench 3.2.0 ตามตัวเลขของ Anthropic Fable 5.1 นำอยู่จริง แต่ส่วนต่างประมาณ 3 จุด

Fable 5.1 ดีกว่า GPT-5.6 Sol หรือไม่?

ใน 4 benchmark ที่ Anthropic เผยแพร่ผลของทั้งสองโมเดล คำตอบคือใช่ โดยนำอยู่ 6–30 จุด อย่างไรก็ตาม Anthropic เป็นผู้ทดสอบ GPT-5.6 Sol เอง และไม่มีข้อมูลของ GPT-5.6 Sol ใน 5 จาก 9 แถว

ผล benchmark ของ Fable 5.1 ได้รับการตรวจสอบโดยอิสระหรือไม่?

ยังไม่ได้รับการตรวจสอบโดยอิสระ ณ วันที่เปิดตัว ตัวเลขทั้งหมดจัดทำโดย Anthropic จึงควรทดสอบกับภาระงานจริงของคุณ

Mythos 5.1 ทำคะแนนได้เท่าไหร่?

Anthropic เผยแพร่ตัวเลขเดียวคือ 60.9% บน Terminal-Bench 4.0 สูงกว่า Fable 5.1 ที่ 55.8% อยู่ 5 จุด ทั้งสองเป็นโมเดลเดียวกันแต่มีระดับการป้องกันแตกต่างกัน

ระดับ effort ใดทำให้เกิดคะแนนเหล่านี้?

Anthropic ไม่ได้ระบุระดับ effort ของแต่ละคะแนน เอกสารระบุว่า Fable 5.1 ได้ประโยชน์มากที่สุดที่ xhigh และ max ดังนั้นควรตั้งสมมติฐานว่าการทดสอบใช้ effort สูง และคาดว่าค่าที่ต่ำกว่าจะได้คะแนนลดลง

DEV Community: Thanawat Wongchai

GPT-6 Astra ใช้คอมพิวเตอร์คุณได้: มอบ OpenAPI spec ให้แทน

สรุปโดยย่อ (TL;DR)

GPT-6 Astra ใช้งานคอมพิวเตอร์ทำอะไรได้บ้าง

งาน 40 นาทีมีค่าใช้จ่ายเท่าไร

เส้นทาง OpenAPI spec

การใช้งานคอมพิวเตอร์เทียบกับสัญญา API

วิธีมอบสัญญา API ให้ Astra

1. ให้ไฟล์ OpenAPI แก่ Astra

2. เชื่อมต่อโปรเจกต์ผ่าน MCP

3. แปลง Spec เป็นฟังก์ชันเครื่องมือ

4. รันสถานการณ์โดยไม่ใช้โมเดล

รักษารั้วป้องกันไว้ แม้ Astra จะเคารพก็ตาม

เมื่อใดควรใช้การควบคุมหน้าจอ

คำถามที่พบบ่อย

สรุป

Gemini 3.8 Flash เทียบกับ 3.7 Flash: เปลี่ยนไปแค่ไหน คุ้มค่าที่จะอัปเกรดไหม

Gemini 3.8 Flash เทียบกับ Gemini 3.7 Flash: ควรอัปเกรดหรือไม่?

เปรียบเทียบ Gemini 3.8 Flash กับ 3.7 Flash

สิ่งที่ยังเหมือนเดิม

ราคาและโควตา

คอนเท็กซ์และรูปแบบข้อมูล

ความเร็ว

พื้นผิว API

สิ่งที่ Gemini 3.8 Flash ปรับปรุง

Benchmark จาก Google

ผลทดสอบจาก Artificial Analysis

งานเอกสารและเอเจนต์หลายขั้นตอน

การเขียนโค้ด

ความปลอดภัยและ Prompt Injection

ค่าใช้จ่ายต่อโทเค็นเท่าเดิม แต่ค่าใช้จ่ายต่อภารกิจเพิ่มขึ้น

Breaking changes ที่ต้องแก้ก่อนย้าย

1. thinking_level: "minimal" ไม่รองรับ

2. Function response ต้องมี ID และชื่อ

ตารางตัดสินใจตามปริมาณงาน

ทดสอบโมเดลทั้งสองกับพรอมต์จริงใน Apidog

1. ตั้งค่า environment

2. สร้าง scenario เปรียบเทียบ

3. ตั้งเวลารันเพื่อเฝ้าระวังค่าใช้จ่าย

คำถามที่พบบ่อย

Gemini 3.8 Flash เร็วกว่า 3.7 Flash หรือไม่?

Gemini 3.8 Flash แพงกว่า 3.7 Flash หรือไม่?

Google จะเลิกใช้ Gemini 3.7 Flash หรือไม่?

มีอะไรที่จะใช้งานไม่ได้เมื่อเปลี่ยนไปใช้ 3.8 Flash?

การเปลี่ยนจาก 3.6 ไป 3.7 ใหญ่กว่าการเปลี่ยนเป็น 3.8 หรือไม่?

สรุป

เจมิไน 3.8 แฟลช: เปรียบเทียบระดับการคิด ต่ำ ปานกลาง สูง พร้อมเหตุผลที่ระดับ Minimal หายไป

ตั้งค่า thinking_level ของ Gemini 3.8 Flash ให้เหมาะกับแต่ละเส้นทาง

ระดับการคิดโดยสรุป

แต่ละระดับควบคุมอะไร

ค่าเริ่มต้นคือ medium ไม่ใช่ high

minimal ไม่รองรับแล้ว: วิธีแก้ข้อผิดพลาด

ก่อนย้ายข้อมูล

หลังย้ายข้อมูล

ค่าใช้จ่ายของแต่ละระดับ

ตั้งค่า thinking_level ใน Interactions API

cURL

Python

ตั้งค่าใน generateContent แบบดั้งเดิม

cURL

Python

กลยุทธ์เลือกใช้ตามเส้นทาง

ทดสอบทั้งสามระดับใน Apidog

คำถามที่พบบ่อย

ระดับการคิดเปลี่ยนราคาต่อโทเค็นหรือไม่

กำหนดงบประมาณ thinking tokens แบบตายตัวได้หรือไม่

คะแนน Artificial Analysis ที่ 59 ใช้ระดับใด

ควรลด temperature เพื่อลดการคิดหรือไม่

ถ้าแม้แต่ low ยังช้าหรือแพงเกินไปควรทำอย่างไร

สรุป: เลือกระดับต่อเส้นทาง แล้ววัดผล

วิธีใช้ Gemini 3.8 Flash API: Interactions API, ระดับการคิด และการเรียกใช้ครั้งแรกใน Apidog

Gemini 3.8 Flash API: คู่มือเชื่อมต่อและควบคุมค่าใช้จ่าย

Gemini 3.8 Flash API โดยสังเขป

ขั้นตอนที่ 1: รับ API key ใน AI Studio

ขั้นตอนที่ 2: เรียกใช้ครั้งแรกด้วย Interactions API

ขั้นตอนที่ 3: สนทนาหลายรอบด้วย previous_interaction_id

ขั้นตอนที่ 4: ใช้ generateContent แบบเดิม

เปรียบเทียบการตั้งค่าใน API ทั้งสองแบบ

ขั้นตอนที่ 5: สตรีมและอ่านค่าใช้จ่ายในการคิด

ข้อผิดพลาดที่พบบ่อยในชั่วโมงแรก

1. `thinking_level: "minimal"` ไม่รองรับ

ตั้งค่า `thinking_level` ของ Gemini 3.8 Flash ให้เหมาะกับแต่ละเส้นทาง

ค่าเริ่มต้นคือ `medium` ไม่ใช่ `high`

`minimal` ไม่รองรับแล้ว: วิธีแก้ข้อผิดพลาด

ตั้งค่า `thinking_level` ใน Interactions API

ตั้งค่าใน `generateContent` แบบดั้งเดิม

ควรลด `temperature` เพื่อลดการคิดหรือไม่

ถ้าแม้แต่ `low` ยังช้าหรือแพงเกินไปควรทำอย่างไร

ขั้นตอนที่ 3: สนทนาหลายรอบด้วย `previous_interaction_id`

ขั้นตอนที่ 4: ใช้ `generateContent` แบบเดิม

ขั้นตอนที่ 1: เปิด AI Studio และเลือก `gemini-3.8-flash`

แก้ข้อผิดพลาด `thinking block` ผูกกับบทสนทนาอื่นใน Claude Fable 5.1

วิธีแก้ฉุกเฉินด้วย `drop_block`

2. ทดสอบด้วย `drop_block`

ทำให้ harness เป็นแบบ `append-only`