จุดที่ Jev 1.13 แตก: รายการข้อจำกัดของ TypeSafe เอง

Jev 1.13 (typesafe/jev-1.13) เปิดตัวเมื่อ 2026-09-15 ซึ่งทำให้มันอยู่นอกช่วงเจ็ดวันล่าสุดไปสองสัปดาห์ ดังนั้นการเปิดตัวของมันจึงไม่ใช่ประเด็นสำคัญ เหตุการณ์ที่มีวันที่ระบุคือ 2026-09-24: นั่นคือวันที่ OrcaRouter เพิ่ม typesafe/jev-1.13เข้าสู่แค็ตตาล็อกของตนและเปิดการ์ดโมเดลสำหรับมัน — การรองรับการให้บริการสำหรับ Jev ครั้งแรกในเกตเวย์ของบุคคลที่สาม หลังจากสองสัปดาห์ที่วิธีเดียวที่จะเรียกใช้มันได้คือเอนด์พอยต์ของ TypeSafe เอง เรื่องนี้สำคัญตรงนี้ด้วยเหตุผลเฉพาะอย่างหนึ่ง Jev แปลกตรงที่ผู้จำหน่ายของมันเผยแพร่รายการวิธีที่มันล้มเหลว และรายการที่คุณอ่านได้อย่างเดียวนั้นง่ายกว่ามากที่จะข้ามไป เมื่อเทียบกับโมเดลที่คุณเรียกใช้ได้จริง

หน้านี้คือรายการนั้น โดยจำกัดเฉพาะสิ่งที่ TypeSafe เองกล่าวไว้ บวกกับขีดจำกัดในการดำเนินงานและค่าใช้จ่าย

TypeSafe เผยแพร่รายการความหยักของตัวเอง

docs.typesafe.ai มีหน้าเพจชื่อ ความขรุขระของ Jev 1.13 ซึ่งใช้กับ jev-1.13 อย่างชัดเจน มีวันที่ตรวจทาน 2026-09-17 และเปิดด้วยถ้อยคำของผู้ขายเองว่า “Jev ไม่สมบูรณ์แบบ นี่คือขอบขรุขระบางส่วนที่เราทราบเกี่ยวกับ jev-1.13 หลายอย่างในสิ่งเหล่านี้จะได้รับการแก้ไขในเวอร์ชันถัดไป” ตามมาด้วยโหมดที่มีชื่อเก้าโหมด แต่ละโหมดมีกรณีเฉพาะและวิธีแก้แบบ “แทนที่:” ไม่มีสิ่งใดด้านล่างนี้ที่ถูกอนุมานขึ้นมา และไม่มีสิ่งใดถูกทำให้อ่อนลง — ถ้อยคำเป็นของ TypeSafe และในจุดที่บริษัทให้ตัวอย่างของตนเอง ตัวเลขในตัวอย่างนั้นก็เป็นของบริษัทเอง

การอ่านแบบตรงตัว: {{1}}มัน{{/1}}ตอบคำถามที่คุณเขียน

คำที่กำหนดขอบเขต คำปฏิเสธ และเงื่อนไขที่บอกเป็นนัยจะถูกตีความตามตัวอักษร คำถามจะได้รับคำตอบจากถ้อยคำในคำสั่ง "ในขณะที่คนเราอาจอ่านเจตนาที่อยู่เบื้องหลังคำสั่ง"

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

คณิตศาสตร์และตัวเลข: มันไม่ใช่เครื่องคิดเลข

TypeSafe กล่าวอย่างตรงไปตรงมาให้อิมพลีเมนต์ตรรกะทางคณิตศาสตร์ในโค้ด ภายใต้คำกล่าวนั้นมีความล้มเหลวเฉพาะเจาะจงสามประการ:

• การนับเป็นสิ่งที่ไม่น่าเชื่อถือ พฤติกรรมนี้ครอบคลุมทั้งจำนวนตัวอักษรในคำ จำนวนครั้งที่คำหนึ่งปรากฏในเนื้อความ และจำนวนรายการในลิสต์ยาว ๆ "โมเดลจดจำรูปร่างหน้าตาของคำตอบมากกว่าที่จะนับจริง และความคลาดเคลื่อนจะยิ่งมากขึ้นตามขนาดของสิ่งที่กำลังนับ" เกณฑ์ทดสอบของทางผู้ขายเองสำหรับตัดสินว่าควรถามตั้งแต่แรกหรือไม่ก็คือ ถ้า regular expression หรือ parser หาหน่วยนั้นได้ การนับก็ควรอยู่ในโค้ด และโมเดลไม่ได้เพิ่มอะไรเลย

• การแทนค่าเชิงตัวเลขมีประสิทธิภาพด้อยกว่าการแทนค่าเชิงความหมาย คำถามเกี่ยวกับสีที่ใช้ค่า hex จะได้ผลแย่กว่าคำถามเดียวกันที่ใช้ชื่อสีภาษาอังกฤษ เมื่อให้ชุดค่า RGB หรือ hex, Jev ไม่สามารถตัดสินได้อย่างน่าเชื่อถือว่าค่าสองค่าใกล้เคียงกันหรือไม่ ช่องว่างเดียวกันนี้ปรากฏในโค้ดระดับต่ำ — แอสเซมบลี หรือคำสั่งที่เข้ารหัสแบบไบนารี — เมื่อเทียบกับภาษาระดับสูง จงแปลงหรือจัดกลุ่มในโค้ด และเก็บโมเดลไว้สำหรับส่วนที่เป็นการตัดสินใจอย่างแท้จริง

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

วันที่และเวลา: อ่านเป็นข้อความ ไม่ใช่ปริมาณ

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

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

ความอ้อม: การปฏิเสธซ้อนและขั้นตอนที่เพิ่มขึ้นทำให้ความแม่นยำลดลง

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

สถานะขนาดใหญ่ที่เต็มไปด้วยรายละเอียดที่ไม่เกี่ยวข้องทำให้ความแม่นยำลดลง

ความแม่นยำลดลงเมื่อสถานะเติบโตขึ้นด้วยเนื้อหาที่ไม่เกี่ยวข้องกับการตัดสินใจ รายละเอียดที่ไม่เกี่ยวข้องทำหน้าที่เป็นตัวรบกวน และสถานะขนาดใหญ่ทำให้ระบุได้ยากขึ้นว่าส่วนใดของอินพุตที่ทำให้เกิดคำตอบผิด คำเตือนของ TypeSafe เองในบันทึกปิดท้ายก็ตรงไปตรงมา: "Jev ประสบกับ context rot ดังนั้นเนื้อหาที่ไม่เกี่ยวข้องในสถานะจึงทำให้คุณสูญเสียความแม่นยำ"

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

เนื้อหาที่เป็นปฏิปักษ์ในสถานะทำให้คำตอบเปลี่ยนไป

สถานะคือข้อมูล และ jev-1.13 ไม่ถือว่ามันเป็นภัยคุกคามโดยค่าเริ่มต้น คำสั่งที่ถูกแทรกเข้ามา การวางกรอบที่จงใจทำให้เข้าใจผิด หรือข้อความที่โต้แย้งเพื่อการจัดประเภทของตัวเอง อาจทำให้ผลลัพธ์เปลี่ยนไปได้ นี่เป็นโหมดเดียวที่ผู้ขายระบุอย่างชัดเจนว่าการแก้ไขเป็นงานในอนาคต — "เราคาดว่าจะปรับปรุงเรื่องนี้ในอนาคต" — และคำแนะนำชั่วคราวคือให้ระบุเกณฑ์อย่างชัดเจน และทดสอบการผสานรวมอย่างละเอียดก่อนนำไปให้ผู้ใช้จำนวนมากใช้งาน

คำแนะนำและเกณฑ์ที่ขัดแย้งกันทำให้มันสับสน

เมื่อคำสั่งและเกณฑ์กำหนดสิ่งที่แตกต่างกัน โมเดลอาจสับสน ตัวอย่างของ TypeSafe คือ noul ที่ซึ่ง true จับคู่กับ no และ false จับคู่กับ yes ซึ่งให้ผลแย่กว่าคำถามเดียวกันที่เขียนไว้อย่างสอดคล้องกัน คำสั่งคือให้ถือว่าเกณฑ์เป็นส่วนขยายของคำสั่ง และปรับทั้งสองให้สอดคล้องกันด้วยภาษาที่คนทั่วไปอ่านและเข้าใจได้

ค่าคงที่เชิงโครงสร้างที่มันไม่ได้รับประกัน

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

• หนึ่งคำถาม สองประเภทคำถาม "ลูกค้ากำลังขอเงินคืนหรือไม่?" เมื่อถามในรูปแบบ noul และเมื่อถามเป็นตัวเลือกใช่/ไม่ใช่ บนทิกเก็ต "ฉันไม่พอใจกับความพอดี แล้วมีทางเลือกอะไรบ้างตรงนี้?" จะคืนค่า noul 0.22 และตัวเลือกใช่ 0.01, ไม่ใช่ 0.99, ความมั่นใจ 0.97 สิ่งเหล่านั้นคือคำตอบสำหรับคำถามเดียวกัน

• คำถามและนิเสธของคำถามนั้น "ลูกค้ากำลังขอเงินคืนหรือไม่?" และ "ลูกค้ากำลังขอสิ่งอื่นที่ไม่ใช่เงินคืนหรือไม่?" โดยถามเป็นสองโหนดบนทิกเก็ต "ฉันถูกเรียกเก็บเงินสองครั้งสำหรับคำสั่งซื้อเดียวกัน มีใครช่วยตรวจสอบเรื่องนี้ได้ไหม?" คืนค่า 0.72 และ 0.47 รวมกันได้ 1.19

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

การสร้าง: มันไม่ได้รับการฝึกให้เขียน

jev-1.13 ไม่ได้รับการฝึกให้สร้างข้อความ คุณสามารถบังคับให้สร้างเอาต์พุตได้โดยการเชื่อมตัวเลือกเข้าด้วยกัน และ TypeSafe กล่าวโดยตรงว่า สิ่งนี้ "จะไม่ทำงานได้ดีและจะช้ามาก" สำหรับการสกัด คำแนะนำคือให้ดึงค่าที่เป็นตัวเลือกออกมาด้วยนิพจน์ทั่วไปหรือโมเดลแบบเจเนอเรทีฟ แล้วให้ Jev เลือกค่าที่ถูกต้อง หรือ — เมื่อพื้นที่คำตอบมีขอบเขตจำกัด — เปลี่ยนการสกัดให้เป็นการเลือกจากตัวเลือกต่างๆ แทนที่จะถามหาค่านั้นเอง

ขีดจำกัด 255 ตัวเลือกในคำถามแบบเลือก

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

• ไม่มีการสร้างข้อความ มันคืนค่าเป็นคำตัดสิน ไม่ใช่ข้อความร้อยเรียง นั่นคือการออกแบบ ไม่ใช่ข้อบกพร่อง

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

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

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

• ภาษาอังกฤษเป็นภาษาหลัก ภาษาอื่นๆ รวมถึงอักษร CJK ได้รับการรองรับแต่ไม่ได้ดีเท่ากัน คำแนะนำของ TypeSafe คือให้ทดสอบกับเนื้อหาของคุณเองก่อนที่จะพึ่งพา Jev สำหรับงานที่ไม่ใช่ภาษาอังกฤษ และให้ใช้ค่าความมั่นใจในการกำหนดเส้นทาง

ขีดจำกัด 255 ตัวเลือกในคำถามแบบเลือก

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

หน้าต่างการให้บริการของเราเองสำหรับ typesafe/jev-1.13 ซึ่งอ่านจากการ์ดโมเดลเมื่อ 2026-09-30 แสดงให้เห็นว่าสิ่งนี้เป็นอย่างไรในทางปฏิบัติตลอดเจ็ดวันของทราฟฟิกของเราเอง: ค่ามัธยฐาน 151 มิลลิวินาที และ p95 247 มิลลิวินาที, 348 โทเคนเอาต์พุตต่อวินาที และอัตราข้อผิดพลาด 0.49% จากการให้บริการ 76.2 ล้านโทเคน ค่ามัธยฐานรายวันเคลื่อนไหวในช่วงแคบ — 175, 170, 163, 161, 170, 147 และ 143 มิลลิวินาที ตั้งแต่ 2026-09-24 ถึง 2026-09-30 — แต่ p95 รายวันสำหรับ 2026-09-28 อยู่ที่ 2,448 มิลลิวินาที ซึ่งประมาณสิบเท่าของวันทั้งสองข้างเคียง เราไม่สามารถถือว่าค่าผิดปกติในวันเดียวนั้นเกิดจาก choice cardinality และเราจะไม่ทำเช่นนั้น; การตีความที่ซื่อตรงคือหางนั้นมีอยู่จริง และเวิร์กโฟลว์ที่ไวต่อความหน่วงควรได้รับการออกแบบโดยยึดหางมากกว่าค่ามัธยฐาน

บิลที่ป้อนเข้าคือบิลทั้งใบ

เอาต์พุตถูกคิดราคาที่ศูนย์บน Jev ซึ่งบางครั้งถูกตีความว่า "Jev ฟรี" แต่ไม่ใช่ เพราะอินพุตถูกคิดตามปริมาณ และ state ขนาดใหญ่ไม่ได้ฟรีเพียงเพราะไม่มีอะไรทางฝั่งเอาต์พุต ราคาจากผู้ขายคือ $0.042 ต่ออินพุต 1 ล้านโทเค็น — ตัวเลขเดียวกับที่ TypeSafe ระบุว่า $42 ต่อพันล้าน — และ OrcaRouter ส่งต่อราคาตามรายการของผู้ให้บริการโดยบวก markup 0% ดังนั้นหากผู้ขายลดราคา ก็จะมีผลที่นี่ภายในวันเดียวกัน

นี่คือสิ่งที่มันทำกับรูปทรงที่สมจริง โดยใช้อัตราของผู้ขายเอง:

• คำขอเล็ก ๆ ข้อหนึ่ง ตั๋วสนับสนุนขนาด 1,200 โทเคน บวกกับรูบริกและคำถามประมาณ 300 โทเคน รวมเป็นโทเคนอินพุต 1,500 โทเคน ซึ่งคิดเป็น $0.000063 ต่อการเรียกหนึ่งครั้ง

• คำขอขนาดใหญ่ สัญญา 55,000 โทเค็น บวกกับคำถามที่ทำให้คำขอรวมเป็น 60,000 โทเค็น คิดเป็น 40 เท่าของจำนวนโทเค็น ดังนั้น $0.0025 ต่อการเรียก — ยังถือว่าน้อยต่อการเรียก และมากกว่ากรณีแรก 40 เท่าสำหรับคำตอบเดียวกันเพียงหนึ่งคำตอบ

• ที่ปริมาณมาก 60,000 โทเคนต่อการเรียก และ 10,000 การเรียกต่อวัน เท่ากับ 600 ล้านโทเคนอินพุตต่อวัน ซึ่งก็คือ 0.6 พันล้าน ดังนั้น $25.20 ต่อวัน และประมาณ $756 ตลอดหนึ่งเดือนที่มี 30 วัน จำนวนการเรียกเท่าเดิมเมื่อใช้คำขอขนาด 1,500 โทเคน คือ 15 ล้านโทเคนต่อวัน: $0.63 ต่อวัน ประมาณ $18.90 ต่อเดือน

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

ขีดจำกัดการใช้งานที่ประกาศไว้ เพื่อไม่ให้ใครต้องเดาเอาเอง

หน้า models ของ TypeSafe เผยแพร่ตัวเลขที่ชัดเจน ผู้วางแผนจึงไม่จำเป็นต้องอนุมานเอง:

• ปริมาณงานและอัตรา 100K โทเคนต่อวินาที และ 40 คำขอต่อวินาที ตาม docs.typesafe.ai/models.md คำขอที่เกินขีดจำกัดใดขีดจำกัดหนึ่งจะได้รับ 429 Too Many Requests; SDK ไคลเอนต์ของผู้ให้บริการจะลองใหม่แบบ backoff โดยค่าเริ่มต้น และปฏิบัติตามส่วนหัว retry-after เมื่อการตอบกลับมีส่วนหัวนี้มาด้วย

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

• งบประมาณบริบท งบประมาณคำขออยู่ที่ประมาณ 64,000 โทเค็นเมื่อรวมสถานะและคำถามทั้งหมดเข้าด้วยกัน — การ์ดโมเดลเผยแพร่ไว้ที่ 65,536 — และหน้าของโมเดลจากผู้ขายกำหนดเพดานแยกต่างหากสำหรับสถานะบวกคำถามที่ยาวที่สุดเพียงข้อเดียวไว้ที่ 32,000 โทเค็น ตัวเลขตัวที่สองนั้นคืองบประมาณสถานะ ไม่ใช่เวอร์ชันที่เล็กกว่าของตัวแรก ทั้งสองเป็นจริงและไม่มีตัวใดขัดแย้งกับอีกตัว

• Aliases เคลื่อนไหวอยู่ใต้เท้าคุณ jev-latest และ jev-preview ต่างชี้ไปที่ jev-1.13.0 ในตอนนี้ และผู้จำหน่ายระบุว่าขณะนี้ยังไม่มีบิลด์พรีวิวให้ใช้งาน Alias จะเปลี่ยนเมื่อมีรีลีสใหม่เปิดตัว ดังนั้นหากคุณปรับค่า threshold ความเชื่อมั่นให้เหมาะกับเวอร์ชันใดเวอร์ชันหนึ่งไว้แล้ว ให้ปักหมุด ID ที่ระบุเวอร์ชันไว้ แล้วเปลี่ยนตามกำหนดเวลาของคุณเอง

สิ่งที่กรณีการใช้งานของคุณต้องมีหน้าตาเป็นอย่างไร

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

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

อีกหนึ่งเรื่องที่ควรรู้ก่อนที่คุณจะเชื่อมต่อ: ความแตกต่างอย่างตรงไปตรงมาในวิธีที่ Jev ถูกเรียกใช้ บน OrcaRouter แค็ตตาล็อกเข้าถึง Jev ผ่านเอนด์พอยต์ systemone โดยเฉพาะ คือ POST /v1/systemone แทนที่จะผ่านรูปแบบ chat-completions ของ OpenAI นั่นคือความแตกต่างจริงในคำขอที่คุณเขียน และเป็นเวอร์ชันที่ถูกต้องของข้อกล่าวอ้างเดิมที่ว่า Jev "มีรูปแบบคำขอเป็นของตัวเอง" ทุกอย่างอื่นเหมือนกับโมเดลอื่น ๆ ในบัญชี — คีย์เดียวสำหรับโมเดล 200+ ตัว ไม่มีค่าธรรมเนียมต่อโทเคนจากเรา และมี failover อัตโนมัติหากเส้นทางมีปัญหา TypeSafe ได้ยกเลิกรายการรอเมื่อวันที่ 2026-09-21; หน้าแรกของผู้ให้บริการเองยังคงอธิบาย Jev ว่าอยู่ในช่วงเปิดให้ใช้งานก่อนกำหนด และหน้าผลการทดสอบประสิทธิภาพของตัวเองยังคงถูกทำเครื่องหมายว่ารอดำเนินการ ดังนั้นตัวเลขประสิทธิภาพเพียงอย่างเดียวในหน้านี้คือตัวเลขการให้บริการที่เราวัดเองและข้อกล่าวอ้างของผู้ให้บริการเอง โดยกำกับว่าเป็นของผู้ให้บริการ