จุดที่ Decisions API ของ OpenAI สิ้นสุด และ Jev เริ่มต้น: สิ่งที่ลูกค้าภายนอกรายแรกแสดงให้เห็น

เมื่อเวลา 23:05 UTC ของวันที่ 2026-10-06 ปลั๊กอินที่ชื่อ llm-openai-decisions ได้เปิดตัวบน PyPI และ README ของมันเองมีประโยคที่การรายงานข่าวตอนเปิดตัวไม่เคยพิมพ์ว่า "ต่างจาก Jev โมเดลตัดสินใจใหม่ gpt-6-luna รองรับอินพุตรูปภาพนอกเหนือจากข้อความ" ผู้เขียนคือ Simon Willison ซึ่งเป็นคนเขียนไคลเอนต์ตัวแรกสำหรับโมเดลตัดสินใจของ TypeSafe และการเปรียบเทียบที่เขาสร้างขึ้นคือระหว่าง GPT-6 Luna — โมเดลที่อยู่เบื้องหลัง Decisions API ของ OpenAI — และ Jev 1.13 ซึ่งเป็นโมเดล System One ที่รองรับเฉพาะข้อความของ TypeSafe บล็อกโพสต์เดียวกันระบุว่าปลั๊กอินนี้เขียนโดย GPT-6 Astra ขณะอ่านเอกสารของ OpenAI

ข้อดีของการที่ไคลเอนต์ออกให้ใช้งานหนึ่งสัปดาห์หลังจาก API ก็คือ มันถูกเขียนขึ้นโดยอิงกับรูปแบบคำขอ ไม่ใช่คีย์โน้ต ดังนั้นจึงเผยให้เห็นความแตกต่างที่ข้อความการตลาดกลบเกลื่อนไว้ ไม่มีสิ่งใดที่นี่เป็นการรั่วไหล และไม่มีสิ่งใดที่นี่ที่ยังไม่ได้รับการยืนยัน — ตัวเลขทุกตัวด้านล่างนี้มาจากหน้าที่เผยแพร่โดย OpenAI, TypeSafe หรือรีโพซิทอรีของปลั๊กอินเอง ทั้งหมดอ่านเมื่อ 2026-10-07 สิ่งที่ยังขาดอยู่คือการวัดเอนด์พอยต์เองอย่างอิสระ และช่องว่างนั้นถูกระบุไว้ตอนท้ายแทนที่จะถูกกลบเกลื่อน

พื้นผิวทั้งสาม ที่แยกออกจากกัน

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

• เอนด์พอยต์ของ OpenAI คือ POST /v1/decisions ซึ่งเป็นเส้นทางเฉพาะ ไม่ใช่โหมดบน Responses API ของ TypeSafe คือ POST /v1/systemone ทั้งคู่รับชุดหลักฐานพร้อมรายการคำถามที่ระบุชนิด และคืนคำตอบหนึ่งรายการต่อคำถามหนึ่งข้อ โดยใช้ชื่อที่คุณกำหนดเป็นคีย์

• โมเดลต่าง ๆ ปัจจุบัน The Decisions API ยอมรับโมเดลเพียงหนึ่งเดียวเท่านั้น คือ gpt-6-luna ซึ่งเป็นระดับราคาย่อมเยาของสาย GPT-6 ทั่วไปของ OpenAI และเปิดตัวเมื่อ 2026-09-22 ในฐานะโมเดลข้อความและรูปภาพทั่วไป Jev 1.13 เป็นโมเดลสำหรับการตัดสินใจแบบครบวงจรตั้งแต่ต้นจนจบ — ไม่สามารถสร้างข้อความอิสระได้เลย TypeSafe เปิดตัวเมื่อ 2026-09-15 และพร้อมให้ใช้งานทั่วไปตั้งแต่ 2026-09-21

• ไคลเอนต์ SDK ของ OpenAI เองรองรับเอนด์พอยต์นี้ตั้งแต่เปิดให้ทดลองใช้แบบสาธารณะเมื่อวันที่ 2026-10-06 ดังนั้นปลั๊กอินนี้จึงไม่ใช่วิธีแรกในการเรียกใช้งาน แต่มันเป็นไคลเอนต์ตัวแรกนอกเหนือจาก SDK ของ OpenAI เองที่เราตรวจสอบได้ และเป็นตัวแรกที่เขียนขึ้นสำหรับเครื่องมือบรรทัดคำสั่งแทนที่จะเป็นไลบรารีสำหรับแอปพลิเคชัน

สองเมตร เคียงข้างกัน

นี่คือจุดที่ README ของลูกค้ามีคุณค่ามากกว่าคำประกาศ เพราะตัวเลขอยู่ติดกับถ้อยคำ

• ราคา — Decisions API คิดค่าบริการ $0.10 ต่อล้านโทเค็นอินพุต โดยไม่มีค่าใช้จ่ายเอาต์พุต ไม่มีค่าอ่านแคช และไม่มีค่าเขียนแคช Jev 1.13 คิดค่าบริการ $0.042 ต่อล้านโทเค็นอินพุต โดยเอาต์พุตฟรี ทั้งสองคิดค่าสิ่งที่คุณส่งและไม่คิดค่าสิ่งที่ส่งกลับ ดังนั้นการตัดสินใจหนึ่งครั้งจึงมีค่าใช้จ่ายเพียงเศษเสี้ยวของเซนต์ที่ราคาใดก็ตาม และความแตกต่างระหว่างทั้งสองคือปัจจัย 2.4 ไม่ใช่รูปแบบการคิดค่าบริการที่ต่างกัน

• อินพุต — Decisions API รับข้อความ หรือข้อความจากผู้ใช้ที่ผสมข้อความกับรูปภาพ และ README ของปลั๊กอินระบุว่ารองรับไฟล์แนบ PNG, JPEG, WebP และ GIF โดยมีรูปภาพได้สูงสุด 128 รูปในหนึ่งคำขอ รูปภาพต้องส่งเป็น data URL แบบ base64 แบบอินไลน์ URL รูปภาพแบบ HTTP หรือ HTTPS ที่โฮสต์ไว้ และอินพุตประเภท file_id ไม่ได้รับการยอมรับจากเอนด์พอยต์ ดังนั้นปลั๊กอินจึงแปลง URL หรือพาธในเครื่องก่อนส่ง เอกสารของ Jev 1.13 กลับระบุอย่างตรงไปตรงมาในทางตรงกันข้ามว่า "ไม่รับอินพุตรูปภาพ เสียง หรือวิดีโอ" และอินพุตที่ไม่ใช่ข้อความควรถูกประมวลผลล่วงหน้าให้เป็นข้อความหรือฟิลด์แบบมีโครงสร้างก่อนที่จะไปถึง state

• ประเภทคำถาม — OpenAI ระบุไว้สามประเภท: predicate (ความน่าจะเป็นตั้งแต่ 0 ถึง 1 ที่เงื่อนไขที่ระบุไว้เป็นจริง), choice (ค่าหนึ่งค่าจากรายการของคุณ พร้อมการแจกแจงและฟิลด์ความเชื่อมั่นแยกต่างหาก), และ score (ค่าเฉลี่ยถ่วงน้ำหนักด้วยความน่าจะเป็นจากระดับต่างๆ ที่เรียงลำดับไว้). สามประเภทของ TypeSafe คือสามแนวคิดเดียวกันภายใต้ชื่อที่ต่างออกไป: noul สำหรับใช่/ไม่ใช่, choice, และ score. "Noul" ย่อมาจาก Bernoulli และชื่อนี้เป็นเครื่องหมายที่เหมาะสมของความแตกต่างทางวัฒนธรรม — ผู้ขายรายหนึ่งส่งคำนามภาษาอังกฤษธรรมดา ส่วนอีกรายส่งมุกสถิติ.

• การคำนวณคะแนน — ทั้งสองตรงกันอย่างแม่นยำ ซึ่งเป็นสัญญาณที่ชัดเจนที่สุดว่านี่คือหมวดหมู่ผลิตภัณฑ์เดียว ไม่ใช่สองหมวดหมู่ เอกสารของ OpenAI ป้อนความน่าจะเป็นสามระดับความรุนแรงที่ 0.1, 0.7 และ 0.2 แล้วได้คะแนนกลับมาเป็น 1.1 — โดยจงใจให้อยู่ระหว่างสองระดับแทนที่จะปัดไปหาระดับที่ใกล้ที่สุด ระดับของ TypeSafe ใช้ดัชนีเริ่มจากศูนย์ในลักษณะเดียวกัน และปลั๊กอินสำหรับ Jev รับระดับที่มีลำดับตั้งแต่สองถึงสิบระดับ หน้าเว็บของ OpenAI ไม่ได้ระบุเพดานสูงสุด นั่นคือการไม่มีข้อมูลในเอกสารของพวกเขา ไม่ใช่ขีดจำกัดที่เรายืนยันได้

• งบประมาณ — Jev ระบุหน้าต่างบริบทของตนอย่างแม่นยำ: ประมาณ 64,000 โทเคนต่อคำขอ โดยราว 32,000 โทเคนในจำนวนนั้นครอบคลุมสถานะบวกกับคำถามเดี่ยวที่ยาวที่สุด เทียบกับบริบทขนาด 1,050,000 โทเคนที่แคตตาล็อกของเราเองระบุไว้สำหรับ GPT-6 Luna ในฐานะโมเดลทั่วไป หน้าคำตัดสินใจของ OpenAI ไม่ได้เผยแพร่งบประมาณโทเคนใด ๆ เลย มีเพียงหมายเหตุว่าค่าธรรมเนียมพิเศษสำหรับการประมวลผลตามภูมิภาคและตัวคูณอินพุตบริบทยาวยังคงมีผลกับอัตรานี้

สิ่งที่ลูกค้าเปิดเผยแต่ประกาศไม่ได้เปิดเผย

มีสามรายละเอียดในปลั๊กอินและ README ของมันที่ควรค่าแก่การหยิบยกมา เพราะแต่ละอย่างล้วนเปลี่ยนวิธีการที่คุณจะเชื่อมต่อ endpoint

ข้อแรกก็คือ การตัดสินใจหนึ่งๆ อาจส่งกลับมาเป็นการปฏิเสธได้ เอกสารของ OpenAI ไม่เคยอธิบายเรื่องนี้เป็นความเรียง แต่ตัวอย่าง SDK ทุกตัวต่างแยกสาขาตามค่านี้ — answer.type === "refusal" ใน JavaScript, เคส OpenAI::Models::Decision::Answer::Refusal ใน Ruby — และ README ของปลั๊กอินระบุชัดเจนว่าคำถามที่ถูกปฏิเสธจะถูกเก็บไว้เป็น {"name":"...","type":"refusal"} ดังนั้น ชนิดของคำตอบจึงมีสี่ค่า ไม่ใช่สามค่า และลูปโปรดักชันใดๆ ต้องจัดการสาขาที่สี่ซึ่งไม่มีประกาศใดกล่าวถึง

อย่างที่สองคือสิ่งที่ขาดไปจากปลั๊กอิน มากกว่าที่จะมีอยู่ในตัวมัน โพสต์ของ Willison เองวางกรอบงานนี้ว่าเป็นการให้ GPT-6 Astra อ่านเอกสารใหม่แล้วสร้างไคลเอนต์จากเอกสารนั้น — จากเอกสารสู่ไคลเอนต์ ในรอบเดียว ไม่มีบทช่วยสอนโดยมนุษย์ ตอนนี้นั่นเป็นวิธีปกติที่ไคลเอนต์จะถูกเขียนขึ้น และมันหมายความว่าคำถามที่ว่าเอกสารของเอนด์พอยต์หนึ่งสมบูรณ์พอที่จะสร้างไคลเอนต์ที่ใช้งานได้จากสิ่งนั้นหรือไม่ ได้กลายเป็นคำถามเชิงปฏิบัติ มากกว่าเชิงบรรณาธิการ สำหรับเอนด์พอยต์นี้ คำตอบคือส่วนใหญ่ใช่ โดยมีประเภทการปฏิเสธเป็นรอยต่อที่มองเห็นได้

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

ตอนนี้หมวดหมู่นี้มีผู้ครองอยู่สามราย และสองรายในนั้นไม่ใช่โมเดลทั่วไป

ควรเอ่ยถึงรายที่สามด้วย เพราะกรอบ decision-endpoint จะสมเหตุสมผลก็ต่อเมื่อมองทั้งสามรายประกอบกัน Perplexity มี Decisions API เป็นของตัวเอง ให้บริการโดย pplx-decider-v1-27b — โมเดลตัดสินใจขนาด 2.7 หมื่นล้านพารามิเตอร์ที่เผยแพร่ภายใต้ Apache 2.0 พร้อมเวตบน Hugging Face เมื่อ 2026-10-01 นั่นทำให้หมวดหมู่นี้มีรูปร่างที่แตกต่างจากของ OpenAI อย่างแท้จริง โดย Jev 1.13 เป็นแบบปิดและรองรับข้อความเท่านั้น ตัวตัดสินใจของ Perplexity เป็นแบบเปิดเวตและรับภาพได้ ส่วนรายการของ GPT-6 Luna เป็นเพียงฮาร์เนสที่ห่อหุ้มโมเดลทั่วไป ไม่ใช่โมเดลที่สร้างขึ้นมาเพื่อตัดสินใจ

สำหรับผู้อ่านที่กำลังเลือกในวันนี้ ความแตกต่างในทางปฏิบัติแคบกว่าที่การตลาดสื่อออกมา หากหลักฐานของคุณคือประโยคหนึ่งประโยคหรือบันทึกหนึ่งรายการ และคุณต้องการต้นทุนต่อการเรียกที่ถูกที่สุดพร้อมความแปรปรวนของพฤติกรรมที่น้อยที่สุด Jev 1.13 คือตัวเลือกเฉพาะทาง และอัตรา $0.042 ของมันเป็นราคาที่ต่ำที่สุดในสามราคาที่เผยแพร่ซึ่งเราสามารถตรวจสอบได้ หากหลักฐานของคุณมีภาพถ่ายรวมอยู่ด้วย หรือคุณต้องการคำตัดสินจากโมเดลที่คุณคุ้นเคยอยู่แล้วจากงานทั่วไป Decisions API เป็นเพียงหนึ่งเดียวในสองตัวเลือกแบบปิดที่รับภาพได้ ส่วนตัวเลือกแบบเปิดน้ำหนักนั้นตอบคำถามคนละข้อ — การควบคุมและการโฮสต์เอง — และเรายังไม่ได้ทดสอบมัน

สิ่งที่เราสามารถวัดได้จริง และสิ่งที่ไม่มีใครมี

คำกล่าวอ้างของ OpenAI สำหรับ endpoint นี้คือ มัน "ประเมินข้อความ รูปภาพ หรือทั้งสองอย่าง และส่งคืนคำตอบแบบมีชนิดข้อมูลได้เร็วกว่า Responses API ประมาณ 10 เท่า" นั่นเป็นคำกล่าวอ้างจากผู้ขายและยังไม่มีการทำซ้ำ: ไม่ระบุภูมิภาค ไม่ระบุขนาดอินพุต ไม่ระบุระดับการทำงานพร้อมกัน ไม่มีข้อตกลงระดับบริการ และตัวเทียบ基準คือ Responses API โดยทั่วไป ไม่ใช่เวิร์กโหลดใดเวิร์กโหลดหนึ่งโดยเฉพาะ ตัวเลขความเร็วที่เพิ่มขึ้นเพียงตัวเลขเดียวไม่ใช่ตัวเลขที่ควรใช้กำหนดเส้นตาย

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

• GPT-6 Luna ทุกรูปแบบคำขอ: ค่ามัธยฐาน 1,448 มิลลิวินาที และ p95 4,912 มิลลิวินาที อัตราข้อผิดพลาด 1.31% จากโทเคน 643,394,111 โทเคนในเจ็ดวัน ซึ่งเป็นลักษณะของอัตราการประมวลผลประมาณ 125 โทเคนเอาต์พุตต่อวินาทีเมื่อโมเดลกำลังเขียน

• Jev 1.13: ค่ามัธยฐาน 149 ms และ p95 245 ms อัตราข้อผิดพลาด 0.10% จาก 110,193,080 โทเคน นั่นคือ endpoint ที่เร็วอย่างแท้จริง และมันเร็วเพราะไม่สร้างการตอบกลับ — มันคืนค่าตัวเลขสำหรับสถานะที่ถูกนำเข้าเพียงครั้งเดียว

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

คำถามที่ลึกกว่าและยังไม่ได้วัดคือการสอบเทียบ (calibration) และเป็นคำถามที่ตัดสินว่าสิ่งใดสิ่งหนึ่งในนี้ใช้งานได้จริงหรือไม่ ความน่าจะเป็น 0.92 สำหรับความเสียหายที่มองเห็นได้จะมีคุณค่าต่อการนำไปกำหนดเส้นทางก็ต่อเมื่อ ในทราฟฟิกของคุณ ภาพที่ได้คะแนนใกล้ 0.92 นั้นเป็นภาพที่มีความเสียหายประมาณ 92% ของเวลา เอกสารของ OpenAI แนะนำให้คุณกำหนดเกณฑ์จากตัวอย่างที่มีป้ายกำกับ และเลือกเกณฑ์โดยพิจารณาต้นทุนของผลบวกลวงเทียบกับผลลบปลอม นั่นเป็นคำแนะนำที่ถูกต้อง และยังเป็นการยอมรับด้วยว่าการสอบเทียบตัวเลขเหล่านี้เป็นสิ่งที่คุณต้องสร้างขึ้นเอง สำหรับรอบแรก ให้วัดการกระจายของความน่าจะเป็นที่ส่งกลับมาในตัวอย่างที่คุณรู้คำตอบอยู่แล้ว หากทุกอย่างส่งกลับมาที่ 0.99 หรือ 0.01 เกณฑ์ก็ไม่ได้ทำงานอะไรเลย และ endpoint ก็เป็นเพียงค่าบูลีนที่แพงมาก

วิธีลองใช้อันใดอันหนึ่งโดยไม่ต้องเดิมพันเส้นทางโปรดักชันกับมัน

แหล่งที่มา พูดตรง ๆ: ข้อกำหนดเอนด์พอยต์ ราคา และกฎเกี่ยวกับรูปภาพในบทความนี้มาจากเอกสาร Decisions API ของ OpenAI เองและ README ของปลั๊กอิน ซึ่งทั้งคู่อ่านเมื่อ 2026-10-07; ข้อกำหนด Jev 1.13 มาจากเอกสารโมเดลของ TypeSafe เอง; ตัวเลขการให้บริการเป็นข้อมูล playground ของเราเองในช่วงเจ็ดวันสิ้นสุด 2026-10-07; การประทับเวลาของแพ็กเกจมาจาก PyPI และประวัติ Git ของโปรเจกต์ ข้ออ้างเรื่องความเร็ว 10x เป็นของ OpenAI และระบุไว้ตามนั้น ใบอนุญาตและวันที่เผยแพร่ของ decider แบบ open-weight มาจากที่เก็บโมเดลของมัน

ตัว Decisions API เองเป็นแพ็กเกจจิงของ OpenAI และเราไม่ได้จัดเส้นทางให้มัน; หากคุณต้องการปลายทางเฉพาะนั้น OpenAI คือที่ที่มันอยู่ ส่วนโมเดลที่อยู่เบื้องหลังนั้นเป็นอีกเรื่องหนึ่ง GPT-6 Luna เป็นเส้นทางที่ใช้งานได้จริงบน OrcaRouter ในราคาตามรายการของ OpenAI โดยไม่มีมาร์กอัปบวกเพิ่ม และ typesafe/jev-1.13 ในราคาตามรายการ อยู่บนคีย์เดียวกัน ซึ่งทำให้การเปรียบเทียบในบทความนี้เป็นสิ่งที่คุณรันได้แทนที่จะอ่านอย่างเดียว: สถานะเดียวกัน คำถามเดียวกัน สองปลายทาง สัญญาเดียวที่ต้องจัดการ และไม่มีใบแจ้งหนี้ใบที่สอง

นั่นก็เป็นวิธีที่สมเหตุสมผลในการนำพื้นผิวที่ยังไม่ผ่านการพิสูจน์มาใช้เช่นกัน วางการตัดสินใจไว้หลังฟอลแบ็ก เพื่อให้การปฏิเสธ การหมดเวลา หรือขีดจำกัดเบต้าที่เปลี่ยนแปลงไปข้างใต้คุณ ลดระดับลงเป็นการเรียกแบบพร้อมท์แทนที่จะเป็นการหยุดให้บริการ และเก็บฟอลแบ็กนั้นไว้บนคีย์เดียวกับตัวหลัก เพื่อไม่ต้องเดินสายใหม่เมื่อปลายทางเคลื่อนไปสู่การเปิดให้ใช้งานทั่วไป OpenAI กล่าวว่า GA คาดว่าจะมาถึงในอีกไม่กี่สัปดาห์ข้างหน้า และว่า gpt-6-luna เป็นโมเดลเดียวที่ใช้ได้ในระหว่างนี้ ทั้งสองอย่างนั้นเป็นเหตุผลในการสร้างให้สอดคล้องกับรูปร่างและติดเครื่องมือวัดให้มันตอนนี้ และไม่มีอย่างใดเป็นเหตุผลที่จะเอาการอนุมัติการชำระเงินไปผูกกับมันในตอนนี้

สิ่งที่ควรดูต่อไป

สามสิ่งนี้จะช่วยตอบคำถามที่บทความชิ้นนี้ตอบไม่ได้ หนึ่ง งบประมาณโทเคนที่ประกาศอย่างเป็นทางการสำหรับ endpoint การตัดสินใจ (decisions endpoint) เพื่อให้ประเมินขนาดของคำขอได้ แทนที่จะต้องเดา สอง การประกาศ GA ไม่ว่าฉบับใด ซึ่งเป็นจุดที่อัตราคิดค่าบริการแบบอินพุตเท่านั้น (input-only) หยุดเป็นเพียงคำสัญญาในเวอร์ชันเบตา และสาม การวัดค่าความหน่วง (latency) และการสอบเทียบ (calibration) บนตัว endpoint เองอย่างเป็นอิสระสักหนึ่งครั้ง — คนแรกที่ป้อนคู่ข้อมูลที่มีป้ายกำกับหลายพันคู่ผ่านมันแล้วเผยแพร่เส้นโค้งความน่าเชื่อถือ จะสร้างคุณประโยชน์ให้กับหมวดหมู่นี้ได้มากกว่าที่โพสต์เปิดตัวทั้งสองฉบับทำไว้

จนถึงตอนนั้น สรุปที่ตรงไปตรงมาก็แคบแต่มีประโยชน์: ถ้าสิ่งที่คุณต้องตัดสินใจเป็นข้อความ Jev 1.13 ถูกกว่า และมันคืนค่าตัวเลขภายในประมาณ 150 มิลลิวินาทีในทราฟฟิกของเรา ถ้าสิ่งที่คุณต้องตัดสินใจมีภาพรวมอยู่ด้วย OpenAI's Decisions API คือตัวที่จะดูภาพนั้น ในราคาอินพุต 2.4 เท่า โดยมีป้ายเบต้าติดอยู่บนกล่อง ทั้งสองเรียกใช้ได้จากบรรทัดคำสั่งตั้งแต่สัปดาห์นี้ และนั่นเป็นตำแหน่งที่ดีกว่าที่แต่ละตัวเคยเป็นเมื่อเจ็ดวันก่อน