รัน agent ของ Letta บน OpenAI-compatible endpoint

คำตอบสั้น ๆ: สอง environment variable บน server

เส้นทางที่ Letta มีเอกสารรองรับสำหรับ OpenAI-compatible endpoint คือการตั้งค่า environment บน server แบบ self-hosted: ตั้ง OPENAI_API_BASE เป็น URL ของ endpoint และ OPENAI_API_KEY เป็น key ของมันตอนเริ่ม server แล้ว Letta จะลงทะเบียนโมเดลที่ endpoint นั้นเสิร์ฟ สำหรับ APIsRouter base คือ https://api.apisrouter.com/v1 ไม่มีฟิลด์ base-URL ต่อ agent ใน UI; endpoint เป็นการตัดสินใจระดับ server ซึ่งเป็นเหตุผลที่ environment คือพื้นผิวที่สำคัญ มีข้อกำหนดหนึ่งที่ต่อรองไม่ได้และควรอ่านก่อนอย่างอื่น: เอกสารของ Letta ระบุว่า OpenAI-compatible endpoint ต้องรองรับ function calling เพราะ agent loop สร้างขึ้นบน tool call endpoint ที่ทำได้แค่ plain chat completions รัน agent ของ Letta ไม่ได้เลย โมเดลในแคตตาล็อกบน APIsRouter พูด tool calling มาตรฐานผ่าน /v1/chat/completions ซึ่งเป็นรูปแบบที่ Letta คาดหวัง

docker run \
  -v ~/.letta/.persist/pgdata:/var/lib/postgresql/data \
  -p 8283:8283 \
  -e OPENAI_API_KEY="$APISROUTER_API_KEY" \
  -e OPENAI_API_BASE="https://api.apisrouter.com/v1" \
  letta/letta:latest

ทำไม Letta พึ่งพาโมเดลของมันหนักกว่าแอปแชท

Letta (letta-ai บน GitHub มีดาวประมาณ 24K) เติบโตมาจากโปรเจกต์วิจัย MemGPT และสร้าง stateful agent: agent ที่มีความจำถาวรและแก้ไขตัวเองได้ซึ่งอยู่รอดข้าม session แอปแชทส่งข้อความของคุณแล้วพิมพ์คำตอบ แต่ agent ของ Letta รัน inner loop ในทุกการโต้ตอบ คิดเรื่องสิ่งที่มันรู้ เรียก tool ความจำเพื่ออ่านและเขียน core memory และ archival storage ของตัวเองใหม่ แล้วค่อยสร้างคำตอบ สถาปัตยกรรมนั้นมีผลสองอย่างต่อการ route endpoint อย่างแรก ทุกขั้นตอนของ loop เป็น request แบบเรียก tool ซึ่งเป็นเหตุผลที่ function calling เป็นข้อกำหนดจำเป็นไม่ใช่แค่สิ่งดี ๆ ที่มีก็ได้ โมเดลที่ทำ tool schema พลาดจะไม่เสื่อมลงอย่างค่อยเป็นค่อยไปที่นี่ มันทำลายความสามารถของ agent ในการจำโดยตรง อย่างที่สอง ปริมาณ request ต่อการโต้ตอบสูงกว่าที่ transcript บทสนทนาบอก เพราะการจัดการความจำทำงานควบคู่กับคำตอบที่มองเห็นทุกครั้ง model id ที่ให้บริการทั้งหมดนี้เป็นสตริงธรรมดาต่อ endpoint ดังนั้นด้วย gateway หลาย vendor อยู่หลัง OPENAI_API_BASE id ของ Claude สามารถขับเคลื่อน agent loop ในขณะที่ id ที่เร็วเสิร์ฟ agent ที่เบากว่าบน server เดียวกัน แต่ละตัวถูกเรียกด้วย handle ของมัน

สถานะการรองรับตรง ๆ จาก upstream

เอกสารของ Letta เองระบุว่า OpenAI proxy endpoint ไม่ได้รับการรองรับอย่างเป็นทางการและคุณอาจเจอ error โดยแนะนำให้เชื่อมต่อ provider โดยตรงแทน คำเตือนนี้สมควรถูกยกมาแทนที่จะถูกฝังไว้ เพราะหน้าส่วนใหญ่เกี่ยวกับหัวข้อนี้แสร้งทำเป็นไม่มีมันอยู่ สิ่งที่มันหมายความในทางปฏิบัติแคบกว่าที่ฟังดู: Letta ทดสอบกับ API ของผู้พัฒนาโดยตรง และ endpoint ที่เบี่ยงเบนจาก semantics ของ OpenAI โดยเฉพาะเรื่อง tool calling จะเกิดความล้มเหลวที่ upstream จะไม่ให้ความสำคัญ endpoint ที่ implement spec ได้จริง รวม tool call ด้วย จะรันได้ดี และนั่นคือมาตรฐานความเข้ากันได้ที่ gateway ต้องผ่านให้ได้พอดี ประวัติการรองรับยังมีบั๊กจริงหนึ่งอย่างที่ควรรู้ ถึงต้นปี 2026 โมเดลที่ลงทะเบียนผ่าน OPENAI_API_BASE ถูกเติม prefix อัตโนมัติเป็น openai-proxy provider ในขณะที่การสร้าง agent ตรวจสอบเทียบกับรายการ prefix ที่สั้นกว่าที่ยอมรับได้ ดังนั้นโมเดล proxy ลงทะเบียนได้แต่ใช้สร้าง agent ไม่ได้ ปัญหานี้ถูกปิดพร้อม fix ในเดือนมกราคม 2026 ถ้าคุณรัน server เวอร์ชันเก่าที่ pin ไว้และการสร้าง agent ปฏิเสธโมเดลที่ server แสดงชัดเจนว่ามีอยู่ นั่นคือสิ่งที่คุณกำลังเจอ และการอัปเกรดคือทางแก้ อีกเป้าหมายที่ขยับ: พื้นผิวผลิตภัณฑ์ของ Letta กำลังเปลี่ยนไป และเอกสารของมันตอนนี้ชี้ผู้ใช้ใหม่ไปยัง deployment mode ใหม่ ๆ พร้อมระบุว่า Docker image แบบคลาสสิกไม่ใช่พื้นผิวที่ดูแลอยู่อีกต่อไป environment variable ข้างบนคือกลไกที่มีเอกสารรองรับสำหรับ self-hosted server เช็กเอกสารปัจจุบันว่า upstream แนะนำ deployment artifact ไหนในสัปดาห์ที่คุณ deploy

# after the server is up, list models Letta knows about
curl -s http://localhost:8283/v1/models/ | head -50
# use the handle exactly as listed when creating agents

เลือกโมเดลสำหรับ stateful agent

การประเมินที่สำคัญคือความซื่อสัตย์ของ loop: สร้าง agent ทดสอบ คุยบทสนทนาที่บังคับให้ update ความจำ แล้วอ่าน core memory ของ agent เพื่อยืนยันว่ามันเปลี่ยนจริง โมเดลสามารถเขียนคำตอบที่น่าประทับใจแต่ยังล้มเหลวสัญญาเรื่องความจำได้ และมีแค่การทดสอบ loop เท่านั้นที่จับได้

• การแก้ไขความจำเป็นงาน tool แบบมีโครงสร้าง claude-sonnet-4-6 และ gpt-5.5 จัดการ loop เขียนความจำของตัวเองซ้ำได้อย่างน่าเชื่อถือ ซึ่งเป็นความสามารถหลักที่ agent ของ Letta ต้องการ
• agent ที่มีอายุยืนสะสม context การเลือกโมเดลที่ยังคงมีเหตุผลลึกเข้าไปใน context window มีความสำคัญที่นี่มากกว่าในแชทแบบ stateless ซึ่งเป็นจุดที่ claude-opus-4-7 สมควรได้ตำแหน่งของมันสำหรับ assistant ที่มีความเสี่ยงสูง
• ฝูง agent แบบเบา หนึ่งตัวต่อผู้ใช้หรือต่องาน คือ workload ปริมาณ claude-haiku-4-5-20251001 ทำให้ต้นทุนต่อ agent คงที่ในขณะที่ยังเรียก tool ได้อย่างมีความสามารถ
• deepseek-v4-pro คุ้มค่าทดสอบสำหรับ agent ที่ผสม reasoning กับ traffic สองภาษา ข้อกำหนดเรื่อง tool-calling คือด่าน ดังนั้นทดสอบ loop ไม่ใช่แค่ร้อยแก้ว
• ไม่ว่าคุณจะเลือกอะไร เลือกต่อ agent server ลงทะเบียนทั้งแคตตาล็อก และแต่ละ agent ผูกกับ handle ดังนั้น concierge ที่หนักเรื่องความจำและ agent งานแบบใช้แล้วทิ้งรันคนละ id ได้ควบคู่กัน

จ่ายตามการใช้งาน · ถูกกว่าราคาทางการ

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

รูปแบบความล้มเหลวเฉพาะของ Letta

การสร้าง agent ปฏิเสธโมเดลที่ server แสดงคือบั๊ก prefix ในประวัติศาสตร์ โมเดลที่ลงทะเบียนผ่าน proxy พก provider prefix ที่การสร้าง agent ปฏิเสธไม่ยอมรับบนเวอร์ชันที่ได้รับผลกระทบ fix เกิดขึ้นในเดือนมกราคม 2026 บน release ปัจจุบัน handle ที่แสดงในรายการโมเดลคือ handle ที่ใช้งานได้ ถ้าคุณ pin อยู่ที่ image เก่ากว่า นี่คือเหตุผลที่แข็งแกร่งที่สุดข้อเดียวให้อัปเกรดก่อนจะ debug อย่างอื่น agent ที่ตอบแต่ไม่เคยจำคือความล้มเหลวของ tool-calling ไม่ว่าจะเป็นเพราะ endpoint ไม่ implement function calling หรือโมเดลหลัง id จัดการ tool schema ได้แย่ อาการคือบทสนทนาที่ทำงานได้ในขณะที่ core memory ไม่เคย update ทดสอบ agent เดียวกันบน claude-sonnet-4-6 เพื่อแยกปัญหา endpoint ออกจากปัญหาโมเดล environment variable ที่ตั้งผิดที่คือปัญหาคลาสสิกของ Docker: OPENAI_API_BASE ที่ export ไว้ใน shell ของคุณไม่มีผลอะไรกับ container ที่เริ่มโดยไม่มี flag -e ตัวแปรต้องไปถึง process ของ server เอง และเพราะ endpoint เป็นระดับ server จำรัศมีความเสียหายไว้: การเปลี่ยน OPENAI_API_BASE ขยับ agent ทุกตัวบน server นั้น ไม่มี override endpoint ต่อ agent ดังนั้น server หนึ่งตัวต่อ gateway หนึ่งตัวคือ topology ที่สะอาด โดยการเลือกโมเดลต่อ agent เป็นตัวสร้างความแตกต่าง

ใครที่ route Letta ผ่าน gateway

• builder ของ assistant ถาวรที่ต้องการการแก้ไขความจำระดับ Claude โดยไม่ต้องมีบัญชี vendor, key และพื้นผิวการเก็บเงินแยกต่างหากสำหรับแต่ละโมเดลที่ลอง
• ทีมที่รันฝูง agent ที่ผู้ใช้แต่ละคนได้ agent ของตัวเอง และการติดตาม usage ต่อ key เปลี่ยนต้นทุนจริงของชั้นความจำเป็นรายงานที่อ่านได้
• นักวิจัยที่เปรียบเทียบว่าโมเดลจัดการความจำแบบแก้ไขตัวเองอย่างไร ที่ผู้เข้าแข่งขันแต่ละรายเป็นแค่การเปลี่ยน handle บน agent ทดสอบแทนที่จะเป็นการย้าย provider
• self-hoster ในสภาพแวดล้อมที่การเข้าถึง API ของ vendor โดยตรงถูกบล็อก และ gateway endpoint เดียวคือสิ่งที่นโยบายเครือข่ายอนุญาต
• นักพัฒนาที่ไม่มีสิทธิ์เข้าถึงระบบเก็บเงินของ vendor รายหนึ่ง การเข้าถึงแบบเติมเงินโดยไม่ต้องใช้บัตรตัดการพึ่งพาการสมัครต่อ provider ออกไป

ตรวจสอบ endpoint และ debug agent แรก

ตรวจสอบ gateway ก่อน server: ลิสต์โมเดลด้วย key แล้วรัน chat completion หนึ่งครั้งพร้อมแนบ tool definition เพราะ tool calling คือความสามารถที่ Letta พึ่งพาจริง ถ้า tool-call round trip ทำงานใน curl ฝั่ง endpoint ก็ได้รับการพิสูจน์แล้ว จากนั้นเริ่ม server ด้วยสองตัวแปรแล้วอ่านรายการโมเดลของมัน โมเดลที่ปรากฏพิสูจน์การลงทะเบียน; agent ที่สร้างสำเร็จจาก handle ที่แสดงพิสูจน์เส้นทาง prefix; บทสนทนาที่ update core memory พิสูจน์ loop ตั้งแต่ต้นจนจบ debug ตามลำดับนั้น เพราะแต่ละขั้นมีชุดความล้มเหลวต่างกัน: env var, เวอร์ชัน server และความสามารถ tool ของโมเดลตามลำดับ เมื่อ agent รันแล้ว console ของ APIsRouter แสดงโมเดลต่อ request, จำนวน token และค่าใช้จ่าย stateful agent คิดเงินต่อการโต้ตอบมากกว่าที่ transcript บอก เพราะการจัดการความจำรันอยู่เบื้องหลังทุกคำตอบ และ usage log คือที่ที่ตัวคูณที่ซ่อนอยู่นั้นกลายเป็นตัวเลขที่คุณตั้งงบได้

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-4-6",
       "messages":[{"role":"user","content":"What is 2+3?"}],
       "tools":[{"type":"function","function":{
         "name":"calc","description":"add numbers",
         "parameters":{"type":"object","properties":{
           "a":{"type":"number"},"b":{"type":"number"}}}}}]}'

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