# แกะ OpenRouter: flow การทำงานของ AI Gateway ที่รับทราฟฟิกระดับล้านล้าน token ต่อวัน > ไล่ตั้งแต่ request เข้าจนเงินถูกหักออกจากกระเป๋า พร้อมอัลกอริทึมเลือก provider ที่เอกสารเปิดเผยไว้จริง และบทเรียนที่เอาไปใช้ออกแบบ gateway ของตัวเองได้ --- ## 1. มันคืออะไรจริง ๆ คำอธิบายที่เจอบ่อยคือ "API เดียวเรียกได้ทุกโมเดล" ซึ่งถูก แต่ตื้นเกินไปจนมองไม่เห็นว่าระบบทำงานยังไง พูดให้ตรงกว่านั้น OpenRouter คือ **API gateway ที่ทำสามอย่างพร้อมกัน**: 1. **Protocol translation** — รับ payload รูปแบบ OpenAI-compatible แล้วแปลงไปเป็นรูปแบบของ provider ปลายทาง และแปลง response กลับมาให้เหมือนเดิม 2. **Routing + failover** — ตัดสินใจว่าใครควรตอบ request นี้ และทำอะไรต่อเมื่อคนนั้นล้ม 3. **Metering + settlement** — นับ token คำนวณเงิน หักกระเป๋า และรวมบิลของ provider หลายสิบเจ้าให้เหลือใบเดียว ตัวมันเองไม่โฮสต์โมเดล มันเป็น middleware ล้วน ๆ ที่ normalize ความต่างของ API 400+ โมเดลจาก 60+ ผู้ให้บริการ ทั้งเรื่อง tool calling, sampling parameter, การรองรับ caching และรูปแบบ structured output ตัวเลขที่บอกขนาดของระบบ: ณ สิงหาคม 2026 ประมวลผลมากกว่า 10 ล้านล้าน token ต่อวัน จากนักพัฒนาและบริษัทมากกว่า 10 ล้านราย --- ## 2. สถาปัตยกรรมภาพรวม ```mermaid flowchart TB subgraph CLI["ฝั่งผู้เรียก"] APP["แอปของคุณ
OpenAI SDK / OpenRouter SDK / curl"] TOOL["เครื่องมือ third-party
Cline / Continue / OpenCode"] end subgraph EDGE["OpenRouter Gateway"] AUTH[["Auth Layer
API key / OAuth key / provisioning key"]] NORM[["Normalizer
แปลงเข้า schema กลาง"]] MROUTE{"Model Routing
โมเดลไหนตอบ"} PROUTE{"Provider Routing
ใครเสิร์ฟโมเดลนั้น"} XFORM[["Transformer
แปลงเป็นรูปแบบของ provider"]] METER[("Metering
token → cost → credits")] TELE[("Telemetry Store
latency / throughput / outage
หน้าต่างเลื่อน 5 นาที")] end subgraph UP["Upstream Providers"] P1["OpenAI"] P2["Anthropic"] P3["Google Vertex"] P4["DeepInfra / Together / Groq ฯลฯ"] end APP --> AUTH TOOL --> AUTH AUTH --> NORM NORM --> MROUTE MROUTE --> PROUTE PROUTE --> XFORM XFORM ==> P1 XFORM ==> P2 XFORM ==> P3 XFORM ==> P4 P1 -.-> METER P2 -.-> METER P3 -.-> METER P4 -.-> METER METER -.-> APP P1 -.-> TELE P4 -.-> TELE TELE -.-> PROUTE N1>"เส้นทึบ = ขาไป
เส้นประ = ขากลับและ feedback loop"] EDGE -.- N1 ``` จุดที่ควรสังเกตในภาพนี้คือ **feedback loop** จาก provider กลับเข้า telemetry store แล้ววนกลับเข้า router — นี่คือสิ่งที่ทำให้ระบบนี้ไม่ใช่แค่ reverse proxy ธรรมดา ยิ่งมีทราฟฟิกผ่านมากก็ยิ่งรู้ว่าใครช้าใครล่ม และตัดสินใจได้ดีขึ้น --- ## 3. แก่นของระบบ: การตัดสินใจสองชั้นที่แยกกัน ถ้าจับประเด็นเดียวจากบทความนี้ ให้จับข้อนี้ **routing ใน OpenRouter ไม่ใช่เรื่องเดียว แต่เป็นสองการตัดสินใจอิสระ** - **Model routing** — โมเดลไหนตอบ request นี้ - **Provider routing** — ใครเป็นคนเสิร์ฟโมเดลนั้น ทุกออปชันของ config จะแมปกับชั้นใดชั้นหนึ่งเสมอ และการแยกสองชั้นนี้ให้ออกคือสิ่งที่ทำให้คุณแก้ปัญหาถูกจุดตอนระบบพัง เหตุผลที่ต้องมีชั้นที่สองคือโมเดล open-weight ยอดนิยมตัวเดียวอาจมีคนเสิร์ฟยี่สิบกว่าราย ราคาต่างกันหลายเท่า ความเร็วต่างกัน คุณภาพ quantization ต่างกัน และล่มไม่พร้อมกัน ```mermaid flowchart TB REQ(["request เดียว"]) --> L1 subgraph L1G["ชั้นที่ 1 — Model Routing"] L1{"เลือกโมเดลอย่างไร"} M1["ระบุ model ตรง ๆ"] M2["ส่ง models array
เรียงตามลำดับความสำคัญ"] M3["openrouter/auto
จัดประเภท task แล้วจัดอันดับ
ตามยอดใช้จ่ายชุมชน 7 วันย้อนหลัง"] L1 --> M1 L1 --> M2 L1 --> M3 end subgraph L2G["ชั้นที่ 2 — Provider Routing"] L2["เลือก endpoint ที่เสิร์ฟโมเดลนั้น"] PA["Provider A"] PB["Provider B"] PC["Provider C"] L2 --> PA PA -.->|"5xx หรือ rate limit"| PB PB -.->|"ล้มอีก"| PC end M1 --> L2 M2 --> L2 M3 --> L2 PC -.->|"ทุก provider ของโมเดลนี้ล้มหมด"| NEXT["เลื่อนไปโมเดลถัดไปใน models array"] NEXT --> L2 OK(["ตอบสำเร็จ"]) PA --> OK PB --> OK PC --> OK N2>"failover ระดับ provider ทำงานอัตโนมัติ
ระดับโมเดลต้องส่ง models array เอง"] L2G -.- N2 ``` --- ## 4. Request lifecycle ทีละสเตป ```mermaid sequenceDiagram autonumber participant C as แอปของคุณ participant G as Gateway participant R as Router participant T as Telemetry Store participant A as Provider A ถูกสุด participant B as Provider B สำรอง C->>G: POST /api/v1/chat/completions พร้อม Bearer key G->>G: ตรวจ key, โควตา, guardrail G->>G: normalize payload เข้า schema กลาง G->>R: resolve model slug และถอด suffix เช่น :nitro R->>T: ขอสถานะ outage 30 วินาที และสถิติ p50-p99 T-->>R: รายการ endpoint พร้อมสถิติ R->>R: กรองด้วย provider object แล้วจัดลำดับ Note over R: ดีฟอลต์ถ่วงน้ำหนักด้วยกำลังสองผกผันของราคา
แต่ถ้า request มี tools จะเข้า Auto Exacto แทน R->>A: แปลงเป็นรูปแบบของ A แล้วยิง A--xR: 503 หรือ rate limit R->>B: fallback ไปตัวถัดไปอัตโนมัติ B-->>R: stream ตอบกลับ R->>G: normalize กลับเป็นรูป OpenAI-style G-->>C: SSE stream B-->>G: usage token ตอนจบ G->>G: คำนวณ cost แล้วหักจาก credits Note over G,C: request ที่ล้มไม่ถูกคิดเงิน
จ่ายเฉพาะรอบที่สำเร็จจริง ``` ขยายความบางสเตปที่มีรายละเอียดซ่อนอยู่ **สเตป auth** — คีย์มีสามชนิดที่ทำงานคนละหน้าที่ API key ปกติใช้เรียก inference, provisioning key ใช้เรียก endpoint จัดการคีย์ใต้ `/api/v1/keys` เท่านั้นและเรียก completion ไม่ได้ (ออกแบบมาให้ SaaS สร้างคีย์ต่อลูกค้าและหมุนคีย์อัตโนมัติ) และคีย์ที่ได้จาก OAuth PKCE ซึ่งเป็นของผู้ใช้ปลายทาง **สเตป resolve model** — suffix อย่าง `:nitro` `:floor` `:free` ไม่ใช่ชื่อโมเดลจริง มันเป็น routing policy ที่ถูกถอดออกและแปลงเป็น config ก่อนเข้าชั้นถัดไป **สเตป metering** — คำนวณ cost จาก token usage ที่ provider รายงานกลับมา ไม่ใช่จากการนับเองฝั่ง gateway ถ้าอยากได้ตัวเลขนี้ในแอป ให้ส่ง `usage: {include: true}` ไปใน request --- ## 5. อัลกอริทึมเลือก provider ส่วนนี้เอกสารเปิดเผยไว้ละเอียดผิดคาด และเป็นส่วนที่น่าศึกษาที่สุด ```mermaid flowchart TB START(["request เข้ามาพร้อมชื่อโมเดล"]) --> LIST["รวบรวม endpoint ทั้งหมด
ที่เสิร์ฟโมเดลนี้"] LIST --> F1{"มี only หรือ ignore ไหม"} F1 -->|"มี"| F1Y["ตัดตาม allowlist / denylist"] F1 -->|"ไม่มี"| F2 F1Y --> F2 F2{"มี zdr, data_collection
หรือ quantizations ไหม"} F2 -->|"มี"| F2Y["กรองตามนโยบายข้อมูล
และระดับ precision"] F2 -->|"ไม่มี"| F3 F2Y --> F3 F3{"มี max_price ไหม"} F3 -->|"มี"| F3Y["ตัดตัวที่แพงเกินเพดาน
ถ้าไม่เหลือเลย request ล้มทันที"] F3 -->|"ไม่มี"| F4 F3Y --> F4 F4{"request มี tools ไหม"} F4 -->|"มี"| EXACTO["Auto Exacto
จัด tier ตามคุณภาพ tool call
แล้วเรียงราคาภายในแต่ละ tier"] F4 -->|"ไม่มี"| F5 F5{"ตั้ง order หรือ sort ไหม"} F5 -->|"order"| ORD["ลองตามลำดับที่ระบุเป๊ะ ๆ"] F5 -->|"sort"| SRT["เรียงตาม price / throughput / latency
load balancing ถูกปิดทันที"] F5 -->|"ไม่ตั้งเลย"| DEF["ดีฟอลต์: price-based load balancing"] DEF --> D1["ขั้นที่ 1 ดันตัวที่มี outage
ใน 30 วินาทีล่าสุดไปท้ายแถว"] D1 --> D2["ขั้นที่ 2 สุ่มจากกลุ่มราคาต่ำสุด
ถ่วงน้ำหนักด้วยกำลังสองผกผันของราคา"] D2 --> D3["ขั้นที่ 3 ที่เหลือเรียงเป็น fallback"] ORD --> PICK SRT --> PICK EXACTO --> PICK D3 --> PICK PICK(["ได้ลำดับ endpoint สำหรับยิงจริง"]) THR>"preferred_min_throughput และ preferred_max_latency
ไม่ตัดใครออก แค่ดันตัวที่ตกเกณฑ์ไปท้ายแถว
ต่างจาก max_price ที่บล็อก request ได้"] PICK -.- THR ``` ### ทำไมต้องกำลังสองผกผัน ตัวอย่างจากเอกสาร สมมติโมเดลหนึ่งมีสามเจ้าเสิร์ฟ: A ราคา 1 ดอลลาร์ต่อล้าน token, B ราคา 2 และ C ราคา 3 โดย B เพิ่งมี outage - A ถูกเลือกเป็นอันดับแรกด้วยความน่าจะเป็นมากกว่า C ประมาณ **9 เท่า** เพราะ 1/3² ให้น้ำหนัก C แค่หนึ่งในเก้าของ A - ถ้า A ล้ม จะไป C - B ถูกลองสุดท้ายเพราะเพิ่งล่ม การยกกำลังสองดึงทราฟฟิกเข้าหาตัวถูกที่สุดแรงกว่าการถ่วงน้ำหนักเชิงเส้นมาก คือไม่ได้กระจายเท่า ๆ กัน แต่ก็ไม่ได้ยิงไปที่ตัวถูกสุดร้อยเปอร์เซ็นต์จนตัวอื่นตายไปหมด เป็นการประนีประนอมระหว่าง cost optimization กับการรักษา provider diversity ไว้ใช้ตอนฉุกเฉิน **สองกฎที่ต้องจำ: หน้าต่าง outage 30 วินาที และการถ่วงน้ำหนักด้วยกำลังสองผกผันของราคา** ### Auto Exacto — ข้อยกเว้นสำหรับ tool calling อันนี้เพิ่มมาทีหลังและสำคัญมากสำหรับคนทำ agent request ที่มี `tools` จะไม่ผ่าน price-weighting ปกติ แต่เข้า Auto Exacto ซึ่งเป็นขั้นตอน routing แบบเน้นคุณภาพ มันจัด tier ผู้ให้บริการตามสัญญาณคุณภาพของ tool call ดันตัวที่ทำได้แย่สุดไปท้ายแถว แล้วค่อยเรียงตามราคาภายในแต่ละ tier เหตุผลชัดเจน: provider ราคาถูกที่ทำ tool call พังบ่อยไม่ได้ช่วยประหยัดอะไร เพราะ agent ต้อง retry อยู่ดี ถ้าอยากได้ price-weighting กลับมาบน tool-calling request ต้องบังคับด้วย `:floor` หรือ `provider.sort: "price"` เอง --- ## 6. `provider` object — ตัวคุมชั้นล่างทั้งหมด | ฟิลด์ | ทำอะไร | ดีฟอลต์ | |---|---|---| | `order` | ลำดับ provider ที่จะลองตามลำดับเป๊ะ ๆ | unset | | `allow_fallbacks` | ปิดเมื่อต้องการ hard stop ไม่ให้หลุดไปเจ้าอื่น | `true` | | `sort` | `"price"` / `"throughput"` / `"latency"` | unset | | `only` | allowlist ของ provider | unset | | `ignore` | denylist ของ provider | unset | | `max_price` | เพดานราคาต่อ token ที่ยอมจ่าย | unset | | `preferred_min_throughput` | รับตัวเลขหรือ object แบบ percentile | unset | | `preferred_max_latency` | รับตัวเลขหรือ object แบบ percentile | unset | | `require_parameters` | ตัด provider ที่ไม่รองรับพารามิเตอร์ที่ส่งไป | `false` | | `data_collection` | `"allow"` หรือ `"deny"` | `"allow"` | | `zdr` | บังคับ Zero Data Retention endpoint เท่านั้น | unset | | `quantizations` | ล็อกระดับ precision เช่น `["fp8"]` | unset | | `enforce_distillable_text` | จำกัดเฉพาะโมเดลที่เจ้าของอนุญาตให้ distill | unset | ### สามกับดักที่คนพลาดบ่อย **หนึ่ง — `preferred_*` ไม่ใช่ hard constraint** `preferred_max_latency` และ `preferred_min_throughput` ไม่การันตีอะไรเลย มันแค่ทำให้ endpoint ที่ผ่านเกณฑ์ถูกจัดเข้ากลุ่ม preferred ส่วนตัวที่ตกเกณฑ์ถูกดันไปท้ายแถว **ไม่ได้ถูกตัดออก** ดังนั้นมันจะไม่มีวันทำให้ request ล้มเหลว ต่างจาก `max_price` โดยสิ้นเชิง — อันนั้นบล็อก request ได้จริงถ้าหาราคาที่ยอมรับได้ไม่เจอ percentile คำนวณจากหน้าต่างเลื่อน 5 นาที และระบุพร้อมกันหลายชั้นได้ ต้องผ่านทุกชั้นถึงจะเข้ากลุ่ม preferred: ```json { "provider": { "preferred_max_latency": { "p50": 1, "p90": 3, "p99": 5 }, "preferred_min_throughput": { "p50": 100, "p90": 50 } } } ``` **สอง — soft preference ที่ทำงานแม้ปิด `require_parameters`** แม้ `require_parameters` จะเป็น `false` ก็ยังมีพารามิเตอร์สามตัวที่ถูกใช้เป็น soft preference คือ `tools`, `response_format` และ `verbosity` ถ้า provider บางรายของโมเดลนั้นรองรับและบางรายไม่รองรับ request จะไปหาเฉพาะรายที่รองรับ แต่ถ้าไม่มีใครรองรับเลย request ก็ยังไปที่โมเดลนั้นและพารามิเตอร์ถูกเมินเฉย ๆ — พฤติกรรมนี้จะไม่มีวันตัดโมเดลออกจาก candidate list **สาม — base slug matching กว้างกว่าที่คิด** slug ฐานอย่าง `"google-vertex"` แมตช์ **ทุก** endpoint ของเจ้านั้น รวมทุก region และทุก variant ถ้าจะเจาะจงต้องใช้ slug เต็ม | slug ที่ส่งไป | แมตช์อะไร | |---|---| | `"google-vertex"` | ทุก endpoint ของ Vertex ทุก region | | `"google-vertex/us-east5"` | เฉพาะ region us-east5 | | `"deepinfra"` | ทั้ง default และ turbo | | `"deepinfra/turbo"` | เฉพาะ turbo endpoint | ข้อยกเว้น: service tier endpoint เช่น `openai/priority` ไม่ถูกแมตช์ด้วย base slug ต้อง opt-in ชัดเจนผ่าน `service_tier` --- ## 7. Model routing — ชั้นบน ### `models` array ส่งรายชื่อเรียงตามลำดับความสำคัญ ถ้าตัวแรก error ก็ลองตัวถัดไป ```python # Model-level fallback. Triggers on context-length errors, # moderation flags, rate limits, and downtime. resp = client.chat.send( model="anthropic/claude-sonnet-4.6", models=["openai/gpt-5.4-mini"], messages=[{"role": "user", "content": "..."}], ) ``` จุดสำคัญ: คิดเงินเฉพาะโมเดลที่รันจริง ไม่ใช่ตัวที่ error ไปก่อนหน้า ถ้าใช้ OpenAI SDK ต้องส่งผ่าน `extra_body` เพราะ `models` เป็น extension ของ OpenRouter ไม่ใช่ของ OpenAI ### `openrouter/auto` — Auto Router กลไกน่าสนใจตรงที่มันไม่ได้ใช้โมเดล classifier ที่ต้องเทรนและดูแล แต่ใช้ **ภูมิปัญญาของตลาด** ขั้นตอน: จัดประเภท prompt เป็น task type ก่อน แล้วจัดอันดับ candidate ตามยอดใช้จ่ายรวมของชุมชน OpenRouter ในหน้าต่าง 7 วันย้อนหลังสำหรับงานประเภทนั้น pool ของ candidate จึงขยับตามตลาดจริง ไม่ใช่รายชื่อตายตัวที่ต้องมาอัปเดตเอง ซึ่งแก้ปัญหาที่โมเดลใหม่ออกทุกเดือน คุมได้ด้วย: ```json { "model": "openrouter/auto", "plugins": [ { "id": "auto-router", "cost_tier": "max", "allowed_models": ["anthropic/*", "openai/*"] } ] } ``` `cost_tier` มีตั้งแต่ `low` (โมเดลถูกสุดที่ยังทำงานได้) ไล่ขึ้นไป `medium` `high` `xhigh` จนถึง `max` (เก่งสุดไม่สนราคา) และไม่มีค่าธรรมเนียมเพิ่มสำหรับ Auto Router — จ่ายเรตปกติของโมเดลที่ถูกเลือก หลังตอบเสร็จ ฟิลด์ `model` ใน response จะบอกว่าใครตอบจริง ### `sort.partition` — ออปชันที่คนไม่ค่อยรู้ ตอนใช้ `models` array ร่วมกับ `sort` ดีฟอลต์คือ `partition: "model"` ซึ่งจัดกลุ่ม endpoint ตามโมเดลก่อนเรียง ทำให้ endpoint ของโมเดลหลักถูกลองก่อนเสมอไม่ว่าจะช้าแค่ไหน ตั้งเป็น `"none"` แล้วมันจะเรียงข้ามขอบเขตโมเดลทั้งหมด ใช้ตอนที่สนความเร็วหรือราคามากกว่าว่าโมเดลไหนตอบ: ```json { "models": ["anthropic/claude-sonnet-4.5", "openai/gpt-5-mini", "google/gemini-3-flash-preview"], "provider": { "sort": { "by": "throughput", "partition": "none" } } } ``` --- ## 8. BYOK และกับดักที่ทำให้โดนชาร์จโดยไม่รู้ตัว BYOK คือเอาคีย์ provider ของตัวเองมาเสียบ inference ไปลงบิลบัญชีคุณเอง OpenRouter ทำแค่ routing และ observability ปัญหาคือ **เป้าหมายหลักของ router คือทำให้ request สำเร็จ** ไม่ใช่ทำให้คุณประหยัด ```mermaid sequenceDiagram autonumber participant C as แอปของคุณ participant R as OpenRouter Router participant K as คีย์ Anthropic ของคุณ participant V as provider อื่นผ่าน credits participant W as กระเป๋า credits C->>R: ขอ anthropic/claude-sonnet-4.5 R->>K: ลองใช้คีย์ BYOK ของคุณก่อน alt คีย์ทำงานปกติ K-->>R: ตอบสำเร็จ R-->>C: response Note over K: บิลไปลงบัญชี Anthropic ของคุณเอง
เกิน allowance จึงคิด 5% จาก credits else คีย์ล้ม เช่น rate limit หรือเครดิตหมด K--xR: error R->>V: fallback ไป provider อื่นที่เสิร์ฟโมเดลเดียวกัน V-->>R: ตอบสำเร็จ R->>W: หัก credits เต็มราคา R-->>C: response Note over C,W: นี่คือสาเหตุที่หลายคนงงว่า
ทำไมใช้คีย์ตัวเองแล้วยังโดนหักเงิน end ``` **วิธีป้องกัน** มีสองทาง ทางแรกตั้งค่าที่ dashboard — เปิด "Always use this key" ต่อคีย์ เพื่อไม่ให้ fallback ไปใช้ credits ผลข้างเคียงคือจะเจอ rate limit error ตรง ๆ ถ้าคีย์คุณหมดโควตา แต่รับประกันว่าทุก request ผ่านบัญชีคุณจริง ทางที่สองบังคับที่ request: ```json { "model": "anthropic/claude-sonnet-4.5", "provider": { "only": ["anthropic"], "allow_fallbacks": false } } ``` **วิธีตรวจว่าโดนแบบไหน** เปิดหน้า Activity แล้วดู request ที่มีค่าใช้จ่ายผิดปกติ ถ้า provider ที่แสดงไม่ใช่เจ้าของคีย์คุณ (เช่นคีย์เป็น Anthropic แต่ request ถูกเสิร์ฟโดย Google Vertex) นั่นคือ fallback ไม่ใช่ค่าธรรมเนียม ค่าธรรมเนียม BYOK เอง: มี free allowance ที่ขึ้นกับแพลน วัดจาก list-price inference cost ไม่ใช่จำนวน request ส่วนที่เกินคิด 5% ของราคาที่โมเดลและ provider เดียวกันจะคิดบน OpenRouter หักจาก credits แยกจากที่คีย์คุณโดนคิด --- ## 9. ชั้นเศรษฐกิจ โครงสร้างราคาแยกเป็นสองชั้นที่คนมักปนกัน **ชั้นที่หนึ่ง — ราคา token** ผ่านตรงจาก provider ไม่มีการบวกเพิ่ม ราคาบนหน้า model ตรงกับราคาที่ provider ประกาศเอง **ชั้นที่สอง — ค่าธรรมเนียมแพลตฟอร์ม** เก็บตอนซื้อ credits ไม่ใช่ตอนใช้ ตัวเลขที่รายงานกันคือ 5.5% สำหรับบัตร มีขั้นต่ำ 0.80 ดอลลาร์ และ 5.0% สำหรับคริปโต ผลกระทบที่หลายคนไม่ทันคิด: **ขั้นต่ำ 0.80 ดอลลาร์ทำให้การเติมทีละน้อยมี effective rate สูงมาก** เติม 5 ดอลลาร์คือจ่ายค่าธรรมเนียม 16% ส่วนเติม 100 ดอลลาร์คือ 5.5% ตามป้าย เติมก้อนใหญ่คุ้มกว่าชัดเจน ### zero-completion insurance request ที่ล้มไม่ถูกคิดเงิน จ่ายเฉพาะรอบที่สำเร็จ นี่คือสิ่งที่ทำให้ leaning on failover ปลอดภัยทางเศรษฐกิจ แต่มีข้อยกเว้นที่ควรรู้: **การ abort stream ไม่หยุดการคิดเงินกับ provider บางเจ้า** เช่น Bedrock, Groq, Google และ Mistral ดังนั้น stream ที่ผู้ใช้กดยกเลิกกลางคันยังอาจมีค่าใช้จ่าย ถ้าแอปคุณมีปุ่ม stop ต้องเผื่อตรงนี้ไว้ในการประมาณต้นทุน --- ## 10. OAuth PKCE — กลไกที่ทำให้ third-party app เกิดได้ นี่คือส่วนที่ทำให้ Cline, Continue, OpenCode และ CLI ต่าง ๆ ต่อ OpenRouter ได้โดยนักพัฒนาไม่ต้องออกค่า token ให้ผู้ใช้ ```mermaid sequenceDiagram autonumber actor U as ผู้ใช้ participant A as แอปหรือ CLI ของคุณ participant O as openrouter.ai participant API as OpenRouter API A->>A: สร้าง code_verifier แบบสุ่ม A->>A: code_challenge = base64url ของ sha256 code_verifier A->>U: เปิดเบราว์เซอร์ไป /auth พร้อม callback_url และ code_challenge U->>O: ล็อกอินและกดอนุมัติแอป O-->>A: redirect กลับ callback_url พร้อม code A->>API: POST /api/v1/auth/keys ด้วย code และ code_verifier API-->>A: คืน API key ที่ผู้ใช้เป็นเจ้าของ A->>A: เก็บคีย์ไว้ฝั่งผู้ใช้ A->>API: เรียก chat/completions ด้วยคีย์นั้น Note over U,API: ผู้ใช้จ่ายค่า token เอง นักพัฒนาไม่ต้องออกให้
และตั้งเพดานเครดิตต่อคีย์ได้ ``` URL ที่ต้อง redirect ไป: ``` https://openrouter.ai/auth?callback_url=&code_challenge=&code_challenge_method=S256 ``` `code_challenge` เป็น optional แต่ควรใส่ และควรใช้ `S256` ไม่ใช่ `plain` รายละเอียดที่ทำให้ CLI tool ใช้ได้: endpoint สร้าง auth code รองรับทั้ง https URL และ `localhost` / `127.0.0.1` ทุกพอร์ต — CLI จึงเปิด local server ชั่วคราวรอ callback ได้ และตั้ง credit limit พร้อม reset interval ให้คีย์ที่ออกได้ด้วย สำหรับ headless host เครื่องมือส่วนใหญ่จะพิมพ์ URL ออกมาแล้วให้ผู้ใช้ paste redirect URL กลับเข้าไปแทน --- ## 11. จุดอ่อนที่ต้องรู้ก่อนพึ่งพา **หนึ่ง — failover กันได้แค่ระดับ provider ไม่ได้กัน OpenRouter เอง** เหตุการณ์ outage เดือนสิงหาคม 2025 ซึ่งเป็นปัญหาฐานข้อมูลราว 50 นาที ทำให้ทั้งบริการล่ม รวมทั้ง fallback ด้วย provider failover เป็นชั้นความทนทาน ไม่ใช่การรับประกัน SLA ถ้าระบบคุณรับ downtime ไม่ได้ ต้องมี escape hatch เรียก provider ตรงไว้ในโค้ด **สอง — hop เพิ่มขึ้นหนึ่งชั้น** แอป → OpenRouter → provider → กลับ สำหรับงานทั่วไปนี่คือ single-digit ถึง low double-digit millisecond ซึ่งเทียบไม่ได้กับเวลา inference แต่สำหรับ real-time voice หรือ agent loop ที่วนเร็ว ๆ ควร benchmark กับ SLA ของตัวเองแทนที่จะสมมติว่าไม่สำคัญ **สาม — auto-routing แลก reproducibility** การเห็นว่าโมเดลไหนถูกใช้ไม่เท่ากับการทำซ้ำได้ ถ้างานต้องการ replayability หรือความสม่ำเสมอของ output ระยะยาว ต้อง log model ID ทุกครั้ง, pin routing window หรือล็อก flow สำคัญไว้กับโมเดลตายตัว นี่ไม่ใช่ abstraction ที่ฟรี มันเป็นการตัดสินใจเชิงสถาปัตยกรรม **สี่ — คุณภาพ provider ไม่เท่ากันและวัดไม่ได้** บางเจ้าเสิร์ฟ variant ที่ quantize หนักกว่าและทำงานได้แย่กว่าโมเดลเดียวกันที่โฮสต์ที่อื่น ไม่มี quality score ให้ sort หรือ filter มีแค่การ exclude provider ออกไปตรง ๆ หรือใช้ `quantizations` จำกัดระดับ precision ที่ไว้ใจ **ห้า — ไม่มี queue เมื่อชน rate limit** เกินลิมิตแล้วได้ 429 ทันที ไม่มีการเข้าคิว ไม่มี auto-upgrade ไม่มี backoff ในตัว แอปต้องจัดการ retry และ pacing เอง --- ## 12. บทเรียนสำหรับคนที่จะสร้าง gateway ของตัวเอง ถ้าคุณกำลังทำ internal API gateway อยู่ ต่อไปนี้คือสิ่งที่ควรลอกและสิ่งที่ไม่ควร ### ควรลอก **แยกการตัดสินใจเป็นชั้น ๆ ที่ระบุชื่อได้** — "โมเดลไหน" กับ "ใครเสิร์ฟ" เป็นคนละเรื่อง การไม่แยกทำให้ config พันกันและ debug ไม่ออก หลักการเดียวกันใช้ได้กับ gateway ทุกประเภท เช่น "backend ไหน" กับ "instance ไหนของ backend นั้น" **ให้ policy อยู่ใน request ไม่ใช่ใน config ของ gateway** — `provider` object เป็น per-request policy ทำให้ caller คุมพฤติกรรมได้เองโดยไม่ต้อง deploy gateway ใหม่ นี่เป็นข้อได้เปรียบใหญ่เทียบกับ gateway ที่ policy ฝังอยู่ใน YAML **แยก hard constraint ออกจาก soft preference ให้ชัด** — `max_price` บล็อกได้ ส่วน `preferred_max_latency` แค่จัดลำดับ การทำให้ผู้ใช้เข้าใจความต่างนี้ตั้งแต่ชื่อฟิลด์ (`max_` กับ `preferred_`) เป็นการออกแบบ API ที่ดี **เก็บ telemetry แล้วป้อนกลับเข้า router** — outage window 30 วินาที และ percentile 5 นาทีเป็นตัวเลขที่ทำได้จริงและไม่ซับซ้อน ไม่ต้องรอทำ ML **คิดเงินจากสิ่งที่ upstream รายงาน ไม่ใช่จากการนับเอง** — ลด dispute และไม่ต้อง implement tokenizer ของทุกเจ้า ### ไม่ต้องลอก **inverse-square price weighting** — ตรรกะนี้เกิดจากการเป็น marketplace ที่มี supplier แข่งกันหลายสิบเจ้า gateway ภายในองค์กรมักมี backend สองสามตัวและราคาไม่ใช่ตัวแปร round-robin หรือ least-connections พอแล้ว **Auto Router แบบใช้ยอดใช้จ่ายชุมชน** — ต้องมี network effect ระดับล้านผู้ใช้ถึงจะมีข้อมูลพอ ภายในองค์กรใช้ rule-based ตรงไปตรงมากว่าและอธิบายได้ **BYOK + free allowance + ค่าธรรมเนียมซื้อ credits** — เป็นโครงสร้างธุรกิจ ไม่ใช่โครงสร้างเทคนิค **ความซับซ้อนของ slug matching** — เกิดจากการต้องรองรับ region และ variant ของ supplier หลายสิบเจ้า ภายในองค์กรตั้งชื่อให้ชัดตั้งแต่แรกดีกว่า --- ## 13. สรุป OpenRouter น่าศึกษาไม่ใช่เพราะมันซับซ้อน แต่เพราะมัน **แก้ปัญหาที่ gateway ทุกตัวเจอด้วยวิธีที่เรียบง่ายและเปิดเผยกลไกไว้ชัด** - routing สองชั้นที่แยกกันชัดเจน ทำให้แก้ปัญหาถูกจุด - อัลกอริทึมเลือก provider ที่ใช้แค่สองตัวแปร (สถานะ outage 30 วินาที และราคาถ่วงกำลังสองผกผัน) แต่ทำงานที่สเกลล้านล้าน token ต่อวันได้ - policy อยู่ใน request ทำให้ caller คุมได้โดยไม่ต้องแก้ gateway - failover ที่ปลอดภัยทางเศรษฐกิจเพราะไม่คิดเงิน request ที่ล้ม สิ่งที่ต้องเผื่อใจคือมันเพิ่ม dependency หนึ่งชั้นที่ล่มได้ และ auto-routing แลกความสามารถในการทำซ้ำ ทั้งสองอย่างเป็น trade-off ที่ต้องตัดสินใจอย่างรู้ตัว ไม่ใช่ยอมรับโดยปริยาย **สถานะล่าสุด:** Stripe ประกาศเมื่อ 19 สิงหาคม 2026 ว่าตกลงเข้าซื้อ OpenRouter ฝั่ง OpenRouter แถลงว่าจะดำเนินการต่อเหมือนเดิม ชื่อเดิม โปรดักต์เดิม โรดแมปเดิม ยังเร็วเกินจะประเมินว่าจะกระทบโครงสร้างราคาหรือ API อย่างไร ควรติดตามต่อถ้าจะวางระบบ production บนแพลตฟอร์มนี้ --- ## อ้างอิง - Provider Routing — - How OpenRouter Model Routing Works — - OAuth PKCE — - BYOK — - Provisioning API Keys — - FAQ — - OpenRouter is Joining Stripe — *ข้อมูลตรวจสอบ ณ สิงหาคม 2026 — ค่าธรรมเนียมและรายละเอียด routing เปลี่ยนบ่อย ควรเช็คเอกสารต้นทางก่อนนำไปใช้ตัดสินใจ*

SECURE_ACCESS

DOWNLOAD_LOCKED

แกะ OpenRouter flow

CONFIRM_DELETE