สิ่งที่มีประโยชน์ที่สุดในการเข้าใจ credits ของ Rivya ไม่ใช่ตัวเลขบน balance
แต่คือหน้าที่ของ wallet เมื่อ project เริ่มเคลื่อนข้าม chat, image, video, audio และ live tools ถ้าคุณต้องการ reference กฎที่เข้มที่สุด Credits & Billing in Rivya ยังเป็นเจ้าของกฎ หน้านี้คือ buying decision guide
pricing guide นี้อิงจากอะไร
คู่มือนี้รีวิวเมื่อวันที่ 28 เมษายน 2026 เทียบกับ public pricing configuration และ billing docs ปัจจุบันของ Rivya
มันสะท้อนว่า:
- signup credits: 6 credits พร้อมวันหมดอายุ 30 วัน
- plan credits: Basic 300, Advanced 800, Pro 1800 และ Premium 3600 credits ต่อเดือน
- pack credits: credits แบบ one-time 500, 1500, 3500 หรือ 7000 พร้อมวันหมดอายุ 365 วัน
- กฎที่ว่า /pricing และ Stripe Checkout คือ final source สำหรับราคาจริง ส่วนลด ภาษี และ payment availability
เริ่มจากดูว่า wallet มีไว้ทำอะไรจริง ๆ
Rivya ใช้ shared wallet หนึ่งใบทั่วทั้งผลิตภัณฑ์
เรื่องนี้สำคัญเพราะ project สามารถเปลี่ยน format ได้โดยไม่ต้องสร้าง spending logic ใหม่ทุกครั้ง
คำถามที่มีประโยชน์กว่ามักไม่ใช่:
ฉันใช้เงินไปเท่าไร?
แต่คือ:
ฉันยังมี room พอให้ workflow นี้เดินต่อโดยไม่สะดุดหรือไม่?
นั่นคือเหตุผลที่ wallet ใน Rivya รู้สึกเป็น operational มันไม่ใช่แค่ balance display แต่เป็นสะพานที่ทำให้งานข้าม format ไม่หยุดชะงัก
การแบ่งซื้อที่สะอาดที่สุด
| สถานการณ์ | ตัวเลือกที่มักเหมาะกว่า | เหตุผล |
|---|---|---|
| คุณยังเรียนรู้ผลิตภัณฑ์อยู่ | signup credits ก่อน | คุณต้องการ signal ไม่ใช่ commitment |
| งานมาเป็น burst | pack | คุณต้องการ overflow ไม่ใช่ monthly rhythm |
| งานเริ่ม recurring | plan | คุณต้องการ capacity ที่เสถียร |
| คุณมี plan อยู่แล้วแต่เจอ temporary spikes | pack เพิ่มด้านบน | คุณต้องการ extra room โดยไม่เปลี่ยน baseline |
plans และ packs ไม่ใช่สิ่งทดแทนกันแบบ universal ทั้งคู่แก้ปัญหา timing คนละแบบ
มอง signup credits เป็น learning budget
signup credits มีค่าที่สุดเมื่อใช้ตอบคำถามเชิงปฏิบัติหนึ่งข้อ:
- ผลิตภัณฑ์นี้เข้ากับวิธีทำงานจริงของฉันหรือไม่?
โดยทั่วไปหมายถึง:
- chat หรือ tool session จริงหนึ่งรอบ
- image, audio หรือ video run หนึ่งรอบที่คุณสนใจผลลัพธ์จริง
- comparison หนึ่งรอบที่บอกได้ว่า workflow นี้คุ้มทำต่อหรือไม่
มักเป็นความผิดพลาดถ้ากระจาย credits แรกไปกับ random tests เพียงเพราะมี balance อยู่ ถ้าต้องการคู่มือที่เข้ากันที่สุดสำหรับ learning loop แรก ให้อ่านหน้านี้คู่กับ How to Run Your First Real Task in Rivya
เมื่อ pack มักเป็นตัวเลือกที่ดีกว่า
pack มักเป็นคำตอบที่สะอาดกว่าเมื่องานฟังดูแบบนี้:
- คุณยังทดสอบว่า Rivya ควรอยู่ใน workflow ปกติของคุณหรือไม่
- งานมาเป็น project bursts แทนการใช้งานรายเดือนที่สม่ำเสมอ
- คุณมี plan อยู่แล้ว แต่ campaign หรือ revision week หนึ่งหนักกว่าปกติ
- คุณต้องการ extra room โดยไม่ต้องแบก recurring commitment ที่ใหญ่ขึ้นทั้งปี
packs มักเป็นเรื่องของ timing ไม่ใช่การตัดสินใจเดียวกับการเลือก baseline สำหรับการใช้งานต่อเนื่อง
เมื่อ plan มักเป็นตัวเลือกที่ดีกว่า
plan มักเป็นคำตอบที่ดีกว่าเมื่องานฟังดูแบบนี้:
- คุณอยู่ใน Rivya ทุกสัปดาห์หรือทุกเดือน
- project เคลื่อนข้ามมากกว่าหนึ่ง surface เป็นประจำ
- คุณไม่อยากให้ทุกช่วงยุ่งกลายเป็นการตัดสินใจ top-up อีกครั้ง
- wallet ตอนนี้รองรับ operating rhythm ไม่ใช่ spike แบบ one-off
นั่นคือจุดที่ plan หยุดรู้สึกเหมือน "credits มากขึ้น" และเริ่มรู้สึกเหมือน working baseline ที่สะอาดกว่า
low balance ขัดจังหวะอะไรจริง ๆ
low balance ไม่ใช่แค่ปัญหา billing แต่เป็นปัญหา workflow interruption
เมื่อ wallet ต่ำเกินไป:
- billable generation อาจไม่เริ่มต้นที่ upstream เลย
- task ยัง fail แบบมองเห็นได้
- notifications อาจบันทึก interruption
- project อาจหยุดตรงช่วงที่คุณพร้อมจะทำต่อพอดี
นั่นคือเหตุผลที่ low balance ใน Rivya รู้สึก disruptive กว่าผลิตภัณฑ์ที่แต่ละ workflow อยู่แยกกัน
จุดที่ credits ถูกอ่านผิดง่าย
credits ไม่ได้รับประกันว่าทุกผลลัพธ์จะ publishable และ run ที่แพงกว่าไม่ได้เป็น first move ที่ดีกว่าโดยอัตโนมัติ
ควรระวังเมื่อ:
- คุณเปรียบเทียบโมเดลก่อนกำหนด task
- คุณเลือก video หรือ audio run ที่หนักเพียงเพื่อสำรวจไอเดียที่ยังไม่ชัด
- คุณคิดว่า failed task มีความหมายเดียวกับผลลัพธ์ที่ completed แต่ใช้ไม่ได้
- คุณซื้อ recurring access ก่อนรู้ว่างาน recurring จริงหรือไม่
ถ้า buying decision ยังไม่ชัด ให้เริ่มจาก run ที่เล็กที่สุดซึ่งตอบคำถามจริงได้
buying pattern ของ Rivya ที่ไว้ใจได้
ถ้าต้องการกฎสั้น ๆ ที่พึ่งได้ ใช้แบบนี้:
- ใช้ signup credits เพื่อเรียนรู้
- ซื้อ pack ถ้างานมีแววแต่ยังไม่สม่ำเสมอ
- ย้ายไป plan เมื่อ pattern กลายเป็น recurring
- เก็บ packs ไว้สำหรับ spikes แม้หลัง plan กลายเป็นปกติแล้ว
- สลับไป Pricing FAQ หรือ Payment Checkout in Rivya เมื่อคำถามจริงกลายเป็น refunds, cancellation หรือ checkout state
pattern นี้มักมีประโยชน์กว่าการจ้อง plan tables ก่อนเข้าใจ rhythm ของตัวเอง
ไปต่อที่ไหน
- ถ้าต้องการ comparison สาธารณะกว้าง ๆ ไปที่ Pricing
- ถ้าต้องการ buying page แบบตอบสั้น อ่าน Pricing FAQ
- ถ้าต้องการ wallet rules ที่เข้มกว่า expiry logic และ failed-run behavior อ่าน Credits & Billing in Rivya
- ถ้าต้องการหน้า plan-vs-pack decision อ่าน Plans and Packs in Rivya
- ถ้าต้องการคำอธิบาย return-and-refresh หลัง checkout อ่าน Payment Checkout in Rivya
ตรวจ cost ก่อนรัน
ก่อนใช้ credits ให้เชื่อม run เข้ากับ buying decision:
- Model or workflow: run ไหนจะใช้จ่ายจาก wallet จริง
- Work pattern: learning pass, one-time burst, recurring work, retry หรือ production attempt
- Cost signal: หน้าโมเดลหรือ pricing page บอกอะไรเกี่ยวกับ expected credit use
- Cheaper test: run ที่เบากว่าสามารถตอบคำถามเดียวกันก่อน run ที่หนักกว่าหรือไม่
- Buying implication: ผลลัพธ์ชี้ไปทาง signup credits, pack, plan หรือยังไม่ซื้อ
เป้าหมายไม่ใช่การใช้ credits ให้น้อยที่สุดทุกครั้ง แต่คือให้ spending ตรงกับ rhythm จริงของงาน
รีวิว spend ก่อน iterate
มอง run ที่เสร็จแล้วแต่ละรอบเป็น cost signal ไม่ใช่ proof ว่าควรใช้ spend เดิมต่อ ตรวจว่าโมเดลหนักเกิน task หรือไม่ prompt กว้างเกินไปหรือไม่ และ run ถัดไปจำเป็นต้องใช้ setting ที่สูงกว่าจริงหรือไม่
ถ้าผลลัพธ์มีทิศทางที่ใช้ได้ ให้ต่อจากส่วนที่แข็งแรงที่สุดแทนการ restart แบบไม่ดูทาง ถ้ามัน fail ต่อ core task ให้แก้ brief หรือ model choice ก่อนใช้ credits เพิ่มหรือเปลี่ยน buying baseline
