ผมอยู่ในสถานการณ์ที่สามารถใช้ Gemini token ได้ในราคาถูกมาก เลยใช้งานโดยต่อพร็อกซีแบ็กเอนด์ที่เชื่อม Gemini เข้ากับ Claude Code ตามชื่อเรื่องอยู่ครับ
Gemini CLI ค่อนข้างบุกหนักเกินไป (แม้จะสั่งให้อ่านโค้ดอย่างเดียวก็ยังพยายามจะแก้อะไรอยู่เรื่อย) เลยไม่ค่อยเข้ามือสำหรับผม และดูเหมือนว่า agent design ของ Claude Code จะทำงานได้ดีที่สุด ผมเลยยังพอใจกับการใช้งานแม้จะเปลี่ยนแบ็กเอนด์แล้วก็ตาม
พร็อกซีเลเยอร์นี้เท่ากับเป็นการครอบ abstraction layer เพิ่มเข้าไปอีกชั้น ทำให้สามารถเชื่อม OpenAI, XAI, Claude และ Gemini เข้ากับ Claude Code แล้วใช้งานได้ด้วยวิธีเดียวกันทั้งหมด
ผมต้องแก้ปัญหาจุกจิกพอสมควร เช่น เรื่อง streaming + JSON parsing หรือการปรับ schema ให้เหมาะกับการใช้ tool use ถ้ามีใครอยากลองทำอะไรคล้าย ๆ กัน บอกในคอมเมนต์ได้เลยนะครับ เดี๋ยวผมจะลองเปิดเป็นโอเพนซอร์ส
ถ้าใครเคยทำงานลักษณะใกล้เคียงกันมาก่อน รบกวนช่วยแชร์ประสบการณ์กันหน่อยครับ~
8 ความคิดเห็น
ผมใช้แนวทางที่ต่างออกไปนิดหน่อยครับ คือไม่ได้ใช้เครื่องมือเอเจนต์อย่าง Claude Code หรือ Cowork แต่พัฒนาในเว็บแชตของ LLM แบบล้วน ๆ ผ่านการสนทนาด้วยภาษาธรรมชาติ ผมตั้งพร็อกซีตัวหนึ่งไว้บนเซิร์ฟเวอร์ของตัวเองเพื่อเชื่อม Claude ↔ Gemini API แล้วให้ Gemini รันงานโปรดักชันจริง ๆ (แชตบอต KakaoTalk, เอเจนต์ภาษาธรรมชาติสำหรับ ERP) ส่วนงานรีวิวโค้ดและออกแบบสถาปัตยกรรมก็ทำผ่านการคุยกับ Claude โดยให้คนทำหน้าที่แค่คอนเฟิร์มสุดท้ายกับดีพลอยเท่านั้น
Gemini รับบทเป็นผู้ช่วยเขียนโค้ด, Claude รับบทเป็นผู้ตรวจโค้ด, ส่วนคนเป็นผู้คอนเฟิร์มขั้นสุดท้าย — การแยกบทบาทแบบนี้เข้ากันได้ดีทีเดียวครับ
ถ้าเทียบกับเอเจนต์ที่ทำงานบนฐานโค้ดเอดิเตอร์ (เช่น Claude Code) ข้อดีก็คือใช้โทเคนน้อยกว่ามาก เพราะรับส่งโค้ดกันผ่านบทสนทนาโดยไม่ต้องมี file I/O และให้คนเป็นฝ่ายนำไปปรับใช้เองโดยตรง จุดที่ผมเห็นด้วยคือ "การออกแบบเอเจนต์ของ Claude ทำงานได้ดีที่สุด" ส่วน Gemini CLI นั้นค่อนข้างมีความเห็นเป็นของตัวเองแรงชัดเจนจริง ๆ (ฮ่าๆ) เลยรู้สึกว่าให้ Claude มารับบทตรวจทานจะดีกว่าครับ
ขอบคุณที่แบ่งปันประสบการณ์ครับ 👍 ผมก็เห็นด้วยกับประเด็นเรื่องความต่างของลักษณะนิสัยระหว่าง Gemini กับ Claude เช่นกัน
คุณใช้งานผู้ให้บริการหลายเจ้าพร้อมกันผ่านเว็บอินเทอร์เฟซเดียวสินะครับ พอทำ autonomous coding แบบอิงเอเจนต์ไปเรื่อย ๆ ก็มีแนวโน้มว่าจะเขียนแบบผิวเผินในลักษณะ "การพัฒนาที่ขับเคลื่อนด้วยเรซูเม่" มากกว่าจะคิดออกแบบให้ดี ดังนั้นผมเองก็คิดว่าการทำงานด้านดีไซน์ในรูปแบบการสนทนาน่าจะดีกว่าครับ ☺️
ผมเคยรันอะไรอย่าง anthropic-proxy ไว้บนเครื่องโลคัล แล้วพร็อกซีด้วยคำสั่งอย่าง
ANTHROPIC_BASE_URL=http://0.0.0.0:3000 claudeเพื่อไปใช้โมเดล Gemini หรือ GPT ตัวอื่นอยู่เหมือนกัน แต่พอได้ยินว่าคุณทำเป็นแบบ serverless เลยก็เลยสนใจครับโอ้ มีโอเพนซอร์สที่เขียนด้วย JS ด้วยสินะครับ ขอบคุณครับ👍👍
โครงสร้างภายในคล้ายกัน แต่ผมใช้งานแบบทำ abstraction ไว้ค่อนข้างเยอะหน่อยครับ (แล้วแต่สไตล์)
ถึงจะเขียนแบบ serverless แต่เพราะเวลาในการตอบกลับของ LLM ช้ากว่ามากอยู่แล้ว เลยแทบไม่รู้สึกถึง cold start และใช้งานได้ลื่นดีครับ อีกทั้งถ้าใช้ความสามารถ Function URL ของ lambda ก็ทำสตรีมมิงได้ด้วย เลยครอบคลุมได้ครบถ้วนเลย โดยเฉพาะจุดที่ว่าแม้จะรีบูตแล้วก็ไม่ต้องเปิดเซิร์ฟเวอร์ใหม่ อันนี้ดีสุดครับ
ในโค้ดนี้ ถ้าลองแก้แค่ส่วน fast api ให้เป็นรูปแบบ lambda handler แล้วเอาขึ้นไปรันบน Lambda ดู (พอแก้ปัญหาจุกจิกนิดหน่อยแล้ว) ก็น่าจะใช้งานได้ดีพอสมควรครับ
https://github.com/1rgs/claude-code-proxy
มันต่างจากพร็อกซีแบบนี้ไหม?
ขอบคุณที่แนะนำไลบรารีดี ๆ นะครับ ถ้ารู้ก่อนก็น่าจะทำได้สะดวกกว่านี้หน่อย 👍👍
ภายในแล้ว การจัดการแปลงรูปแบบอินพุต/เอาต์พุตเองก็ดูเหมือนไม่ได้ต่างกันมากนัก
แต่ถ้าจะหาความแตกต่าง ไลบรารีที่คุณแนะนำมานั้นอิงกับ self-serving / Docker / Python / LiteLLM ขณะที่ผมทำแบบ serverless / AWS Lambda / TS / โดยไม่พึ่งพา dependencies ครับ
ถ้าเชื่อม Gemini เข้ากับ Claude Code ก็มีโอกาสโดนระงับได้เหมือนกันนะครับ
ดูเหมือนว่าต้องระวังกรณี opencode โดนระงับเป็นวงกว้างไว้ให้ดี
ขอบคุณสำหรับคอมเมนต์อย่างรวดเร็วครับ 🙌
กรณี Open Code ถูกระงับ (สมัครสมาชิก Claude => เชื่อมต่อ Open Code) เกิดปัญหาเพราะนำคีย์แพ็กเกจเหมาจ่ายที่ยืนยันตัวตนผ่าน OAuth ไปใช้ในซอฟต์แวร์ของบุคคลที่สาม หากจะใช้งานแบบด้านบน ต้องออก API key แล้วใช้งานแบบคิดค่าบริการตามปริมาณการใช้ ซึ่งไม่ถือว่าผิดข้อกำหนดการใช้งาน