Fallback routing untuk LLM APIs bersifat sederhana ketika setiap permintaan mengembalikan teks. Jika rute utama mengalami timeout, Anda mencoba ulang sekali, beralih ke model cadangan, memvalidasi skema, dan mencatat alasannya.
Logika itu runtuh ketika produk yang sama juga merutekan pembuatan gambar, transkripsi audio, keluaran suara, dan pembuatan video. Cadangan yang aman untuk ekstraksi JSON tidak otomatis aman untuk citra merek. Fallback speech-to-text tidak sama dengan fallback text-to-speech. Fallback video dapat menciptakan pengeluaran ganda, kebingungan antrean, atau keluaran yang masih memerlukan persetujuan manusia.
Panduan ini mengubah Fallback Routing untuk LLM APIs: Multimodal Agent Routing untuk Teks, Gambar, Audio, dan Video menjadi playbook implementasi untuk tim produk AI. Tujuannya bukan memilih satu model universal. Tujuannya adalah membuat pemilihan rute, verifikasi, fallback, dan tinjauan biaya menjadi eksplisit untuk setiap modality yang disentuh agen Anda.
Pada 12 September 2026, halaman publik live Flatkey merangkum produk di sekitar satu key, satu balance, satu invoice, 100+ model AI resmi, 1.000+ tools, setup yang kompatibel dengan OpenAI, usage logs, dan automatic failover. Surfaces model dan harga publik Flatkey juga menampilkan rute model berorientasi teks, gambar, audio, dan video. Perlakukan halaman live tersebut sebagai checkpoint komersial saat ini sebelum rollout karena ketersediaan model, harga, dan kesehatan rute dapat berubah.
Jawaban singkat: apa yang berubah dalam perutean fallback multimodal?
Dalam sistem yang hanya teks, fallback biasanya menanyakan satu pertanyaan: "Apakah rute lain dapat menghasilkan jawaban yang setara?"
Dalam sistem multimodal, fallback routing untuk LLM APIs harus menanyakan empat pertanyaan:
- Artefak apa yang sedang dihasilkan? Teks, gambar, audio, dan video tidak berbagi satu standar kualitas.
- Bagaimana artefak diverifikasi? Parser JSON, reviewer visual, pemeriksa transkrip, dan antrean persetujuan video adalah sistem verifikasi yang berbeda.
- Kegagalan apa yang benar-benar dapat dipulihkan? Rate limit, timeout, input tidak valid, penolakan safety, dan output berkualitas buruk memerlukan tindakan yang berbeda.
- Apakah cadangan dapat mempertahankan kontrak? Rute fallback aman hanya ketika mempertahankan modality, bentuk output, batas latensi, plafon biaya, dan jalur review.
Aturan praktisnya sederhana: fallback tetap berada dalam kelas workflow kecuali lapisan manusia atau kebijakan secara eksplisit menyetujui perpindahan tersebut.
Mengapa percobaan ulang generik gagal untuk teks, gambar, audio, dan video
Retry generik memperlakukan setiap permintaan yang gagal sebagai masalah transport. Itu terlalu dangkal untuk multimodal agent routing.
| Modality | Bentuk kegagalan umum | Mengapa retry generik berisiko |
|---|---|---|
| Teks | Timeout, rate limit, kegagalan parser, ketidakcocokan tool-call, jawaban lemah | Retry mungkin aman, tetapi berpindah model dapat merusak skema, sitasi, tools, atau nada. |
| Gambar | Blokir keamanan, rasio aspek salah, ketidakcocokan merek, fidelitas rendah, kepatuhan edit buruk | Model gambar lain mungkin mengembalikan file valid yang tetap gagal dalam peninjauan kreatif. |
| Audio | Format tidak didukung, transkrip buruk, bahasa salah, ketidakcocokan suara, lonjakan latensi | Transkripsi, terjemahan, dan keluaran suara adalah pekerjaan terpisah dengan aturan fallback terpisah. |
| Video | Antrean panjang, task gagal, aset kedaluwarsa, gerakan tidak konsisten, output mahal yang ditolak | Mengirim ulang secara membabi buta dapat membuat job duplikat, biaya duplikat, dan lebih banyak aset untuk ditinjau. |
Router perlu mengetahui apakah kegagalan merupakan peristiwa layanan yang bisa di-retry, permintaan yang tidak valid, hasil keamanan atau kebijakan, atau kegagalan kualitas. Kategori-kategori tersebut mengarah ke tindakan yang berbeda.
Mulai dengan kelas rute, bukan nama model
Fallback routing yang paling aman untuk LLM APIs dimulai dengan kelas rute. Model dapat berpindah masuk dan keluar dari suatu kelas seiring berubahnya ketersediaan dan kualitas; kebijakan workflow seharusnya tetap stabil.
| Kelas rute | Tugas utama | Kelas verifikasi | Perilaku fallback default |
|---|---|---|---|
| Penalaran teks | Ekstraksi, klasifikasi, ringkasan, coding, output terstruktur, tool calls | Pemeriksaan skema, pengujian parser, sampling rubrik, keberhasilan tool | Auto-fallback dapat diizinkan ketika backup mempertahankan bentuk respons dan perilaku tool. |
| Pemahaman visi | Analisis gambar, review dokumen, interpretasi screenshot | Pemeriksaan output teks plus cakupan input visual | Fallback ke rute penalaran lain yang mampu memproses visi, bukan ke rute pembuatan gambar. |
| Generasi atau pengeditan gambar | Gambar baru, edit, variasi produk, draf kreatif | QA visual, pemeriksaan merek, review template prompt | Fallback hanya ke rute gambar yang disetujui dengan rasio aspek, gaya, dan aturan review yang cocok. |
| Input audio | Transkripsi, terjemahan, ringkasan rapat, QA panggilan | Pemeriksaan akurasi transkrip, pemeriksaan bahasa, review cap waktu | Fallback ke rute transkripsi atau pemahaman audio lain dengan batas input yang sama. |
| Output audio | Sintesis suara, respons voice agent, narasi | QA pemutaran, kebijakan suara, anggaran latensi | Fallback ke rute suara yang disetujui; pisahkan dari fallback transkripsi. |
| Generasi video | Text-to-video, image-to-video, klip pratinjau, aset kreatif | Persetujuan manusia, pemeriksaan durasi/fidelitas, pemantauan antrean | Batasi fallback secara sempit; sering kali lebih baik gagal ke tinjauan manual daripada otomatis membuat job lain. |
Peta kelas rute ini mencegah kesalahan umum: memperlakukan "model multimodal" sebagai satu kelompok kemampuan. Model yang menerima gambar untuk analisis tidak selalu dapat menghasilkan gambar. Model yang memahami audio tidak otomatis menjadi model suara produksi. Model yang dapat menghasilkan video dalam demo tidak otomatis aman untuk otomatisasi yang berhadapan dengan pelanggan.
Gunakan matriks keputusan fallback sebelum Anda menulis kode
Matriks keputusan memberi produk, engineering, dan operasional satu kebijakan bersama. Mulailah dengan matriks di bawah ini dan gantilah contoh-contohnya dengan model, penyedia, dan aturan persetujuan Anda sendiri.
| Kondisi | Tindakan teks | Tindakan gambar | Tindakan audio | Tindakan video |
|---|---|---|---|---|
| Timeout rute utama sebelum output mulai | Coba lagi dalam batas anggaran, lalu fallback ke rute teks yang disetujui | Coba sekali lagi jika tidak ada aset yang dibuat, lalu fallback ke rute gambar yang disetujui | Coba lagi atau fallback dalam jenis pekerjaan audio yang sama | Periksa status tugas terlebih dahulu; jangan buat tugas duplikat sampai status asli diketahui. |
| Rate limit atau error kapasitas | Fallback ketika cadangan memenuhi batas skema dan biaya | Fallback ketika cadangan memenuhi batas prompt, ukuran, dan peninjauan | Fallback ketika cadangan mendukung format file dan bahasa yang sama | Fallback hanya jika biaya duplikat dan perilaku antrean dapat diterima. |
| Permintaan tidak valid atau input tidak didukung | Hentikan dan perbaiki permintaan | Hentikan dan perbaiki prompt, jenis input, ukuran, atau aspek | Hentikan dan perbaiki format media, durasi, bahasa, atau sample rate | Hentikan dan perbaiki durasi, media referensi, prompt, atau field endpoint. |
| Penolakan keamanan atau kebijakan | Jangan sembunyikan penolakan dengan fallback | Jangan melewati kebijakan dengan model lain | Jangan melewati kebijakan dengan penyedia audio lain | Jangan melewati kebijakan dengan penyedia video lain. |
| Output gagal verifikasi otomatis | Fallback jika kontraknya dapat diperiksa oleh mesin | Kirim ke peninjauan visual atau regenerasi di bawah kebijakan rute yang disetujui | Kirim ke peninjauan transkrip/pemutaran atau fallback di dalam jenis tugas yang sama | Kirim ke peninjauan manusia; gunakan aturan regenerasi, bukan failover buta. |
| Output streaming parsial sudah mencapai pengguna | Biasanya berhenti dan rekonsiliasi; hindari pergantian model yang transparan | Tidak berlaku untuk sebagian besar rute gambar | Berhenti dan rekonsiliasi status yang terlihat oleh pengguna | Jangan beralih secara tak terlihat setelah status tugas yang terlihat sudah ada. |
| Panggilan alat mungkin telah menciptakan efek samping | Rekonsiliasi idempotensi sebelum coba lagi atau fallback | Rekonsiliasi setiap penulisan aset/penyimpanan | Rekonsiliasi status transkrip, panggilan, atau sesi suara | Rekonsiliasi ID tugas, penyimpanan, penagihan, dan status persetujuan terlebih dahulu. |
Matriks ini adalah aset nilai utama artikel. Ini mengubah fallback routing untuk LLM APIs dari pemikiran belakangan rekayasa menjadi kebijakan yang dapat ditinjau sebelum traffic produksi berpindah.
Arsitektur referensi untuk routing agen multimodal
Router produksi tidak perlu rumit, tetapi memang perlu batas yang jelas.
flowchart LR
A[Permintaan agen] --> B[Klasifikasikan alur kerja]
B --> C[Pilih rute utama]
C --> D[Panggil penyedia atau gateway]
D --> E[Verifikasi artefak]
E -->|lulus| F[Kembalikan dan catat]
E -->|kegagalan yang dapat dicoba ulang| G[Kebijakan fallback]
E -->|kebijakan atau input tidak valid| H[Berhenti dengan error yang dapat ditindaklanjuti]
G --> I[Rute cadangan yang disetujui]
I --> D
G --> J[Tinjauan manusia atau antrean manual]
Bagian-bagian utamanya adalah:
- Klasifikator alur kerja: memberi label pada tugas sebagai teks, visi, pembuatan gambar, input audio, output audio, atau pembuatan video sebelum pemilihan rute.
- Registri kapabilitas: mencatat rute mana yang mendukung setiap modalitas, endpoint, format input, bentuk output, konteks maksimum, perilaku streaming, dan kelas biaya.
- Kebijakan fallback: mendefinisikan error yang dapat dicoba ulang, cadangan yang diizinkan, aturan anti-bypass, dan jumlah percobaan maksimum.
- Lapisan verifikasi: memeriksa artefak sebelum mengembalikannya ke pengguna atau meneruskannya ke tahap berikutnya.
- Buku besar dan observabilitas: mencatat model, rute, pemilik, status, alasan fallback, latensi, penggunaan, biaya, dan hasil peninjau.
Flatkey dapat ditempatkan di lapisan penyedia-atau-gateway ketika sebuah tim menginginkan satu router yang kompatibel dengan OpenAI, satu saldo bersama, dan satu tempat untuk meninjau rute model yang didukung. Aplikasi Anda tetap memiliki kebijakannya: kelas modalitas mana yang boleh melakukan fallback, kapan harus berhenti, dan kapan manusia harus memutuskan.
Definisikan kebijakan sebagai data
Jangan letakkan kebijakan routing di dalam pernyataan if yang tersebar. Objek data kecil lebih mudah ditinjau dan lebih aman diubah.
{
"workflow": "support_ticket_with_screenshot",
"route_class": "vision_understanding",
"primary_model": "primary-vision-reasoning-route",
"fallback_models": ["backup-vision-reasoning-route"],
"fallback_on": ["timeout_before_output", "rate_limit", "upstream_5xx"],
"do_not_fallback_on": ["safety_rejection", "invalid_input", "partial_stream_sent"],
"verification": {
"type": "structured_text",
"required_fields": ["summary", "severity", "evidence"]
},
"max_attempts": 2,
"max_incremental_cost_usd": 0.05,
"log_fields": [
"request_id",
"workspace_id",
"route_class",
"model",
"fallback_reason",
"latency_ms",
"cost_usd",
"verification_status"
]
}
Struktur yang sama dapat mewakili alur kerja media:
{
"workflow": "product_video_preview",
"route_class": "video_generation",
"primary_model": "primary-video-route",
"fallback_models": ["approved-video-preview-route"],
"fallback_on": ["provider_5xx", "capacity_unavailable"],
"do_not_fallback_on": ["client_timeout_without_task_state", "safety_rejection", "asset_created"],
"verification": {
"type": "human_review",
"checks": ["duration", "motion", "brand_safety", "reference_consistency"]
},
"max_attempts": 1,
"manual_queue_after_failure": true
}
Perhatikan perbedaannya: kebijakan teks sering kali dapat melakukan fallback secara otomatis karena hasilnya bisa diperiksa oleh mesin. Kebijakan video lebih sempit karena generasi kedua bukan sekadar percobaan ulang; itu adalah artefak lain dan event biaya lain.
Aturan fallback per modalitas
Teks: pertahankan kontrak respons
Teks adalah tempat termudah untuk memulai karena verifikasi dapat diotomatisasi. Untuk fallback routing bagi LLM APIs, backup teks harus mempertahankan:
- bentuk endpoint;
- bentuk event streaming jika digunakan;
- perilaku JSON atau structured output;
- perilaku tool-call;
- persyaratan sitasi atau retrieval;
- batas latensi;
- batas biaya.
Kesalahannya adalah melakukan fallback dari route structured output yang dapat diprediksi ke model yang lebih kreatif yang terdengar lebih baik tetapi merusak parsing downstream. Jika route melayani automasi produk, stabilitas parser lebih penting daripada gaya prosa.
Visi: pisahkan pemahaman gambar dari pembuatan gambar
Job vision sering menghasilkan teks tentang sebuah gambar. Job image-generation menghasilkan artefak visual baru. Keduanya tidak boleh berbagi bucket fallback.
OpenAI, Google Gemini, dan Anthropic semuanya mendokumentasikan kemampuan API image-understanding atau terkait gambar, tetapi dokumentasi tersebut menjelaskan surface permintaan dan perilaku model yang berbeda. Untuk multimodal agent routing, pertanyaan kebijakannya bukan sekadar "apakah route ini bisa menangani gambar?" Melainkan "apakah route ini menangani job gambar ini dengan batas input dan kontrak output yang sama?"
Misalnya, workflow triase screenshot mungkin membutuhkan route penalaran yang mendukung vision dan mengembalikan teks terstruktur. Workflow creative merek membutuhkan route image-generation yang mengembalikan file dan lolos review visual. Itu adalah kelas route yang terpisah.
Pembuatan gambar: jangan melewati tinjauan kreatif
Fallback gambar harus melindungi kontrak kreatif:
- rasio aspek;
- resolusi atau kelas ukuran;
- edit versus generasi baru sepenuhnya;
- kompatibilitas template prompt;
- review merek dan kepatuhan;
- penyimpanan dan siklus hidup aset;
- biaya per aset yang diterima.
Jika route gambar utama gagal karena input tidak valid, fallback adalah langkah yang salah. Perbaiki request-nya. Jika gagal karena penyedia sementara tidak tersedia sebelum ada aset yang dibuat, fallback bisa masuk akal ketika route cadangan sudah lolos QA visual.
Audio: pisahkan transkripsi, pemahaman, dan ucapan
Routing audio sering menyembunyikan tiga pekerjaan yang berbeda:
- Speech-to-text: mengubah audio menjadi transkrip.
- Pemahaman audio: menalar konten audio, niat pembicara, atau konteks rapat.
- Text-to-speech: menghasilkan keluaran lisan.
Pekerjaan-pekerjaan tersebut memiliki mode kegagalan yang berbeda. Sebuah rute transkripsi dapat dinilai berdasarkan word error rate, kosakata domain, label pembicara, stempel waktu, dan latensi. Sebuah rute ucapan dinilai berdasarkan kualitas suara, pengucapan, latensi, kebijakan suara yang diizinkan, dan pengalaman pemutaran.
Fallback harus tetap berada di dalam jenis pekerjaan audio yang spesifik. Jangan gunakan "audio-capable" sebagai label kebijakan tunggal.
Video: perlakukan fallback sebagai peristiwa produksi lain
Video biasanya merupakan modalitas dengan risiko tertinggi untuk fallback otomatis karena permintaan yang gagal atau lambat mungkin sudah menciptakan tugas di sisi penyedia. Sebelum membuat tugas lain, sistem Anda harus mengetahui:
- apakah tugas asli sudah ada;
- apakah tugas itu dalam antrean, sedang diproses, berhasil, gagal, atau kedaluwarsa;
- apakah URL output telah dibuat;
- apakah ada penggunaan atau biaya yang tercatat;
- apakah seorang peninjau telah melihat aset tersebut;
- apakah pembuatan kedua akan melanggar anggaran atau alur persetujuan.
Untuk pembuatan video, default yang aman adalah: ulangi transport hanya sebelum ada tugas, lakukan polling pada tugas yang sudah ada sampai ke status terminal, lalu gunakan jalur regenerasi manual atau yang disetujui secara sempit.
Apa yang harus dicatat saat fallback terjadi
Fallback yang tidak terlihat di log menjadi mustahil untuk ditingkatkan. Setidaknya, setiap permintaan harus merekam:
| Field | Mengapa ini penting |
|---|---|
request_id |
Menghubungkan perilaku yang terlihat oleh pengguna dengan bukti dari penyedia dan gateway. |
route_class |
Menunjukkan apakah pekerjaan itu teks, visi, gambar, audio, atau video. |
primary_model dan final_model |
Mengungkap rute mana yang menjawab atau menghasilkan artefak. |
fallback_reason |
Membedakan timeout, rate limit, upstream error, kegagalan verifikasi, atau override manual. |
attempt_count |
Mencegah loop retry yang tak terbatas. |
latency_ms |
Menunjukkan apakah fallback membantu atau justru merugikan pengalaman pengguna. |
usage dan cost |
Membuat ekonomi rute cadangan menjadi terlihat. |
verification_status |
Menghubungkan fallback dengan kualitas output, bukan hanya keberhasilan API. |
reviewer_outcome |
Diperlukan untuk pelacakan penerimaan gambar, audio, dan video. |
Untuk tim produk AI, metrik yang paling berguna sering kali bukan uptime mentah. Melainkan accepted output rate setelah fallback. Rute cadangan yang merespons cepat tetapi menghasilkan aset yang ditolak tidak dapat diandalkan dalam istilah produk.
Di mana Flatkey berperan
Flatkey relevan untuk fallback routing pada LLM APIs karena beban operasionalnya lebih besar daripada satu panggilan API. Produk multimodal sering menumpuk kunci spesifik penyedia, akun penagihan langsung, ID model yang tersebar, penanganan error yang tidak konsisten, dan dashboard terpisah untuk eksperimen teks, gambar, audio, dan video.
Dokumen publik dan situs Flatkey memberi tim satu URL router yang kompatibel dengan OpenAI untuk panggilan model yang didukung, katalog model, log penggunaan, satu saldo, dan satu tampilan faktur. Situs live juga membingkai keandalan di sekitar failover otomatis dan tampilan status/SLA publik. Itu tidak menghilangkan kebutuhan akan kebijakan modality Anda sendiri. Itu memberi kebijakan tersebut satu tempat untuk beroperasi, alih-alih menyebarkan pilihan rute ke seluruh kode fitur.
Gunakan Flatkey ketika Anda menginginkan:
- satu endpoint router sambil membandingkan rute model yang didukung;
- satu tempat untuk memeriksa ketersediaan model dan konteks komersial;
- satu saldo dan faktur, bukan akun penyedia yang terpisah-pisah;
- log penggunaan untuk model, token, biaya, latensi, dan tinjauan pemilik;
- tata kelola rute saat semakin banyak agen dan alur kerja mengadopsi AI APIs.
Gunakan akun penyedia langsung ketika satu penyedia adalah satu-satunya kebutuhan, beban kerja tidak memerlukan fallback, dan jalur vendor yang paling sederhana lebih penting daripada kontrol lintas-model.
Daftar periksa peluncuran untuk perutean fallback bagi LLM APIs
Sebelum Anda mengaktifkan fallback otomatis dalam produk multimodal, selesaikan daftar periksa ini:
- Inventarisasi modality. Daftarkan setiap alur kerja yang menghasilkan teks, menganalisis gambar, menghasilkan gambar, menerima audio, berbicara, atau menghasilkan video.
- Tetapkan kelas rute. Jangan biarkan satu label "multimodal" menutupi jenis artefak yang berbeda.
- Tetapkan verifikasi. Setiap kelas rute memerlukan metode lulus/gagal sebelum fallback dapat dipercaya.
- Pisahkan retry dari fallback. Retry mengulangi rute yang sama. Fallback mengubah rute. Regenerasi membuat artefak baru.
- Tulis aturan anti-bypass. Penolakan keamanan, input tidak valid, efek samping, dan output parsial yang terlihat tidak boleh diam-diam fallback.
- Tetapkan batas biaya. Fallback yang menyelamatkan permintaan tetapi merusak anggaran tetap gagal untuk produk.
- Catat keputusan rute. Simpan rute utama, rute akhir, alasan kegagalan, biaya, latensi, dan hasil verifikasi.
- Uji injeksi kegagalan. Simulasikan timeout, batas laju, error 5xx, input tidak valid, kegagalan parser, gambar yang ditolak, transkrip yang buruk, dan job video yang lambat.
- Mulai dengan satu alur kerja berisiko rendah. Jangan aktifkan fallback lintas-modality di seluruh produk sekaligus.
- Tinjau tingkat output yang diterima setiap minggu. Optimalkan untuk hasil yang dapat digunakan, bukan hanya respons HTTP yang sukses.
Inilah perbedaan antara fallback routing yang andal untuk LLM APIs dan retry buta di berbagai rute yang tidak kompatibel.
Pertanyaan umum
Apa itu perutean fallback untuk LLM APIs?
Fallback routing untuk LLM APIs adalah kebijakan yang menentukan kapan rute model yang gagal, menurun kualitasnya, atau tidak tersedia harus melakukan retry, beralih ke cadangan yang disetujui, berhenti dengan error yang dapat ditindaklanjuti, atau berpindah ke tinjauan manusia.
Mengapa multimodal agent routing lebih sulit daripada routing hanya teks?
Multimodal agent routing lebih sulit karena output teks, gambar, audio, dan video memiliki metode verifikasi, kurva biaya, ekspektasi latensi, dan risiko peninjauan yang berbeda. Satu aturan fallback generik tidak dapat secara aman mencakup keempatnya.
Bisakah satu API gateway menangani teks, gambar, audio, dan video?
Ya, satu gateway dapat memusatkan akses dan peninjauan penggunaan di seluruh rute yang didukung. Aplikasi tetap memerlukan kelas rute terpisah dan kebijakan fallback untuk setiap modalitas dan alur kerja.
Kapan fallback harus otomatis?
Fallback otomatis paling aman ketika kontrak output dapat diverifikasi oleh mesin, rute cadangan sudah diuji sebelumnya, tidak ada output parsial yang sampai ke pengguna, tidak ada efek samping yang tidak pasti, dan rute cadangan tetap berada dalam batas latensi dan biaya.
Kapan fallback harus tetap manual?
Fallback harus tetap manual ketika artefak memerlukan peninjauan subjektif, permintaan mungkin telah menimbulkan efek samping, biaya pekerjaan duplikat tinggi, atau terjadi penolakan kebijakan/keamanan. Generasi video dan generasi gambar yang sensitif terhadap merek sering kali termasuk dalam kategori ini.
Apakah retry sama dengan fallback?
Tidak. Retry mengirim permintaan yang sama ke rute yang sama lagi. Fallback mengubah rute. Regenerasi membuat artefak baru. Perlakukan semuanya sebagai tindakan kebijakan yang terpisah karena memiliki implikasi biaya dan kualitas yang berbeda.
Bagaimana tim harus mengukur kualitas fallback?
Ukur tingkat keberhasilan, tingkat fallback, latensi, biaya tambahan, kegagalan parser, penerimaan peninjau, tingkat output yang ditolak, dan tingkat output yang diterima setelah fallback. HTTP 200 hanyalah awal dari pengukuran.
Bangun kebijakan routing sebelum perubahan model berikutnya
Alasan terkuat untuk memformalkan fallback routing bagi LLM APIs adalah bahwa akses model berubah lebih cepat daripada arsitektur aplikasi. Rute teks, gambar, audio, dan video baru akan terus diluncurkan. Beberapa akan menghilang, melambat, berubah harga, atau berperilaku berbeda di bawah beban.
Jika produk Anda memiliki kelas rute, aturan verifikasi, batas biaya, dan keputusan fallback yang dapat diamati, menambah atau menghapus model menjadi pembaruan kebijakan yang terkendali. Jika logika routing Anda tersembunyi dalam kode fitur, setiap perubahan model menjadi risiko migrasi.
Mulailah dengan satu alur kerja yang terisolasi, definisikan modalitas dan kelas verifikasinya, uji backup yang disetujui, lalu perluas. Saat Anda siap memusatkan akses dan penagihan di seluruh rute yang didukung, gunakan Flatkey API quickstart, tinjau alur kerja unified AI API, dan bandingkan ketersediaan model saat ini di direktori model Flatkey.
