แนวคิดที่ Anthropic ยกมาคือ ให้ Sonnet 5 เป็น executor ทำงานหลักใน loop ปกติ แล้วให้ Fable 5 เป็น advisor ที่ถูกเรียกเฉพาะตอนต้องใช้ judgment สูง เช่น วางแผน ตัดสินใจ architecture แก้ทางเมื่อเริ่มหลุด หรือ review ก่อนจบงาน ผมว่ามันเป็น pattern ที่ practical มาก เพราะมันไม่ได้พยายามลดคุณภาพด้วยการใช้โมเดลเล็กอย่างเดียว แต่ใช้โมเดลฉลาดให้ถูกจังหวะมากกว่า

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพูช่วยกันเรียบเรียง โดยอิงจากโพสต์ของ ClaudeDevs บน X, เอกสาร Advisor tool ของ Anthropic และ Claude Cookbook แล้วนำมาตีความเป็นแนวทางใช้งานจริงสำหรับคนทำ AI agent / coding agent

ต้นทางของเรื่องนี้สรุปไว้สั้นมากว่า หนึ่งใน pattern ที่ Anthropic ใช้กับ Fable 5 คือ “ใช้ Fable 5 เป็น advisor” โดย executor อย่าง Sonnet 5 จะเรียก Fable 5 เพื่อขอคำแนะนำ ดังนั้นการทำงานส่วนใหญ่จะใช้ token ไปกับ executor ที่ Sonnet 5 ทำมากกว่า

ต้องเข้าใจก่อนว่า agent workload ไม่ต้องใช้โมเดลฉลาดทุกงาน

เวลาพูดถึง AI coding agent หรือ agent ที่ทำงานหลาย step ผมคิดว่าหลายคนมักติดกับดักว่า “ใช้โมเดลฉลาดสุดไปเลยจะได้จบ” ซึ่งจริงในบางงาน แต่ไม่จริงเสมอไป โดยเฉพาะงานยาวๆ ที่มี token จำนวนมากถูกใช้ไปกับงาน mechanical มากกว่า reasoning

ในงานหนึ่งๆ มักมี 2 ส่วนปนกัน:

• ส่วนที่ต้องคิดจริง: แตกโจทย์, ตีความ requirement, เลือก architecture, ประเมิน trade-off, หาทางออกตอนติดปัญหา
• ส่วนที่ต้องทำเยอะ: อ่านไฟล์, อ่านเว็บ, grep โค้ด, ดู log, แก้ไฟล์, รัน test, สรุป output จาก tool

ถ้าใช้โมเดลระดับ frontier ทำทั้งสองส่วนทั้งหมด ก็โครตจะเปลือง token เลยครับ เพราะถูกใช้ไปกับงานทั่วไปที่ไม่ต้องการ frontier reasoning ทุกบรรทัด เช่น อ่านหน้าเว็บยาวๆ หรือไล่ log หลายพันบรรทัด ตรงนี้เองที่ทำให้ค่าใช้จ่ายสูงโดยไม่จำเป็น

ผมขอเปรียบให้เห็นภาพง่ายๆ เหมือนเอา senior engineer ไปนั่งอ่าน log ทุกบรรทัดเอง ซึ่งงานเขาควรเข้ามาตอนวางทิศทาง ตรวจจุดเสี่ยง หรือช่วยตัดสินใจเรื่องที่ถ้าผิดแล้วจะเสียเวลาเยอะ ส่วนงานอ่าน/เก็บข้อมูล/ทำตามขั้นตอนให้คนที่เร็วกว่าและต้นทุนต่ำกว่าช่วยทำได้

หรือเทียบในงานก่อสร้าง ก็เหมือนเอาวิศะไปก่ออิฐฉาบปูนแทนคนงานก่อสร้าง แทนที่วิศวะจะออกแบบ วางแผน และคนงานจะเป็นคนทำ

เแนวคิด: Sonnet 5 เป็นคนทำงานหลัก ส่วน Fable 5 เป็นคนให้คำปรึกษา

จาก diagram ในโพสต์ของ ClaudeDevs โครงสร้างคือ Sonnet 5 ทำหน้าที่ executor และรัน main loop ทุก turn ส่วน Fable 5 เป็น advisor ที่ถูกเรียกผ่าน tool call เฉพาะเมื่อจำเป็น พูดง่ายๆ คือ Sonnet ทำงานหนัก แต่ Fable ช่วยคิดตอนที่ต้องคิดอย่างมีเหตุมีผล

เอกสาร Advisor tool ของ Anthropic อธิบายแนวคิดนี้ว่า executor model ที่เร็วกว่า/ต้นทุนต่ำกว่า สามารถ consult advisor model ที่ฉลาดกว่า mid-generation ได้ โดย advisor จะเห็น conversation transcript ทั้งหมด แล้วส่งคำแนะนำกลับมาให้ executor ทำงานต่อ

จุดที่ผมว่าสำคัญคือ advisor ไม่ได้มาแทน executor แต่เป็นเหมือน reviewer หรือ architect ที่ถูกเรียกในจังหวะที่ควรเรียก ทำให้เรายังได้คุณภาพจากโมเดลใหญ่ในการตัดสินใจสำคัญๆ แต่ไม่ต้องจ่ายราคาโมเดลใหญ่กับทุกการทำงานง่ายๆ หลายงาน

แล้ว Advisor tool ทำงานยังไง?

เมื่อเราเพิ่ม advisor tool เข้าไปใน tools array แล้ว ตัว executor จะตัดสินใจเองว่าจะเรียก advisor เมื่อไรเหมือน tool อื่นๆ แต่การ call นี้เกิดฝั่ง server ภายใน request เดียว ไม่ใช่ client ต้อง orchestration เองหลายรอบ

• executor สร้าง server_tool_use ชื่อ advisor
• server ส่ง transcript ทั้งหมดให้ advisor model
• advisor ส่งคำแนะนำกลับมาเป็น advisor_tool_result
• executor ใช้คำแนะนำนี้ทำงานต่อจนจบ

ตัวอย่างแบบย่อจากเอกสาร Anthropic:

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    betas=["advisor-tool-2026-03-01"],
    tools=[
        {
            "type": "advisor_20260301",
            "name": "advisor",
            "model": "claude-opus-4-8",
        }
    ],
    messages=[
        {
            "role": "user",
            "content": "Build a concurrent worker pool in Go with graceful shutdown.",
        }
    ],
)

ถ้านำ concept นี้มาเทียบกับโพสต์ Fable 5 ภาพในหัวจะประมาณนี้:

tools=[
    {
        "type": "advisor_20260301",
        "name": "advisor",
        "model": "claude-fable-5",
        "max_tokens": 2048,
        "max_uses": 2,
    }
]

ตรงนี้ max_tokens กับ max_uses สำคัญมาก เพราะถ้าเปิด advisor ไว้แบบไม่จำกัด มันอาจกลายเป็น “เรียกโมเดลแพงบ่อยขึ้น” แทนที่จะช่วยประหยัด token

วิธีใช้ให้ประหยัด token จริง

1. ให้ executor อ่านบริบทก่อน แล้วค่อยเรียก advisor

ผมคิดว่าเราไม่ควรเรียก Fable 5 ตั้งแต่ครั้งแรกที่ยังไม่รู้อะไรเลย เพราะคำแนะนำจะกว้างเกินไป วิธีที่ดีกว่าคือให้ Sonnet 5 อ่านทำความเข้าใจบริบทแรกของเราก่อน เช่น requirement, โครง repo, error log หรือไฟล์หลัก แล้วค่อยเรียก Fable 5 เพื่อช่วยวางแผน

2. ใช้ advisor ในจุดที่ตัดสินใจผิดแล้วแพง

จุดที่คุ้มจะเรียก advisor คือจุดที่ถ้าคิดผิดแล้วต้องแก้งานเยอะ เช่น:

• เลือก architecture หรือ migration strategy
• ตีความ requirement ที่กำกวม
• เจอ test fail ซ้ำๆ แล้วแนวทางเดิมแก้ไม่ได้ หรือไม่ครอบคลุม
• ก่อนจบงาน เพื่อ review ว่าหลุด security, edge case หรือ test อะไรไหม

3. จำกัดจำนวนครั้งด้วย max_uses

ถ้างานหนึ่งควรเรียก advisor แค่ 1–2 ครั้ง ก็ตั้ง max_uses ไว้เลย จะช่วยไม่ให้ executor เรียก advisor ถี่เกินไปใน request เดียว

4. จำกัดคำตอบของ advisor ด้วย max_tokens

เอกสาร Anthropic แนะนำจุดเริ่มต้นที่ max_tokens: 2048 สำหรับ advisor output cap โดยระบุว่าในการทดสอบของเขา การตั้ง cap นี้ลด output ของ advisor ได้มากเมื่อเทียบกับการไม่ตั้ง และยังไม่เห็นว่าคุณภาพลดลงเท่าไรอย่างชัดเจน (quality degradation) แต่ประโยคสำคัญคือ เราต้องตรวจสอบกับ workload ของตัวเองเสมอนะ เพื่อป้องกันความผิดพลาด เนื่องจากจำกัด token (ผมเคยเจอบ่อยว่า output งานออกมาได้ไม่ถูกต้อง หรือโค้ดไม่ครบ)

5. เปิด caching เฉพาะงานที่เรียก advisor หลายครั้ง

ใน docs ระบุว่า advisor-side caching จะเริ่มคุ้มเมื่อคาดว่าจะมี advisor call ประมาณ 3 ครั้งขึ้นไปใน conversation เดียว ถ้างานสั้นๆ เรียกครั้งเดียวหรือสองครั้ง การเปิด cache อาจไม่คุ้ม เพราะ cache write ก็มีต้นทุนของมันเอง

อีกแนวคิดที่คล้ายกัน คือ Plan big, execute small

ใน Claude Cookbook เรื่อง Coordinator pattern Anthropic อธิบายอีก pattern ที่คล้ายกันมาก คือให้โมเดลใหญ่เป็น coordinator สำหรับวางแผนและสังเคราะห์คำตอบ ส่วน worker model ที่ถูกกว่าเป็นคนอ่านเว็บหรือดึงข้อมูลจำนวนมากใน context ของตัวเอง

ในการทดลองที่ Anthropic ยกตัวอย่าง ทีมแบบ split ราคาจะถูกลงกว่าประมาณ 2.5x และทำงานเร็วขึ้นประมาณ 3x โดยจำนวน input token 84–98% ถูกคิดที่ worker ที่ใช้ราคา Token ถูกกว่า

แต่ๆๆ เขาบอกว่า นี่แค่ตัวอย่างนะ อย่าเอาตัวเลขนี้ไปใช้อ้างอิงว่าทุกงานจะประหยัดเท่านี้ เพราะมันขึ้นกับ workload แต่ละงาน

แต่โครงสร้างวิธีการทำแบบนี้ก็ชัดเจนดี คือ งานอ่านเยอะๆ ให้ worker ทำ ส่วนโมเดลใหญ่แตะเฉพาะ planning/synthesis

จากที่อ่าน ถ้าผมจะใช้จริง จะวาง flow แบบนี้

1. เริ่มด้วย Sonnet 5: ให้ทำงานหลัก อ่านไฟล์ เรียก tool แก้โค้ด รัน test
2. Orientation: เก็บบริบทขั้นต่ำก่อน เช่น requirement, repo structure, error หลัก
3. Advisor call แรก: เรียก Fable 5 ให้ช่วยวางแผนและชี้ risk
4. Execute: ให้ Sonnet 5 ลงมือทำตาม plan โดยไม่เรียก advisor ทุกจุด
5. Replan เมื่อจำเป็น: ถ้า error วนหรือทางเดิมไม่ไปต่อ ค่อยเรียก Fable 5 อีกครั้ง
6. Review ก่อนจบ: เรียก advisor ช่วยดูว่าตกหล่น test, security, edge case หรือ assumption อะไรไหม
7. Finish: ให้ executor สรุปผลพร้อม evidence จาก test/diff/tool output

ต้องบอกว่า ผมยังแค่คิดนะ เพราะยังไม่มีโจทย์ซับซ้อนพอที่จะใช้ Fable ทำงาน และยังไม่อยากลองรันเทียบ เพราะต้องทำหลายครั้ง อาจจะเสีย Token เยอะ ฮาา, ไว้รอมีผลการทดสอบจากผู้กล้า หรือได้ลองจริงๆ แล้วจะเอามาเล่าให้ฟังอีกที หรือหากใครลองแล้วก็มาแชร์กันหน่อยครับ

ข้อควรระวัง

• งานเล็กมากอาจไม่คุ้ม: ถ้าเป็น single-turn Q&A หรือแก้ typo เล็กๆ advisor อาจเพิ่ม overhead มากกว่าประโยชน์
• ต้องวัดกับ workload จริง: ตัวเลขประหยัด token ไม่ใช่ค่าคงที่ ขึ้นกับชนิดงานและความยาวของ context
• อย่าแตกงานย่อยจนเกินพอดี: ใน cookbook เองก็เตือนว่าการแตก brief แคบเกินไปมี floor cost ของ worker thread (ขออธิบายเพิ่มเติมครับ: มันคือต้นทุนขั้นต่ำต่อ worker thread หมายถึง ทุกครั้งที่สร้าง worker หรือ sub-agent ใหม่ มันมี “ต้นทุนตั้งต้น” เสมอ ไม่ว่าจะงานเล็กหรือใหญ่ เช่น เปิด session ,รับ prompt, อ่าน context, เรียก Skill)
• advisor แก้โจทย์เท่าที่ได้รับจาก context: ถ้า executor ยังไม่ได้อ่านของสำคัญก่อนเรียก advisor คำแนะนำก็อาจกว้างหรือผิดทิศได้ เช่นเราใส่บริบทไม่ครบหรือไม่เข้าใจให้ advisor เองแต่แรก (นั่นคือเหตุผลของ Anthopic ว่าทำไมไม่ควรเอาตัวฉลาดมารับงานก่อน)
• ต้อง track cost แยก: usage ของ advisor อยู่ใน usage.iterations เป็น advisor_message เพราะถูก bill คนละ rate กับ executor

ผมขอขยายความข้อสุดท้ายนิดนึงคือ มันไม่สามารถคิด token cost แบบ usage.input_tokens + usage.output_tokens ทั่วไปนะ เพราะอาจจะเข้าใจผิดคิดว่าแพงทั้งหมด แต่ควรคิดจาก

total_cost = executor_tokens × ราคา Sonnet 5 + advisor_tokens × ราคา Fable 5

ดังนั้น ใน Anthropic API ที่ส่งค่า usage.iterations กลับมา เราต้องคิดราคาแยกตาม type ด้วย ว่าอะไรคือ executor (message) และอะไรคือ advisor (advisor_message)

สรุป

ผมคิดว่า “Fable 5 เป็น advisor” เป็นแนวทางที่น่าลองมากสำหรับ agent workflow ที่เราจะให้มันทำงานยากๆ หรือต้องใช้การตัดสินใจอย่างมีเหตุมีผลสูงมาก ส่วนงานง่ายๆ อย่างการ อ่าน/ทำ/ตรวจซ้ำ ก็ให้ใช้โมเดลรองๆ ลงมา ทำก็คิดว่าเพียงพอแล้ว (อย่างน้องชมพูที่ผมให้แชต ก็ใช้แค่ ChatGPT mini แต่หาข้อมูลและเขียนบทความ ผมจะใช้ ChatGPT ปกติ

อ้างอิง

• ClaudeDevs on X — Fable 5 as advisor pattern
• Anthropic Claude Platform Docs — Advisor tool
• Anthropic Claude Cookbooks — Coordinator pattern: big models for planning, small models for execution