API AI Pihak Ketiga:
Apakah Tool Benar-Benar Berjalan?

Sebuah gateway API pihak ketiga menawarkan banyak model melalui satu endpoint kompatibel. Chat biasa berhasil. Masalah baru terlihat ketika integrasi dipakai untuk agent: tool yang dipaksa tidak muncul sebagai struktur, model berkata tidak memiliki tool, atau menulis pemanggilan fungsi sebagai teks biasa.

Bagi web developer, perbedaan ini menentukan apakah workflow benar-benar dapat menjalankan fungsi, atau hanya menampilkan percakapan yang tampak teknis. Harga murah tidak berguna apabila kontrak respons berubah antar-model dan aplikasi tidak dapat membedakan proposal model dari tindakan nyata.

Satu Masalah, Tiga Sudut Pandang

Ketidaksesuaian antara fitur yang ditawarkan dan perilaku API bukan hanya persoalan coding. Masalah yang sama menimbulkan tanggung jawab berbeda bagi penyedia, risiko pembelian bagi customer, dan beban teknis bagi developer.

Transparansi penyedia, ketelitian pembeli, dan validasi developer harus bertemu pada bukti yang sama: respons terstruktur dan hasil yang benar-benar dapat dibaca kembali.

Empat Lapis yang Sering Dicampur

Model dapat meminta sebuah tool, tetapi model custom-function umumnya bukan pihak yang mengeksekusinya. Aplikasi Anda tetap harus menjadi executor.

“OpenAI-Compatible” Tidak Otomatis Berarti Feature Parity

Kompatibilitas dapat hanya mencakup path endpoint, Bearer token, format messages, dan respons teks dasar. Function calling membutuhkan penerjemahan parameter, format tool native upstream, pemetaan hasil, streaming events, serta metadata penyelesaian yang konsisten.

Karena itu, daftar model panjang tidak membuktikan semua model mendukung kontrak yang sama. Setiap adapter model adalah jalur implementasi terpisah yang perlu diuji.

Studi Kasus Anonim: Chat Berhasil, Tool Berbeda-beda

Pengujian dilakukan menggunakan API key milik penguji, canary sintetis, satu endpoint resmi gateway, dan fungsi aman bernama record_canary. Tidak ada data pihak ketiga, command berbahaya, atau perubahan pada sistem penyedia.

Pada payload khusus yang digunakan dalam pengujian ini, keluaran XML yang pernah dilihat pengguna tidak berhasil direproduksi. Kesimpulan yang sah adalah kegagalan structured tool calling pada jalur dan payload yang diuji—bukan klaim bahwa seluruh model, endpoint, atau produk selalu gagal.

Uji “Bash Execute” Tanpa Menjalankan Bash

Tool bernama bash didefinisikan dengan schema sederhana dan diperintah mengembalikan permintaan untuk mencetak marker aman. Request diulang, lalu dibandingkan dengan tool_choice: none.

Hasilnya hanya teks yang mengatakan tool tidak tersedia, disertai contoh command dalam Markdown. Tidak ada tool_calls, tidak ada executor, dan tidak ada marker hasil command. Ini membantah klaim eksekusi untuk tuple pengujian tersebut. Jika UI menampilkan “bash execute”, developer masih harus memeriksa network response, log executor, process exit code, dan artefak hasil.

Positive Control: Buktikan Harness Anda Tidak Rusak

Pengujian negatif sendirian belum cukup. Sebuah executor lokal allowlist dibuat untuk hanya menerima fungsi record_canary dengan marker yang telah ditentukan. Respons dari dua jalur yang memiliki structured tool call berhasil membuat file marker dan hash sumber respons. Tiga jalur berbasis teks tidak membuat marker dan berhenti dengan alasan NO_STRUCTURED_TOOL_CALL.

Ini bukan bukti gateway mengeksekusi tool di server. Ini membuktikan perbedaan operasional yang lebih sempit: respons terstruktur dapat diteruskan ke executor klien, sedangkan prosa, XML semu, dan code fence tidak memenuhi kontrak tersebut.

Payload Uji Minimum Sebelum Membeli

1. Baseline: minta marker teks exact untuk memastikan model dan autentikasi berfungsi.
2. Forced tool: definisikan fungsi harmless dan paksa model memilih fungsi tersebut.
3. Disabled control: gunakan prompt sama dengan tool_choice: none. Respons harus berbeda secara struktural dari forced tool.
4. Unknown tool: pastikan gateway tidak mengarang keberhasilan atau diam-diam menjalankan nama tool yang tidak diizinkan.
5. Reproduksi: ulangi minimal dua kali pada setiap model yang akan digunakan.
6. Executor canary: allowlist satu fungsi tanpa efek berbahaya dan simpan marker terkontrol.
7. Readback: baca marker dari sumber kebenaran, bukan dari klaim model.

Contoh Pemeriksaan Respons

const message = response.choices?.[0]?.message;
const call = message?.tool_calls?.[0];

if (!call || call.type !== "function") {
  throw new Error("NO_STRUCTURED_TOOL_CALL");
}

if (call.function.name !== "record_canary") {
  throw new Error("TOOL_NOT_ALLOWLISTED");
}

const args = JSON.parse(call.function.arguments);
await recordCanary(args.marker); // aplikasi Anda yang mengeksekusi
const saved = await readCanary(); // verifikasi authoritative

Jangan mengeksekusi string command yang dibuat model secara langsung. Terapkan allowlist tool, validasi schema, authorization server-side, timeout, batas biaya, logging, dan approval untuk operasi sensitif.

Red Flag untuk Pembeli API

• demo hanya menunjukkan chat UI atau animasi terminal tanpa raw response;
• istilah “support tools” tidak disertai contoh request dan response per model;
• forced tool dan disabled control menghasilkan bentuk yang sama;
• pseudo-call berada di content tetapi dipasarkan sebagai function calling;
• model mengaku “sudah menjalankan” tanpa log executor atau state readback;
• dokumentasi hanya menguji satu model tetapi katalog menjual banyak adapter;
• tidak ada kontrak kompatibilitas, versi adapter, status page, atau kebijakan refund;
• penjual meminta API key upstream utama milik pelanggan tanpa scope dan rotasi yang jelas.

Kapan Layak Disebut Menyesatkan atau Scam?

Kegagalan teknis, adapter belum lengkap, dan dokumentasi buruk belum otomatis membuktikan penipuan. Klaim menjadi menyesatkan apabila kemampuan tertentu dipasarkan secara eksplisit, pengujian terkontrol membuktikan kemampuan itu tidak tersedia, dan penyedia tetap merepresentasikannya sebagai eksekusi nyata tanpa disclosure atau perbaikan.

Istilah scam membutuhkan bukti tambahan tentang representasi, transaksi, pengetahuan atau niat, pola keluhan, penolakan pemulihan, dan yurisdiksi. Untuk artikel teknis, bahasa yang lebih akurat adalah ketidaksesuaian kemampuan yang direproduksi atau klaim eksekusi yang belum terbukti.

Checklist Kontrak untuk Tim Web

• Minta daftar fitur per model: chat, streaming, JSON mode, tools, vision, embeddings, dan limits.
• Simpan golden request/response dan jalankan contract test pada CI.
• Fail closed jika tool call tidak terstruktur atau schema tidak valid.
• Jangan parse code fence, XML bebas, atau kalimat model sebagai perintah produksi.
• Pisahkan biaya inferensi dari biaya tool/API eksternal.
• Gunakan key terpisah dengan limit rendah untuk evaluasi; rotasi setelah pengujian atau kebocoran.
• Catat model yang diminta, model yang dikembalikan, adapter version, request ID, dan usage.
• Verifikasi setiap aksi melalui API/database/log yang authoritative.

Referensi Teknis Resmi

Kesimpulan

Sebelum membeli akses API AI pihak ketiga, jangan hanya menguji apakah model bisa menjawab. Uji apakah adapter mempertahankan kontrak tool per model, apakah aplikasi memiliki executor yang aman, dan apakah efeknya dapat dibaca kembali dari state nyata.

Kalimat, XML, JSON semu, code fence, dan animasi “execute” tetaplah tampilan sampai log serta state membuktikan sebaliknya. Bagi web developer, disiplin ini mencegah workflow agent berubah menjadi teater reasoning yang mahal.