pxpipe เลือกส่ง context ให้โมเดลอ่านเป็นรูปภาพ แทนที่จะส่งเป็นข้อความตัวหนังสือ

context คือข้อความทั้งหมดที่เราต้องส่งให้โมเดลอ่านก่อนจะตอบกลับมาทุกครั้ง มีตั้งแต่คำสั่งระบบ คู่มือเครื่องมือ ไปจนถึงประวัติการสนทนาทั้งหมด ด้าน Claude Code ก็คือเครื่องมือสั่ง AI เขียนและแก้โค้ดผ่านหน้าจอ terminal ซึ่งคนที่ใช้งานประจำจะรู้ดีว่า ยิ่งคุยยาวเท่าไร บิลค่าบริการก็ยิ่งแพงขึ้นเท่านั้น ตัว pxpipe ทำหน้าที่เป็นพร็อกซี หรือโปรแกรมเล็กๆ ที่รันอยู่บนเครื่องของเรา โปรแกรมนี้จะคอยแทรกอยู่ตรงกลางระหว่างเครื่องมือกับผู้ให้บริการโมเดล เพื่อดักจับทุกคำขอก่อนจะถูกส่งออกจากเครื่อง

สาเหตุที่การส่ง context เป็นภาพช่วยลดค่าใช้จ่ายได้ มาจากวิธีคิดเงินของตัวโมเดลเอง ปกติแล้วระบบจะคิดค่าบริการตามจำนวนโทเคน ซึ่งเป็นหน่วยวัดปริมาณข้อมูลทั้งขาเข้าและขาออก หากส่งเป็นข้อความ ระบบจะนับโทเคนตามจำนวนตัวอักษร แต่ถ้าส่งเป็นภาพ ระบบจะนับตามขนาดพิกเซล โดยไม่สนใจว่าในภาพนั้นจะมีตัวหนังสืออัดแน่นอยู่กี่ตัว พอเรานำเนื้อหาแน่นๆ อย่างโค้ดหรือผลลัพธ์จากเครื่องมือมาวางเรียงเต็มหน้าแล้วแปลงเป็นภาพ ตัวอักษรที่บรรจุอยู่ในหนึ่งโทเคนจึงเพิ่มขึ้นหลายเท่า โดยที่เนื้อหายังอยู่ครบทุกบรรทัดโดยไม่ถูกตัดทอน จากการทดสอบกับบิลของผู้พัฒนาเอง พบว่าค่าใช้จ่ายลดลงราว 59-70% โดยโปรเจกต์นี้เปิดเป็นโอเพนซอร์สภายใต้สัญญาอนุญาต MIT

ทุกครั้งที่พิมพ์คำสั่งใหม่ เราจ่ายค่าของเดิมอีกรอบ

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

พอเราพิมพ์คำสั่งใหม่แต่ละครั้ง โปรแกรมจะส่งคำสั่งประจำระบบ คู่มือเครื่องมือ และประวัติการคุยทั้งหมดกลับไปให้โมเดลอีกรอบ เพราะโมเดลไม่ได้จำข้อมูลจากรอบก่อนเอาไว้ เราจึงต้องจ่ายเงินค่าข้อมูลชุดเดิมซ้ำๆ ในทุกเทิร์น ยิ่งคุยยาว ข้อมูลก้อนนี้ก็ยิ่งใหญ่ขึ้นเรื่อยๆ จนเราต้องคอยสั่งย่อประวัติทิ้งบ่อยเกินความจำเป็น เรื่องนี้เคยเล่าไว้แล้วในบทความเกี่ยวกับ Edgee gateway ที่บีบ context ก่อนถึงโมเดล ว่าโทเคนเกือบทั้งหมดในเซสชัน Claude Code มาจาก context ที่ไหลเข้าสู่โมเดล ไม่ใช่จากประโยคที่เราพิมพ์สั่งเลย

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

ทำไมส่ง context เป็นภาพถึงถูกกว่าส่งเป็นตัวหนังสือ

ช่องทางที่โมเดลใช้อ่านภาพไม่ได้เป็นระบบใหม่ที่เพิ่งสร้างขึ้นมาแต่อย่างใด

จริงๆ แล้วเป็นช่องทางเดียวกับที่โมเดลใช้มองหน้าจอเวลารับคำสั่งให้ทำงานแทนเรา pxpipe แค่นำช่องทางนี้มาใช้ส่ง context แทนการส่งภาพหน้าจอปกติ ความแตกต่างที่เห็นได้ชัดที่สุดคือเรื่องต้นทุน จากการใช้งานจริงบน Claude Code เนื้อหาแน่นๆ อย่างโค้ดและผลลัพธ์จากเครื่องมือ อัดตัวอักษรได้ราว 3.1 ตัวต่อหนึ่งโทเคนภาพ ส่วนการส่งเป็นข้อความธรรมดาจะใส่ได้เพียงราว 1 ตัวอักษรต่อโทเคนเท่านั้น

ตัวอย่างบนหน้าโปรเจกต์ช่วยให้เราเห็นภาพได้ชัดขึ้น โดยคำสั่งประจำระบบรวมกับคู่มือเครื่องมือก้อนหนึ่งยาวราว 48,000 ตัวอักษร หากส่งเป็นข้อความปกติจะต้องใช้ถึงราว 25,000 โทเคน แต่พอเรนเดอร์เป็นภาพหน้าเดียวแล้วส่งกลับใช้เพียงราว 2,700 โทเคนเท่านั้น ทั้งที่เนื้อหายังคงเดิมครบถ้วนทุกตัวอักษร ต่างกันแค่ช่องทางที่โมเดลใช้อ่าน

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

รัน pxpipe จริงด้วยสองบรรทัด

วิธีการเริ่มใช้งาน ให้เปิดพร็อกซีขึ้นมาก่อน แล้วตั้งค่าให้ Claude Code ส่งคำขอผ่านพร็อกซีตัวนั้น

npx pxpipe-proxy                                    # proxy on 127.0.0.1:47821
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude    # point Claude Code at it

พอพร็อกซีเริ่มทำงาน เราสามารถเปิดหน้าแดชบอร์ดได้ที่ http://127.0.0.1:47821/ หน้าแดชบอร์ดนี้จะบอกจำนวนโทเคนที่ประหยัดได้ พร้อมเปรียบเทียบข้อความกับภาพให้เห็นแบบคู่ต่อคู่ว่ามีอะไรถูกแปลงไปบ้าง ทั้งยังมีสวิตช์ปิดฉุกเฉิน และปุ่มเปิดปิดการทำงานแยกรายโมเดลให้กดปรับได้ทันที

สิ่งที่ควรรู้ก่อนเปิดใช้งานคือ ระบบจะบีบอัดเฉพาะขาคำขอที่ส่งออกไปเท่านั้น โดยไม่ยุ่งกับคำตอบที่ส่งกลับมาจากโมเดล ข้อความตอบกลับจึงยังคงทยอยสตรีมขึ้นหน้าจอตามปกติ ส่วนข้อมูลในคำขอที่จะถูกแปลงเป็นภาพมีอยู่ 3 ส่วน ได้แก่ คำสั่งประจำระบบพร้อมคู่มือเครื่องมือ ประวัติการคุยเก่าที่เลยช่วงสนทนาล่าสุดไปแล้ว และผลลัพธ์ก้อนใหญ่จากเครื่องมือที่ยาวเกินราว 6,000 ตัวอักษร เช่น เนื้อหาไฟล์ที่เพิ่งอ่าน หรือ log ที่โปรแกรมพ่นทิ้งไว้ ขณะที่บทสนทนาในเทิร์นล่าสุดยังคงส่งเป็นข้อความตามเดิมเสมอ

โหมด export สำหรับคนที่ยังไม่อยากรันพร็อกซี

หากเรายังไม่อยากนำโปรแกรมอะไรไปคั่นระหว่างเครื่องมือกับผู้ให้บริการโมเดล pxpipe ก็ยังมีโหมด export ที่ช่วยเรนเดอร์ไฟล์ โฟลเดอร์ หรือ diff ออกมาเป็นภาพ PNG ได้โดยไม่ต้องเปิดพร็อกซีทิ้งไว้

npx pxpipe-proxy export src/
cat prompt.txt | npx pxpipe-proxy export --stdin
npx pxpipe-proxy export --git

ทุกครั้งที่รันคำสั่ง ระบบจะสร้างโฟลเดอร์ใหม่ที่ขึ้นต้นชื่อด้วย pxpipe-export- พร้อมแสดงพาธโฟลเดอร์แบบเต็มเมื่อทำงานเสร็จ ด้านในโฟลเดอร์จะมีไฟล์ภาพ page-*.png วางคู่กับไฟล์ prompt.txt สำหรับให้เราคัดลอกข้อความไปใช้งาน จากนั้นเราสามารถนำภาพไปอัปโหลดใส่เครื่องมือที่รองรับรูปภาพอย่าง Cursor เพื่อส่ง context แบบอัดแน่นได้ทันทีโดยไม่ต้องง้อพร็อกซี

ตัวเลข 59-70% มาจากไหน

ตัวเลขนี้คิดจากบิลรวมทั้งก้อน ไม่ใช่คิดแค่เฉพาะส่วนที่บีบอัดได้

เรื่องนี้มีรายละเอียดที่ควรอ่านอย่างระมัดระวัง เพราะฐานที่ใช้หารคือทุกคำขอในการใช้งานจริง ทั้งคำขอขนาดเล็กที่ pxpipe ปล่อยผ่านโดยไม่แปลงเป็นภาพ โทเคนฝั่งแคชทั้งขาอ่านและขาเขียน ไปจนถึงโทเคนฝั่งคำตอบที่พร็อกซีไม่ได้บีบอัดเลย โดยทั้งหมดอิงจากราคาปัจจุบันของ Fable 5 ซึ่งเป็นหนึ่งในโมเดลที่ pxpipe เปิดใช้งานไว้เป็นค่าเริ่มต้น

• 59% คำนวณจากชุดข้อมูลการใช้งานจริง 13,709 คำขอ ซึ่งช่วยลดค่าใช้จ่ายจาก 100 ดอลลาร์ เหลือเพียงราว 41 ดอลลาร์
• ราว 70% ได้มาจากชุดข้อมูลอีกชุดที่เก็บตามหลังมา มีคำขอที่ถูกบีบอัดจำนวน 8,904 คำขอ โดยวัดผลจากบิลรวมเช่นเดียวกัน
• ราว 72-74% คือตัวเลขที่คิดเฉพาะคำขอที่ถูกบีบอัดจริง ซึ่งผู้พัฒนาระบุว่าแยกรายงานไว้ต่างหาก และไม่เคยนำมาใช้เป็นตัวเลขพาดหัว

ในคลิปสาธิตบนหน้าโปรเจกต์ ฝั่งที่เชื่อมต่อผ่าน pxpipe ทำงานเสร็จสิ้นด้วยค่าใช้จ่ายเพียง 6.06 ดอลลาร์ และใช้ context ไปแค่ 73,500 โทเคน จากความจุทั้งหมด 1 ล้านโทเคน ขณะที่ฝั่งส่งข้อความปกติมีค่าใช้จ่ายสูงถึง 42.21 ดอลลาร์ แถมยังใช้พื้นที่ context ไปแล้วถึง 96%

ส่วนการทดสอบกับงานจริง ผู้พัฒนาใช้ชุดทดสอบ SWE-bench เพื่อวัดจำนวนโจทย์ที่เอเจนต์แก้ไขได้สำเร็จ ผลปรากฏว่า ในชุด Lite เอเจนต์แก้โจทย์ผ่าน 10 จาก 10 ข้อเท่ากันทั้งตอนเปิดและปิดใช้งานพร็อกซี โดยขนาดคำขอลดลงราว 65% ส่วนในชุด Pro ตอนเปิดพร็อกซีแก้ได้ 14 จาก 19 ข้อ และตอนปิดพร็อกซีแก้ได้ 15 จาก 19 ข้อ โดยขนาดคำขอลดลงราว 60% มีเพียงโจทย์ข้อเดียวเท่านั้นที่ผลลัพธ์ต่างกัน แต่พอทดสอบรันซ้ำอีก 3 รอบ ก็ได้ผลเหมือนกันทั้งหมด ผู้พัฒนาจึงสรุปว่าเป็นเพียงความผันผวนระหว่างรอบ ไม่ใช่ผลกระทบจากการบีบอัดภาพ พร้อมย้ำว่ากลุ่มตัวอย่างนี้ยังเล็กเกินกว่าจะใช้สรุปผลได้อย่างเด็ดขาด

ตัวเลขทั้งหมดนี้วัดผลโดย teamchong ซึ่งเป็นผู้พัฒนา pxpipe เอง โดยยังไม่ได้ผ่านการประเมินจากคนกลาง ถึงอย่างนั้น ผู้พัฒนาก็เปิดให้ทุกคนนำวิธีการวัดไปทดสอบซ้ำได้เอง เพราะทุกคำขอจะมีการยิงตัวนับโทเคนแบบไม่คิดเงินไปวัดเนื้อหาฉบับที่ยังไม่ถูกบีบ ควบคู่ไปกับคำขอจริงที่ส่งออกไป แล้วเก็บผลทั้งสองฝั่งลงไฟล์ ~/.pxpipe/events.jsonl บนเครื่องของเรา ทำให้เรานำล็อกของตัวเองมาคำนวณผลประหยัดจริงได้โดยตรง

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

ส่วนที่ต้องยอมแลกคือค่าที่ต้องเป๊ะ

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

ดังนั้น ข้อมูลที่ต้องการความถูกต้องแม่นยำสูงแบบห้ามผิดแม้แต่ตัวอักษรเดียว เช่น API key รหัสอ้างอิง หรือค่า hash ของไฟล์ จึงไม่ควรปล่อยให้ถูกแปลงเป็นภาพ แต่ต้องคงไว้เป็นข้อความธรรมดาเท่านั้น พอทดสอบให้โมเดลอ่านรหัส hex ความยาว 12 ตัวอักษร จำนวน 15 ชุด ที่แทรกอยู่ในเนื้อหาอัดแน่น แล้วตอบกลับมาให้ถูกต้อง ผลปรากฏว่า Fable 5 อ่านได้ถูกต้อง 13 จาก 15 ชุด ส่วน Claude Opus 5 อ่านถูกเพียง 2 ชุด และ Sol อ่านถูก 0 ชุด

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

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

นอกจากนี้ ยังมีข้อจำกัดอื่นๆ ที่ควรรู้ไว้ก่อนตัดสินใจใช้งาน

• คุ้มค่ากับเนื้อหาอัดแน่น แต่ขาดทุนกับข้อความโปร่ง ตัวเครื่องมือมีเกณฑ์ประเมินความคุ้มค่าเพื่อตัดสินใจว่าควรรันแปลงข้อมูลเป็นภาพหรือไม่ โดยคำนวณจากข้อมูลใช้งานจริง 391 แถว เนื้อหาที่แน่นระดับราว 1 ตัวอักษรต่อโทเคนจะถูกแปลงเป็นภาพ ส่วนข้อความโปร่งๆ ระดับราว 3.5 ตัวอักษรต่อโทเคนจะถูกปล่อยไว้เป็นข้อความตามเดิม เพราะหากแปลงเป็นภาพจะขาดทุนโทเคนแทน
• ไม่ได้เปิดใช้งานกับทุกโมเดล โมเดลที่เปิดใช้งานไว้เป็นค่าเริ่มต้น ได้แก่ claude-fable-5, claude-opus-5 และ gemini-3.6-flash ส่วน Sol, GPT-5.5 และ Grok ต้องเข้าไปตั้งค่าเปิดเอง ซึ่งบางโมเดลมีประสิทธิภาพในการอ่านภาพต่ำกว่ามาก
• ระบบ Windows อาศัยชุมชนช่วยดูแล ผู้พัฒนาหลักใช้ macOS และ Linux เป็นหลัก การแก้ไขปัญหาเฉพาะบน Windows จึงต้องรอความช่วยเหลือจากชุมชนผู้ใช้ภายนอก
• ระยะเวลารอก่อนส่งคำขอเพิ่มขึ้น ระบบต้องประมวลผลเข้ารหัสภาพ PNG ให้เสร็จสิ้นก่อนส่งออกจากเครื่อง ยิ่งคำขอมีขนาดใหญ่ก็ยิ่งสังเกตเห็นความล่าช้าได้ชัดเจนขึ้น

ภาษาไทยไม่มีอยู่ในเอกสารเลยสักบรรทัด

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

เอกสารของโปรเจกต์ระบุว่า ตัวอักษรกลุ่ม ASCII และ Latin-1 ผ่านการทดสอบเรียบร้อยแล้ว ส่วนภาษาจีน ญี่ปุ่น และเกาหลี สามารถใช้งานได้แต่ต้องใช้ความระมัดระวัง ทว่าตลอดทั้งเอกสารกลับไม่ได้เอ่ยถึงภาษาไทยไว้เลยสักบรรทัด ไม่ว่าจะในแง่บวกหรือแง่ลบ

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

ใครควรลอง ใครยังไม่ต้องรีบ

เส้นแบ่งไม่ได้อยู่ที่ว่าบิลแพงแค่ไหน แต่อยู่ที่ว่า context ของงานเรามีหน้าตาแบบไหนต่างหาก

• ควรลอง หากเราต้องจ่ายค่าใช้จ่าย API เอง และงานประจำวันเต็มไปด้วยโค้ด log การทำงาน รวมถึงผลลัพธ์ขนาดใหญ่จากเครื่องมือ
• ควรลอง หากเซสชันการทำงานยาวนานจนต้องคอยย่อประวัติการคุยทิ้งบ่อยๆ จนเสียจังหวะทำงาน
• ยังไม่ต้องรีบ หากลักษณะงานต้องประมวลผลข้อมูลที่ห้ามผิดพลาดแม้แต่ตัวอักษรเดียว เช่น รหัสอ้างอิง หรือ API key
• ยังไม่ต้องรีบ หากเน้นคุยกับ AI ด้วยข้อความขนาดยาวมากกว่าเขียนโค้ด เพราะเกณฑ์ความคุ้มค่าของระบบจะปล่อยผ่านเป็นข้อความปกติอยู่แล้ว

ถ้าอยากทดสอบการใช้งาน เราเสียแค่เวลาในการรันคำสั่งสองบรรทัดข้างต้นเพื่อเปิดพร็อกซี แล้วเชื่อมต่อ Claude Code เข้าไป จากนั้นลองเปิดแดชบอร์ดติดตามผลสัก 1-2 วัน ตัวเลขสถิติบนนั้นก็จะเป็นข้อมูลจริงจากการทำงานของเราเอง

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

ที่มา: โปรเจกต์ teamchong/pxpipe บน GitHub