OpenAI API การตัดสินใจ เทียบกับ Jev

OpenAI Decisions API และ Jev ของ TypeSafe ทำงานเหมือนกันคือ: ส่งข้อมูลนำเข้าและชุดคำถาม แล้วรับกลับมาเป็นคำตอบแบบระบุประเภทพร้อมความน่าจะเป็น แทนที่จะเป็นข้อความที่ต้องแยกวิเคราะห์ และจ่ายเงินเฉพาะสำหรับโทเค็นนำเข้าเท่านั้น Decisions มีค่าใช้จ่าย $0.10 ต่อโทเค็นนำเข้า 1 ล้านโทเค็น อยู่ในช่วง Public Beta รองรับทั้งข้อความและรูปภาพ และทำงานบน GPT-6 Luna Jev มีค่าใช้จ่าย $0.042 ต่อโทเค็นนำเข้า 1 ล้านโทเค็น อยู่ในช่วง Early Access โดยต้องเข้าถึงผ่านบัญชีคอนโซล TypeSafe รองรับเฉพาะข้อความ และจำกัดแต่ละคำขอไว้ที่ 64k โทเค็น

สำหรับพื้นฐาน เริ่มต้นด้วย Decisions API คืออะไร และ วิธีการใช้ Jev โพสต์นี้จะเปรียบเทียบทั้งสองแบบทีละส่วน จากนั้นจะเชื่อมต่อทั้งคู่เข้ากับโปรเจกต์ Apidog เดียวภายใต้กฎความเชื่อมั่นเดียว

button

การเปรียบเทียบแบบเคียงข้างกัน

ข้อมูลในแต่ละช่องมาจากหน้าผู้จำหน่ายตามเอกสารอ้างอิง

	OpenAI Decisions API	TypeSafe Jev
เอนด์พอยต์	`POST /v1/decisions`	`POST /v1/systemone`
โมเดล	เฉพาะ `gpt-6-luna`	`jev-1.13.0` (`jev-latest`)
สถานะ	Public beta, GA “ภายในไม่กี่สัปดาห์ข้างหน้า”	Early access (ประกาศเปิดตัว), การเข้าถึงโดยตรงถูกจำกัดด้วยบัญชีคอนโซล
อินพุต	ข้อความ + รูปภาพ (base64 data URL; เอกสารอ้างอิงยังระบุ public URL)	เฉพาะข้อความ, 64k ต่อคำขอ
ประเภทคำถาม	`predicate` / `choice` (2 ถึง 255 ตัวเลือก) / `score`	`noul` / `choice` / `score`
รูปแบบคำถาม	อาร์เรย์ที่มี `name` ที่เป็นทางเลือก	อ็อบเจกต์ที่ใช้ id เป็นคีย์
ฟิลด์เอาต์พุต	`probability`; `choice` หรือ `score` + `probabilities` + `confidence`; `refusal`	`noul`; `choice` หรือ `score` + `confidence` + `probabilities`
ราคา	$0.10 ต่ออินพุต 1 ล้าน, ไม่มีค่าใช้จ่ายสำหรับเอาต์พุต	$0.042 ต่ออินพุต 1 ล้าน, ไม่มีค่าใช้จ่ายสำหรับเอาต์พุต
การแคช	ยังไม่มี (ฟอรัม OpenAI)	ไม่มีการเผยแพร่
ข้อจำกัดอัตรา	หน้าข้อจำกัดต่อองค์กร	100K TPS / 80 RPS, ปรับเปลี่ยนได้
การอ้างอิงความเร็ว	“เร็วกว่า Responses API ประมาณ 10 เท่า” (OpenAI)	70 ถึง 500 ms แบบ end-to-end (TypeSafe)
ข้อมูล	ZDR + HIPAA สำหรับลูกค้าที่มีคุณสมบัติ; ถิ่นที่อยู่ US/EU	ZDR สำหรับองค์กร; ไม่ได้ฝึกฝนจากคำขอ

Decisions เป็นเอนด์พอยต์ ไม่ใช่โมเดล; มันทำงานบน GPT-6 Luna Jev คือ “โมเดล System One” ของ TypeSafe ซึ่งได้รับการฝึกฝนด้วย RLCD เพื่อให้ผลการตัดสินใจที่ปรับเทียบได้ และไม่ใช่ LLM ทั่วไป

คำขอการจัดเส้นทางตั๋วแบบเดียวกันในสองรูปแบบ

เมื่อมีตั๋วสนับสนุนเข้ามา คุณต้องการระบุแผนกพร้อมคำตอบใช่/ไม่ใช่ว่าลูกค้าต้องการเงินคืนหรือไม่ เริ่มที่ Decisions ก่อน: คำถามเป็นอาร์เรย์ โดยแต่ละคำถามมี type, instructions และ name ที่เป็นทางเลือก ซึ่ง API จะส่งกลับมา

curl https://api.openai.com/v1/decisions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-luna",
    "input": "I was charged twice for my order.",
    "questions": [
      {
        "type": "choice",
        "name": "department",
        "instructions": "Which team should handle this ticket?",
        "choices": [
          {"value": "billing", "description": "Charges, refunds"},
          {"value": "technical", "description": "Bugs, errors"},
          {"value": "other"}
        ]
      },
      {
        "type": "predicate",
        "name": "wants_refund",
        "instructions": "Is the customer asking for money back?"
      }
    ]
  }'

สำหรับ Jev: ฟิลด์อินพุตคือ state, คำถามเป็นอ็อบเจกต์ที่ใช้ id ที่คุณเลือกเป็นคีย์, choice ใช้ criteria แมปตัวเลือกกับคำอธิบาย และประเภทใช่/ไม่ใช่คือ noul

curl https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": "I was charged twice for my order.",
    "questions": {
      "department": {
        "type": "choice",
        "instructions": "Which team should handle this ticket?",
        "criteria": {
          "billing": "Charges, refunds",
          "technical": "Bugs, errors",
          "other": "Anything else"
        }
      },
      "wants_refund": {
        "type": "noul",
        "instructions": "Is the customer asking for money back?"
      }
    }
  }'

สิ่งที่ได้รับกลับมา

Decisions ส่งคืน model, answers และ usage คำตอบจะมาในลำดับที่ถาม โดยแต่ละคำตอบมี name; ความน่าจะเป็นของแต่ละตัวเลือกเป็นอาร์เรย์ของอ็อบเจกต์ โปรดทราบว่า output_tokens: 0

{
  "model": "gpt-6-luna",
  "answers": [
    {
      "type": "choice",
      "name": "department",
      "choice": "billing",
      "probabilities": [
        {"value": "billing", "probability": 0.95},
        {"value": "technical", "probability": 0.02},
        {"value": "other", "probability": 0.03}
      ],
      "confidence": 0.93
    },
    {"type": "predicate", "name": "wants_refund", "probability": 0.95}
  ],
  "usage": {
    "input_tokens": 42,
    "input_tokens_details": {"cached_tokens": 0, "cache_write_tokens": 0},
    "output_tokens": 0,
    "output_tokens_details": {"reasoning_tokens": 0},
    "total_tokens": 42
  }
}

Jev ส่งคืน model (id เวอร์ชัน), อ็อบเจกต์ answers ที่ใช้ id คำถามของคุณเป็นคีย์ และ usage ที่มี input_tokens และ output_tokens คุณอ่าน answers.department.choice, confidence และ probabilities ที่ใช้ชื่อตัวเลือกเป็นคีย์ รวมถึง answers.wants_refund.noul ในฝั่ง OpenAI เท่านั้น คำตอบ refusal สามารถปรากฏสำหรับแต่ละคำถาม ในขณะที่คำถามอื่นๆ ยังคงได้รับคำตอบ

ราคาต่อล้าน และค่าใช้จ่ายของตั๋วหนึ่งล้านใบ

คำกล่าวของ OpenAI: ด้วย gpt-6-luna, อินพุตมีค่าใช้จ่าย $0.10 ต่อ 1 ล้านโทเค็น โดยไม่มีค่าใช้จ่ายสำหรับการอ่านแคช, เขียนแคช หรือโทเค็นเอาต์พุต TypeSafe ระบุ $0.042 ต่อ 1 ล้านโทเค็นอินพุต และเอาต์พุตฟรี

ลองดูตั๋ว 500 โทเค็นพร้อมคำถามสองข้อข้างต้น:

Decisions: 500 / 1,000,000 x $0.10 = $0.00005 ต่อคำขอ ตั๋วหนึ่งล้านใบ = $50
Jev: 500 / 1,000,000 x $0.042 = $0.000021 ต่อคำขอ ตั๋วหนึ่งล้านใบ = $21

มีการใช้ตัวคูณสองตัวในฝั่ง OpenAI: อินพุตบริบทขนาดยาว (มากกว่า 272K โทเค็น) มีค่าใช้จ่าย 2 เท่า หรือ $0.20 ต่อ 1 ล้านโทเค็น ซึ่งมาจาก หน้าการกำหนดราคา และการประมวลผลตามภูมิภาคจะเพิ่มอีก 10% ยังไม่มีเอกสารสำหรับ Batch, Flex, หรือ Fast tier สำหรับ /v1/decisions และตามฟอรัมของ OpenAI ยังไม่มีการแคชพรอมต์ แม้ว่า usage จะมีฟิลด์ cached_tokens และ cache_write_tokens ก็ตาม Jev ไม่ได้เผยแพร่ข้อมูลเกี่ยวกับการแคช

อินพุต: รูปภาพในฝั่งหนึ่ง, ข้อความในอีกฝั่ง

Decisions รับสตริงหรืออาร์เรย์ของข้อความผู้ใช้ที่ผสมผสานส่วน input_text และ input_image คู่มือระบุว่ารูปภาพต้องเป็น base64 data URL แบบอินไลน์; เอกสารอ้างอิง API ยังระบุ public HTTP(S) URL และรูปภาพสูงสุด 128 รูปต่อคำขอ ดังนั้นควรใช้ base64 เป็นวิธีที่ปลอดภัยและทดสอบ URL ที่โฮสต์ไว้ก่อนที่จะใช้งานจริง ไม่รองรับ file_id, ไฟล์ และเสียง

Jev รองรับเฉพาะข้อความ: สตริง, อ็อบเจกต์ JSON หรืออาร์เรย์ของข้อความ โดยไม่มีอินพุตรูปภาพ เสียง หรือวิดีโอ ตามหน้าโมเดลของ TypeSafe ในฟอรัมของ OpenAI, sam.saffron ได้กล่าวไว้อย่างชัดเจนว่า การทำความเข้าใจรูปภาพเป็นสิ่งที่ Jev ยังไม่รองรับ หากการตัดสินใจของคุณขึ้นอยู่กับรูปภาพ มีเพียง Decisions เท่านั้นที่สามารถพิจารณาได้

บริบทและข้อจำกัดอัตรา

Jev เผยแพร่ข้อจำกัด 64k โทเค็นต่อคำขอ โดย 32k เป็นสำหรับ state บวกกับคำถามที่ยาวที่สุด และระบุว่ามันจะรับสถานะเข้ามาเพียงครั้งเดียวและประเมินทุกคำถามแบบขนาน หน้าโมเดลของมันระบุ 100K โทเค็นต่อวินาที และ 80 คำขอต่อวินาที ซึ่งจะปรับเปลี่ยนแบบไดนามิก โดยมี 429 เมื่อเกินขีดจำกัด ตัวเลขเหล่านี้มีการเปลี่ยนแปลงตั้งแต่เดือนกันยายน ดังนั้นโปรดดูหน้าเว็บปัจจุบัน

OpenAI ไม่ได้เผยแพร่ตัวเลขหน้าต่างบริบทและข้อจำกัดอัตราเฉพาะของ Decisions; หน้าต่างโทเค็น 1,050,000 ของ Luna เป็นตัวเลขหน้าโมเดล ไม่ใช่ของเอนด์พอยต์ ตรวจสอบ Settings > Organization > Limits (คู่มือข้อจำกัดอัตรา); คู่มือข้อจำกัดอัตราของเราครอบคลุมการจัดการ 429 ทั้งสองฝั่ง

สถานะและการเข้าถึง

Decisions เข้าสู่ Public beta เมื่อวันที่ 2026-10-06 เปิดให้สำหรับนักพัฒนาทุกคนตาม ประกาศ; คู่มือระบุว่า OpenAI คาดการณ์ว่า GA จะเปิดตัว “ในอีกไม่กี่สัปดาห์ข้างหน้า” โดยไม่มีการระบุวันที่แน่นอน

Jev อยู่ในช่วง early access ตาม โพสต์เปิดตัวของ TypeSafe ซึ่งกล่าวถึงรายการรอ และการเข้าถึงโดยตรงไปยัง api.typesafe.ai ต้องผ่านบัญชีคอนโซล TypeSafe; วิธีการเข้าถึง Jev อธิบายเส้นทาง และ Jev API key ครอบคลุมการสร้างคีย์ เส้นทางที่สองคือ Vercel AI Gateway ซึ่ง Jev คือ typesafe-ai/jev โดยถูกเรียกผ่าน experimental_evaluate ใน AI SDK (7.0.105 หรือใหม่กว่า) ตาม บันทึกการเปลี่ยนแปลงของ Vercel; เอกสารการประเมินของ Vercel ระบุว่ามันไม่ได้เปิดเผยบนเอนด์พอยต์ที่เข้ากันได้กับ OpenAI ของ Gateway และที่นั่นประเภทใช่/ไม่ใช่คือ boolean ซึ่งคืนค่าความน่าจะเป็นของจริง

การควบคุมข้อมูล

OpenAI กล่าวว่า Decisions รองรับ Zero Data Retention และการใช้งาน HIPAA สำหรับลูกค้าที่มีคุณสมบัติ พร้อมด้วยการจัดเก็บข้อมูลและการประมวลผลระดับภูมิภาคในสหรัฐอเมริกาและยุโรป (EEA บวกสวิตเซอร์แลนด์); หน้าการควบคุมข้อมูลเสริมว่าบันทึกการตรวจสอบการใช้งานที่ไม่เหมาะสมสำหรับ /v1/decisions จะถูกเก็บไว้สูงสุด 30 วันโดยค่าเริ่มต้น TypeSafe กล่าวว่า Jev ไม่ได้รับการฝึกฝนจากคำขอหรือการตอบกลับของลูกค้า ให้บริการ ZDR สำหรับลูกค้าองค์กร และใช้ค่าถ่วงน้ำหนักเดียวกันสำหรับทุกบัญชี

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

ความเร็ว แล้วจะเลือกอะไรดี

OpenAI กล่าวว่า Decisions เร็วกว่า Responses API ประมาณ 10 เท่า และไม่ได้เผยแพร่ตัวเลขความหน่วงสัมบูรณ์; นักพัฒนาคนหนึ่งในฟอรัม OpenAI รายงานว่าการตัดสินใจจากอินพุตรูปภาพใช้เวลาประมาณ 0.8 วินาทีในการเชื่อมต่อที่ช้า TypeSafe ระบุว่า Jev ใช้เวลา 70 มิลลิวินาทีถึง 500 มิลลิวินาทีแบบ end-to-end การวัดเหล่านี้ไม่สามารถเปรียบเทียบกันได้ ดังนั้นควรจับเวลาทั้งสองแบบกับตั๋วของคุณเอง

เลือก Decisions เมื่ออินพุตมีรูปภาพ, เมื่อคุณใช้งาน OpenAI อยู่แล้วและต้องการคีย์เดียวและบิลเดียว, หรือเมื่อคุณต้องการความคุ้มครอง HIPAA ภายใต้ OpenAI BAA เลือก Jev เมื่ออินพุตเป็นข้อความ, เมื่อราคาต่อโทเค็นที่ต่ำกว่ามีความสำคัญต่อปริมาณการใช้งานของคุณ, หรือเมื่อคุณใช้งาน Vercel AI Gateway อยู่แล้ว

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

ทดสอบทั้งสองแบบในโปรเจกต์ Apidog เดียว

สองสภาพแวดล้อม สร้าง OpenAI ด้วย OPENAI_API_KEY และ TypeSafe ด้วย TYPESAFE_API_KEY โดยแต่ละตัวมีค่าอยู่ในฟิลด์ภายในเครื่อง เพื่อไม่ให้ซิงค์กับทีม (สภาพแวดล้อมและตัวแปรลับ ครอบคลุมขอบเขตนี้)

คำขอที่บันทึกไว้สองรายการ POST https://api.openai.com/v1/decisions พร้อม Bearer {{OPENAI_API_KEY}} และเนื้อหาแรกด้านบน; POST https://api.typesafe.ai/v1/systemone พร้อม Bearer {{TYPESAFE_API_KEY}} และเนื้อหาที่สอง

กฎการยืนยันหนึ่งข้อ, ใช้สองครั้ง กฎทางธุรกิจ: ความเชื่อมั่นที่สูงกว่า 0.8 จะจัดเส้นทางตั๋วโดยอัตโนมัติ ส่วนที่ต่ำกว่านั้นจะเข้าสู่คิวการตรวจสอบ ในคำขอ Decisions ให้ยืนยันสถานะ 200, $.answers[0].choice เท่ากับ billing, $.answers[0].confidence มากกว่า 0.8, และ $.usage.output_tokens เท่ากับ 0 ในคำขอ Jev ให้ยืนยัน $.answers.department.choice เท่ากับ billing และ $.answers.department.confidence มากกว่า 0.8

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

จำลองทั้งสองรูปแบบ บันทึกการตอบสนอง Decisions และการตอบสนอง Jev เป็น mock เพื่อให้ส่วนหน้าสามารถสร้างได้โดยอิงตามอาร์เรย์ answers และอ็อบเจกต์ answers ที่เสถียร; การจำลองการตอบสนองแบบมีเงื่อนไข จะคืนค่ากรณีความเชื่อมั่นต่ำตามความต้องการเพื่อทดสอบสาขาคิวการตรวจสอบ

รันใน CI รันสถานการณ์ด้วย Apidog CLI (apidog run พร้อม cli หรือ junit reporter) ในทุกการปรับใช้ เพื่อให้การเปลี่ยนแปลงฟิลด์ที่ GA หรือการอัปเดต jev-latest ทำให้ build ล้มเหลว ไม่ใช่คิวสนับสนุน ดาวน์โหลด Apidog เพื่อตั้งค่านี้

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

Jev เป็น LLM เหมือน GPT-6 Luna หรือไม่? ไม่ใช่ TypeSafe อธิบายว่า Jev เป็นโมเดล System One ที่ได้รับการฝึกฝนด้วย RLCD เพื่อให้ผลการตัดสินใจที่ปรับเทียบได้; มันไม่ได้สร้างข้อความ Decisions เป็นเอนด์พอยต์บนโมเดล Luna ทั่วไป

OpenAI สร้าง Decisions API เพื่อตอบสนองต่อ Jev หรือไม่? หน้าเว็บของ OpenAI ไม่ได้ระบุเช่นนั้น และเราก็ไม่ได้อ้างเช่นกัน ทั้งสองนำเสนอแนวคิดเดียวกัน: คำตอบแบบระบุประเภทพร้อมความน่าจะเป็น โดยคิดค่าบริการตามอินพุต

อันไหนถูกกว่า? Jev ที่ $0.042 ต่อ 1 ล้านโทเค็นอินพุต เทียบกับ $0.10; สำหรับตั๋ว 500 โทเค็นหนึ่งล้านใบ คือ $21 เทียบกับ $50

ทั้งสองสามารถคืนค่า JSON schema ของฉันได้หรือไม่? ไม่ได้ ทั้งสองคืนค่ารูปแบบคำตอบที่ตายตัว; สำหรับฟิลด์ที่ดึงมาหรือคำอธิบายที่เป็นข้อความ ให้ใช้ Structured Outputs บน Responses API

ขั้นตอนถัดไป

ส่งคำขอ curl สองรายการด้านบนด้วยตั๋วเดียวกัน บันทึกทั้งสองใน Apidog และเพิ่มการยืนยันความเชื่อมั่น 0.8 ให้แต่ละรายการ จากนั้นเปลี่ยนเป็นตั๋วของคุณเองยี่สิบใบ และดูว่า API ใดที่ข้ามเกณฑ์ของคุณบ่อยกว่า คู่มือการใช้งาน มีเวอร์ชัน Python และ JavaScript

button