Forem: Walse

GPT-5.5 Pro vs Instant: Kapan Harga 6x Lebih Mahal Sepadan?

Walse — Tue, 12 May 2026 06:57:16 +0000

OpenAI menyediakan dua varian GPT-5.5: Instant seharga $5 input dan $30 output per juta token, serta Pro seharga $30 input dan $180 output per juta token. Itu berarti Pro 6x lebih mahal di semua lini. Keputusan teknisnya sederhana: kapan biaya ekstra ini menghasilkan ROI, dan kapan hanya membakar budget?

Coba Apidog hari ini

Panduan ini membantu Anda membuat keputusan tersebut secara praktis: hitung biaya per fitur, ukur akurasi pada prompt nyata, masukkan latensi ke desain produk, lalu bangun regression suite di Apidog sebelum memilih model untuk produksi.

TL;DR

Gunakan GPT-5.5 Instant sebagai default untuk chat, ringkasan, klasifikasi, retrieval QA, intent routing, dan tugas dengan biaya kesalahan rendah.

Eskalasi ke GPT-5.5 Pro hanya jika satu jawaban buruk dapat menimbulkan biaya lebih besar daripada premium token 6x untuk percakapan tersebut. Biasanya ini berlaku untuk:

drafting atau review hukum
triase medis
analisis dokumen keuangan
perencanaan agen multi-langkah
refactor kode multi-file
workflow yang membutuhkan reasoning panjang dan akurasi tinggi

Jika Anda belum bisa menyatakan biaya kesalahan dalam dolar untuk sebuah fitur, Anda belum siap membayar Pro untuk fitur tersebut.

Pendahuluan

Harga GPT-5.5 membuat pemilihan model menjadi keputusan finansial yang bisa dihitung, bukan sekadar intuisi dari benchmark. Misalnya, tim yang memproses 100.000 pesan dukungan pelanggan per hari dapat membayar sekitar $4.500 per bulan dengan Instant atau $27.000 per bulan dengan Pro untuk volume yang sama. Selisih $22.500 per bulan itu harus dibenarkan dengan data.

Artikel ini menunjukkan cara menghitung biaya, membandingkan akurasi, dan menjalankan pengujian model menggunakan Apidog. Jika Anda baru mengenal keluarga GPT-5.5, baca juga panduan akses dan API GPT-5.5 Instant, pedoman pelacakan pengeluaran API OpenAI, dan panduan referensi API GPT-5.5.

Dua model di balik keluarga GPT-5.5

Instant dan Pro berbagi keluarga model, jendela konteks, dan permukaan API. Perbedaannya ada pada bobot di balik endpoint, anggaran reasoning default, dan harga per token.

ID model:

gpt-5.5      # Instant
gpt-5.5-pro  # Pro

Keduanya mendukung:

konteks input hingga 272.000 token
output hingga 128.000 token
parameter reasoning_effort: minimal, low, medium, high
streaming melalui Responses API
bentuk request yang sama

Artinya, Anda bisa mengganti model tanpa mengubah struktur request.

Harga dasar:

Model	Input / 1 juta token	Output / 1 juta token
GPT-5.5 Instant	$5	$30
GPT-5.5 Pro	$30	$180

Tier Batch memangkas harga menjadi setengah:

Model	Batch input	Batch output
Instant	$2.50	$15
Pro	$15	$90

Prompt caching juga penting. Token input yang di-cache turun menjadi:

Model	Cached input / 1 juta token
Instant	$0.50
Pro	$3

Jika workload Anda bisa memakai Batch atau caching tetapi tidak menggunakannya, Anda membayar terlalu mahal.

Latensi juga berbeda. Instant dengan reasoning_effort=minimal dapat mengembalikan token pertama dalam 200–400 ms untuk prompt pendek. Pro dengan reasoning_effort=high bisa membutuhkan 8–30 detik sebelum token pertama karena melakukan reasoning internal lebih lama. Artikel TechCrunch tentang catatan rilis GPT-5.5 Pro juga menyoroti gap ini.

Untuk UI chat, pengguna akan merasakannya. Untuk pipeline async, latensi ini mungkin tidak masalah.

Delta akurasi: kapan Pro lebih unggul?

Evaluasi yang diterbitkan OpenAI menunjukkan pola umum: Pro lebih unggul pada tugas multi-langkah dengan risiko kesalahan berantai. Instant cukup kompetitif untuk tugas yang hanya mengambil, memformat, atau meringkas informasi yang sudah ada di prompt.

Contoh benchmark yang dilaporkan:

Benchmark / tugas	Instant	Pro
GPQA Diamond	71%	87%
SWE-bench Verified	61%	~78%
MMLU / HellaSwag	>90%	>90%, gap kecil

Pada prompt medis dan hukum adversarial, OpenAI juga melaporkan bahwa Pro menghasilkan jawaban salah yang percaya diri sekitar 40% lebih jarang dibanding Instant.

Gunakan Pro untuk:

review kontrak hukum
diagnosis diferensial medis
analisis dokumen keuangan
perencanaan agen multi-langkah
refactor kode multi-file
tugas yang membutuhkan reasoning panjang dengan banyak constraint

Gunakan Instant untuk:

customer support chat
FAQ retrieval
ringkasan konten
klasifikasi sentimen
routing intent sederhana
function calling dengan tool yang jelas
completion kode dalam satu file

Bandingkan Instant dan Pro pada prompt Anda sendiri

Mulai dengan request minimal berikut. Bentuk API sama; hanya model dan reasoning.effort yang berubah.

from openai import OpenAI

client = OpenAI()

prompt = """Analyze this contract clause for unilateral termination risk:
'Either party may terminate this agreement for convenience upon
thirty (30) days written notice, provided that the terminating party
shall pay any amounts then due.'"""

instant = client.responses.create(
    model="gpt-5.5",
    reasoning={"effort": "minimal"},
    input=prompt,
)

pro = client.responses.create(
    model="gpt-5.5-pro",
    reasoning={"effort": "high"},
    input=prompt,
)

print("INSTANT:", instant.output_text)
print("PRO:", pro.output_text)

Untuk evaluasi yang lebih sistematis, siapkan 50–200 prompt yang mirip dengan traffic produksi Anda. Jalankan semua kombinasi model dan effort, lalu simpan hasilnya ke CSV.

import time
import csv
from openai import OpenAI

client = OpenAI()

PROMPTS = open("eval_prompts.txt").read().split("\n---\n")

CONFIGS = [
    ("gpt-5.5", "minimal"),
    ("gpt-5.5", "high"),
    ("gpt-5.5-pro", "minimal"),
    ("gpt-5.5-pro", "high"),
]

with open("results.csv", "w") as f:
    w = csv.writer(f)
    w.writerow([
        "model",
        "effort",
        "prompt_id",
        "latency_s",
        "in_tokens",
        "out_tokens",
        "cost_usd",
        "output",
    ])

    for i, prompt in enumerate(PROMPTS):
        for model, effort in CONFIGS:
            t0 = time.time()

            response = client.responses.create(
                model=model,
                reasoning={"effort": effort},
                input=prompt,
            )

            latency = time.time() - t0
            input_tokens = response.usage.input_tokens
            output_tokens = response.usage.output_tokens

            rate_in = 5 if model == "gpt-5.5" else 30
            rate_out = 30 if model == "gpt-5.5" else 180

            cost = (
                input_tokens * rate_in +
                output_tokens * rate_out
            ) / 1_000_000

            w.writerow([
                model,
                effort,
                i,
                round(latency, 2),
                input_tokens,
                output_tokens,
                round(cost, 5),
                response.output_text[:500],
            ])

Setelah itu:

Beri label output secara blind review.
Hitung akurasi per model.
Hitung biaya per prompt.
Hitung latensi per konfigurasi.
Tentukan rule routing per fitur.

Delta akurasi pada workload nyata hampir selalu berbeda dari benchmark publik. Itu alasan utama Anda harus menguji prompt sendiri.

Untuk workflow evaluasi agen, lihat panduan pengujian API agen AI. Untuk membuat dataset awal dari jejak produksi, baca pembuatan pengujian berbasis AI.

Perhitungan biaya: kapan 6x sepadan?

Fitur 1: bot dukungan pelanggan

Asumsi:

100.000 pesan per hari
rata-rata input: 800 token
rata-rata output: 250 token

Volume harian:

input: 80 juta token
output: 25 juta token

Biaya Instant:

80M * $5 / 1M  = $400
25M * $30 / 1M = $750
Total harian   = $1.150
Total bulanan  ≈ $34.500

Biaya Pro:

80M * $30 / 1M  = $2.400
25M * $180 / 1M = $4.500
Total harian    = $6.900
Total bulanan   ≈ $207.000

Premium Pro:

$207.000 - $34.500 = $172.500 per bulan

Putusan: gunakan Instant. Untuk workload customer support umum, gunakan budget ekstra untuk retrieval yang lebih baik, prompt sistem yang lebih ketat, dan observability.

Fitur 2: asisten review kode

Asumsi:

5.000 komentar review per hari
rata-rata input: 8.000 token
rata-rata output: 1.200 token

Volume harian:

input: 40 juta token
output: 6 juta token

Biaya Instant:

40M * $5 / 1M  = $200
6M * $30 / 1M  = $180
Total harian   = $380
Total bulanan  ≈ $11.400

Biaya Pro:

40M * $30 / 1M  = $1.200
6M * $180 / 1M  = $1.080
Total harian    = $2.280
Total bulanan   ≈ $68.400

Premium:

$68.400 - $11.400 = $57.000 per bulan

Sekarang bandingkan dengan biaya engineer. Jika Pro menangkap 5 bug nyata tambahan per 1.000 review dan setiap bug menghemat 1 jam engineer senior senilai $150/jam:

5 bug / 1.000 review * 5.000 review = 25 bug per hari
25 jam * $150 = $3.750 per hari
≈ $112.500 per bulan

Putusan: Pro bisa sepadan, tetapi hanya jika Anda benar-benar mengukur bug catch rate.

Fitur 3: ringkasan dokumen hukum

Asumsi:

500 dokumen per hari
rata-rata input: 40.000 token
rata-rata output: 3.000 token

Volume harian:

input: 20 juta token
output: 1,5 juta token

Biaya Instant:

20M * $5 / 1M     = $100
1.5M * $30 / 1M   = $45
Total harian      = $145
Total bulanan     ≈ $4.350

Biaya Pro:

20M * $30 / 1M    = $600
1.5M * $180 / 1M  = $270
Total harian      = $870
Total bulanan     ≈ $26.100

Premium:

$26.100 - $4.350 = $21.750 per bulan

Jika satu klausul ganti rugi yang terlewat dapat menimbulkan kerugian lebih besar dari premium tahunan Pro, gunakan Pro. Jika workload tidak real-time, gunakan Batch untuk memangkas biaya Pro menjadi sekitar setengah.

Rule of thumb untuk break-even

Bayar Pro jika:

nilai kesalahan yang dicegah > premium token Pro

Dengan kata lain:

expected_value_gain = error_cost * accuracy_improvement

Jika expected_value_gain lebih besar dari biaya ekstra Pro per request, gunakan Pro.

Contoh sederhana:

Biaya kesalahan: $5.000
Peningkatan akurasi Pro: 1%
Expected gain: $50 per request

Jika premium Pro untuk request tersebut hanya $0.20, Pro layak.

Sebaliknya:

Biaya kesalahan: $50
Peningkatan akurasi Pro: 1%
Expected gain: $0.50 per request

Jika premium Pro lebih tinggi dari $0.50, gunakan Instant.

Uji tradeoff Pro/Instant dengan Apidog

Jangan memilih model hanya berdasarkan benchmark. Buat regression suite kecil di Apidog dan jalankan pada prompt Anda sendiri.

Langkah implementasi:

Buka Apidog.
Buat project baru.
Tambahkan request ke endpoint:

POST https://api.openai.com/v1/responses

Buat dua request:
- gpt55-instant-minimal
- gpt55-pro-high
Gunakan header yang sama:

Authorization: Bearer {{OPENAI_KEY}}
Content-Type: application/json

Simpan OPENAI_KEY sebagai environment variable, bukan di body request.

Body untuk Instant:

{
  "model": "gpt-5.5",
  "reasoning": {
    "effort": "minimal"
  },
  "input": "{{prompt}}"
}

Body untuk Pro:

{
  "model": "gpt-5.5-pro",
  "reasoning": {
    "effort": "high"
  },
  "input": "{{prompt}}"
}

Ikat {{prompt}} ke data file berisi 50–200 prompt pengujian.
Jalankan kedua request sebagai batch.
Bandingkan respons dengan tampilan diff Apidog.
Ekspor hasil sebagai CSV.
Hitung biaya menggunakan tarif input/output di atas.
Simpan project sebagai regression suite.

Workspace Apidog menyimpan history, sehingga Anda bisa melihat kapan akurasi berubah dan prompt mana yang memicu regresi. Untuk setup lebih detail, gunakan alur kerja pengujian API untuk insinyur QA atau unduh Apidog.

Teknik lanjutan

1. Route berdasarkan fitur, bukan pengguna

Jangan membuat rule seperti “semua pengguna premium memakai Pro”. Itu mahal dan sering tidak akurat.

Lebih baik, tag setiap call dengan:

nama fitur
kelas risiko
estimasi biaya kesalahan
kebutuhan latensi
kebutuhan real-time atau batch

Contoh:

{
  "feature": "legal_contract_review",
  "risk_class": "high",
  "error_cost_usd": 5000,
  "latency_tolerance": "async",
  "preferred_model": "gpt-5.5-pro"
}

Banyak produk akhirnya memakai pola 80/20: sekitar 80% call tetap di Instant dan 20% diekskalasi ke Pro.

2. Gunakan Pro sebagai jalur eskalasi

Pola umum:

Kirim request ke Instant.
Validasi output.
Jika gagal, eskalasi ke Pro.

Eskalasi bisa dipicu oleh:

confidence check gagal
structured output tidak valid
JSON schema gagal
tool call gagal
output terlalu pendek
missing required fields
kategori risiko tinggi

Contoh pseudo-code:

def call_model(prompt, risk_class):
    instant = client.responses.create(
        model="gpt-5.5",
        reasoning={"effort": "minimal"},
        input=prompt,
    )

    if risk_class == "high":
        return client.responses.create(
            model="gpt-5.5-pro",
            reasoning={"effort": "high"},
            input=prompt,
        )

    if not is_valid_output(instant.output_text):
        return client.responses.create(
            model="gpt-5.5-pro",
            reasoning={"effort": "medium"},
            input=prompt,
        )

    return instant

Dengan pola ini, Anda membayar Instant untuk semua request dan Pro hanya untuk 5–15% request yang benar-benar membutuhkan eskalasi.

3. Cache prompt sistem

Jika prompt sistem Anda panjang dan stabil, caching wajib digunakan. Tarif cached input jauh lebih rendah:

Model	Standard input	Cached input
Instant	$5	$0.50
Pro	$30	$3

Pastikan:

prefix prompt identik antar-request
prompt sistem tidak berubah tanpa alasan
response.usage.cached_tokens dilacak
alert dibuat jika cache hit rate turun

Lihat juga panduan atribusi pengeluaran OpenAI.

4. Gunakan Batch untuk workload non-real-time

Gunakan Batch untuk:

ringkasan malam hari
klasifikasi retrospektif
evaluasi dataset
content generation terjadwal
review dokumen async

Batch memakai model yang sama, tetapi dengan diskon 50% dan SLA penyelesaian lebih panjang.

5. Jangan selalu memenuhi context window

Instant dan Pro mendukung input hingga 272K token. Namun biaya tetap naik linear dengan jumlah token. Di atas sekitar 180K token, akurasi retrieval juga bisa mulai menurun untuk kedua model.

Lebih baik:

chunk dokumen
retrieve bagian relevan
ringkas konteks panjang
deduplikasi input
hindari memasukkan seluruh corpus jika tidak perlu

Kesalahan umum

Hindari pola berikut:

memilih model langsung di client app, bukan routing layer
membandingkan model hanya dari benchmark publik
memakai reasoning_effort=high untuk semua request Pro
lupa mengatur max_output_tokens
tidak memantau cached_tokens
tidak menghitung biaya per fitur
memakai Pro untuk semua pengguna berbayar
tidak menjalankan regression suite setelah mengubah prompt

Untuk perbandingan lintas keluarga model, lihat panduan API Pratinjau Gemini 3 Flash dan opsi akses API GPT-5.5 gratis.

Kasus penggunaan dunia nyata

Triase klaim asuransi

Tim memakai Instant untuk ringkasan penerimaan awal dan mengeskalasi pertanyaan polis kompleks ke Pro. Sekitar 12% klaim masuk jalur Pro. Total pengeluaran turun 60% dibanding kebijakan full-Pro sebelumnya, sementara akurasi pada audit regulator meningkat.

Asisten review kode

Setiap PR diproses oleh Instant untuk style issue dan bug jelas. PR yang menyentuh lebih dari tiga file atau path berisiko dieskalasi ke Pro. Pro menangkap tambahan 3,8% bug dengan biaya API tambahan $40.000 per tahun, dibanding estimasi $300.000 waktu engineering yang dihemat.

Ringkasan penerimaan rumah sakit

Semua ringkasan pasien memakai Pro dengan reasoning_effort=high karena biaya kesalahan sangat tinggi. Untuk 80% ringkasan yang tidak butuh real-time, tim memakai Batch dan memangkas tagihan hingga 50%.

Kesimpulan

Premium 6x antara Instant dan Pro memaksa tim menghitung nilai akurasi secara eksplisit. Untuk sebagian besar produk, hanya 5–25% call yang benar-benar layak memakai Pro. Sisanya lebih efisien memakai Instant, caching, Batch, dan routing yang baik.

Checklist implementasi:

pilih model per fitur, bukan per user tier
default ke Instant
eskalasi ke Pro hanya jika biaya kesalahan jelas
gunakan reasoning_effort sebagai bagian dari strategi routing
aktifkan prompt caching
gunakan Batch untuk workload async
ukur biaya per fitur setiap bulan
pantau cached_tokens
jalankan regression suite di Apidog
evaluasi ulang setelah rilis model atau perubahan harga

Untuk konteks tambahan, baca panduan akses GPT-5.5 Instant dan pedoman atribusi pengeluaran per fitur OpenAI.

FAQ

T: Apakah GPT-5.5 Pro 6x lebih baik dari Instant?

J: Tidak. Pro 6x lebih mahal per token. Pada banyak workload, peningkatannya kecil. Pada tugas multi-langkah berisiko tinggi, peningkatannya bisa signifikan.

T: Bisakah saya memakai kode API yang sama untuk kedua model?

J: Ya. Keduanya memakai Responses API dengan bentuk request yang sama. Ganti model: "gpt-5.5" menjadi model: "gpt-5.5-pro". Lihat panduan API GPT-5.5.

T: Apakah reasoning_effort bekerja sama pada kedua model?

J: Nilai parameternya sama: minimal, low, medium, high. Efeknya lebih besar pada Pro karena kapasitas reasoning yang dialokasikan lebih besar.

T: Berapa penghematan prompt caching pada Pro?

J: Token input yang di-cache turun dari $30 menjadi $3 per juta token pada Pro, dan dari $5 menjadi $0.50 pada Instant.

T: Default terbaik: Pro lalu downgrade, atau Instant lalu eskalasi?

J: Default ke Instant lalu eskalasi. Pola ini biasanya lebih murah karena Pro hanya dipakai pada kasus yang gagal validasi atau berisiko tinggi.

T: Berapa penalti latensi Pro dengan reasoning tinggi?

J: Token pertama dapat membutuhkan 8–30 detik pada Pro dengan high, dibanding sekitar 200–400 ms pada Instant dengan minimal.

T: Apakah Batch menghasilkan jawaban yang sama dengan real-time?

J: Ya. Batch adalah diskon berdasarkan waktu pengiriman, bukan model berbeda. Modelnya sama, harga setengah, dengan jendela penyelesaian lebih panjang.

T: Kapan saya harus mengevaluasi ulang pilihan model?

J: Setiap ada rilis model baru, perubahan harga, perubahan prompt sistem, atau pergeseran workload. Jalankan ulang regression suite. Workflow regression suite membantu membuat proses ini berulang.

Cara Memvalidasi Respons API dalam Pengujian Playwright

Walse — Tue, 12 May 2026 06:23:55 +0000

Tes Playwright Anda bisa lulus sementara API tetap salah. Contohnya: tombol login berhasil diklik, dashboard tampil, grafik dirender, tetapi pelanggan melaporkan angka grafik keliru. Setelah ditelusuri, API mengembalikan 200 OK dengan payload yang formatnya salah. Tes browser tidak menangkapnya karena hanya memeriksa UI. Untuk menutup celah ini, tambahkan penegasan API berbasis kontrak. Alat seperti Apidog membantu memvalidasi kontrak API, skema, dan semantik respons, lalu menjalankannya bersama suite Playwright di CI.

Coba Apidog hari ini

TL;DR

Gunakan kombinasi:

fixture request Playwright untuk pemeriksaan API ringan di dekat alur UI,
page.route untuk stub/mocking data UI,
skenario Apidog untuk validasi skema, kontrak, workflow API berantai, dan jalur error,
satu spesifikasi OpenAPI sebagai sumber kebenaran,
satu pipeline CI yang menjalankan Playwright dan Apidog secara paralel.

Hasilnya: perubahan kontrak API cepat gagal, baik di lapisan UI maupun API.

Pendahuluan

Playwright adalah kerangka kerja otomatisasi browser yang banyak digunakan, dan dokumentasi Playwright membuat pengujian API terlihat sederhana:

const response = await request.get('/api/orders');
expect(response.status()).toBe(200);

Masalahnya muncul saat suite membesar. Banyak tim berakhir dengan ratusan tes yang hanya memeriksa status code, tanpa validasi bentuk respons, tanpa sumber kebenaran bersama, dan tanpa cara menjalankan UI secara offline saat backend lambat atau rusak.

Pola yang lebih aman:

Jadikan openapi.yaml atau openapi.json sebagai kontrak.
Gunakan kontrak itu untuk fixture Playwright dan skenario Apidog.
Validasi respons di dua lapisan:
- Playwright untuk smoke check di sekitar aksi pengguna.
- Apidog untuk validasi skema dan workflow API yang lebih dalam.
Jalankan keduanya di CI.

Jika belum memasang alatnya, Unduh Apidog, lalu ikuti langkah implementasi di bawah.

Untuk konteks pemilihan alat, lihat juga alat pengujian API untuk insinyur QA.

Celah antara tes Playwright dan penegasan API

Tes Playwright biasanya melakukan hal berikut:

Login.
Navigasi ke halaman.
Pastikan elemen UI terlihat.
Pastikan teks, tombol, atau grafik muncul.

Itu cukup untuk memverifikasi alur pengguna, tetapi belum cukup untuk memverifikasi API di baliknya.

Tiga kegagalan umum yang sering lolos:

1. Regresi bentuk payload

Endpoint mengembalikan 200 OK, tetapi field berubah:

{
  "totalCount": 10
}

Padahal kontrak mengharapkan:

{
  "total_count": 10
}

UI mungkin tetap menampilkan angka default atau nilai kosong. Playwright bisa tetap lulus jika hanya memeriksa elemen terlihat.

2. Penyimpangan logika bisnis

Endpoint diskon seharusnya menerapkan diskon 15%, tetapi backend hanya mengembalikan 10%.

UI tetap menampilkan apa pun yang diberikan API. Jika tes hanya memeriksa “harga muncul”, bug ini bisa lolos.

3. Jalur error tidak diuji

Tes browser sering fokus pada happy path. Sementara API memiliki banyak cabang:

token kedaluwarsa,
rate limit,
konflik idempotensi,
validasi input gagal,
kegagalan parsial,
respons 4xx dan 5xx.

Cabang-cabang ini lebih cocok diuji di suite API khusus.

Pembagian tanggung jawab yang praktis:

Playwright: validasi alur UI, intersepsi jaringan, smoke check API di sekitar aksi pengguna.
Apidog: validasi skema, kontrak OpenAPI, workflow API berantai, jalur error, dan mock server.

Keduanya memakai spesifikasi OpenAPI yang sama. Untuk pendekatan contract-first, baca perkakas pengembangan API design-first.

Cara berbagi fixture antara Playwright dan Apidog

Mulai dari satu sumber kebenaran:

.
├── openapi.yaml
├── fixtures/
│   └── order.json
├── tests/
│   ├── fixtures/
│   │   └── api.ts
│   └── orders.spec.ts
└── apidog/
    └── scenarios/
        └── checkout.json

openapi.yaml mendefinisikan kontrak API. Folder fixtures/ menyimpan data uji yang digunakan oleh Playwright dan Apidog.

1. Buat fixture Playwright untuk API

// tests/fixtures/api.ts
import { test as base, APIRequestContext, expect } from '@playwright/test';
import { readFileSync } from 'fs';
import path from 'path';

type ApiFixtures = {
  apiRequest: APIRequestContext;
  authToken: string;
  sampleOrder: Record<string, unknown>;
};

export const test = base.extend<ApiFixtures>({
  apiRequest: async ({ playwright }, use) => {
    const ctx = await playwright.request.newContext({
      baseURL: process.env.API_BASE_URL ?? 'https://api.staging.example.com',
      extraHTTPHeaders: {
        Accept: 'application/json',
        'Content-Type': 'application/json',
      },
    });

    await use(ctx);
    await ctx.dispose();
  },

  authToken: async ({ apiRequest }, use) => {
    const res = await apiRequest.post('/auth/token', {
      data: {
        email: 'qa@example.com',
        password: process.env.QA_PASSWORD,
      },
    });

    expect(res.status()).toBe(200);

    const body = await res.json();
    await use(body.access_token);
  },

  sampleOrder: async ({}, use) => {
    const raw = readFileSync(
      path.join(__dirname, '..', '..', 'fixtures', 'order.json'),
      'utf8',
    );

    await use(JSON.parse(raw));
  },
});

export { expect };

Setelah itu, impor test dari file fixture ini, bukan langsung dari @playwright/test.

2. Gunakan fixture di spesifikasi Playwright

// tests/orders.spec.ts
import { test, expect } from './fixtures/api';

test('POST /orders returns a valid order with 15 percent discount', async ({
  apiRequest,
  authToken,
  sampleOrder,
}) => {
  const res = await apiRequest.post('/orders', {
    headers: {
      Authorization: `Bearer ${authToken}`,
    },
    data: {
      ...sampleOrder,
      coupon: 'SAVE15',
    },
  });

  expect(res.status()).toBe(201);

  const body = await res.json();

  expect(body).toMatchObject({
    id: expect.any(String),
    status: 'pending',
    discount_pct: 15,
    total_cents: expect.any(Number),
  });

  expect(body.total_cents).toBeLessThan(sampleOrder.subtotal_cents);
});

Playwright menangkap assertion semantik penting seperti:

expect(body.discount_pct).toBe(15);

Namun Playwright tidak ideal untuk validasi skema mendalam pada banyak endpoint. Di sinilah Apidog melengkapi.

3. Impor OpenAPI yang sama ke Apidog

Di Apidog:

Buka proyek.
Klik Import.
Pilih openapi.yaml.
Gunakan endpoint, schema, parameter, dan contoh request yang dihasilkan.
Simpan payload seperti fixtures/order.json sebagai variabel lingkungan atau dataset.

Skenario Apidog untuk POST /orders dapat menggunakan payload yang sama, lalu memvalidasi respons terhadap komponen Order di OpenAPI.

Contoh manfaatnya:

Playwright memastikan discount_pct benar.
Apidog memastikan semua field sesuai tipe.
Apidog memastikan enum valid.
Apidog memastikan required field tidak hilang.
Apidog menangkap field yang berubah nama atau berubah tipe.

Jika baru mulai dengan pengujian berbasis spesifikasi, lihat alur kerja API design-first.

Untuk tim yang masih memakai Postman, baca juga alternatif Postman yang di-host sendiri.

Menyiapkan alur kerja Apidog + Playwright

Berikut setup implementasi dari nol hingga CI.

Langkah 1: Simpan satu spesifikasi OpenAPI di repo

Letakkan file di root:

openapi.yaml

Perlakukan seperti kode:

wajib review PR,
breaking change perlu penanda versi,
schema harus diperbarui bersama perubahan endpoint,
contoh request/response harus realistis.

Jika belum punya OpenAPI, buat dari framework backend yang digunakan. Banyak framework seperti FastAPI dan NestJS bisa menghasilkan OpenAPI secara native. Apidog juga dapat membantu merekayasa balik spesifikasi dari traffic jika Anda mengimpor file HAR.

Langkah 2: Sambungkan Playwright

Instal Playwright:

npm init playwright@latest

Tambahkan script:

{
  "scripts": {
    "test:e2e": "playwright test"
  }
}

Contoh konfigurasi dasar:

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  retries: 2,
  use: {
    baseURL: process.env.WEB_BASE_URL ?? 'http://localhost:3000',
    trace: 'on-first-retry',
  },
});

Prinsipnya:

satu skenario per file atau per blok test,
jangan membuat test terlalu panjang,
validasi API di Playwright hanya untuk smoke check penting,
validasi kontrak lengkap tetap di Apidog.

Langkah 3: Tambahkan skenario Apidog

Di Apidog:

Impor openapi.yaml.
Buat skenario untuk perjalanan pengguna penting:
- registrasi,
- login,
- checkout,
- refund,
- webhook,
- pembatalan order.
Rangkai response dari satu request menjadi input request berikutnya.
Tambahkan assertion pasca-respons.
Ekspor skenario agar bisa dijalankan via CLI.

Contoh eksekusi:

apidog-cli run ./apidog/scenarios/checkout.json

Langkah 4: Gunakan `page.route` untuk isolasi UI

Saat backend lambat atau Anda ingin menguji kondisi tertentu, stub respons jaringan di Playwright.

test('dashboard renders cached order list when offline', async ({
  page,
  sampleOrder,
}) => {
  await page.route('**/api/orders', async (route) => {
    await route.fulfill({
      status: 200,
      contentType: 'application/json',
      body: JSON.stringify({
        orders: [sampleOrder],
      }),
    });
  });

  await page.goto('/dashboard');

  await expect(page.getByTestId('order-row')).toHaveCount(1);
});

Catatan penting: stub page.route bukan pengganti tes API. Stub dipakai untuk isolasi UI. Validasi API tetap dijalankan di Apidog terhadap backend asli atau mock server.

Langkah 5: Jalankan Playwright dan Apidog di CI

Contoh GitHub Actions:

name: tests

on: [push, pull_request]

jobs:
  playwright:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test

  apidog:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm i -g apidog-cli
      - run: apidog-cli run ./apidog/scenarios/checkout.json --reporters cli,junit

Jika salah satu job gagal, PR diblokir.

Gunakan reporter JUnit agar hasil bisa dianotasi di CI:

apidog-cli run ./apidog/scenarios/checkout.json --reporters cli,junit

Untuk optimasi workflow, lihat Dokumentasi GitHub Actions.

Untuk pembagian kepemilikan antara developer dan QA, lihat alat pengujian API untuk insinyur QA.

Langkah 6: Tambahkan deteksi schema drift

Tambahkan job harian yang membandingkan schema saat ini dengan schema yang dipakai di test.

Tujuannya: menangkap perubahan seperti:

- total_count: integer
+ totalCount: integer

atau:

- discount_pct: number
+ discount_pct: string

Jika schema berubah tanpa pembaruan test dan review, build harus gagal sebelum regresi masuk ke production.

Teknik lanjutan dan kiat profesional

Aktifkan Playwright trace

Di playwright.config.ts:

use: {
  trace: 'on-first-retry',
}

Saat test gagal di CI, Anda bisa melihat:

timeline aksi,
network request,
snapshot DOM,
console log.

Pasangkan dengan report HTML dari Apidog untuk melihat apakah sumber masalah ada di UI atau API.

Gunakan mock server Apidog untuk mode offline

Apidog dapat menjalankan mock server dari spesifikasi OpenAPI. Ini berguna saat:

backend sedang deploy,
database staging di-reset,
service dependency lambat,
developer frontend butuh data stabil.

Pola yang disarankan:

Playwright diarahkan ke mock saat menguji UI secara lokal.
Skenario Apidog tetap dijalankan terhadap backend asli di CI.
Kontrak tetap berasal dari OpenAPI yang sama.

Untuk pola yang berhubungan dengan pembuatan test, baca pembuatan tes API yang dibantu AI.

Batasi retry

Contoh konfigurasi Playwright:

export default defineConfig({
  retries: 2,
});

Jika test butuh lebih dari dua retry untuk lulus, kemungkinan ada masalah stabilitas.

Prinsip yang sama berlaku untuk skenario API. Jangan menyembunyikan endpoint flaky dengan retry berlebihan.

Gagal tertutup pada schema drift

Jika Apidog menemukan ketidakcocokan schema, biarkan job keluar dengan status non-zero.

Hindari pola seperti:

apidog-cli run scenario.json || true

Jika benar-benar perlu soft-fail sementara, buat eksplisit:

ALLOW_SCHEMA_DRIFT=true

Dan minta komentar di PR yang menjelaskan alasannya.

Tag test berdasarkan prioritas

Gunakan tag untuk mengontrol durasi CI:

test('checkout happy path @smoke', async ({ page }) => {
  // ...
});

test('refund with expired token @regression', async ({ page }) => {
  // ...
});

Strategi umum:

@smoke: setiap push,
@regression: PR ke main,
@nightly: seluruh suite,
skenario Apidog lengkap: PR penting dan jadwal malam.

Kesalahan umum yang harus dihindari

Hanya memeriksa status === 200.
Tidak memvalidasi field body.
Hardcode bearer token di fixture.
Memakai fixture berbeda antara Playwright dan Apidog.
Tidak menjalankan Apidog CLI di CI.
Menganggap stub page.route sebagai pengganti tes API.
Menyimpan OpenAPI tetapi tidak menjadikannya bagian dari review PR.

Untuk kasus API yang non-deterministik, lihat cara menguji API agen AI.

Alternatif dan perbandingan alat

Stack	Kekuatan	Kelemahan	Terbaik untuk
Playwright saja dengan fixture `request`	Satu alat, cepat, native ke suite	Validasi skema dangkal, skenario berantai terbatas, cakupan error lemah	Tim kecil, API sederhana
Playwright + Postman	Ekosistem Postman matang, Newman CLI	Potensi dua sumber kebenaran, koleksi bisa menyimpang dari OpenAPI	Tim yang sudah memakai Postman
Playwright + Apidog	Satu sumber OpenAPI, validasi skema, mock, CLI untuk CI, workflow design-first	Dua alat untuk dipelajari, butuh disiplin spesifikasi	Tim yang ingin pengujian berbasis kontrak
Cypress + plugin cy-api	Akrab bagi pengguna Cypress	Pengujian API terbatas, bergantung plugin	Basis kode Cypress yang sudah ada
Pact	Kontrak kuat antar layanan	Kurva belajar lebih curam, butuh broker, tidak fokus UI	Organisasi microservice dengan banyak consumer internal

Jika Anda berasal dari alat lama seperti SoapUI atau ReadyAPI, lihat:

Pasangan Playwright + Apidog paling cocok untuk tim yang sudah memiliki OpenAPI, mengirimkan beberapa layanan, dan ingin satu pipeline CI yang menangkap regresi UI dan API.

Kasus penggunaan dunia nyata

Checkout e-commerce

Playwright menguji alur:

tambah produk ke keranjang,
isi alamat,
pilih metode pembayaran,
klik checkout,
lihat halaman konfirmasi.

Apidog menguji rantai API:

buat payment intent,
jalankan pemeriksaan fraud,
kurangi inventaris,
verifikasi order,
validasi respons error dari gateway pembayaran.

Jika payment gateway mengubah error_code menjadi errorCode, Apidog menangkapnya di lapisan kontrak. Playwright mungkin hanya melihat layar “checkout gagal”.

Dashboard SaaS dengan data grafik

Playwright memastikan grafik dirender dan filter UI bekerja.

Apidog memastikan endpoint agregasi mengembalikan:

total,
percentile,
time series,
jumlah data,
tipe field,
nilai enum.

Jika endpoint p99 latency menghilangkan outlier, grafik bisa tetap terlihat normal. Validasi API lebih mungkin menangkap kesalahan tersebut.

Workflow berbasis webhook

Playwright menguji portal pengguna.

Apidog menguji:

pengiriman webhook,
retry,
idempotensi,
signature,
duplicate event ID,
eventual consistency.

Contoh assertion yang relevan:

expect(response.status()).toBe(409);
expect(body.code).toBe('DUPLICATE_WEBHOOK');

Kesimpulan

Playwright sangat kuat untuk alur browser, tetapi bukan alat utama untuk pengujian API mendalam.

Gabungkan dengan Apidog untuk mendapatkan:

satu spesifikasi OpenAPI sebagai kontrak,
fixture bersama,
validasi skema di setiap endpoint,
mock server untuk pengembangan offline,
pipeline CI yang gagal pada regresi UI atau API,
page.route untuk isolasi UI,
skenario API berantai untuk validasi backend,
kepemilikan yang jelas antara frontend dan backend.

Mulai dari satu perjalanan kritis seperti checkout atau registrasi:

Tambahkan fixture Playwright.
Impor OpenAPI ke Apidog.
Buat skenario API yang sesuai.
Jalankan keduanya di CI.
Perluas cakupan secara bertahap.

Unduh Apidog, impor spesifikasi OpenAPI Anda, lalu jalankan skenario pertama.

FAQ

Bisakah saya memvalidasi API dalam tes Playwright tanpa Apidog?

Ya. Gunakan fixture request Playwright dan assertion manual:

const res = await request.get('/orders');
expect(res.status()).toBe(200);

const body = await res.json();
expect(body.orders).toBeDefined();

Namun untuk validasi skema, skenario berantai, mock, dan cakupan jalur error pada skala besar, alat khusus seperti Apidog lebih praktis. Lihat juga perbandingan alat pengujian API untuk insinyur QA.

Apakah saya memerlukan spesifikasi OpenAPI?

Untuk manfaat penuh, ya.

Tanpa OpenAPI, Anda masih bisa menjalankan Playwright dan Apidog berdampingan, tetapi akan kehilangan sumber kebenaran bersama. Akibatnya, payload contoh dan schema bisa menyimpang.

Bagaimana cara menangani autentikasi di kedua alat?

Ambil token baru dari endpoint autentikasi, lalu simpan di fixture Playwright dan variabel lingkungan Apidog.

Di Playwright:

authToken: async ({ apiRequest }, use) => {
  const res = await apiRequest.post('/auth/token', {
    data: {
      email: 'qa@example.com',
      password: process.env.QA_PASSWORD,
    },
  });

  const body = await res.json();
  await use(body.access_token);
}

Jangan hardcode token di repo.

Bisakah skenario Apidog menggantikan Playwright?

Tidak.

Apidog menguji API. Playwright menguji browser. Untuk validasi UI seperti teks terlihat, klik, layout, form, dan navigasi, Anda tetap membutuhkan Playwright.

Bagaimana jika staging backend tidak stabil?

Gunakan mock server Apidog dari spesifikasi OpenAPI.

Pola praktis:

lokal: Playwright diarahkan ke mock,
CI: Apidog menguji backend asli,
fallback: jika staging rusak, jalankan smoke UI terhadap mock agar developer tetap bisa bekerja.

Bagaimana menjaga CI tetap cepat?

Gunakan strategi bertingkat:

smoke test pada setiap push,
regression test pada PR ke main,
full suite pada jadwal malam,
parallel worker untuk Playwright,
parallel execution untuk skenario Apidog jika tersedia.

Contoh Playwright:

export default defineConfig({
  workers: 4,
});

Apakah saya memerlukan paket Apidog berbayar untuk CI?

Apidog CLI dapat dijalankan secara lokal dan di CI untuk eksekusi skenario. Periksa halaman harga terbaru sebelum mengadopsi dalam skala besar, terutama jika tim membutuhkan fitur kolaborasi tambahan.

OpenAI Daybreak vs Claude Mythos: Perbandingan dan Keunggulannya

Walse — Tue, 12 May 2026 06:11:21 +0000

Dua laboratorium AI paling berpengaruh di dunia sama-sama meluncurkan platform keamanan siber dalam waktu lima minggu. Anthropic mengumumkan Claude Mythos pada 7 April 2026. OpenAI menyusul dengan Daybreak pada 11 Mei 2026.

Coba Apidog hari ini

Sekilas, keduanya terlihat mirip: sama-sama memakai model frontier untuk menemukan kerentanan, menghasilkan eksploitasi, dan membantu tim defensif bekerja lebih cepat. Namun strategi implementasinya berbeda: akses, alur kerja, cakupan kemampuan, dan cara masing-masing vendor mengelola risiko kemampuan ofensif.

Artikel ini membandingkan Claude Mythos dan OpenAI Daybreak dari sudut pandang praktis: apa yang bisa Anda gunakan, bagaimana mengintegrasikannya ke workflow keamanan, dan kapan masing-masing relevan untuk tim Anda.

Jawaban singkat

Claude Mythos adalah model penelitian frontier dari Anthropic yang dibatasi di balik konsorsium undangan bernama Project Glasswing. Di atas kertas, Mythos lebih kuat untuk riset kerentanan tingkat lanjut. Namun, sebagian besar tim tidak bisa mengaksesnya.

OpenAI Daybreak adalah platform berbasis GPT-5.5 dengan beberapa tingkatan akses, plugin Codex Security, dan ekosistem mitra yang lebih luas. Kemampuannya mungkin lebih sederhana dibanding Mythos pada benchmark mentah, tetapi lebih mudah diterapkan dalam workflow tim keamanan dan engineering.

Kesimpulan praktisnya:

Jika Anda membutuhkan kemampuan eksploitasi mentah dan Anda adalah mitra Project Glasswing, Mythos layak digunakan untuk riset mendalam.
Jika Anda ingin alat yang bisa diadopsi tim keamanan pada kuartal ini, Daybreak lebih realistis.
Jika fokus Anda adalah keamanan API, kombinasikan model AI dengan alat pengujian API seperti Apidog.

Perbandingan berdampingan

Fitur	Claude Mythos	OpenAI Daybreak
Diluncurkan	7 April 2026	11 Mei 2026
Vendor	Anthropic	OpenAI
Tipe	Model penelitian frontier	Platform: beberapa model + Codex Security
Ketersediaan publik	Tidak, hanya Project Glasswing	Ya, dengan tingkatan verifikasi
Tingkatan	Model penelitian tunggal	GPT-5.5 / Akses Tepercaya untuk Siber / GPT-5.5-Cyber
Platform kode	Claude Code	Plugin Codex Security
Tingkat keberhasilan CTF	73% pada CTF tingkat ahli	Tidak diungkapkan secara publik
Penemuan zero-day	Ribuan dalam pengujian pra-rilis	Kemampuan diklaim, tanpa angka publik
Reproduksi eksploitasi	83% keberhasilan percobaan pertama	Tidak diungkapkan secara publik
Mitra	~40 organisasi termasuk AWS, Apple, Microsoft, Google, CrowdStrike, Palo Alto	20+ vendor termasuk Cisco, Cloudflare, Snyk, Tenable, Fortinet, Zscaler
Model akses	Undangan melalui Project Glasswing	Aplikasi + pemeriksaan untuk tingkatan tinggi
Kasus penggunaan utama	Riset kerentanan infrastruktur kritis	Secure development workflow berkelanjutan
Harga	Tidak diungkapkan	Harga platform OpenAI untuk tingkatan yang dapat diakses

Apa itu Claude Mythos

Pratinjau Claude Mythos adalah model frontier Anthropic yang berada di atas keluarga Claude 4 publik. Model ini bersifat umum, tetapi paling menonjol pada penalaran jangka panjang dan keamanan perangkat lunak.

Menurut klaim yang dipublikasikan, Mythos:

mencapai 73% pada tantangan CTF tingkat ahli yang tidak dapat diselesaikan model sebelumnya;
mengidentifikasi ribuan kerentanan zero-day dalam pengujian pra-rilis pada sistem operasi dan browser utama;
mereproduksi kerentanan dan menghasilkan eksploitasi yang berfungsi pada percobaan pertama sebanyak 83% dari waktu.

Karena kemampuan ini berisiko tinggi, Anthropic tidak merilis Mythos secara publik. Mereka membangun Project Glasswing, konsorsium privat untuk menggunakan Mythos dalam memperkuat software kritis sebelum kemampuan serupa tersedia bagi penyerang.

Mitra Project Glasswing mencakup AWS, Apple, Microsoft, Google, CrowdStrike, Palo Alto Networks, dan sekitar 40 organisasi tambahan yang diundang. Jika organisasi Anda tidak termasuk dalam konsorsium, Anda tidak memiliki jalur akses langsung ke Mythos.

Apa itu OpenAI Daybreak

Daybreak adalah platform keamanan siber, bukan model tunggal. Ia menggabungkan beberapa tingkatan model dengan workflow berbasis Codex.

Tingkatannya:

GPT-5.5

Model umum yang tersedia untuk pengguna OpenAI.
GPT-5.5 dengan Akses Tepercaya untuk Siber

Untuk pembela terverifikasi. Tingkat penolakan lebih rendah untuk pekerjaan keamanan sah seperti analisis malware dan reverse engineering.
GPT-5.5-Cyber

Pratinjau terbatas untuk red team dan penetration testing pada lingkungan yang diizinkan.

Komponen operasionalnya adalah Codex Security, plugin yang terhubung ke repositori, membangun threat model dari kode, memantau kerentanan, lalu membantu menghasilkan dan memvalidasi patch.

Workflow sederhananya seperti ini:

Repository
   ↓
Codex Security
   ↓
Analisis kode + threat model
   ↓
Temuan kerentanan
   ↓
Patch suggestion
   ↓
Validasi
   ↓
Pull request / tiket remediation

Kami membahas platform lengkapnya di apa itu OpenAI Daybreak. Intinya: Daybreak dirancang untuk tim keamanan yang ingin memasukkan AI ke workflow harian, bukan sekadar melakukan query manual ke model riset.

Kemampuan: di mana Mythos unggul

Jika hanya melihat benchmark mentah, Mythos lebih kuat.

1. Penemuan kerentanan

Mythos diklaim menemukan ribuan zero-day dalam pengujian pra-rilis pada sistem operasi dan browser. OpenAI juga mengklaim kemampuan serupa untuk GPT-5.5-Cyber, tetapi belum mempublikasikan angka setara.

Untuk tim riset keamanan, ini berarti Mythos lebih menarik jika targetnya adalah:

audit sistem kompleks;
riset eksploitasi tingkat lanjut;
validasi kerentanan pada software kritis;
eksplorasi attack chain multi-tahap.

2. Reproduksi eksploitasi

Mythos menghasilkan eksploitasi yang berfungsi pada percobaan pertama sebanyak 83% dari waktu. Metrik ini penting karena banyak tim keamanan tidak hanya perlu mengetahui “ada bug”, tetapi juga perlu memverifikasi apakah bug tersebut benar-benar dapat dieksploitasi.

Contoh workflow defensif:

Laporan kerentanan
   ↓
Reproduksi lokal
   ↓
Validasi exploitability
   ↓
Prioritasi severity
   ↓
Patch
   ↓
Regression test

Model seperti Mythos membantu pada tahap reproduksi dan validasi exploitability.

3. Penalaran jangka panjang

Mythos mampu menjalankan serangan multi-tahap secara otonom: mulai dari discovery, eksploitasi, hingga pasca-eksploitasi tanpa kehilangan konteks.

Kemampuan ini relevan untuk simulasi defensif, misalnya:

Enumerasi service
   ↓
Analisis source code
   ↓
Identifikasi trust boundary
   ↓
Hipotesis exploit
   ↓
Proof of concept
   ↓
Rekomendasi patch

4. Evaluasi independen

Evaluasi UK AI Safety Institute terhadap kemampuan siber Mythos mengonfirmasi peningkatan signifikan dibanding generasi sebelumnya. AISI juga menerbitkan evaluasi GPT-5.5, tetapi angka utama yang dipublikasikan lebih menguntungkan Mythos.

Jika pertanyaannya adalah “model mana yang lebih kuat untuk menemukan dan mengeksploitasi kerentanan saat ini?”, jawabannya adalah Mythos.

Ketersediaan dan workflow: di mana Daybreak unggul

Kemampuan tinggi tidak terlalu berguna jika tim Anda tidak bisa mengaksesnya.

Di sinilah Daybreak lebih praktis.

1. Distribusi lebih terbuka

Dengan akun OpenAI, tim dapat mulai memakai GPT-5.5 untuk pekerjaan keamanan umum. Untuk kemampuan lebih sensitif, Anda dapat mengajukan Akses Tepercaya untuk Siber.

Sebaliknya, Mythos hanya tersedia melalui Project Glasswing. Tidak ada jalur self-service, formulir publik, atau halaman harga.

2. Integrasi dengan repository

Codex Security dirancang untuk masuk ke workflow engineering. Pendekatannya bukan hanya “tanya model”, tetapi integrasi langsung ke repository dan pipeline remediation.

Checklist implementasi Daybreak untuk tim engineering:

[ ] Tentukan repository prioritas
[ ] Hubungkan Codex Security ke repo
[ ] Definisikan policy akses
[ ] Jalankan baseline scan
[ ] Review temuan awal
[ ] Buat tiket remediation
[ ] Validasi patch
[ ] Tambahkan regression/security test
[ ] Pantau perubahan baru secara kontinu

3. Ekosistem mitra lebih luas

Daybreak memiliki integrasi mitra di berbagai area keamanan:

endpoint: CrowdStrike, SentinelOne;
cloud: Cloudflare, Akamai;
identity: Okta;
code security: Snyk, Semgrep, Socket;
vulnerability management: Qualys, Rapid7, Tenable.

Project Glasswing memiliki mitra besar, tetapi lebih tertutup dan berorientasi riset.

4. Jalur adopsi lebih realistis

Untuk sebagian besar tim, Daybreak bisa dievaluasi seperti produk keamanan lain:

Proof of concept
   ↓
Integrasi repo terbatas
   ↓
Review false positive
   ↓
Integrasi ticketing
   ↓
Rollout bertahap ke tim lain

Mythos tidak memiliki jalur seperti ini untuk publik.

Filosofi: dua pendekatan berbeda terhadap risiko

Perbedaan utama bukan hanya teknis. Ini juga soal filosofi rilis kemampuan berbahaya.

Pendekatan Anthropic

Anthropic tampaknya mengambil posisi bahwa kemampuan sekuat Mythos terlalu berisiko untuk rilis umum. Solusinya adalah membatasi akses ke konsorsium kecil yang tepercaya.

Artinya:

risiko difusi kemampuan ofensif lebih rendah;
dampak defensif terbatas pada mitra terpilih;
ekosistem publik tidak langsung mendapatkan manfaat penuh.

Pendekatan OpenAI

OpenAI mengambil pendekatan bertingkat:

pengguna umum mendapatkan model defensif;
pembela terverifikasi mendapatkan lebih sedikit pembatasan;
workflow paling sensitif masuk ke model khusus dengan kontrol akun yang lebih ketat.

Artinya:

lebih banyak tim bisa mengakses kemampuan defensif;
sistem verifikasi menjadi komponen keamanan utama;
integrasi workflow menjadi bagian dari mitigasi risiko.

Keduanya masuk akal. Untuk tim keamanan, strategi paling praktis adalah:

Gunakan Daybreak jika tersedia
Pantau publikasi Mythos
Jangan membangun roadmap berdasarkan akses yang belum pasti

Bagaimana dengan Claude Code untuk pekerjaan keamanan?

Jika Anda tidak bisa mengakses Mythos, Anda masih dapat memakai Claude Code dengan keluarga Claude 4 publik untuk pekerjaan terkait keamanan.

Contoh penggunaan yang masih realistis:

membaca kode dan menjelaskan alur autentikasi;
mencari pola input validation yang lemah;
membantu membuat test case keamanan;
membuat draft proof of concept untuk lingkungan yang Anda miliki;
meninjau patch keamanan.

Contoh prompt defensif:

Anda adalah reviewer keamanan aplikasi.
Analisis kode berikut untuk mencari:
1. broken authentication
2. broken authorization
3. injection risk
4. insecure error handling

Batasi analisis pada rekomendasi defensif.
Berikan output dalam format:
- Risiko
- Lokasi kode
- Dampak
- Rekomendasi patch
- Test case

Kami membahas permukaan API Claude yang lebih luas di dapatkan akses API Claude tanpa batas gratis. Untuk tim yang sudah memakai ekosistem Anthropic, ini adalah jalur realistis sampai Glasswing dibuka atau model penerus dirilis publik.

Jalur setara OpenAI adalah memakai API GPT-5.5 untuk tugas keamanan umum sebelum mengajukan Akses Tepercaya untuk Siber.

Mana yang harus Anda pilih?

Untuk hampir semua tim, jawabannya adalah Daybreak.

Bukan karena Daybreak pasti lebih kuat, tetapi karena Daybreak adalah opsi yang dapat diakses, diuji, dan diintegrasikan.

Gunakan matriks berikut:

Kondisi tim Anda	Pilihan praktis
Anda adalah mitra Project Glasswing	Gunakan Mythos untuk riset mendalam dan Daybreak untuk workflow harian
Anda bukan mitra Project Glasswing	Evaluasi Daybreak
Anda fokus pada keamanan API	Kombinasikan Daybreak/Claude Code dengan alat API seperti Apidog
Anda belum punya workflow security review	Mulai dari repository prioritas dan CI/CD
Anda butuh red team pada environment internal	Ajukan akses Daybreak tingkat lebih tinggi jika memenuhi syarat

Pohon keputusannya sederhana:

Apakah Anda mitra Project Glasswing?
   ├─ Ya  → Gunakan Mythos + Daybreak
   └─ Tidak
        ↓
   Apakah Anda butuh workflow keamanan yang bisa diterapkan sekarang?
        ├─ Ya  → Evaluasi Daybreak
        └─ Tidak → Pantau publikasi Mythos dan evaluasi ulang nanti

Dalam praktik, “Mythos vs Daybreak” lebih tepat dibaca sebagai “Daybreak vs menunggu akses Mythos”. Untuk kebanyakan organisasi, Daybreak menang karena bisa digunakan sekarang.

Apa artinya ini bagi pengembang API

Sebagian besar serangan produksi menargetkan API: bypass autentikasi, otorisasi rusak, injection pada request boundary, dan dependensi rentan di service backend.

Baik Mythos maupun Daybreak bukan alat khusus keamanan API. Keduanya bisa menganalisis kode API, tetapi API tetap diperlakukan sebagai bagian dari codebase yang lebih luas.

Untuk keamanan API, Anda membutuhkan dua lapisan:

Model AI keamanan untuk menemukan cacat logika dan pola eksploitasi dalam implementasi.
Platform API untuk menjaga kontrak, skema, test, dan perubahan perilaku.

Di sinilah Apidog relevan.

Apidog membantu mendeteksi:

penyimpangan kontrak API;
skema request/response yang rusak;
perubahan perilaku endpoint;
ketidaksesuaian antara dokumentasi dan implementasi;
regresi dari perubahan API.

Anda dapat menggabungkannya dengan pendekatan AI seperti ini:

OpenAPI / API spec
   ↓
Apidog contract testing
   ↓
Deteksi schema drift dan behavior change
   ↓
AI security review pada implementation code
   ↓
Patch
   ↓
Regression test API
   ↓
Deploy

Apidog juga mendukung workflow seperti pengembangan API contract-first dan pengujian server MCP. Daybreak atau Mythos membantu menemukan cacat logika dalam implementasi, sedangkan Apidog membantu memastikan API tetap sesuai kontrak dari spesifikasi hingga runtime.

FAQ

Apakah Claude Mythos tersedia untuk umum?

Tidak. Mythos dibatasi untuk mitra Project Glasswing. Anthropic belum mengumumkan jadwal rilis publik. Pada Mei 2026, tidak ada proses aplikasi untuk individu atau organisasi kecil.

Bisakah saya mendapatkan Akses Tepercaya untuk Siber di OpenAI?

Ya, dengan verifikasi. Anda perlu mengajukan akses melalui platform OpenAI. Persetujuan bergantung pada kasus penggunaan defensif yang sah. Akses individu ke GPT-5.5-Cyber memerlukan Keamanan Akun Tingkat Lanjut yang diaktifkan pada 1 Juni 2026.

Apakah Mythos lebih mumpuni daripada GPT-5.5-Cyber?

Berdasarkan benchmark yang dipublikasikan, ya. Mythos mencapai 73% pada CTF ahli dan menghasilkan eksploitasi yang berfungsi pada percobaan pertama sebanyak 83% dari waktu. OpenAI belum mempublikasikan angka setara untuk GPT-5.5-Cyber.

Apakah Mythos dan Daybreak adalah produk yang bersaing?

Dalam positioning pasar, ya. Dalam praktik, tidak sepenuhnya. Mythos adalah model riset di balik konsorsium privat. Daybreak adalah platform dengan jalur akses dan integrasi workflow. Sebagian besar tim sebenarnya memilih antara Daybreak dan menunggu akses Mythos publik.

Bisakah salah satu model digunakan untuk menyerang pihak ketiga?

Tidak. Keduanya memiliki guardrail untuk memblokir eksploitasi sistem yang tidak Anda miliki atau tidak diizinkan untuk diuji. GPT-5.5-Cyber mendukung red team dan penetration testing pada environment yang diizinkan. Mythos melalui Glasswing digunakan untuk penemuan kerentanan defensif pada sistem mitra.

Bagaimana ini dibandingkan dengan Microsoft Security Copilot?

Microsoft Security Copilot berfokus pada operasi SOC seperti triase alert, respons insiden, dan threat intelligence. Daybreak dan Mythos lebih fokus pada penemuan serta remediasi kerentanan tingkat kode. Keduanya berada di bagian workflow keamanan yang berbeda. Konteks terkait: apa itu GPT Realtime 2.

Intinya

Mythos dan Daybreak mewakili dua strategi berbeda untuk AI keamanan siber.

Mythos menunjukkan bahwa beberapa kemampuan terlalu berbahaya untuk dirilis luas. Daybreak menunjukkan bahwa verifikasi, tingkatan akses, dan integrasi workflow bisa menjadi pendekatan distribusi yang lebih praktis.

Untuk implementasi hari ini:

Evaluasi Daybreak sekarang
Gunakan Claude Code atau GPT-5.5 untuk review keamanan terbatas
Tambahkan pengujian API dengan Apidog
Pantau publikasi Mythos dan evaluasi AISI
Jangan membangun roadmap berdasarkan akses yang belum tersedia

Jika tim Anda butuh hasil yang bisa dijalankan, mulai dari workflow yang bisa diakses: repository scanning, contract testing API, validasi patch, dan regression test. Daybreak dapat masuk ke sisi AI security review, sementara Apidog membantu menjaga kualitas dan keamanan API dari kontrak hingga implementasi.

Cara Melacak Pengeluaran API OpenAI per Fitur: Panduan Atribusi Biaya

Walse — Tue, 12 May 2026 02:44:51 +0000

Faktur OpenAI Anda mungkin menunjukkan total pengeluaran $4.237 bulan lalu, tetapi tidak menjelaskan bahwa $3.100 berasal dari satu endpoint ringkasan yang lepas kontrol, $700 dari pelanggan yang hanya membayar $50/bulan, dan $437 dari fitur yang hampir tidak digunakan. Untuk mengambil keputusan harga, kapasitas, atau roadmap, Anda perlu atribusi biaya per fitur, rute, dan pelanggan.

Coba Apidog hari ini

Panduan ini menunjukkan cara membangun atribusi biaya API OpenAI yang bisa dipakai di produksi: beri tag setiap request dengan metadata, log penggunaan token dan biaya, agregasikan di data warehouse, pasang budget guardrail per key, lalu uji wrapper dengan Apidog sebelum rilis.

💡 Apidog memberi visibilitas tingkat request dan pengujian skenario untuk memverifikasi wrapper pelacakan biaya sebelum masuk produksi. Gunakan Apidog untuk memutar ulang request bertag, memvalidasi bentuk log, dan memastikan setiap panggilan membawa metadata yang dibutuhkan data warehouse Anda.

Ringkasan

Implementasi minimum:

Bungkus semua panggilan OpenAI dengan satu wrapper.
Wajibkan metadata: feature, route, customer_id, environment.
Ambil response.usage dari API OpenAI.
Hitung cost_usd saat event ditulis.
Kirim satu baris JSON per request ke pipeline log.
Agregasikan di BigQuery, ClickHouse, Snowflake, atau Postgres.
Pasang budget limit per project key di OpenAI.
Uji wrapper dengan pengujian skenario Apidog.

Mengapa Dasbor Penagihan OpenAI Tidak Cukup

Dasbor billing OpenAI berguna untuk melihat total pengeluaran, rincian model, dan batas penggunaan. Namun, untuk produk yang memakai LLM di beberapa fitur, pelanggan, environment, atau background job, informasi itu tidak cukup.

Yang biasanya hilang:

Tidak ada atribusi fitur: Anda tidak tahu apakah biaya berasal dari support-chat, summarization, atau job embedding.
Tidak ada atribusi pelanggan: sulit menghitung margin per pelanggan B2B.
Tidak real-time: data usage bisa terlambat puluhan menit hingga beberapa jam.
Tidak ada alert granular: Anda tidak bisa membuat alert seperti “endpoint chat melebihi $50/jam”.
Project key hanya membantu sebagian: key per project memberi satu dimensi atribusi, tetapi bukan per fitur, rute, atau pelanggan.

Untuk referensi harga yang dipakai dalam perhitungan biaya, lihat rincian harga GPT-5.5. Untuk konteks billing API lain, lihat penagihan penggunaan GitHub Copilot untuk tim API. Dokumentasi OpenAI tersedia di referensi API OpenAI resmi.

Model Data Atribusi Biaya

Mulailah dari satu aturan: setiap request OpenAI harus menghasilkan satu event terstruktur.

Skema minimum:

Kolom	Tipe	Contoh	Fungsi
`request_id`	uuid	`7a91...`	Idempotensi, deduplikasi, retry
`timestamp`	timestamptz	`2026-05-06T14:23:01Z`	Analisis time-series
`feature`	text	`support-chat`	Fitur produk
`route`	text	`/api/v1/chat/answer`	HTTP route atau background job
`customer_id`	text	`cust_4291`	Biaya per pelanggan
`environment`	text	`prod`	Pisahkan prod, staging, dev
`model`	text	`gpt-5.5`	Tarif model
`prompt_tokens`	int	`15234`	Token input
`completion_tokens`	int	`812`	Token output
`reasoning_tokens`	int	`4500`	Token reasoning, ditagih sebagai output
`cached_tokens`	int	`12000`	Token prompt cache
`latency_ms`	int	`2341`	Korelasi biaya dan latency
`cost_usd`	numeric	`0.045672`	Biaya request
`prompt_cache_key`	text	`system-v3`	Analisis cache hit
`error_code`	text	`429`	Retry dan error analysis

Hitung biaya saat event ditulis, bukan saat query. Dengan begitu, data historis tetap mencerminkan tarif yang berlaku pada hari request terjadi.

PRICING = {  # USD per 1 juta token, per Mei 2026
    "gpt-5.5":      {"input": 5.00,  "cached": 2.50,  "output": 30.00},
    "gpt-5.5-pro":  {"input": 30.00, "cached": 15.00, "output": 180.00},
    "gpt-5.4":      {"input": 2.50,  "cached": 1.25,  "output": 15.00},
    "gpt-5.4-mini": {"input": 0.25,  "cached": 0.125, "output": 2.00},
}

def compute_cost_usd(
    model,
    prompt_tokens,
    cached_tokens,
    completion_tokens,
    reasoning_tokens
):
    rates = PRICING[model]

    uncached = max(0, prompt_tokens - cached_tokens)

    input_cost = (uncached * rates["input"]) / 1_000_000
    cache_cost = (cached_tokens * rates["cached"]) / 1_000_000
    output_cost = (
        (completion_tokens + reasoning_tokens) * rates["output"]
    ) / 1_000_000

    return round(input_cost + cache_cost + output_cost, 6)

Token reasoning dikembalikan di:

usage.completion_tokens_details.reasoning_tokens

Namun, token ini ditagih dengan tarif output. Jangan hitung sebagai input.

Wrapper Python untuk Semua Request OpenAI

Jangan panggil SDK OpenAI langsung dari banyak tempat. Buat satu wrapper dan paksa semua fitur melewatinya.

import time
import uuid
import json
import logging
from openai import OpenAI

client = OpenAI()
logger = logging.getLogger("llm.cost")

def call_with_attribution(
    *,
    feature,
    route,
    customer_id,
    environment,
    model,
    messages,
    **openai_kwargs
):
    request_id = str(uuid.uuid4())
    started = time.time()
    error_code = None
    response = None

    try:
        response = client.chat.completions.create(
            model=model,
            messages=messages,
            **openai_kwargs
        )
        return response

    except Exception as e:
        error_code = getattr(e, "code", "unknown_error")
        raise

    finally:
        latency_ms = int((time.time() - started) * 1000)
        usage = response.usage if response else None

        prompt_tokens = getattr(usage, "prompt_tokens", 0)
        completion_tokens = getattr(usage, "completion_tokens", 0)

        cached_tokens = (
            getattr(
                getattr(usage, "prompt_tokens_details", None),
                "cached_tokens",
                0
            ) or 0
        )

        reasoning_tokens = (
            getattr(
                getattr(usage, "completion_tokens_details", None),
                "reasoning_tokens",
                0
            ) or 0
        )

        cost_usd = compute_cost_usd(
            model=model,
            prompt_tokens=prompt_tokens,
            cached_tokens=cached_tokens,
            completion_tokens=completion_tokens,
            reasoning_tokens=reasoning_tokens,
        )

        logger.info(json.dumps({
            "event": "openai.request",
            "request_id": request_id,
            "feature": feature,
            "route": route,
            "customer_id": customer_id,
            "environment": environment,
            "model": model,
            "prompt_tokens": prompt_tokens,
            "completion_tokens": completion_tokens,
            "reasoning_tokens": reasoning_tokens,
            "cached_tokens": cached_tokens,
            "latency_ms": latency_ms,
            "cost_usd": cost_usd,
            "error_code": error_code,
        }))

Contoh pemakaian:

response = call_with_attribution(
    feature="support-chat",
    route="/api/v1/chat/answer",
    customer_id="cust_4291",
    environment="prod",
    model="gpt-5.5",
    messages=[
        {"role": "system", "content": "Anda adalah asisten support."},
        {"role": "user", "content": "Bagaimana cara reset password?"},
    ],
)

Kirim log JSON tersebut ke pipeline yang sudah ada: Vector, Fluent Bit, Logstash, OTLP collector, Kafka, Pub/Sub, atau langsung ke data warehouse.

Implementasi Node.js

Pola yang sama berlaku di Node.js: wrapper menerima metadata, menjalankan request, membaca usage, menghitung biaya, lalu menulis event JSON.

import OpenAI from "openai";
import crypto from "node:crypto";

const client = new OpenAI();

const PRICING = {
  "gpt-5.5": {
    input: 5.0,
    cached: 2.5,
    output: 30.0,
  },
};

function computeCostUsd({
  model,
  promptTokens,
  cachedTokens,
  completionTokens,
  reasoningTokens,
}) {
  const rates = PRICING[model];

  const uncached = Math.max(0, promptTokens - cachedTokens);

  const inputCost = (uncached * rates.input) / 1_000_000;
  const cacheCost = (cachedTokens * rates.cached) / 1_000_000;
  const outputCost =
    ((completionTokens + reasoningTokens) * rates.output) / 1_000_000;

  return Number((inputCost + cacheCost + outputCost).toFixed(6));
}

export async function callWithAttribution({
  feature,
  route,
  customerId,
  environment,
  model,
  messages,
  ...openaiArgs
}) {
  if (!feature || !route || !customerId || !environment) {
    throw new Error("Missing OpenAI attribution metadata");
  }

  const requestId = crypto.randomUUID();
  const started = Date.now();

  let response;
  let errorCode = null;

  try {
    response = await client.chat.completions.create({
      model,
      messages,
      ...openaiArgs,
    });

    return response;
  } catch (err) {
    errorCode = err.code || "unknown_error";
    throw err;
  } finally {
    const usage = response?.usage || {};

    const promptTokens = usage.prompt_tokens || 0;
    const completionTokens = usage.completion_tokens || 0;
    const cachedTokens =
      usage.prompt_tokens_details?.cached_tokens || 0;
    const reasoningTokens =
      usage.completion_tokens_details?.reasoning_tokens || 0;

    const costUsd = computeCostUsd({
      model,
      promptTokens,
      cachedTokens,
      completionTokens,
      reasoningTokens,
    });

    console.log(JSON.stringify({
      event: "openai.request",
      request_id: requestId,
      feature,
      route,
      customer_id: customerId,
      environment,
      model,
      prompt_tokens: promptTokens,
      completion_tokens: completionTokens,
      reasoning_tokens: reasoningTokens,
      cached_tokens: cachedTokens,
      latency_ms: Date.now() - started,
      cost_usd: costUsd,
      error_code: errorCode,
    }));
  }
}

Query Agregasi Biaya

Setelah event masuk ke data warehouse, mulai dari query harian per fitur:

SELECT
  feature,
  DATE_TRUNC(timestamp, DAY) AS day,
  COUNT(*) AS requests,
  SUM(cost_usd) AS spend_usd,
  SUM(prompt_tokens + completion_tokens) AS tokens,
  AVG(latency_ms) AS avg_latency_ms,
  SUM(cached_tokens) / NULLIF(SUM(prompt_tokens), 0) AS cache_hit_rate
FROM openai_events
WHERE environment = 'prod'
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY feature, day
ORDER BY day DESC, spend_usd DESC;

Query biaya per pelanggan:

SELECT
  customer_id,
  COUNT(*) AS requests,
  SUM(cost_usd) AS spend_usd,
  SUM(prompt_tokens) AS input_tokens,
  SUM(completion_tokens + reasoning_tokens) AS output_tokens
FROM openai_events
WHERE environment = 'prod'
  AND timestamp >= TIMESTAMP_TRUNC(CURRENT_TIMESTAMP(), MONTH)
GROUP BY customer_id
ORDER BY spend_usd DESC;

Query top route kemarin:

SELECT
  route,
  feature,
  COUNT(*) AS requests,
  SUM(cost_usd) AS spend_usd,
  AVG(latency_ms) AS avg_latency_ms
FROM openai_events
WHERE environment = 'prod'
  AND DATE(timestamp) = DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY)
GROUP BY route, feature
ORDER BY spend_usd DESC
LIMIT 20;

Dashboard minimum yang sebaiknya Anda punya:

Pengeluaran per fitur dari waktu ke waktu.
Pengeluaran per pelanggan dari waktu ke waktu.
Top route berdasarkan biaya.
Cache hit rate per fitur.
Rata-rata prompt token per fitur.
Error dan retry rate.

Uji Wrapper dengan Apidog

Wrapper atribusi biaya adalah bagian kritis dari sistem billing internal Anda. Jika metadata salah atau log tidak konsisten, dashboard akan terlihat benar tetapi angkanya salah.

Gunakan Apidog untuk menguji alur end-to-end:

Buat skenario yang memanggil endpoint AI Anda.
Kirim request dengan customer_id, feature, dan payload yang diketahui.
Tangkap respons dan event log.
Assert bahwa log memiliki:
- feature
- route
- customer_id
- environment
- model
- prompt_tokens > 0
- cost_usd > 0
Jalankan skenario di staging dan produksi memakai environment variable Apidog.
Putar ulang request dan pastikan retry tidak menggandakan biaya.

Contoh assertion yang ingin Anda validasi:

{
  "event": "openai.request",
  "feature": "support-chat",
  "route": "/api/v1/chat/answer",
  "customer_id": "cust_test_001",
  "environment": "staging",
  "cost_usd": 0.001234
}

Untuk pendekatan pengujian API yang lebih luas, lihat alat pengujian API untuk insinyur QA. Jika Anda memakai pendekatan contract-first, lihat pengembangan API contract-first.

Pasang Budget Guardrail

Atribusi biaya memberi visibilitas. Guardrail mencegah kerusakan.

Gunakan project key OpenAI per environment atau per fitur:

prod-support-chat
prod-summarization
prod-embeddings
staging-all
dev-all

Lalu:

Tetapkan hard limit di dashboard OpenAI.
Simpan key di secret manager.
Map key ke service atau fitur tertentu.
Tambahkan alert berbasis data warehouse.

Contoh alert SQL setiap 10 menit:

WITH hourly AS (
  SELECT
    feature,
    TIMESTAMP_TRUNC(timestamp, HOUR) AS hour,
    SUM(cost_usd) AS spend_usd
  FROM openai_events
  WHERE environment = 'prod'
    AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 8 DAY)
  GROUP BY feature, hour
),

baseline AS (
  SELECT
    feature,
    AVG(spend_usd) AS avg_hourly_spend
  FROM hourly
  WHERE hour < TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)
  GROUP BY feature
),

current_hour AS (
  SELECT
    feature,
    SUM(cost_usd) AS current_spend
  FROM openai_events
  WHERE environment = 'prod'
    AND timestamp >= TIMESTAMP_TRUNC(CURRENT_TIMESTAMP(), HOUR)
  GROUP BY feature
)

SELECT
  c.feature,
  c.current_spend,
  b.avg_hourly_spend
FROM current_hour c
JOIN baseline b USING (feature)
WHERE c.current_spend > b.avg_hourly_spend * 3;

Kirim hasilnya ke Slack, PagerDuty, Opsgenie, atau webhook internal.

Teknik Optimasi Biaya

1. Pakai prompt caching

GPT-5.5 mengenakan biaya lebih rendah untuk cached token. Strukturkan prompt agar bagian sistem stabil berada di awal, lalu variabel request di akhir.

Pantau:

SELECT
  feature,
  SUM(cached_tokens) / NULLIF(SUM(prompt_tokens), 0) AS cache_hit_rate
FROM openai_events
WHERE environment = 'prod'
GROUP BY feature
ORDER BY cache_hit_rate ASC;

Dokumentasi resmi: Prompt caching OpenAI.

2. Gunakan Batch API untuk workload offline

Pekerjaan seperti ringkasan malam, evaluasi, reprocessing dokumen, dan embedding backfill tidak perlu respons sinkron. Jalankan lewat Batch API jika cocok dengan kebutuhan workload Anda.

Tetap log event dengan metadata tambahan:

{
  "feature": "nightly-summary",
  "route": "batch:nightly-summary",
  "batch_job_id": "batch_123"
}

3. Audit reasoning effort

Jika fitur memakai mode reasoning, cek apakah semua request benar-benar butuh effort tinggi.

Bandingkan:

kualitas output
latency
reasoning_tokens
cost_usd

Untuk detail penggunaan API, lihat cara menggunakan API GPT-5.5.

4. Batasi ukuran context

Prompt panjang mahal. Jika prompt_tokens naik dari minggu ke minggu tanpa perubahan produk, kemungkinan prompt atau retrieval Anda membengkak.

Pantau:

SELECT
  feature,
  DATE_TRUNC(timestamp, WEEK) AS week,
  AVG(prompt_tokens) AS avg_prompt_tokens
FROM openai_events
WHERE environment = 'prod'
GROUP BY feature, week
ORDER BY week DESC;

5. Tambahkan guard untuk request besar

Jika Anda tahu ada threshold token yang memicu biaya lebih tinggi, tambahkan warning di wrapper.

if prompt_tokens > 250_000:
    logger.warning(json.dumps({
        "event": "openai.large_prompt_warning",
        "request_id": request_id,
        "feature": feature,
        "route": route,
        "customer_id": customer_id,
        "prompt_tokens": prompt_tokens,
    }))

Untuk detail harga, lihat postingan harga GPT-5.5.

6. Batasi pengeluaran per pelanggan

Untuk SaaS B2B, tambahkan quota per customer_id.

Alur sederhana:

Hitung spend bulanan per pelanggan.
Simpan limit per plan.
Sebelum request OpenAI, cek spend saat ini.
Jika melewati limit, kembalikan 429.

Contoh respons:

{
  "error": "ai_quota_exceeded",
  "message": "Kuota AI bulanan terlampaui. Silakan upgrade paket atau hubungi admin billing."
}

Kesalahan Umum

Hindari ini:

Menghitung reasoning token sebagai input. Reasoning token ditagih sebagai output.
Mengandalkan dashboard OpenAI untuk alert real-time.
Memberi tag di level SDK, bukan di call site.
Melupakan background job, cron, queue worker, dan webhook.
Sampling log. Untuk atribusi biaya, catat semua request.
Membiarkan customer_id bernilai null.
Tidak menduplikasi retry dengan request_id.
Tidak menyimpan versi pricing saat menghitung cost_usd.

Untuk route non-HTTP, gunakan nama sintetis:

cron:nightly-summarize
queue:image-caption
webhook:incoming-ticket
batch:embedding-backfill

Alternatif dan Peralatan

Pendekatan	Kelebihan	Biaya	Cocok Untuk
API penggunaan OpenAI	Bawaan, akurat untuk total usage	Gratis	Satu project, kebutuhan sederhana
Helicone	Proxy, dashboard, caching, biaya per user	Free tier; berbayar mulai $20/bln	Ingin dashboard cepat
Langfuse	Open source, trace + cost	Self-host gratis; cloud mulai $29/bln	Ingin observability LLM open source
LangSmith	Integrasi kuat dengan LangChain	Mulai $39/user/bln	Tim yang sudah memakai LangChain
Data warehouse kustom	Kontrol penuh, tanpa proxy	Waktu engineering	Workload besar dan dimensi khusus

Trade-off:

Proxy seperti Helicone menambah hop di jalur request.
Self-hosted observability memberi kontrol, tetapi Anda harus mengoperasikannya.
Data warehouse kustom paling fleksibel, tetapi Anda menulis query dan alert sendiri.
API usage OpenAI cukup untuk rekonsiliasi, bukan atribusi produk granular.

Referensi tambahan:

Studi Kasus

SaaS B2B dengan pengeluaran LLM per pelanggan

Sebuah perusahaan intelijen penjualan menghabiskan $80.000/bulan untuk OpenAI. Setelah atribusi per pelanggan, mereka menemukan 12% pelanggan menghasilkan 71% pengeluaran. Mereka lalu menerapkan tier pricing, soft quota untuk plan bawah, dan overage charge. Margin fitur AI naik dari 41% ke 73% dalam satu kuartal.

Alat developer internal

Sebuah organisasi engineering memberi akses asisten GPT-5.5 ke developer. Dengan tag per developer, platform engineering menemukan tiga developer menyumbang 50% pengeluaran internal. Dua menjalankan loop agen otomatis yang lupa dimatikan. Setelah dihentikan, perusahaan menghemat $1.800/bulan.

Estimasi biaya fitur baru

Tim produk ingin meluncurkan fitur ringkasan. Dengan data historis, mereka menghitung:

rata-rata prompt token per request
rata-rata output token
request per active user
active user estimate

Hasilnya: sekitar $0,04 per active user per hari, atau $1,20 per bulan. Tim pricing menetapkan harga $5/user/bulan karena unit economics terlihat jelas.

Checklist Implementasi

Gunakan checklist ini sebelum rilis:

[ ] Semua panggilan OpenAI melewati wrapper.
[ ] feature, route, customer_id, dan environment wajib.
[ ] response.usage dicatat.
[ ] reasoning_tokens dihitung sebagai output.
[ ] cost_usd dihitung saat write.
[ ] Event JSON masuk ke pipeline log.
[ ] Data tersedia di warehouse.
[ ] Dashboard per fitur, rute, dan pelanggan tersedia.
[ ] Alert anomali biaya aktif.
[ ] Project key dipisah per environment atau fitur.
[ ] Budget limit dipasang di dashboard OpenAI.
[ ] Wrapper diuji dengan Apidog.

Kesimpulan

Dasbor billing OpenAI menjawab “berapa total yang saya bayar?”. Produk Anda membutuhkan jawaban yang lebih operasional: fitur mana, pelanggan mana, route mana, dan request mana yang menghasilkan biaya.

Bangun wrapper, catat metadata, hitung biaya saat write, agregasikan di data warehouse, lalu pasang alert dan budget guardrail.

Poin utama:

Beri tag setiap request dengan fitur, route, pelanggan, dan environment.
Hitung biaya saat event ditulis agar angka historis stabil.
Gunakan project key per environment atau fitur sebagai guardrail.
Tambahkan alert berbasis warehouse untuk mendeteksi lonjakan lebih cepat.
Uji wrapper dengan Apidog sebelum produksi.
Audit prompt, caching, dan reasoning effort secara berkala.

Unduh Apidog dan gunakan untuk memverifikasi wrapper atribusi biaya Anda: jalankan request bertag, validasi payload log, dan putar ulang skenario di semua environment.

Untuk bacaan terkait, lihat rincian harga GPT-5.5 dan penagihan penggunaan GitHub Copilot untuk tim API.

FAQ

Apakah token reasoning dihitung sebagai input atau output?

Output. OpenAI mengembalikannya di usage.completion_tokens_details.reasoning_tokens. Tambahkan ke completion_tokens saat menghitung biaya. Lihat rincian harga GPT-5.5.

Seberapa akurat `response.usage` dibandingkan dashboard OpenAI?

Jumlah token dari response.usage seharusnya cocok dengan usage yang ditagihkan. Selisih biaya biasanya terjadi jika tabel pricing internal Anda sudah usang.

Bisakah atribusi cukup dengan project key OpenAI?

Tidak untuk kebutuhan granular. Project key membantu membagi usage per project atau environment, tetapi tidak memberi atribusi per fitur, pelanggan, atau route.

Bagaimana dengan retry?

Request gagal sebelum model berjalan biasanya tidak memiliki usage, jadi tidak dicatat sebagai biaya. Jika request berhasil lalu aplikasi melakukan retry, Anda bisa mencatat biaya dua kali. Gunakan request_id yang sama untuk retry idempoten dan deduplikasi saat write.

Seberapa cepat API usage OpenAI mengembalikan data?

Biasanya ada jeda. Gunakan API usage untuk rekonsiliasi, bukan alert real-time. Untuk alert, gunakan event dari wrapper Anda sendiri.

Haruskah saya sampling request untuk mengurangi volume log?

Tidak. Satu baris JSON per request biasanya kecil. Sampling merusak atribusi per pelanggan dan per route.

Bisa dipakai untuk penyedia LLM lain?

Ya. Tambahkan kolom provider, misalnya:

openai
anthropic
google
deepseek

Lalu buat tabel pricing per provider. Untuk perbandingan, lihat harga API DeepSeek V4.

Apakah berlaku untuk embeddings dan image generation?

Ya, tetapi rumus biayanya berbeda. Tambahkan kolom endpoint:

chat
embeddings
image

Lalu cabangkan perhitungan biaya berdasarkan endpoint.

Panduan Pengujian Server MCP: Manual + Otomatis dengan Apidog

Walse — Mon, 11 May 2026 08:57:40 +0000

Post Show HN "Ableton Live MCP" mencapai 118 poin dan 78 komentar awal minggu ini. Polanya familiar: seseorang menulis server Model Context Protocol untuk alat yang tidak terduga, komunitas Claude Desktop menyukainya, lalu muncul banyak pertanyaan "haruskah saya menulis satu untuk X?". Dalam waktu kurang dari setahun, MCP bergerak dari eksperimen khusus Anthropic menjadi lapisan integrasi agen yang makin standar.

Coba Apidog hari ini

Masalahnya: tooling untuk menguji server MCP masih belum rapi. Menjalankan JSON-RPC manual lewat stdio cukup untuk hello-world, tetapi cepat berantakan ketika server punya 12 tool, 3 prompt, dan API upstream yang tidak stabil. Panduan ini menunjukkan cara menguji server MCP secara manual, lalu mengotomatiskannya dengan Apidog, sehingga server MCP bisa dikirim seperti API lain: dengan kontrak, mock, dan regression suite.

Jika Anda bekerja di konteks agen yang lebih umum, panduan agents.md juga relevan. Konvensi di sana membantu tim mendokumentasikan kontrak server MCP dengan lebih jelas.

TL;DR

MCP adalah Model Context Protocol dari Anthropic: JSON-RPC 2.0 melalui stdio atau HTTP.
MCP mengekspos tiga primitif utama: tools, resources, dan prompts.
Pengujian server MCP berarti memverifikasi respons initialize, tools/list, tools/call, resources/read, dan prompts/get terhadap kontrak.
Mulai dari manual: jalankan server via stdio, cek respons JSON-RPC, lalu simpan request/response kanonik.
Lanjutkan ke otomatisasi: simpan request di Apidog, tambahkan assertion, mock API upstream, dan jalankan suite di CI.
Gunakan mock server Apidog agar pengujian tetap deterministik.
Unduh Apidog jika Anda ingin request collection, mock server, dan CI runner dalam satu workflow.

Apa itu MCP dalam dua menit

Spesifikasi Model Context Protocol mendefinisikan protokol JSON-RPC 2.0 dengan permukaan kecil. Klien seperti Claude Desktop, Cursor, atau agen Anda sendiri memulai server MCP, melakukan handshake initialize, lalu memanggil method MCP.

Method yang paling sering perlu diuji:

initialize: negosiasi versi protokol dan kapabilitas.
tools/list: daftar tool yang diekspos server, termasuk JSON Schema argumen.
tools/call: pemanggilan tool berdasarkan nama dan argumen.
resources/list dan resources/read: akses konten berbasis URI.
prompts/list dan prompts/get: daftar dan render template prompt.

Transport bisa berupa:

stdio: frame JSON-RPC dipisahkan newline melalui stdin/stdout.
HTTP streaming: biasanya POST /, sering dengan SSE untuk streaming.

Sebagian besar server lokal memakai stdio. Server remote biasanya memakai HTTP.

Kenapa pengujian penting? Karena bug pada bentuk respons tools/list bisa merusak semua klien sekaligus. Setiap Claude Desktop, Cursor, IDE, atau agen yang memakai server Anda akan membaca kontrak yang sama.

Apa yang perlu diuji

Suite pengujian server MCP yang berguna sebaiknya mencakup enam area.

1. Kesesuaian protokol

Pastikan initialize mengembalikan:

protocolVersion yang benar
capabilities yang sesuai dengan fitur yang benar-benar didukung server

Contoh assertion:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2026-04-01",
    "capabilities": {}
  }
}

Yang perlu dicek pada respons:

$.result.protocolVersion ada
$.result.capabilities ada
tidak ada error JSON-RPC untuk handshake valid

2. Kebenaran schema

Pada tools/list, pastikan setiap tool punya:

name
description
inputSchema

Deskripsi kosong atau terlalu pendek bisa menurunkan kualitas pemilihan tool oleh klien AI. JSON Schema yang salah juga membuat klien gagal membangun form argumen.

3. Perilaku tool

Untuk setiap tools/call, cek:

response berisi content
setiap block punya type
type yang digunakan valid, misalnya text, image, atau resource
error bisnis dikembalikan dengan isError: true, bukan error protokol JSON-RPC

Contoh respons tool yang sehat:

{
  "jsonrpc": "2.0",
  "id": 42,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Weather in Tokyo: 22°C, cloudy"
      }
    ]
  }
}

Contoh error tingkat tool:

{
  "jsonrpc": "2.0",
  "id": 43,
  "result": {
    "isError": true,
    "content": [
      {
        "type": "text",
        "text": "Missing required argument: city"
      }
    ]
  }
}

4. Akses resource

Untuk resource, uji alur lengkap:

panggil resources/list
ambil salah satu URI
panggil resources/read
cek konten yang dikembalikan

Jika server mendukung pagination, uji halaman setelah halaman pertama.

5. Render prompt

Untuk prompt, uji:

prompts/list mengembalikan daftar template
prompts/get mengembalikan array messages
substitusi argumen masuk ke lokasi yang benar

6. Mode kegagalan

Uji kondisi yang biasanya muncul di produksi:

API upstream mati
argumen wajib hilang
tipe argumen salah
timeout
rate limit
respons upstream berubah bentuk

Pengujian manual dengan stdio

Mulai dari setup paling kecil: terminal, server MCP, dan inspector.

Jika belum punya server, buat satu dari quickstart SDK MCP resmi di Python atau TypeScript. Contoh weather server dengan dua tool sudah cukup untuk latihan.

Jalankan server dengan inspector:

npx @modelcontextprotocol/inspector node your-server.js

Inspector akan membuka UI web lokal yang berbicara MCP ke server Anda. Gunakan untuk memverifikasi:

server berhasil start
initialize sukses
capability benar
tools/list menampilkan tool yang diharapkan
tools/call mengembalikan konten valid

Setelah itu, jalankan request mentah via stdio agar Anda bisa menyimpan frame JSON-RPC untuk otomatisasi di Apidog:

echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2026-04-01","capabilities":{}}}' | node your-server.js

Simpan request dan response. Ulangi untuk:

tools/list
tools/call
resources/list
resources/read
prompts/list
prompts/get

Pada akhir langkah ini, Anda akan punya 6–12 pasangan request/response kanonik yang mendefinisikan kontrak wire-level server MCP Anda.

Perhatikan bentuk content block

Hasil tool biasanya berbentuk:

{
  "content": [
    {
      "type": "text",
      "text": "..."
    }
  ]
}

Atau untuk gambar:

{
  "content": [
    {
      "type": "image",
      "data": "...",
      "mimeType": "image/png"
    }
  ]
}

Mencampur beberapa jenis content dalam satu respons diperbolehkan, tetapi klien bisa berbeda dalam cara render-nya.

Pisahkan error tool dan error protokol

Untuk kegagalan eksekusi tool, gunakan hasil normal dengan isError: true.

Jangan memicu error JSON-RPC dari dalam tool kecuali memang terjadi kegagalan protokol. Banyak klien akan memperlakukan error JSON-RPC sebagai masalah koneksi atau protokol, bukan error bisnis.

Dari manual ke otomatis: membangun test suite di Apidog

Pengujian manual bagus untuk menemukan bug awal. Tetapi begitu server punya banyak tool, Anda butuh regression suite.

Polanya:

ambil request/response kanonik dari pengujian manual
simpan setiap request di Apidog
tambahkan assertion
mock API upstream
jalankan suite di CI

1. Buat proyek Apidog untuk server MCP

Buka Apidog, buat proyek baru, lalu atur base URL ke endpoint HTTP server MCP Anda.

Jika server MCP Anda hanya mendukung stdio, jalankan wrapper HTTP tipis untuk testing. Inspector resmi bisa membantu untuk kebutuhan manual. Alternatifnya, buat script Node kecil yang menerima JSON-RPC via HTTP lalu meneruskannya ke proses stdio.

Pola yang sama juga dipakai dalam pengujian API tanpa Postman di tahun 2026 untuk backend non-HTTP.

2. Simpan request kanonik

Simpan satu request untuk setiap method penting:

initialize
tools/list
tools/call
resources/list
resources/read
prompts/list
prompts/get

Contoh body tools/call:

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "city": "Tokyo"
    }
  }
}

Buat beberapa variasi request untuk setiap tool:

happy path
argumen wajib hilang
tipe argumen salah
upstream error

3. Tambahkan assertion

Otomatisasi berguna jika Anda menegaskan bentuk dan isi respons, bukan sekadar mengirim request.

Untuk tools/list, minimal cek:

$.result.tools ada
$.result.tools.length lebih besar dari nol
setiap tool punya name
setiap tool punya description
setiap tool punya inputSchema
setiap inputSchema valid sebagai JSON Schema

Untuk tools/call dengan input valid, cek:

$.result.isError bernilai false atau tidak ada
$.result.content adalah array
$.result.content[0].type ada
konten sesuai ekspektasi

Untuk tools/call dengan input invalid, cek:

$.result.isError bernilai true
$.result.content[0].text cocok dengan pola error yang stabil

Hindari assertion yang terlalu rapuh, misalnya mencocokkan seluruh string error secara persis. Gunakan regex atau kode error stabil jika tersedia.

4. Mock API upstream

Banyak server MCP membungkus API eksternal:

weather API
GitHub
Linear
Notion
database internal
layanan observability

CI sebaiknya tidak memanggil API live di setiap commit. Alasannya:

lambat
rentan rate limit
hasil bisa berubah
butuh credential eksternal
bisa membuat test flaky

Gunakan mock server bawaan Apidog:

definisikan endpoint upstream sebagai mock route
isi respons JSON realistis
arahkan konfigurasi server MCP ke URL mock saat testing
gunakan URL produksi saat runtime nyata

Workflow mock ini juga dibahas dalam pengembangan API contract-first.

Hasilnya: test suite berjalan cepat, deterministik, dan tidak bergantung pada jaringan eksternal.

5. Jalankan suite di CI

Ekspor proyek Apidog ke CLI runner. Perintah apidog run menjalankan request yang tersimpan, mengevaluasi assertion, lalu keluar dengan status non-zero jika ada kegagalan.

Contoh GitHub Actions:

name: MCP server tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22

      - run: npm ci

      - name: Start MCP HTTP wrapper
        run: node test/wrapper.js &

      - name: Run Apidog suite
        run: npx apidog run --project-id $APIDOG_PROJECT --env ci
        env:
          APIDOG_PROJECT: ${{ secrets.APIDOG_PROJECT }}
          APIDOG_TOKEN: ${{ secrets.APIDOG_TOKEN }}

Dengan ini, setiap push menjalankan kontrak MCP. Jika schema tool berubah tanpa sengaja, CI akan gagal sebelum perubahan masuk ke main branch.

Contoh cakupan test yang sehat

Untuk server MCP di Apidog, rencana pengujian biasanya berisi:

1 request initialize dengan assertion capability
1 request tools/list dengan assertion bentuk dan JSON Schema
2–4 request tools/call per tool:
- happy path
- argumen hilang
- tipe tidak valid
- upstream error
1 request resources/list
1 request resources/read per famili resource
1 request prompts/list
1 request prompts/get per template prompt

Untuk server dengan 10 tool, 3 resource, dan 4 prompt, suite bisa berisi 50–70 request. Dengan mock server yang siap, suite seperti ini biasanya cukup cepat untuk dijalankan di CI.

Kesalahan umum saat menguji server MCP

Melewatkan `initialize`

Beberapa server membangun registry tool saat handshake. Jika Anda langsung memanggil tools/list, server bisa crash atau mengembalikan respons tidak lengkap.

Selalu jalankan initialize terlebih dahulu.

Assertion terlalu kaku pada string error

Pesan error bisa berubah. Lebih aman cek:

isError: true
kode error stabil jika ada
regex pada bagian pesan yang penting

Mock menyimpang dari produksi

Mock yang tidak mirip respons asli memberi rasa aman palsu. Rekam ulang fixture mock dari respons nyata secara berkala, terutama sebelum rilis besar.

Tidak menguji streaming

Server MCP HTTP dapat mengalirkan hasil tool melalui SSE. Jika server Anda mendukung streaming, aktifkan mode streaming pada request test dan assert hasil stream yang sudah dirakit.

Tidak menguji concurrency

Klien MCP bisa mengirim beberapa tools/call secara paralel. Jika server menyimpan shared state tanpa kontrol, single-request test bisa lulus sementara produksi gagal.

Tambahkan parallel run test untuk tool yang menyentuh state bersama.

Mencampur error protokol dan error tool

Gunakan error JSON-RPC untuk masalah protokol. Gunakan isError: true untuk kegagalan eksekusi tool. Pemisahan ini penting agar klien seperti Claude Desktop tidak menutup koneksi karena mengira protokol rusak.

Jenis bug kontrak serupa juga dibahas dalam pengembangan platform API contract-first.

Kasus penggunaan dunia nyata

Sebuah tim yang membangun server MCP internal untuk API manajemen insiden menemukan tiga regresi dalam satu minggu dengan assertion Apidog pada bentuk tools/list. Tanpa pengujian kontrak, bug tersebut akan terkirim ke semua engineer yang memakai Claude Desktop.

Seorang pengembang solo yang menerbitkan server MCP open-source untuk Notion memakai mock Apidog agar CI tidak menyentuh rate limit Notion. Suite berjalan di setiap PR, memakan waktu sekitar beberapa detik, dan fixture mock disimpan di repo sehingga kontributor tidak memerlukan akses API.

Sebuah tim platform yang menjalankan 14 server MCP internal membuat workspace Apidog bersama untuk kontrak tiap server. Server baru mewarisi test suite dasar. Reviewer bisa membandingkan perubahan schema sebelum merge. Dua potensi outage tertangkap dari assertion tools/list pada PR yang mengganti nama argumen tool.

Tim lain yang membangun server MCP untuk platform observability internal memakai environment switcher Apidog untuk menjalankan suite yang sama terhadap staging dan production. Environment berbeda menunjuk ke fixture mock berbeda, sementara request dan assertion tetap sama.

Checklist implementasi

Gunakan checklist ini saat menyiapkan pengujian MCP:

[ ] Jalankan server dengan inspector resmi.
[ ] Verifikasi initialize.
[ ] Verifikasi tools/list.
[ ] Simpan request/response JSON-RPC kanonik.
[ ] Buat proyek di Apidog.
[ ] Simpan request initialize, tools/list, tools/call, resources/read, dan prompts/get.
[ ] Tambahkan assertion JSONPath.
[ ] Tambahkan test untuk argumen invalid.
[ ] Mock API upstream.
[ ] Jalankan suite di CI.
[ ] Jalankan smoke test manual di Claude Desktop sebelum rilis.

Kesimpulan

MCP makin mainstream, tetapi praktik pengujiannya masih sering ad hoc dan manual. Cara paling praktis adalah memperlakukan server MCP sebagai API JSON-RPC biasa: definisikan kontrak, simpan request kanonik, mock dependency, dan jalankan assertion di CI.

Poin penting:

Server MCP adalah API JSON-RPC; uji dengan disiplin yang sama seperti REST API.
Mulai dari inspector resmi, lalu simpan request kanonik.
Apidog dapat dipakai untuk JSON-RPC request, assertion, mock, dan CI.
Cakup enam area: protokol, schema, tool behavior, resource, prompt, dan failure mode.
Mock API upstream di Apidog agar suite cepat dan deterministik.

Langkah berikutnya: buka Apidog, buat proyek, tempelkan body request MCP yang Anda tangkap secara manual, tambahkan assertion untuk tools/list, lalu jalankan suite. Dalam waktu singkat, Anda akan tahu apakah kontrak server MCP Anda cukup stabil untuk dikirim.

FAQ

Apa itu MCP?

MCP, atau Model Context Protocol, adalah spesifikasi terbuka Anthropic untuk cara klien AI seperti Claude Desktop memanggil tool, resource, dan prompt eksternal. MCP menggunakan JSON-RPC 2.0 melalui stdio atau HTTP streaming. Spesifikasi MCP tersedia di modelcontextprotocol.io.

Dapatkah saya menguji server MCP tanpa wrapper HTTP?

Ya. Inspector MCP resmi berbicara langsung via stdio dan menyediakan UI untuk pengujian manual.

Untuk otomatisasi di Apidog, bungkus stdio dalam server HTTP tipis selama CI. Traffic produksi tetap bisa memakai stdio.

Bagaimana cara mock API upstream yang dipanggil server MCP?

Definisikan setiap endpoint upstream sebagai mock di proyek Apidog, arahkan konfigurasi server MCP ke URL mock saat test, lalu gunakan URL produksi saat runtime. Pola serupa dibahas dalam alat pengujian API untuk insinyur QA.

Bagaimana dengan streaming hasil tool?

Server MCP HTTP dapat mengalirkan hasil tool melalui Server-Sent Events. Apidog mendukung SSE dalam request yang disimpan. Aktifkan streaming pada pengaturan request, lalu buat assertion pada hasil stream yang sudah dirakit.

Haruskah saya menguji versi protokol?

Ya. Sematkan protocolVersion yang Anda dukung di initialize, lalu assert nilainya. Ketidakcocokan versi bisa menyebabkan incompatibility yang sulit terlihat.

Dapatkah saya menguji server MCP terhadap Claude Desktop asli?

Bisa, dan sebaiknya dilakukan minimal sekali sebelum rilis. Namun jangan jadikan Claude Desktop sebagai loop pengujian utama. Itu lambat, manual, dan tidak deterministik. Gunakan Apidog untuk regression suite dan Claude Desktop untuk smoke test.

Di mana saya bisa melihat contoh server MCP nyata?

Repositori server MCP resmi berisi implementasi referensi untuk filesystem, GitHub, Slack, Postgres, dan banyak lainnya. Baca definisi tool-nya untuk memahami bentuk MCP yang baik.

Apa Itu Maigret: Pemindai OSINT yang Tidak Merusak

Walse — Mon, 11 May 2026 06:13:45 +0000

Sebagian besar alat OSINT cepat usang: endpoint berubah, captcha berevolusi, dan halaman profil didesain ulang. Maigret adalah pengecualian yang menarik untuk dipelajari developer. Alat ini berjalan selama bertahun-tahun, mendukung 3.000+ situs, tersedia sebagai paket Python, bot Telegram, dan antarmuka web, serta menunjukkan pola engineering yang relevan untuk membangun scanner dan test suite yang tahan terhadap perubahan.

Coba Apidog hari ini

Panduan ini fokus pada implementasi: bagaimana Maigret bekerja, kapan penggunaannya sah, arsitektur yang membuatnya skalabel, dan bagaimana pola yang sama—signature database, recursive verification, drift detection—bisa diterapkan pada pengujian API dengan Apidog.

Jika Anda belum membacanya, lihat juga artikel Pengujian API tanpa Postman di tahun 2026, yang membahas pattern matching dan drift detection dalam konteks API testing.

TL;DR

Maigret mencari akun publik berdasarkan username di 3.000+ situs dan mengekstrak informasi profil publik.
Arsitekturnya berbasis signature database, recursive search, drift detection, captcha/rate-limit handling, dan mode ringkasan AI opsional.
Penggunaan yang sah: investigasi OSINT oleh jurnalis, pemulihan akun pribadi, pencarian orang hilang dengan otorisasi, audit keamanan, dan monitoring penyalahgunaan merek.
Penggunaan terhadap individu tanpa persetujuan dapat masuk ke ranah pelecehan, stalking, atau pelanggaran hukum.
Pattern yang dipakai Maigret bisa diterapkan langsung ke API testing: multi-signal assertion, contract replay, fixture validasi, dan alert saat schema berubah.
Apidog dapat digunakan untuk mendesain dan menjalankan assertion bergaya signature terhadap API Anda.

Apa itu Maigret dan Apa Bukan

Maigret adalah tool Python berlisensi MIT yang dikelola oleh soxoj. Berdasarkan README-nya, Maigret “mengumpulkan berkas tentang seseorang berdasarkan username dari lebih dari 3.000 situs”.

Instalasi dasar:

pip install maigret

Contoh penggunaan:

maigret some_username

Maigret akan:

Membaca database situs.
Membentuk URL profil berdasarkan template tiap situs.
Mengirim request anonim.
Mendeteksi apakah username ditemukan.
Mengekstrak informasi profil publik.
Membuat laporan.

Ada tiga batasan penting.

Pertama, Maigret hanya memakai data publik. Tidak ada login, credential abuse, atau private API key. Jika profil bisa dibaca pengunjung anonim, Maigret membacanya. Jika tidak, hasilnya akan berupa “tidak ditemukan”, “unknown”, atau halaman yang ditandai untuk verifikasi manual.

Kedua, Maigret umum dipakai dalam konteks riset yang sah: jurnalisme investigatif, pencarian orang hilang, fraud prevention, brand protection, dan red team engagement yang memiliki otorisasi tertulis.

Ketiga, Maigret bisa disalahgunakan. Menjalankannya terhadap individu pribadi tanpa persetujuan dapat melanggar etika dan hukum. Artikel ini membahas engineering pattern-nya, bukan workflow untuk menargetkan manusia.

Basis Data Signature Situs

Komponen paling penting di Maigret adalah database signature situs. Setiap entri menjelaskan bagaimana satu situs harus diperiksa.

Sebuah signature menjawab pertanyaan berikut:

Bagaimana membentuk URL profil?
Apa indikator bahwa username ditemukan?
Apa indikator bahwa username tidak ditemukan?
Field apa yang bisa diekstrak?
Apakah situs memakai rate limit atau captcha?
Header khusus apa yang dibutuhkan?

Secara konseptual, satu entri bisa terlihat seperti ini:

{
  "name": "ExampleSite",
  "urlMain": "https://example.com",
  "url": "https://example.com/user/{username}",
  "presenseStrs": ["Profile", "@{username}"],
  "absenceStrs": ["User not found", "This profile does not exist"],
  "headers": {
    "User-Agent": "Mozilla/5.0"
  },
  "tags": ["social", "global"]
}

Database ini disimpan sebagai JSON, di-versioning di repository, dan dapat diperbarui otomatis dari GitHub setiap 24 jam. Jadi ketika maintainer memperbaiki signature untuk situs yang berubah, instalasi Maigret lain bisa mengambil update tanpa reinstall.

Pattern ini sama dengan API testing yang baik.

Untuk setiap endpoint, Anda seharusnya punya “signature”:

Method dan path
Expected status code
Required response fields
Error envelope
Header penting
Schema response
Fixture response yang diketahui benar

Contoh signature endpoint:

{
  "endpoint": "GET /users/{id}",
  "expectedStatus": 200,
  "requiredFields": ["id", "email", "created_at"],
  "forbiddenFields": ["password", "token"],
  "contentType": "application/json"
}

Jika vendor mengubah response shape, test suite harus gagal cepat dengan diff yang jelas. Pattern ini juga dibahas dalam pengembangan API berorientasi kontrak dan panduan pengujian server MCP.

Cara Maigret Mendeteksi “Username Ditemukan” vs “Tidak Ditemukan”

Scanner naïf biasanya hanya melakukan:

GET https://example.com/user/<username>

Lalu mengecek status code.

Masalahnya, banyak situs tetap mengembalikan 200 OK untuk halaman “user not found”, halaman fallback, cached page, atau captcha challenge. Karena itu, Maigret memakai deteksi multi-sinyal.

Signature situs dapat berisi:

urlMain
url
presenseStrs
absenceStrs
Regex ekstraksi username atau field lain
Header opsional
Tag kategori atau negara

Logika sederhananya:

def detect(response_text, presence_strs, absence_strs):
    has_presence = all(s in response_text for s in presence_strs)
    has_absence = any(s in response_text for s in absence_strs)

    if has_presence and not has_absence:
        return "found"

    if has_absence:
        return "not_found"

    return "unknown"

Ini juga pattern yang dibutuhkan dalam API testing.

Status 200 saja tidak cukup. Untuk API, Anda perlu assertion seperti:

pm.test("status code is 200", function () {
  pm.response.to.have.status(200);
});

pm.test("response has required fields", function () {
  const json = pm.response.json();

  pm.expect(json).to.have.property("id");
  pm.expect(json).to.have.property("email");
  pm.expect(json).to.not.have.property("password");
});

Di Apidog, pattern yang sama bisa dibuat dengan assertion status code, body field, header, dan schema dalam satu request. Ini ekuivalen dengan kombinasi presenseStrs dan absenceStrs di Maigret.

Recursive Search dan Ekstraksi Informasi

Setelah akun ditemukan, Maigret melakukan dua hal:

Mengekstrak identifier publik tambahan.
Memakai identifier baru itu untuk pencarian lanjutan.

Contoh identifier:

Email publik
Nomor telepon publik
Nama asli
Username lain
Link ke profil lain

Alurnya:

username
  -> profile ditemukan
    -> ekstrak email
      -> cari email/username terkait
        -> temukan profil lain
          -> ekstrak identifier baru

Untuk OSINT, ini membedakan “menemukan satu akun” dari “memetakan beberapa akun yang saling terhubung”.

Untuk API testing, pattern-nya juga berguna. Jika satu endpoint mengembalikan field yang tidak terdokumentasi, field itu sering mengarah ke:

Endpoint terkait
Service downstream
Model internal
Kasus uji yang belum ada
Breaking change yang belum dikomunikasikan

Contoh:

{
  "id": "usr_123",
  "email": "dev@example.com",
  "billing_profile_id": "bp_456"
}

Jika billing_profile_id tidak ada di kontrak, itu sinyal untuk:

Menambahkan assertion schema.
Mengecek endpoint billing terkait.
Menanyakan apakah field tersebut stabil atau internal.
Membuat regression test agar perubahan berikutnya terdeteksi.

Captcha dan Rate Limit Handling

Maigret tidak mencoba “mengalahkan” semua mekanisme anti-otomasi. Ia mendeteksi captcha dan rate limit dari bentuk response, lalu menyesuaikan strategi.

Strategi yang disebutkan meliputi:

Rotasi user-agent
Menghormati header retry
Fallback ke domain mobile atau lightweight jika tersedia
Routing via Tor atau I2P jika situs mengizinkan

Jika situs memakai anti-automation yang agresif, Maigret menandai kondisi tersebut sebagai captcha atau unknown dan menyerahkan verifikasi ke pengguna.

Pattern ini penting untuk API client dan test runner.

Jangan brute-force rate limit. Deteksi dan mundur dengan benar.

Contoh handling 429 Too Many Requests:

async function requestWithBackoff(fetchFn, maxRetries = 3) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetchFn();

    if (response.status !== 429) {
      return response;
    }

    const retryAfter = Number(response.headers.get("retry-after") || 1);
    await new Promise(resolve => setTimeout(resolve, retryAfter * 1000));
  }

  throw new Error("Rate limit exceeded after retries");
}

Prinsipnya sama: test runner harus menghormati batas sistem, bukan memaksa melewatinya.

Masalah Signature Drift

Database 3.000 situs hanya berguna jika tetap mutakhir. Situs bisa:

Mengubah URL profil
Mendesain ulang halaman
Mengganti teks “not found”
Menambahkan captcha
Melakukan rebrand
Mengubah struktur HTML

Signature usang menyebabkan:

False negative: akun ada, tetapi tidak terdeteksi.
False positive: akun tidak ada, tetapi dianggap ditemukan.
Unknown result yang terlalu banyak.

Maigret mengurangi drift dengan beberapa lapisan:

Update otomatis dari repository GitHub pusat setiap 24 jam.
Pull request komunitas untuk memperbaiki signature.
Flag --update untuk memaksa refresh.
Test harness bawaan untuk memvalidasi signature terhadap username yang diketahui ada.

Contoh:

maigret --update some_username

Bagian paling penting adalah fixture validasi. Untuk setiap situs, Maigret dapat memakai username yang diketahui valid. Harness mengecek apakah signature masih berhasil mendeteksi akun tersebut. Jika gagal, signature ditandai drift.

Ini persis yang dibutuhkan API contract testing.

Di Apidog, Anda bisa menerapkan pattern berikut:

Simpan response yang diketahui benar untuk endpoint penting.
Jalankan ulang request secara berkala.
Bandingkan status code, schema, field wajib, dan response body penting.
Kirim alert jika ada drift.

Alur manual untuk vendor tertentu juga dibahas di Panduan API DeepSeek V4.

Mode Ringkasan AI Opsional

Flag --ai di Maigret mengubah temuan mentah menjadi ringkasan investigasi singkat menggunakan endpoint LLM yang kompatibel dengan OpenAI. Pengguna menyediakan API key sendiri.

Arsitekturnya tepat karena:

Rule deterministik tetap menentukan apakah username cocok.
LLM tidak menjadi hakim utama.
LLM hanya meringkas output yang sudah dibatasi.
Risiko halusinasi lebih terkendali.

Pattern yang sama bagus untuk API monitoring:

deterministic assertions
  -> execution report
    -> LLM summarization
      -> Slack-friendly summary

Gunakan rule engine untuk menentukan pass/fail. Gunakan LLM hanya untuk membuat laporan lebih mudah dibaca.

Pendekatan ini sejalan dengan artikel penggunaan komputer vs API terstruktur: lapisan terstruktur harus didahulukan.

Kasus Penggunaan Sah

Berikut konteks di mana Maigret dapat digunakan secara tepat.

1. Pemulihan akun pribadi

Gunakan Maigret pada username milik Anda sendiri untuk menemukan akun lama sebelum audit privasi atau penghapusan jejak digital.

maigret your_old_username

2. Monitoring penyalahgunaan merek

Perusahaan dapat menjalankan pencarian terhadap nama brand atau produk untuk menemukan akun peniru.

Contoh target:

companyname
company_support
company-login

3. Pencarian orang hilang dengan otorisasi

Organisasi pencarian dan penyelamatan dapat memakai OSINT dengan persetujuan keluarga dan koordinasi penegak hukum. Jangan bekerja sendiri tanpa koordinasi karena dapat mengganggu investigasi.

4. Red team engagement yang berwenang

Tim pentest dapat memakai Maigret untuk memetakan public attack surface organisasi dalam scope kontrak tertulis.

Scope harus jelas:

Allowed:
- company-owned domains
- public brand usernames
- employee accounts explicitly included in scope

Not allowed:
- private individuals outside scope
- unrelated third-party accounts

5. Jurnalisme investigatif

Reporter dapat memakai OSINT untuk meneliti penipuan, pelanggaran figur publik, atau kejahatan terorganisir dengan tinjauan editorial dan hukum.

Yang tidak termasuk penggunaan sah: mencari orang asing karena penasaran, memantau mantan pasangan, atau membangun dataset orang tanpa persetujuan.

Pattern Maigret yang Bisa Diterapkan ke API Testing

Ada lima pattern engineering yang langsung bisa dipakai.

1. Simpan perilaku sebagai data, bukan kode

Alih-alih hard-code assertion di banyak file, definisikan expected behavior sebagai data.

{
  "name": "Get user profile",
  "method": "GET",
  "path": "/users/{id}",
  "expected": {
    "status": 200,
    "requiredFields": ["id", "email"],
    "forbiddenFields": ["password"]
  }
}

2. Gunakan multi-signal assertion

Jangan hanya mengecek status code.

Minimal cek:

Status code
Content-Type
Required fields
Forbidden fields
Error envelope
Response schema

3. Sinkronkan signature secara terpusat

Maigret mengambil signature dari repository pusat. Untuk API testing, gunakan project yang tersinkronisasi agar assertion terbaru dipakai semua environment.

Apidog mendukung workflow berbasis cloud. Lihat juga pengujian API tanpa Postman.

4. Jadwalkan drift detection

Jalankan ulang test terhadap fixture yang diketahui benar.

Contoh jadwal:

name: API drift check

on:
  schedule:
    - cron: "0 */6 * * *"

jobs:
  drift-check:
    runs-on: ubuntu-latest
    steps:
      - name: Run API contract tests
        run: echo "Run Apidog/API test collection here"

Tujuannya bukan hanya mencari bug, tetapi mendeteksi perubahan kontrak sebelum pengguna terdampak.

5. Pakai LLM sebagai post-processor

Jangan gunakan LLM untuk menentukan pass/fail. Gunakan rule deterministik untuk itu.

Gunakan LLM untuk merangkum:

12 endpoint failed.
Primary cause: missing field `billing_profile_id`.
First detected in staging at 02:14 UTC.
Likely impacted services: billing, checkout, account dashboard.

Kesalahan Umum Saat Menjalankan Maigret

Jika Anda bereksperimen dengan Maigret, hindari kesalahan berikut.

Menganggap default scan sudah lengkap

Default Maigret memindai subset situs populer. Untuk memindai database penuh, gunakan:

maigret -a username

Perhatikan bahwa proses akan lebih lama.

Mengabaikan tag

Gunakan --tags untuk membatasi kategori atau negara.

maigret username --tags social

Default yang terlalu umum bisa melewatkan situs regional.

Tidak memperbarui database

Signature lama menghasilkan false positive dan false negative.

maigret --update username

Menafsirkan blokir Tor sebagai sinyal user

Beberapa situs memblokir Tor exit node. Itu bukan bukti bahwa username tidak ada. Perlakukan hasil seperti ini sebagai unknown.

Mempercayai hasil ekstraksi tanpa verifikasi

Maigret mengekstrak apa yang ada di halaman publik. Halaman bisa salah, lama, atau sengaja dimanipulasi. Perlakukan hasil sebagai petunjuk, bukan bukti final.

Kasus Penggunaan Dunia Nyata

Konsultan keamanan memakai Maigret sebagai langkah awal dalam red team engagement yang memiliki scope jelas. Output-nya masuk ke laporan awal agar klien melihat public attack surface sebelum assessment dimulai.

Investigator fraud dapat memakai flag --ai untuk meringkas hasil scan besar menjadi laporan pendek untuk klien non-teknis. Data tetap berasal dari pencarian deterministik; LLM hanya membuat ringkasan.

Tim engineering dapat mengadopsi arsitektur yang sama—signature database, drift detection, scheduled replay—untuk menjaga API test suite tetap relevan di ratusan microservice. Implementasinya bisa dilakukan di Apidog; prinsipnya sama dengan Maigret.

Kesimpulan

Maigret adalah contoh bagus tentang cara membangun scanner yang bertahan lama: bukan dengan hard-code logic per situs, tetapi dengan signature database, multi-signal detection, update otomatis, drift detection, dan post-processing yang terpisah.

Lima poin utama:

Maigret memeriksa 3.000+ situs memakai signature database yang di-versioning.
Multi-signal detection lebih andal daripada status code saja.
Drift adalah musuh semua test suite jangka panjang.
LLM paling aman dipakai sebagai post-processor, bukan hakim pass/fail.
Pattern yang sama bisa diterapkan ke API testing di Apidog.

Langkah praktis berikutnya: ambil satu endpoint penting di proyek Anda, lalu desain seperti signature Maigret:

{
  "endpoint": "GET /orders/{id}",
  "expectedStatus": 200,
  "requiredFields": ["id", "status", "total", "created_at"],
  "forbiddenFields": ["internal_note"],
  "driftFixture": "order_known_good.json"
}

Simpan fixture, jalankan ulang secara berkala, dan buat alert saat response berubah. Disiplin ini akan berguna saat vendor mengganti nama field pada jam 2 pagi dan test suite Anda mendeteksinya sebelum user terdampak.

FAQ

Apakah Maigret legal untuk digunakan?

Tergantung yurisdiksi dan target. Menjalankannya pada diri sendiri, akun milik Anda, perusahaan yang memberi otorisasi tertulis, atau dalam jurnalisme yang sah umumnya dapat diterima. Menjalankannya pada individu tanpa persetujuan dapat melanggar hukum stalking atau pelecehan. Periksa aturan lokal sebelum penggunaan terhadap pihak ketiga.

Apakah Maigret bisa dipakai tanpa Python?

Paket resminya membutuhkan Python 3.10+. Penulis juga menyediakan bot Telegram dan setup Cloud Shell untuk pengguna yang tidak ingin instalasi lokal.

Seberapa akurat klaim 3.000 situs?

Repository Maigret berisi 3.000+ entri situs, tetapi tidak semuanya aktif setiap saat. Update otomatis dan kontribusi komunitas membantu menjaga subset yang berfungsi tetap mutakhir.

Apa fungsi mode AI?

Flag --ai memakai LLM kompatibel OpenAI untuk meringkas temuan deterministik menjadi laporan yang mudah dibaca. Mode ini tidak mengubah proses pencarian. Anda perlu menyediakan API key sendiri.

Bisakah Maigret dipakai di CI?

Untuk investigasi OSINT, biasanya tidak ideal karena sifatnya interaktif dan bergantung konteks. Namun pattern arsitekturnya—signature database, drift detection, scheduled replay—sangat cocok untuk pipeline CI API testing. Apidog mendukung workflow semacam ini.

Apa bedanya Maigret dengan Sherlock?

Sherlock adalah tool yang lebih tua dan lebih sederhana. Maigret memperluasnya dengan ekstraksi informasi, recursive search, captcha handling, mode ringkasan AI, dan database situs yang lebih kaya. Keduanya berlisensi MIT.

Di mana melaporkan signature yang usang?

README Maigret mengarahkan pengguna ke issue dan pull request di repository GitHub. Kontribusi komunitas menjaga database tetap relevan; biasanya satu PR untuk satu situs yang perlu diperbaiki.

Cara Mengatasi Error 'Invalid custom3p enterprise config' di Claude Code

Walse — Mon, 11 May 2026 03:34:34 +0000

Jika Anda mengarahkan Claude Code ke DeepSeek V4, OpenRouter, LiteLLM, vLLM, atau penyedia model pihak ketiga lain, error ini mungkin muncul: Invalid custom3p enterprise config. Artinya Claude Code gagal memvalidasi konfigurasi provider non-Anthropic sebelum request pertama dikirim.

Coba Apidog hari ini

Panduan ini menjelaskan arti custom3p, penyebab umum error tersebut, dan langkah implementasi untuk memperbaikinya. Fokusnya: konfigurasi Claude Code dengan gateway LLM seperti OpenRouter, LiteLLM, DeepSeek, atau vLLM lokal.

TL;DR

Invalid custom3p enterprise config berarti Claude Code tidak bisa memvalidasi konfigurasi penyedia pihak ketiga.

custom3p adalah label internal Claude Code untuk endpoint API non-Anthropic yang dikonfigurasi lewat:

ANTHROPIC_BASE_URL

Penyebab paling umum:

ANTHROPIC_BASE_URL memakai trailing /v1
Salah memilih ANTHROPIC_AUTH_TOKEN vs ANTHROPIC_API_KEY
~/.claude/settings.json tidak valid
Instalasi baru belum menyelesaikan onboarding
Gateway tidak meneruskan header yang dibutuhkan
Ada konflik kebijakan enterprise/managed settings

Mulai dari URL dulu. Menghapus trailing /v1 biasanya menyelesaikan sebagian besar kasus.

Apa arti sebenarnya `custom3p`

Claude Code merutekan request melalui beberapa mode:

Mode	Cara terpicu
API Anthropic default	Tidak ada override
Amazon Bedrock	`CLAUDE_CODE_USE_BEDROCK=1`
Google Vertex AI	`CLAUDE_CODE_USE_VERTEX=1`
Microsoft Foundry	`CLAUDE_CODE_USE_FOUNDRY=1`
Pihak ketiga kustom	`ANTHROPIC_BASE_URL` menunjuk ke endpoint lain

Mode terakhir adalah custom3p, singkatan dari custom third-party provider.

Saat Anda mengatur ANTHROPIC_BASE_URL ke host non-Anthropic seperti LiteLLM, OpenRouter, vLLM lokal, atau gateway internal perusahaan, Claude Code menjalankan validasi konfigurasi sebelum API call pertama.

Jika validasi gagal, Anda mendapatkan:

Invalid custom3p enterprise config

Ini adalah error konfigurasi, bukan pemblokiran kebijakan. Jadi biasanya bisa diperbaiki dari sisi environment, JSON config, atau gateway.

Mengapa banyak developer mengalami error ini

Pada April 2026, Anthropic memblokir akses langganan Claude Pro dan Max untuk alat agen pihak ketiga yang memalsukan ID klien Claude Code. Tool seperti OpenClaw yang merutekan sesi Claude Code melalui backend mereka sendiri berhenti berfungsi.

Itu masalah berbeda.

Yang dibahas di sini adalah penggunaan dukungan provider pihak ketiga resmi Claude Code. Banyak developer mulai merutekan Claude Code melalui backend yang lebih murah, misalnya DeepSeek V4 Pro melalui OpenRouter. Thread komunitas juga membahas biaya sekitar $0.87 per juta token output dibandingkan $15 dari Anthropic. Proyek seperti DeepClaude mengemas setup ini menjadi satu perintah.

Masalahnya: dukungan resmi ini tetap membutuhkan konfigurasi enterprise/custom provider yang valid. Satu field salah bisa memicu Invalid custom3p enterprise config.

Penyebab 1: trailing `/v1` di `ANTHROPIC_BASE_URL`

Ini penyebab paling sering.

Claude Code otomatis menambahkan path:

/v1/messages

ke URL dasar yang Anda set.

Jika Anda sudah memasukkan /v1 di ANTHROPIC_BASE_URL, path akhirnya menjadi:

/v1/v1/messages

Hasilnya biasanya 404.

Salah

export ANTHROPIC_BASE_URL="https://api.openrouter.ai/api/v1"

export ANTHROPIC_BASE_URL="https://litellm.yourcompany.com/v1"

Benar

export ANTHROPIC_BASE_URL="https://api.openrouter.ai/api"

export ANTHROPIC_BASE_URL="https://litellm.yourcompany.com"

Verifikasi endpoint

Jalankan test berikut:

curl -s -o /dev/null -w "%{http_code}" \
  -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
  "${ANTHROPIC_BASE_URL}/v1/messages" \
  -d '{"model":"claude-sonnet-4-6","max_tokens":1,"messages":[{"role":"user","content":"hi"}]}'

Interpretasi hasil:

Status	Arti
`200`	Endpoint benar dan request diterima
`400`	Endpoint ada, body/header mungkin belum tepat
`404`	URL salah, biasanya karena `/v1` dobel
`401` / `403`	Masalah autentikasi

Penyebab 2: variabel kredensial salah

Claude Code memakai dua variabel autentikasi berbeda:

Variabel	Header yang dikirim	Cocok untuk
`ANTHROPIC_API_KEY`	`x-api-key`	Gateway format Anthropic yang memakai API key
`ANTHROPIC_AUTH_TOKEN`	`Authorization: Bearer`	OpenRouter, LiteLLM, gateway OAuth/bearer token

Jika gateway mengharapkan bearer token tetapi Anda memakai ANTHROPIC_API_KEY, request akan gagal walaupun key-nya benar.

OpenRouter

OpenRouter biasanya memakai bearer token:

export ANTHROPIC_AUTH_TOKEN="sk-or-kunci-openrouter-anda"
export ANTHROPIC_BASE_URL="https://openrouter.ai/api"

Jangan gunakan ini untuk OpenRouter jika gateway Anda mengharapkan bearer token:

export ANTHROPIC_API_KEY="sk-or-kunci-openrouter-anda"

Karena Claude Code akan mengirim header:

x-api-key: sk-or-kunci-openrouter-anda

bukan:

Authorization: Bearer sk-or-kunci-openrouter-anda

LiteLLM

export ANTHROPIC_AUTH_TOKEN="sk-litellm-kunci-virtual-anda"
export ANTHROPIC_BASE_URL="https://server-litellm-anda:4000"

Gateway DeepSeek atau vLLM lokal dengan API key

export ANTHROPIC_API_KEY="kunci-anda-di-sini"
export ANTHROPIC_BASE_URL="https://server-vllm-anda"

Selalu cek dokumentasi gateway untuk memastikan header autentikasi yang diharapkan.

Penyebab 3: `settings.json` salah format

Jika konfigurasi disimpan di:

~/.claude/settings.json

Claude Code harus bisa membaca JSON tersebut sebelum menjalankan validasi provider.

Salah: trailing comma

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "sk-or-kunci-anda",
  }
}

JSON tidak mengizinkan koma terakhir.

Salah: smart quotes

{
  "env": {
    “ANTHROPIC_BASE_URL”: “https://openrouter.ai/api”
  }
}

Gunakan tanda kutip biasa:

bukan smart quotes.

Benar

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "sk-or-kunci-openrouter-anda"
  }
}

Validasi file JSON

Dengan Python:

python3 -c "import json, os; json.load(open(os.path.expanduser('~/.claude/settings.json')))" && echo "JSON valid"

Dengan jq:

jq . ~/.claude/settings.json

Jika parsing gagal, Claude Code tidak akan sampai ke tahap request API.

Penyebab 4: instalasi baru belum menyelesaikan onboarding

Claude Code mengecek:

~/.claude.json

dan mencari flag:

"hasCompletedOnboarding": true

Pada instalasi baru, flag ini bisa belum ada. Akibatnya Claude Code masuk mode onboarding dan tidak membaca konfigurasi custom provider dari settings.json.

Cek status onboarding

cat ~/.claude.json | python3 -m json.tool 2>/dev/null | grep hasCompletedOnboarding

Jika key tidak ada atau bernilai false, tambahkan konfigurasi berikut.

Perbaikan

Edit ~/.claude.json:

{
  "hasCompletedOnboarding": true,
  "primaryApiKey": "sk-placeholder"
}

primaryApiKey hanya placeholder. Nilainya akan digantikan konfigurasi provider Anda. Gunakan nilai yang diawali sk- agar lolos validasi format.

Setelah itu restart Claude Code.

Penyebab 5: gateway tidak meneruskan header yang dibutuhkan

Claude Code melakukan handshake fitur dengan mengirim beberapa header ke gateway.

Header penting yang sebaiknya diteruskan:

anthropic-beta
anthropic-version
X-Claude-Code-Session-Id

Jika gateway menghapus header ini, respons yang diterima Claude Code bisa tidak sesuai ekspektasi dan memicu:

Invalid custom3p enterprise config

Contoh konfigurasi nginx

location /v1/ {
  proxy_pass http://backend;
  proxy_set_header anthropic-beta $http_anthropic_beta;
  proxy_set_header anthropic-version $http_anthropic_version;
  proxy_set_header X-Claude-Code-Session-Id $http_x_claude_code_session_id;
}

Untuk LiteLLM, penerusan header ini berfungsi secara default sejak v1.82.9+.

Jika gateway tidak bisa meneruskan header beta

Set variabel ini sebelum menjalankan Claude Code:

export CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1

Ini meminta Claude Code melewati fitur yang membutuhkan header beta. Loop agen inti tetap berjalan, tetapi beberapa fitur eksperimental tidak tersedia.

Penyebab 6: konflik kebijakan enterprise

Jika Anda memakai paket Team atau Enterprise Claude, admin bisa menerapkan managed settings yang mengalahkan konfigurasi lokal.

Managed settings dapat membatasi:

availableModels
URL dasar kustom
provider tertentu
konfigurasi environment

Cek apakah managed settings aktif:

ls ~/.claude/managed-settings.json 2>/dev/null && echo "Pengaturan terkelola ditemukan"

Atau dari dalam Claude Code:

/status

Jika managed settings aktif, minta admin untuk:

menambahkan domain gateway ke daftar URL yang diizinkan
menambahkan ID model gateway ke availableModels
memberi pengecualian untuk custom base URL

Untuk deployment yang Anda kontrol, file managed settings biasanya berada di:

/Library/Application Support/ClaudeCode/managed-settings.json

di macOS, atau path setara di Windows/Linux.

Konfigurasi kerja lengkap

Claude Code + OpenRouter + DeepSeek V4 Pro

Gunakan konfigurasi ini di:

~/.claude/settings.json

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "sk-or-kunci-openrouter-anda",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "deepseek/deepseek-v4-pro",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "deepseek/deepseek-v4-pro",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "deepseek/deepseek-v4-pro"
  }
}

Override model diperlukan karena Claude Code default-nya tetap mengirim model seperti:

claude-sonnet-4-6

meskipun Anda sudah mengubah ANTHROPIC_BASE_URL.

Tanpa override model, request bisa tetap meminta model Claude di OpenRouter, atau dirutekan tidak sesuai ekspektasi.

Catatan kompatibilitas: OpenRouter belum sepenuhnya mengimplementasikan semua detail streaming Anthropic untuk tool call. Pada beberapa kasus tepi, argumen function call bisa kosong. Loop agen utama tetap berjalan, tetapi chain multi-tool kompleks dapat bermasalah. Pantau status kompatibilitas OpenRouter untuk pembaruan.

Claude Code + LiteLLM

LiteLLM cocok jika Anda ingin gateway yang menangani routing model lintas provider.

Contoh config.yaml LiteLLM:

model_list:
  - model_name: claude-sonnet-4-6
    litellm_params:
      model: deepseek/deepseek-v4
      api_key: "sk-kunci-deepseek-anda"
  - model_name: claude-opus-4-7
    litellm_params:
      model: deepseek/deepseek-v4-pro
      api_key: "sk-kunci-deepseek-anda"

Konfigurasi Claude Code di ~/.claude/settings.json:

{
  "env": {
    "ANTHROPIC_BASE_URL": "http://localhost:4000",
    "ANTHROPIC_AUTH_TOKEN": "sk-litellm-kunci-anda"
  }
}

Dengan setup ini, Claude Code tetap mengirim:

claude-sonnet-4-6

Lalu LiteLLM memetakan model tersebut ke DeepSeek V4. Anda tidak perlu override nama model di Claude Code.

Claude Code + vLLM lokal

Untuk inferensi lokal dengan vLLM, jalankan server terlebih dahulu:

python -m vllm.entrypoints.openai.api_server \
  --model deepseek-ai/DeepSeek-V3 \
  --dtype auto \
  --api-key local-key \
  --port 8000

Lalu konfigurasi Claude Code:

export ANTHROPIC_BASE_URL="http://localhost:8000"
export ANTHROPIC_API_KEY="local-key"
export ANTHROPIC_DEFAULT_SONNET_MODEL="deepseek-ai/DeepSeek-V3"

Checklist debugging

Jika error masih muncul, gunakan urutan ini.

1. Cek environment aktif

env | grep -E 'ANTHROPIC|CLAUDE'

Pastikan tidak ada konfigurasi lama yang tertinggal, terutama:

ANTHROPIC_BASE_URL
ANTHROPIC_API_KEY
ANTHROPIC_AUTH_TOKEN
ANTHROPIC_DEFAULT_SONNET_MODEL

2. Cek URL final

echo "${ANTHROPIC_BASE_URL}/v1/messages"

Pastikan tidak menjadi:

/v1/v1/messages

3. Jalankan Claude Code dengan debug log

claude --debug 2>&1 | head -100

Cari bagian:

Sending request to:
Response status:
enterprise config error:

Ini biasanya menunjukkan apakah masalah ada di URL, header, auth, atau body request.

4. Replikasi request dengan curl

curl -v -X POST "${ANTHROPIC_BASE_URL}/v1/messages" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${ANTHROPIC_AUTH_TOKEN}" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: max-tokens-3-5-sonnet-2024-07-15" \
  -d '{
    "model": "claude-sonnet-4-6",
    "max_tokens": 10,
    "messages": [{"role": "user", "content": "hi"}]
  }'

Jika gateway memakai x-api-key, gunakan:

curl -v -X POST "${ANTHROPIC_BASE_URL}/v1/messages" \
  -H "Content-Type: application/json" \
  -H "x-api-key: ${ANTHROPIC_API_KEY}" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-sonnet-4-6",
    "max_tokens": 10,
    "messages": [{"role": "user", "content": "hi"}]
  }'

Interpretasi:

Status	Kemungkinan penyebab
`200`	Gateway valid
`400` / `422`	Body atau model tidak sesuai
`401`	Token/key salah
`403`	Akses ditolak
`404`	URL/path salah
`5xx`	Masalah gateway/backend

Menguji API dengan Apidog

Saat melakukan debug integrasi provider pihak ketiga, Apidog membantu Anda menguji request dan response gateway LLM tanpa harus menjalankan Claude Code berulang kali.

Buat collection untuk endpoint:

/v1/messages

Lalu simpan header sebagai variable tingkat collection:

anthropic-version
anthropic-beta
Authorization
x-api-key

Dengan begitu, Anda bisa mengganti gateway, token, atau model dari satu tempat.

Ini berguna untuk memastikan apakah gateway meneruskan header seperti:

anthropic-beta
anthropic-version
X-Claude-Code-Session-Id

sebelum Anda mencari masalah di konfigurasi Claude Code.

Konfigurasi Claude Code terkait

Nonaktifkan dependency header beta

Jika gateway enterprise Anda tidak bisa meneruskan custom header:

export CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1

Efeknya:

validasi lebih sederhana
loop agen tetap berjalan
beberapa fitur eksperimental tidak tersedia

Aktifkan discovery model gateway

Mulai Claude Code v2.1.129, Anda bisa meminta Claude Code mengambil daftar model dari gateway:

export CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1

Claude Code akan memanggil:

/v1/models

Namun hanya model dengan ID yang diawali claude atau anthropic yang otomatis masuk ke pemilih /model.

Untuk model seperti DeepSeek, set manual:

export ANTHROPIC_DEFAULT_SONNET_MODEL="deepseek/deepseek-v4-pro"

Tambahkan opsi model kustom

Untuk menambahkan satu model ke pemilih /model:

export ANTHROPIC_CUSTOM_MODEL_OPTION="deepseek/deepseek-v4-pro"
export ANTHROPIC_CUSTOM_MODEL_OPTION_NAME="DeepSeek V4 Pro"
export ANTHROPIC_CUSTOM_MODEL_OPTION_DESCRIPTION="17x lebih murah dari Claude Opus"

Model akan muncul di bagian bawah selector /model.

Panduan terkait

Jika Anda mengeksplorasi Claude Code dengan backend model kustom, baca juga:

Cara Menulis File AGENTS.md untuk Tim Pengembangan API — konfigurasikan perilaku Claude Code untuk stack Anda
Ruflo: Orkestrasi Multi-Agen untuk Claude Code — tambahkan swarm, memori persisten, dan 100+ tool MCP ke Claude Code
Dapatkan API Claude Gratis Tanpa Batas melalui Puter.js — alternatif berbasis browser jika Anda membangun aplikasi klien
LLM Lokal Terbaik 2026 — jika Anda ingin menjalankan inferensi lokal melalui vLLM

FAQ

Apakah memakai provider pihak ketiga dengan Claude Code melanggar ketentuan Anthropic?

Tidak. Anthropic mendokumentasikan pola ANTHROPIC_BASE_URL untuk routing melalui Bedrock, Vertex AI, Foundry, dan gateway kustom.

Yang diblokir pada April 2026 adalah tool pihak ketiga yang memalsukan ID klien Claude Code untuk mengakses API Anthropic dengan harga langganan. Menggunakan gateway sendiri atau provider seperti OpenRouter dengan API key sendiri adalah kasus berbeda.

Apakah loop agen Claude Code berfungsi dengan DeepSeek V4 Pro?

Loop inti berfungsi:

edit file
menjalankan shell command
tugas multi-step
refactor kode
debugging

Namun ada batasan melalui provider pihak ketiga:

tool server MCP tidak didukung
input gambar/vision tidak didukung

Jika workflow Anda membutuhkan MCP atau vision, gunakan API Anthropic, Bedrock, atau Vertex.

Mengapa error menyebut `enterprise config` padahal saya bukan user enterprise?

Claude Code memakai istilah enterprise config untuk konfigurasi provider pihak ketiga. Itu label internal, bukan berarti fitur tersebut hanya untuk paket Enterprise.

Developer individual tetap bisa memakai custom provider selama konfigurasi valid.

Bisa beralih antara Anthropic dan provider pihak ketiga di tengah sesi?

Tidak dalam satu sesi.

ANTHROPIC_BASE_URL dibaca saat startup. Untuk mengganti provider:

keluar dari Claude Code
ubah environment atau settings.json
mulai sesi baru

Tool seperti DeepClaude mengemas proses ini dengan flag CLI seperti:

--backend ds
--backend anthropic

Gateway saya di belakang firewall. Apakah Claude Code mendukung proxy?

Ya. Set proxy sebelum menjalankan Claude Code:

export HTTPS_PROXY="http://proxy-anda:8080"
export ANTHROPIC_BASE_URL="https://gateway-internal-anda"

Jika proxy perusahaan melakukan TLS interception, tambahkan CA bundle:

export NODE_EXTRA_CA_CERTS="/path/to/corporate-ca-bundle.pem"

Curl berhasil, tetapi Claude Code tetap error. Apa bedanya?

Claude Code bisa mengirim request validasi tambahan yang tidak Anda replikasi di curl.

Jalankan:

claude --debug

Lalu bandingkan:

URL final
header anthropic-beta
header X-Claude-Code-Session-Id
header auth
body JSON
nama model

Perbedaan kecil di header atau model sering cukup untuk memicu error validasi.

Kesimpulan

Invalid custom3p enterprise config adalah error validasi konfigurasi, bukan pemblokiran provider.

Urutan perbaikannya:

Hapus trailing /v1 dari ANTHROPIC_BASE_URL
Pastikan memakai ANTHROPIC_AUTH_TOKEN atau ANTHROPIC_API_KEY sesuai gateway
Validasi ~/.claude/settings.json
Pastikan onboarding Claude Code sudah selesai
Pastikan gateway meneruskan header yang dibutuhkan
Cek managed settings jika memakai Team atau Enterprise

Setelah konfigurasi valid, Claude Code dapat menjalankan loop agen melalui backend pilihan Anda seperti OpenRouter, LiteLLM, DeepSeek, atau vLLM lokal. Batasan utama provider pihak ketiga tetap sama: MCP dan input vision membutuhkan backend Anthropic/Bedrock/Vertex yang kompatibel.

Dapatkan Akses API Gemini Tak Terbatas Gratis

Walse — Sat, 09 May 2026 07:03:23 +0000

Keluarga Gemini Google adalah lini model hemat biaya untuk beban kerja bervolume tinggi, tetapi biaya token tetap bisa naik cepat saat aplikasi publik gratis, proyek sampingan, atau demo hackathon mulai dipakai banyak pengguna. Puter.js menawarkan pola berbeda: Anda dapat memanggil model Gemini dan Gemma dari peramban tanpa kunci API Google, tanpa proyek Google Cloud, dan tanpa backend. Penggunaan dibebankan ke pengguna akhir melalui akun Puter mereka, bukan ke akun developer Anda.

Coba Apidog hari ini

TL;DR

Puter.js memberi developer akses ke katalog Gemini dan Gemma tanpa kunci API Google, proyek Google Cloud, atau server.
Model Gemini yang didukung mencakup 2.5 Pro, 2.5 Flash, 2.5 Flash Lite, 2.0 Flash, 2.0 Flash Lite, 3 Flash Preview, plus pratinjau lama.
Model Gemma yang didukung mencakup Gemma 2, 3, 4 dalam berbagai ukuran.
Integrasi minimum: satu tag <script> dan satu pemanggilan puter.ai.chat().
Streaming, input gambar, percakapan multi-giliran, dan parameter seperti temperature dapat dipakai langsung di peramban.
Pengguna akhir menanggung pemakaian melalui akun Puter; Anda tidak perlu menyimpan kunci API.
Gunakan Apidog untuk membandingkan alur Puter dengan API Gemini resmi saat merencanakan migrasi.

Cara kerja “gratis tanpa batas” di Puter.js

Puter.js membalik model penagihan LLM. Biasanya, Anda membuat project Google Cloud atau Google AI Studio, menyimpan API key, lalu menanggung setiap biaya token. Dengan Puter, pengguna akhir masuk ke akun Puter mereka, dan panggilan model dikenakan ke saldo akun pengguna tersebut.

Dampaknya untuk developer:

Tidak perlu Google Cloud project.
Tidak perlu menyimpan API key di frontend atau backend.
Tidak perlu menangani rotasi key, kuota, atau billing Google.
Skala penggunaan mengikuti jumlah pengguna yang masuk ke Puter.

Batasan utamanya: Puter.js berorientasi peramban. Untuk cron job, batch processing, webhook, atau proses backend tanpa sesi pengguna, gunakan API Gemini resmi.

Langkah 1: Pasang Puter.js

Untuk aplikasi statis atau prototipe cepat, cukup tambahkan CDN berikut:

<script src="https://js.puter.com/v2/"></script>

Contoh file HTML minimum:

<!DOCTYPE html>
<html>
  <body>
    <script src="https://js.puter.com/v2/"></script>
    <script>
      puter.print("Puter.js siap digunakan");
    </script>
  </body>
</html>

Jika aplikasi Anda memakai bundler:

npm install @heyputer/puter.js

Lalu impor di JavaScript:

import { puter } from '@heyputer/puter.js';

Langkah 2: Pilih model Gemini atau Gemma

Gunakan model sesuai kebutuhan aplikasi, bukan selalu model terbesar.

ID Model	Kapan digunakan
`google/gemini-2.5-pro`	Penalaran lebih dalam, analisis kompleks, dan prompt sulit
`google/gemini-2.5-flash`	Default untuk sebagian besar aplikasi chat, QA, dan konten
`google/gemini-2.5-flash-lite`	Klasifikasi, tagging, dan tugas volume tinggi yang sederhana
`google/gemini-2.0-flash`	Baseline stabil dengan perilaku yang lebih mudah diprediksi
`google/gemini-3-flash-preview`	Eksperimen dengan varian preview terbaru
`google/gemma-3-27b-it`	Model Gemma instruction-tuned untuk baseline open-weight
`google/gemma-4-31b-it`	Varian Gemma besar untuk kualitas output yang lebih tinggi

Rekomendasi praktis:

Mulai dari google/gemini-2.5-flash.
Naik ke google/gemini-2.5-pro hanya untuk tugas penalaran sulit.
Gunakan google/gemini-2.5-flash-lite untuk klasifikasi atau tagging skala besar.

Langkah 3: Buat panggilan Gemini pertama

Contoh paling sederhana:

<!DOCTYPE html>
<html>
  <body>
    <script src="https://js.puter.com/v2/"></script>

    <script>
      puter.ai.chat(
        "Explain machine learning in three sentences",
        { model: "google/gemini-2.5-flash" }
      ).then(response => {
        puter.print(response);
      });
    </script>
  </body>
</html>

Jalankan file tersebut di peramban. Puter akan menangani proses autentikasi pengguna dan pemanggilan model. Anda tidak perlu menaruh API key di kode.

Langkah 4: Tampilkan respons ke elemen UI

Untuk aplikasi nyata, jangan hanya memakai puter.print(). Render respons ke elemen HTML.

<div id="output"></div>

<script src="https://js.puter.com/v2/"></script>
<script>
  const output = document.getElementById("output");

  async function askGemini() {
    const response = await puter.ai.chat(
      "Buat ringkasan singkat tentang REST API.",
      { model: "google/gemini-2.5-flash" }
    );

    output.textContent = response;
  }

  askGemini();
</script>

Pola ini cocok untuk:

chatbot sederhana,
generator konten,
fitur ringkasan,
alat QA dokumen pendek,
demo statis tanpa backend.

Langkah 5: Streaming respons

Untuk UI chat atau jawaban panjang, gunakan streaming agar pengguna melihat output muncul bertahap.

const outputDiv = document.getElementById("output");

const response = await puter.ai.chat(
  "Explain photosynthesis in detail",
  {
    model: "google/gemini-2.5-flash",
    stream: true,
  }
);

for await (const part of response) {
  if (part?.text) {
    outputDiv.innerHTML += part.text;
  }
}

Implementasi UI sederhana:

<button id="ask">Tanya Gemini</button>
<div id="output"></div>

<script src="https://js.puter.com/v2/"></script>
<script>
  const button = document.getElementById("ask");
  const output = document.getElementById("output");

  button.addEventListener("click", async () => {
    output.textContent = "";

    const stream = await puter.ai.chat(
      "Jelaskan konsep event loop JavaScript dengan contoh.",
      {
        model: "google/gemini-2.5-flash",
        stream: true,
      }
    );

    for await (const part of stream) {
      if (part?.text) {
        output.textContent += part.text;
      }
    }
  });
</script>

Langkah 6: Gunakan input gambar

Gemini mendukung input multimodal. Di Puter.js, Anda dapat mengirim prompt dan URL gambar.

puter.ai.chat(
  "What do you see in this image? Describe colors, objects, and mood.",
  "https://assets.puter.site/doge.jpeg",
  { model: "google/gemini-2.5-flash" }
).then(response => {
  puter.print(response);
});

Kasus penggunaan yang cocok:

membuat alt text,
QA visual,
analisis screenshot,
OCR ringan,
alat aksesibilitas,
tagging gambar produk.

Untuk screenshot yang sangat padat teks, tetap lakukan pengujian terhadap model lain sebelum memilih model produksi.

Langkah 7: Atur `temperature`

Gunakan temperature untuk mengontrol variasi output.

const response = await puter.ai.chat(
  "Write a creative short story about a robot chef",
  {
    model: "google/gemini-2.5-flash",
    temperature: 0.2,
  }
);

console.log(response);

Panduan cepat:

0.0–0.3: output lebih stabil, cocok untuk data faktual, ekstraksi, dan format terstruktur.
0.4–0.7: default aman untuk chat umum.
0.7–1.0: lebih kreatif, cocok untuk ide, cerita, dan variasi copywriting.

Contoh untuk output terstruktur:

const response = await puter.ai.chat(
  `
  Klasifikasikan teks berikut sebagai bug, feature_request, atau question.
  Jawab hanya dalam JSON.

  Teks: "Tombol submit tidak bekerja setelah update terakhir."
  `,
  {
    model: "google/gemini-2.5-flash-lite",
    temperature: 0.1,
  }
);

console.log(response);

Langkah 8: Buat percakapan multi-giliran

Untuk chatbot, simpan riwayat pesan dan kirim ulang pada setiap giliran.

const messages = [
  { role: "user", content: "I am building a Next.js app with Postgres." },
  { role: "assistant", content: "Got it. What do you need help with?" },
  { role: "user", content: "How should I structure migrations?" },
];

const response = await puter.ai.chat(messages, {
  model: "google/gemini-2.5-pro",
});

console.log(response);

Pola implementasi:

const messages = [];

async function sendMessage(userInput) {
  messages.push({
    role: "user",
    content: userInput,
  });

  const response = await puter.ai.chat(messages, {
    model: "google/gemini-2.5-flash",
  });

  messages.push({
    role: "assistant",
    content: response,
  });

  return response;
}

Dengan pola ini, Gemini membaca konteks percakapan sebelumnya dan dapat menjawab secara konsisten di giliran berikutnya.

Membandingkan Gemini dengan model lain

Puter menyediakan beberapa model melalui antarmuka yang sama. Untuk memilih model, jalankan prompt yang sama ke beberapa model dan bandingkan output serta latensi.

const models = [
  "google/gemini-2.5-flash",
  "claude-sonnet-4-6",
  "gpt-5.5",
  "x-ai/grok-4.3",
];

const prompt = "Refactor this React component to use hooks: ...";

for (const model of models) {
  const start = performance.now();

  const response = await puter.ai.chat(prompt, { model });

  const elapsed = performance.now() - start;

  console.log(`${model}: ${elapsed.toFixed(0)}ms`);
  console.log(response);
  console.log("---");
}

Gunakan hasilnya untuk membuat keputusan berbasis kasus nyata:

kualitas jawaban,
latensi,
konsistensi format,
kemampuan mengikuti instruksi,
kebutuhan pengguna Anda.

Apa yang Anda dapatkan

Dengan Puter.js, Anda dapat membangun fitur LLM berbasis peramban dengan:

katalog Gemini 2.5/2.0/3 Flash dan 2.5 Pro,
keluarga Gemma 2/3/4,
percakapan multi-giliran,
streaming respons,
input gambar via URL,
parameter seperti temperature, max_tokens, dan system prompt,
integrasi frontend tanpa backend.

Apa yang mungkin belum cocok

Tergantung versi Puter dan kebutuhan aplikasi, beberapa skenario lebih cocok memakai API Gemini resmi:

function calling native pada Gemini,
tool execution,
grounding dengan Google Search,
konteks sangat panjang hingga batas penuh Gemini,
pemrosesan sisi server tanpa sesi peramban,
observabilitas langsung terhadap rate limit Google.

Untuk workflow agentik yang membutuhkan tool execution atau integrasi backend kompleks, API Google AI Studio resmi biasanya lebih tepat. Untuk chat, QA, pembuatan konten, dan tugas visual berbasis peramban, Puter.js sudah cukup untuk banyak kasus.

Kapan memakai Puter.js vs API Gemini resmi

Gunakan Puter.js ketika:

Anda membuat aplikasi publik gratis dan tidak ingin menanggung biaya token.
Anda membuat prototipe tanpa setup Google Cloud.
Anda membangun situs statis, demo hackathon, atau ekstensi peramban.
Pengguna Anda dapat menerima proses login Puter.
Anda ingin validasi ide sebelum membuat backend produksi.

Gunakan API Gemini resmi ketika:

Anda membutuhkan cron, batch job, webhook, atau worker backend.
Anda membutuhkan eksekusi kode, grounding Search, atau konteks Gemini penuh.
Anda membutuhkan kontrak langsung dengan Google untuk kebutuhan compliance.
Anda membutuhkan fine-tuning pada dataset sendiri.
Pengguna Anda tidak dapat menerima login pihak ketiga.

Untuk panduan Gemini 3 Flash, baca Cara menggunakan API Pratinjau Gemini 3 Flash.

Menguji integrasi dengan Apidog

Karena Puter berjalan di peramban, Anda tidak bisa mengujinya persis seperti endpoint backend biasa. Pola yang lebih praktis:

Buat halaman statis kecil yang menerima prompt dari query parameter.
Jalankan Puter.js di halaman tersebut.
Simpan halaman itu sebagai target prototipe.
Gunakan Apidog untuk menguji API Gemini resmi jika nanti Anda migrasi ke backend.
Simpan konfigurasi Puter dan Gemini resmi sebagai environment terpisah.

Contoh struktur environment:

puter-prototype: URL lokal, misalnya http://localhost:5173
gemini-prod: https://generativelanguage.googleapis.com/v1

Anda bisa mengunduh Apidog, lalu membuat koleksi yang memisahkan eksperimen frontend Puter dan pengujian API resmi. Untuk pola pengujian API yang lebih luas, lihat Alat pengujian API untuk insinyur QA.

Jalur LLM gratis lain melalui Puter

Model bayar-pengguna yang sama juga dapat dipakai untuk LLM lain melalui Puter:

Pola implementasinya sama: ubah nilai model, lalu jalankan prompt yang sama.

const response = await puter.ai.chat("Jelaskan OAuth 2.0 secara singkat.", {
  model: "google/gemini-2.5-flash",
});

FAQ

Apakah ini benar-benar tidak terbatas?

Dari sisi developer, Anda tidak menanggung billing API. Pengguna akhir memakai saldo akun Puter mereka. Akun baru mendapatkan kredit awal, dan pengguna dapat mengisi ulang jika membutuhkan lebih banyak penggunaan.

Apakah saya perlu akun Google atau Google Cloud project?

Tidak. Puter menangani hubungan dengan provider model. Anda tidak melihat atau menyimpan kunci API Google.

Apakah bisa dipakai di produksi?

Bisa untuk aplikasi berbasis peramban. Pertanyaan utamanya adalah apakah alur login Puter cocok untuk pengguna Anda.

Apakah output Gemini via Puter sama dengan API resmi?

Model yang dipanggil tetap Gemini. Namun, latensi dan batas kemampuan tertentu dapat bergantung pada lapisan Puter dan model yang tersedia.

Bagaimana dengan konteks Gemini yang sangat besar?

Jika Anda membutuhkan konteks sangat panjang hingga batas penuh Gemini, gunakan API Google AI Studio resmi. Untuk sebagian besar chat, QA, dan tugas konten, kebutuhan konteks biasanya jauh lebih kecil.

Bisakah dipakai untuk bot Discord atau backend service?

Tidak ideal. Puter.js berorientasi peramban dan mengasumsikan sesi pengguna. Untuk bot, worker, cron, dan service backend, gunakan API Gemini resmi.

Model apa yang sebaiknya jadi default?

Gunakan google/gemini-2.5-flash sebagai default. Naik ke google/gemini-2.5-pro untuk reasoning yang lebih sulit, atau turun ke google/gemini-2.5-flash-lite untuk klasifikasi volume tinggi.

Apakah pembuatan gambar Imagen didukung?

Puter mengekspos pembuatan gambar melalui model seperti gpt-image-2 dan varian DALL-E, bukan Imagen. Lihat Dapatkan API GPT-5.5 gratis tanpa batas untuk jalur pembuatan gambar.

Kesimpulan

Puter.js adalah cara cepat untuk menambahkan Gemini ke aplikasi berbasis peramban tanpa API key, tanpa backend, dan tanpa setup Google Cloud. Tambahkan script, pilih google/gemini-2.5-flash, lalu panggil puter.ai.chat() dari frontend.

Untuk server-side processing, fine-tuning, tool execution, atau konteks Gemini penuh, gunakan API Gemini resmi. Untuk prototipe, hackathon, situs statis, aplikasi publik gratis, dan fitur AI frontend, Puter.js adalah jalur implementasi yang sederhana.

Buat permintaan di Apidog, bandingkan alur Puter dengan API resmi, lalu pilih arsitektur yang paling sesuai dengan kebutuhan aplikasi Anda.

Dapatkan API GPT-5.5 & Semua Model OpenAI Gratis Tanpa Batas

Walse — Sat, 09 May 2026 02:41:06 +0000

GPT-5.5 dari OpenAI hadir dengan API berbayar: $5 per juta token input dan $30 per juta token output. Untuk proyek sampingan, hackathon, atau aplikasi publik gratis, biaya ini bisa menghentikan eksperimen sebelum dimulai. Puter.js menawarkan pola berbeda: akses katalog OpenAI seperti GPT-5.5, GPT-5.5 Pro, varian GPT-5.x, GPT-Image-2, DALL-E, dan OpenAI TTS tanpa kunci OpenAI. Pengguna akhir membayar penggunaan melalui akun Puter mereka, bukan Anda.

Coba Apidog hari ini

Intinya

Puter.js memberi akses ke model OpenAI tanpa kunci API, tanpa akun OpenAI, dan tanpa server backend.
Model teks yang didukung meliputi gpt-5.5, gpt-5.5-pro, gpt-5.4, gpt-5, gpt-5-mini, o1, o3, gpt-4.1, gpt-4o, plus varian chat dan codex.
Model gambar: gpt-image-2, gpt-image-1.5, dall-e-3.
Model TTS: gpt-4o-mini-tts, tts-1, tts-1-hd.
Integrasi minimal: satu tag <script> dan satu panggilan puter.ai.chat().
Streaming, function calling, vision input, image generation, dan text-to-speech dapat berjalan langsung di browser.
Pengguna akhir menanggung penggunaan dari akun Puter mereka; aplikasi Anda tidak membawa tagihan OpenAI.
Gunakan Apidog untuk membandingkan prompt terhadap Puter dan API resmi OpenAI saat merencanakan migrasi.

Cara kerja “gratis tak terbatas”

Puter.js mengubah model penagihan LLM. Biasanya, Anda menyimpan kunci OpenAI dan menanggung semua biaya token. Dengan Puter, pengguna akhir masuk ke Puter, lalu penggunaan AI dibebankan ke saldo akun mereka.

Dari sisi developer, hasilnya:

Tidak ada kunci OpenAI di repo. Tidak perlu mengelola secret, rotasi key, atau risiko kebocoran.
Tidak ada batas penggunaan di akun Anda. Setiap pengguna menggunakan akun Puter masing-masing.
Tidak ada tagihan OpenAI untuk aplikasi Anda. Anda tidak perlu menyiapkan billing OpenAI untuk prototipe browser.

Komprominya: Puter bersifat browser-first. Untuk job backend, cron, webhook handler, atau batch processing, API resmi OpenAI tetap jalur yang lebih tepat.

Langkah 1: Instalasi

Untuk prototipe cepat, gunakan CDN:

<script src="https://js.puter.com/v2/"></script>

Contoh file HTML minimal:

<!DOCTYPE html>
<html>
<body>
  <script src="https://js.puter.com/v2/"></script>
</body>
</html>

Untuk aplikasi yang dibundel dengan npm:

npm install @heyputer/puter.js

Lalu import di kode JavaScript:

import { puter } from '@heyputer/puter.js';

Gunakan CDN untuk situs statis, demo hackathon, atau ekstensi browser. Gunakan npm jika proyek Anda membutuhkan bundler dan tipe TypeScript.

Langkah 2: Pilih model

Puter mengekspos jajaran GPT-5.x dan model OpenAI yang lebih lama. Pilih model berdasarkan kebutuhan, bukan selalu yang paling besar.

ID Model	Kapan digunakan
`gpt-5.5-pro`	Penalaran paling berat, coding agent, analisis kompleks
`gpt-5.5`	Default harian untuk chat, reasoning, dan tugas umum
`gpt-5.4-nano`	Klasifikasi volume tinggi, respons cepat, biaya rendah
`gpt-5.4-mini`	UI chat ringan dan fitur AI dalam aplikasi
`gpt-5.3-codex`	Tugas khusus kode
`o3`	Rantai penalaran kompleks
`o1-pro`	Perencanaan multi-langkah
`gpt-4.1`, `gpt-4o`, `gpt-4o-mini`	Baseline stabil dan umum digunakan

Model gambar:

gpt-image-2: terbaru, output tajam, cepat.
gpt-image-1.5, gpt-image-1, dall-e-3, dall-e-2: opsi lebih lama tetapi stabil.

Model text-to-speech:

gpt-4o-mini-tts: suara lebih alami.
tts-1, tts-1-hd: TTS klasik dengan latensi lebih rendah.

Langkah 3: Jalankan chat GPT-5.5

Contoh paling kecil:

<!DOCTYPE html>
<html>
<body>
  <script src="https://js.puter.com/v2/"></script>
  <script>
    puter.ai.chat(
      "Explain WebSockets in three sentences",
      { model: "gpt-5.5" }
    ).then(response => {
      puter.print(response);
    });
  </script>
</body>
</html>

Buka file tersebut di browser. Puter akan menangani sesi pengguna, autentikasi, dan pemanggilan model. Anda tidak perlu membuat backend, environment variable, atau proxy API.

Langkah 4: Streaming respons

Untuk UI chat, gunakan streaming agar pengguna melihat output muncul bertahap.

const response = await puter.ai.chat(
  "Explain the theory of relativity in detail",
  {
    model: "gpt-5.5",
    stream: true
  }
);

for await (const part of response) {
  puter.print(part?.text);
}

Di aplikasi nyata, ganti puter.print() dengan update ke elemen UI:

const output = document.querySelector("#output");

for await (const part of response) {
  output.textContent += part?.text ?? "";
}

Contoh HTML-nya:

<div id="output"></div>

Langkah 5: Vision input dengan gambar

Untuk meminta model menganalisis gambar, kirim prompt, URL gambar, dan opsi model:

puter.ai.chat(
  "What do you see in this image? Describe colors, objects, and mood.",
  "https://assets.puter.site/doge.jpeg",
  { model: "gpt-5.5" }
).then(response => {
  puter.print(response);
});

Kasus penggunaan praktis:

membuat alt text otomatis,
menganalisis screenshot,
QA visual,
OCR ringan,
fitur aksesibilitas.

Langkah 6: Generate gambar

Gunakan puter.ai.txt2img() untuk membuat gambar dari prompt. Fungsi ini mengembalikan elemen <img> yang siap ditempel ke DOM.

puter.ai.txt2img(
  "A futuristic cityscape at night, cinematic, neon, rain",
  { model: "gpt-image-2" }
).then(imageElement => {
  document.body.appendChild(imageElement);
});

Untuk aplikasi publik, tambahkan kontrol agar pengguna tidak memicu generasi berulang tanpa sengaja, misalnya disable tombol selama proses berjalan:

const button = document.querySelector("#generate");

button.addEventListener("click", async () => {
  button.disabled = true;

  try {
    const image = await puter.ai.txt2img(
      "A futuristic cityscape at night, cinematic, neon, rain",
      { model: "gpt-image-2" }
    );

    document.body.appendChild(image);
  } finally {
    button.disabled = false;
  }
});

Langkah 7: Text-to-speech

Gunakan txt2speech() untuk menghasilkan audio. Fungsi ini mengembalikan elemen <audio>.

puter.ai.txt2speech(
  "Welcome back. Your account balance is $1,247.50.",
  {
    provider: "openai",
    model: "gpt-4o-mini-tts"
  }
).then(audio => {
  audio.setAttribute("controls", "");
  document.body.appendChild(audio);
});

Gunakan TTS untuk:

voice prompt,
narasi onboarding,
pengisi suara aplikasi,
ringkasan audio,
fitur aksesibilitas.

Langkah 8: Function calling

Puter mengikuti bentuk function calling OpenAI. Anda mendeklarasikan tool, model menghasilkan tool_calls, lalu aplikasi Anda mengeksekusi fungsi yang sesuai.

const tools = [
  {
    type: "function",
    function: {
      name: "get_weather",
      description: "Get the current weather for a city.",
      parameters: {
        type: "object",
        properties: {
          city: {
            type: "string"
          }
        },
        required: ["city"]
      }
    }
  }
];

const response = await puter.ai.chat(
  "What's the weather in Tokyo right now?",
  {
    model: "gpt-5.5",
    tools
  }
);

const toolCalls = response.message.tool_calls;

if (toolCalls?.length) {
  const call = toolCalls[0];

  console.log(call.function.name);
  console.log(call.function.arguments);

  // Jalankan fungsi Anda sendiri di sini.
}

Contoh eksekusi lokal sederhana:

function get_weather({ city }) {
  return {
    city,
    temperature: "24°C",
    condition: "Cloudy"
  };
}

if (toolCalls?.length) {
  const args = JSON.parse(toolCalls[0].function.arguments);
  const result = get_weather(args);

  console.log(result);
}

Bentuk ini mirip dengan OpenAI, sehingga definisi tool yang sudah Anda punya biasanya mudah dipindahkan. Untuk menguji alur berbasis tool dalam skenario produksi, lihat pengujian server MCP di Apidog.

Langkah 9: Atur temperature dan max_tokens

Kirim parameter OpenAI standar melalui objek opsi:

const response = await puter.ai.chat(
  "Tell me about Mars",
  {
    model: "gpt-5.5",
    temperature: 0.2,
    max_tokens: 200
  }
);

Panduan praktis:

Gunakan temperature: 0.0 sampai 0.3 untuk jawaban faktual.
Gunakan temperature: 0.7 sampai 1.0 untuk penulisan kreatif.
Gunakan max_tokens untuk membatasi panjang output dan menjaga penggunaan tetap terkendali.

Untuk aplikasi publik, selalu tentukan batas output:

const options = {
  model: "gpt-5.5",
  temperature: 0.2,
  max_tokens: 300
};

Apa yang Anda dapatkan dan apa yang tidak

Akses Puter berguna untuk aplikasi browser, tetapi tidak identik dengan seluruh permukaan API resmi OpenAI.

Anda mendapatkan:

katalog GPT-5.x termasuk 5.5, 5.5 Pro, 5.4 mini/nano/pro, dan varian codex,
model OpenAI lebih lama seperti GPT-4.1, GPT-4o, o1, dan o3,
GPT-Image-2 dan DALL-E untuk pembuatan gambar,
jajaran OpenAI TTS termasuk gpt-4o-mini-tts,
streaming,
vision input,
function calling,
kontrol temperature,
kontrol max_tokens.

Anda mungkin tidak mendapatkan:

Responses API,
pengurangan biaya dari prompt caching,
Files API untuk konteks dokumen yang diunggah,
penggunaan server-side tanpa sesi browser,
header rate limit langsung dari OpenAI,
structured output OpenAI dengan enforcement skema JSON penuh.

Jika Anda membutuhkan pipeline produksi server-side, API resmi OpenAI lebih tepat. Jika targetnya adalah prototipe browser, situs statis, tool publik, atau aplikasi hackathon, Puter cukup praktis.

Kapan menggunakan Puter vs API resmi OpenAI

Gunakan Puter ketika:

Anda membuat aplikasi publik gratis dan tidak ingin menanggung tagihan token.
Anda membuat prototipe tanpa setup billing OpenAI.
Anda ingin menjalankan AI dari situs statis atau ekstensi browser.
Anda tidak ingin menyimpan API key di frontend.
Pengguna Anda bersedia masuk ke Puter.

Gunakan API resmi OpenAI ketika:

Anda butuh panggilan server-side seperti cron, webhook, atau batch job.
Anda butuh prompt caching untuk prompt sistem yang besar dan stabil.
Anda butuh Responses API, Files API, atau structured output lengkap.
Anda punya kebutuhan kepatuhan dan kontrak.
Pengguna tidak boleh melihat langkah login Puter.

Strategi umum: mulai dengan Puter untuk validasi produk, lalu migrasi ke API resmi OpenAI saat kebutuhan backend, kontrol, atau compliance mulai muncul.

Untuk setup produksi berbayar, lihat Cara menggunakan API GPT-5.5.

Menguji integrasi di Apidog

Panggilan Puter berjalan di browser, jadi pendekatan testing-nya berbeda dari API backend biasa. Pola yang bisa digunakan:

Buat halaman statis kecil yang menjalankan Puter.
Terima prompt melalui query parameter.
Jalankan prompt yang sama terhadap API resmi OpenAI di environment terpisah.
Simpan konfigurasi Puter dan OpenAI dalam koleksi Apidog yang sama untuk memudahkan migrasi.

Contoh halaman statis:

<!DOCTYPE html>
<html>
<body>
  <pre id="output"></pre>

  <script src="https://js.puter.com/v2/"></script>
  <script>
    const params = new URLSearchParams(window.location.search);
    const prompt = params.get("prompt") ?? "Say hello";

    puter.ai.chat(prompt, { model: "gpt-5.5" })
      .then(response => {
        document.querySelector("#output").textContent = response;
      });
  </script>
</body>
</html>

Jalankan lokal:

npx serve .

Lalu akses:

http://localhost:3000?prompt=Explain%20WebSockets

Unduh Apidog, lalu siapkan dua environment:

puter-prototype: URL localhost yang menghosting halaman Puter.
openai-prod: https://api.openai.com/v1.

Dengan cara ini, Anda bisa menjaga prompt, skenario test, dan rencana migrasi tetap berada dalam satu workspace. Untuk pola testing API yang lebih luas, lihat tool pengujian API untuk insinyur QA.

FAQ

Apakah ini benar-benar tidak terbatas?

Tidak terbatas dari sisi developer. Pengguna akhir tetap menggunakan saldo akun Puter mereka. Akun baru mendapatkan kredit awal dan pengguna dapat mengisi ulang jika perlu.

Apakah saya memerlukan akun OpenAI?

Tidak. Puter menangani hubungan dengan OpenAI. Anda tidak perlu melihat atau menyimpan kunci OpenAI.

Bisakah digunakan di produksi?

Ya, untuk aplikasi berbasis browser. Pertanyaan utamanya adalah apakah pengguna Anda bersedia masuk ke Puter.

Apakah output GPT-5.5 melalui Puter identik dengan API resmi?

Model yang dipanggil sama, tetapi Puter menambahkan lapisan di antara browser dan OpenAI. Latensi bisa berbeda karena ada hop tambahan.

Bagaimana dengan prompt caching?

Puter tidak mengekspos kontrol harga prompt caching OpenAI saat ini. Jika Anda bergantung pada prompt caching untuk menghemat biaya, gunakan API resmi.

Bisakah digunakan di backend?

Tidak secara bersih. Puter browser-first dan mengasumsikan sesi pengguna. Untuk backend service, gunakan API resmi OpenAI. Untuk opsi server-side gratis, lihat Cara menggunakan API GPT-5.5 secara gratis.

Model apa yang sebaiknya digunakan sebagai default?

Gunakan gpt-5.5 untuk reasoning harian, gpt-5.4-nano untuk klasifikasi volume tinggi, gpt-5.5-pro untuk reasoning sulit, dan o3 untuk rantai penalaran panjang.

Apakah pengguna akan dikenakan biaya besar?

Untuk penggunaan chat biasa, biaya umumnya kecil per sesi. Pembuatan gambar biasanya lebih mahal. Batasi max_tokens, hindari retry yang tidak perlu, dan beri feedback UI saat proses sedang berjalan.

Bisakah membuat gambar dengan Puter?

Ya. Gunakan txt2img dengan gpt-image-2 atau DALL-E. Pengguna membayar biaya pembuatan gambar dari saldo Puter mereka. Untuk panduan API resmi, lihat Cara menggunakan API GPT-Image-2.

Kesimpulan

Puter.js adalah cara cepat untuk menambahkan kemampuan OpenAI ke aplikasi browser tanpa menyimpan API key dan tanpa membawa tagihan token di sisi developer. Tambahkan script, pilih model, kirim prompt, lalu tampilkan respons ke UI.

Untuk workload server-side, prompt caching, Responses API, Files API, atau structured output penuh, gunakan API resmi OpenAI. Untuk prototipe, hackathon, situs statis, ekstensi browser, dan aplikasi publik gratis, Puter adalah opsi yang praktis.

Buat request sekali di Apidog, bandingkan Puter dengan API resmi, lalu pilih jalur yang paling sesuai dengan arsitektur aplikasi Anda.

Dapatkan Akses API Claude Opus 4.7 Gratis Tanpa Batas

Walse — Sat, 09 May 2026 02:33:48 +0000

Rangkaian model Claude dari Anthropic dikenal kuat untuk pengkodean serius, pekerjaan agen, dan penalaran konteks panjang. Namun biaya API bisa cepat menjadi hambatan: Sonnet berjalan di kisaran $3 / $15 per juta token, sementara Opus lebih tinggi. Puter.js menawarkan jalur berbeda: akses ke jajaran Claude seperti Opus 4.7, Sonnet 4.6, Haiku 4.5, dan varian lain tanpa kunci Anthropic. Model biayanya dipindahkan ke pengguna akhir melalui akun Puter, bukan ke pengembang aplikasi.

Coba Apidog hari ini

Panduan ini menunjukkan cara mengintegrasikan Claude lewat Puter.js: mulai dari pemasangan script, pemilihan model, panggilan chat, streaming, percakapan multi-giliran, sampai strategi pengujian sebelum produksi.

TL;DR

Puter.js memberi akses ke keluarga model Claude tanpa kunci API Anthropic, tanpa server, dan tanpa tagihan langsung ke pengembang.
Pengguna akhir menggunakan saldo akun Puter mereka sendiri.
Model yang tersedia mencakup Opus 4.7, Opus 4.6, Opus 4.6 Fast, Opus 4.5, Opus 4.1, Opus 4, Sonnet 4.6, Sonnet 4.5, Sonnet 4, dan Haiku 4.5.
Integrasi minimal: satu tag <script> dan satu panggilan puter.ai.chat.
Streaming, prompt sistem, dan percakapan multi-giliran dapat digunakan dari browser.
Gunakan Apidog untuk membandingkan prompt yang sama antara prototipe Puter dan API resmi Anthropic.

Cara kerja model “gratis untuk pengembang”

Puter.js adalah pustaka cloud dan AI berbasis browser. Alih-alih menyimpan kunci API Anthropic di backend Anda, pengguna masuk ke akun Puter mereka sendiri. Panggilan model kemudian dikaitkan dengan akun pengguna tersebut.

Dampaknya untuk pengembang:

Tidak ada kunci API di repo. Tidak ada risiko kebocoran secret atau rotasi key.
Tidak ada tagihan Anthropic langsung ke aplikasi Anda. Penggunaan bergantung pada akun Puter pengguna.
Tidak perlu backend hanya untuk memanggil Claude. Aplikasi statis, demo, dan prototipe bisa langsung berjalan di browser.

Batasannya: pendekatan ini browser-first. Untuk cron job, worker backend, batch processing, atau API internal, gunakan API resmi Anthropic.

Langkah 1: Tambahkan Puter.js

Untuk HTML statis, cukup tambahkan script berikut:

<script src="https://js.puter.com/v2/"></script>

Contoh halaman minimal:

<!DOCTYPE html>
<html>
<body>
  <script src="https://js.puter.com/v2/"></script>
</body>
</html>

Jika Anda memakai bundler seperti Vite atau Webpack, gunakan paket NPM:

npm install @heyputer/puter.js

Lalu import di kode JavaScript:

import { puter } from '@heyputer/puter.js';

Gunakan CDN untuk prototipe cepat. Gunakan NPM jika aplikasi Anda sudah memakai build pipeline dan TypeScript.

Langkah 2: Pilih model Claude

Puter mengekspos model Claude dengan ID model berikut:

ID Model	Kapan digunakan
`claude-opus-4-7`	Model flagship terbaru untuk penalaran kompleks dan tugas agen yang berat
`claude-opus-4-6`	Model Opus sebelumnya untuk pengkodean dan analisis mendalam
`claude-opus-4.6-fast`	Varian Opus dengan latensi lebih rendah
`claude-opus-4-5`	Pilihan stabil untuk workflow produksi
`claude-opus-4-1`	Model legacy dengan perilaku yang lebih mudah diprediksi
`claude-opus-4`	Basis awal keluarga Opus 4
`claude-sonnet-4-6`	Default harian untuk keseimbangan kualitas dan kecepatan
`claude-sonnet-4-5`	Sonnet sebelumnya untuk sebagian besar tugas umum
`claude-sonnet-4`	Basis awal keluarga Sonnet 4
`claude-haiku-4-5`	Model cepat untuk klasifikasi, ekstraksi, dan tugas volume tinggi

Rekomendasi awal:

Pakai claude-sonnet-4-6 sebagai default.
Pakai claude-haiku-4-5 untuk tugas ringan dan cepat.
Pakai claude-opus-4-7 untuk analisis panjang, review kode kompleks, atau perencanaan multi-langkah.

Langkah 3: Buat panggilan chat pertama

Contoh paling sederhana:

<!DOCTYPE html>
<html>
<body>
  <script src="https://js.puter.com/v2/"></script>

  <script>
    puter.ai.chat(
      "Jelaskan komputasi kuantum dalam istilah sederhana",
      { model: "claude-sonnet-4-6" }
    ).then(response => {
      puter.print(response.message.content[0].text);
    });
  </script>
</body>
</html>

Buka file tersebut di browser. Saat diperlukan, Puter akan menangani proses login pengguna. Setelah itu, respons Claude dicetak ke halaman.

Struktur respons mengikuti bentuk pesan Anthropic:

response.message.content[0].text

Untuk output teks biasa, blok pertama biasanya cukup. Jika respons berisi beberapa blok konten, lakukan iterasi:

for (const block of response.message.content) {
  if (block.text) {
    console.log(block.text);
  }
}

Langkah 4: Tampilkan respons dengan streaming

Untuk jawaban panjang, gunakan streaming agar UI terasa lebih responsif:

const response = await puter.ai.chat(
  "Tulis esai terperinci tentang dampak kecerdasan buatan pada masyarakat",
  {
    model: "claude-sonnet-4-6",
    stream: true
  }
);

for await (const part of response) {
  puter.print(part?.text);
}

Untuk UI chat, append setiap potongan teks ke elemen pesan:

const output = document.querySelector("#output");

const response = await puter.ai.chat("Buatkan ringkasan tentang REST API", {
  model: "claude-sonnet-4-6",
  stream: true
});

for await (const part of response) {
  if (part?.text) {
    output.textContent += part.text;
  }
}

HTML minimalnya:

<div id="output"></div>

Langkah 5: Buat percakapan multi-giliran

Untuk percakapan, kirim array pesan dengan role dan content:

const messages = [
  {
    role: "user",
    content: "Saya sedang membangun aplikasi Next.js dengan Postgres."
  },
  {
    role: "assistant",
    content: "Baik. Apa yang Anda butuhkan bantuannya?"
  },
  {
    role: "user",
    content: "Bagaimana saya harus menyusun folder migrasi?"
  }
];

const response = await puter.ai.chat(messages, {
  model: "claude-opus-4-7"
});

console.log(response.message.content[0].text);

Untuk mempertahankan konteks, simpan riwayat pesan:

const messages = [];

async function sendMessage(userInput) {
  messages.push({
    role: "user",
    content: userInput
  });

  const response = await puter.ai.chat(messages, {
    model: "claude-sonnet-4-6"
  });

  const assistantText = response.message.content[0].text;

  messages.push({
    role: "assistant",
    content: assistantText
  });

  return assistantText;
}

Dengan pola ini, setiap giliran berikutnya membawa konteks sebelumnya.

Langkah 6: Tambahkan prompt sistem

Gunakan pesan system untuk mengatur persona, batasan, dan format output:

const messages = [
  {
    role: "system",
    content: "Anda adalah insinyur backend senior. Balas dalam poin bernomor, maksimal lima poin."
  },
  {
    role: "user",
    content: "Bagaimana cara mencegah injeksi SQL di aplikasi Node.js?"
  }
];

const response = await puter.ai.chat(messages, {
  model: "claude-sonnet-4-6"
});

console.log(response.message.content[0].text);

Contoh prompt sistem untuk output JSON:

const messages = [
  {
    role: "system",
    content: "Balas hanya dalam JSON valid dengan field: summary, risks, recommendations."
  },
  {
    role: "user",
    content: "Review rencana migrasi database ini: ..."
  }
];

const response = await puter.ai.chat(messages, {
  model: "claude-sonnet-4-6"
});

Prompt sistem cocok untuk:

format output,
gaya jawaban,
batasan panjang,
peran teknis,
aturan keamanan aplikasi.

Benchmark beberapa model dengan prompt yang sama

Jangan memilih model berdasarkan nama saja. Jalankan prompt yang sama di beberapa model, lalu bandingkan output dan latensinya.

const models = [
  "claude-haiku-4-5",
  "claude-sonnet-4-6",
  "claude-opus-4-7"
];

const prompt = "Refactor komponen React ini agar menggunakan hooks: ...";

for (const model of models) {
  const start = performance.now();

  const response = await puter.ai.chat(prompt, { model });

  const elapsed = performance.now() - start;

  console.log(`${model}: ${elapsed.toFixed(0)}ms`);
  console.log(response.message.content[0].text);
  console.log("---");
}

Gunakan hasil benchmark untuk menentukan default:

Haiku untuk tugas cepat dan repetitif.
Sonnet untuk mayoritas fitur aplikasi.
Opus untuk prompt sulit, analisis panjang, atau keputusan yang membutuhkan penalaran lebih dalam.

Untuk membandingkan jalur Puter dengan API resmi Anthropic di Apidog, simpan keduanya sebagai environment berbeda dalam satu collection.

Apa yang tersedia dan apa yang perlu dicek

Claude melalui Puter cocok untuk banyak aplikasi berbasis browser, tetapi tidak selalu menggantikan API resmi Anthropic.

Yang tersedia:

katalog model Claude,
percakapan multi-giliran,
prompt sistem,
respons streaming,
integrasi browser tanpa backend,
tidak ada kunci Anthropic di sisi pengembang.

Yang perlu Anda verifikasi di dokumentasi Puter terbaru:

tool use atau function calling,
input gambar,
prompt caching Anthropic,
penggunaan server-side,
header rate limit Anthropic langsung.

Jika aplikasi Anda membutuhkan workflow tool use yang kompleks, pertimbangkan API resmi Anthropic atau pengujian server MCP di Apidog.

Kapan memakai Puter dan kapan memakai API resmi Anthropic

Gunakan Puter.js ketika:

aplikasi Anda berjalan di browser,
Anda membuat prototipe, demo, hackathon project, atau situs statis,
Anda tidak ingin mengelola kunci API,
pengguna bisa login ke akun Puter,
Anda ingin menghindari risiko tagihan langsung di sisi pengembang.

Gunakan API resmi Anthropic ketika:

Anda membutuhkan pemanggilan dari backend,
Anda menjalankan batch processing, cron job, atau worker,
Anda membutuhkan prompt caching,
Anda membutuhkan kontrol penuh atas tool use, vision, atau Files API,
Anda memiliki kebutuhan kepatuhan atau kontrak tertentu,
pengguna tidak boleh melewati langkah login Puter.

Strategi praktis: mulai dari Puter untuk validasi produk. Jika aplikasi membutuhkan server-side execution atau kontrol API lebih dalam, migrasikan ke API resmi. Struktur pesan yang mirip membuat transisinya lebih mudah.

Untuk pendekatan serupa pada model GPT, lihat Cara menggunakan GPT-5.5 API.

Menguji integrasi dengan Apidog

Karena Puter berjalan di browser, Anda tidak mengujinya seperti endpoint backend biasa. Pola yang lebih praktis:

Buat halaman statis kecil yang menerima prompt dari query parameter.
Jalankan prompt tersebut melalui Puter di browser.
Buat request Anthropic resmi di Apidog untuk skenario yang sama.
Simpan konfigurasi sebagai environment berbeda.

Contoh environment:

puter-prototype: URL lokal untuk halaman Puter Anda.
anthropic-prod: https://api.anthropic.com/v1.

Unduh Apidog, lalu buat collection untuk menyimpan prompt, payload, dan hasil pengujian. Dengan cara ini, Anda bisa membandingkan hasil Puter dan API resmi sebelum memilih jalur produksi.

FAQ

Apakah ini benar-benar tidak terbatas?

Tidak terbatas dari sisi pengembang. Pengguna akhir tetap menggunakan saldo akun Puter mereka sendiri.

Apakah saya perlu akun Anthropic?

Tidak. Puter menangani integrasi ke Anthropic. Anda tidak menyimpan kunci Anthropic.

Apakah bisa digunakan di produksi?

Bisa untuk aplikasi berbasis browser, selama flow login Puter dapat diterima oleh pengguna Anda.

Apakah output Claude melalui Puter sama dengan API resmi?

Puter memanggil Claude melalui jalur Anthropic atas nama pengguna. Perilaku model mengikuti model yang digunakan, meskipun latensi bisa dipengaruhi lapisan tambahan.

Apakah prompt caching Anthropic tersedia?

Jika Anda membutuhkan kontrol prompt caching secara langsung, gunakan API resmi Anthropic.

Bisakah dipakai untuk bot Discord atau service backend?

Tidak ideal. Puter dirancang browser-first dan bergantung pada sesi pengguna. Untuk bot dan backend service, gunakan API resmi.

Model default apa yang sebaiknya dipilih?

Mulai dari claude-sonnet-4-6. Naik ke claude-opus-4-7 untuk tugas sulit, atau turun ke claude-haiku-4-5 untuk klasifikasi dan tugas cepat.

Kesimpulan

Puter.js adalah cara cepat untuk menambahkan Claude ke aplikasi browser tanpa mengelola kunci Anthropic atau backend khusus. Tambahkan script, pilih model, lalu panggil puter.ai.chat.

Gunakan Puter untuk prototipe, aplikasi publik gratis, proyek sampingan, demo, dan situs statis. Gunakan API resmi Anthropic jika Anda membutuhkan eksekusi server-side, prompt caching, tool use yang lengkap, atau kebutuhan kepatuhan tertentu.

Buat skenario pengujian di Apidog, bandingkan hasil Puter dengan API resmi, lalu pilih arsitektur yang paling sesuai untuk aplikasi Anda.

Cara Menggunakan Grok 4.3 Gratis: 4 Cara Ampuh di 2026

Walse — Sat, 09 May 2026 02:28:40 +0000

Grok 4.3 adalah model unggulan xAI per Mei 2026, dengan jendela konteks 1M-token, input video asli, dan harga $1.25 / $2.50 per juta token. Jika Anda sedang membuat prototipe, belajar integrasi LLM, atau membangun proyek sampingan, ada tiga jalur praktis untuk mencoba Grok 4.3 tanpa biaya langsung: kredit promosi Konsol xAI, Puter.js dengan model pengguna-membayar, dan UI obrolan gratis di grok.com atau X.

Coba Apidog hari ini

Panduan ini fokus pada implementasi: cara menyiapkan akun, melakukan request pertama, memilih jalur yang sesuai, dan memahami trade-off sebelum Anda pindah ke penggunaan berbayar. Untuk panduan API berbayar lengkap, lihat Cara menggunakan API Grok 4.3. Untuk versi suara, lihat Cara menggunakan Grok Voice secara gratis.

TL;DR

Tiga jalur gratis ke Grok 4.3: Konsol xAI dengan kredit promosi, Puter.js dengan model pengguna-membayar, dan UI obrolan di grok.com atau X.
Untuk developer web publik: gunakan Puter.js. Pengguna akhir menanggung penggunaan mereka sendiri, sehingga Anda tidak perlu menyimpan billing key.
Untuk prototipe backend/API: gunakan Konsol xAI dengan kredit promosi akun baru.
Untuk non-developer: gunakan grok.com atau aplikasi X. Tidak ada API dan tidak perlu kode.
ID model di Puter.js: x-ai/grok-4.3.
ID model langsung di xAI: grok-4.3.
Gunakan Apidog untuk menguji request yang sama terhadap beberapa penyedia dan membandingkan respons, token, serta latensi.

Jalur 1: Kredit promosi Konsol xAI

Gunakan jalur ini jika Anda ingin menguji API Grok 4.3 secara langsung dari backend, script, atau tooling internal.

Langkah 1: Buat akun xAI Console

Buka console.x.ai, lalu buat akun menggunakan akun X Anda. Setelah masuk, buka dashboard dan cek bagian billing atau credits.

Langkah 2: Cek kredit promosi

xAI menjalankan periode promosi yang memberikan kredit gratis untuk akun baru. Jumlah dan periode kelayakan dapat berubah, jadi selalu cek tab Billing setelah pendaftaran.

Pola umumnya:

Kredit diberikan sekali.
Kredit tidak otomatis diperbarui.
Kredit cocok untuk validasi integrasi, bukan beban produksi jangka panjang.

Gunakan kredit ini untuk menguji:

Format request.
Respons model.
Streaming.
Function calling.
Token usage.
Latensi.
Error handling.

Langkah 3: Simpan API key sebagai environment variable

Jangan hard-code API key di repo.

export XAI_API_KEY="xai-..."

Langkah 4: Kirim request pertama

Endpoint xAI kompatibel dengan skema OpenAI Chat Completions.

curl https://api.x.ai/v1/chat/completions \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "grok-4.3",
    "messages": [
      {
        "role": "user",
        "content": "Explain prompt caching in three sentences."
      }
    ],
    "reasoning_effort": "low"
  }'

Untuk prototipe, mulai dengan:

"reasoning_effort": "low"

Naikkan ke medium atau high hanya jika output membutuhkan reasoning lebih dalam, karena penggunaan kredit akan lebih cepat habis.

Contoh Node.js sederhana

const response = await fetch("https://api.x.ai/v1/chat/completions", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.XAI_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "grok-4.3",
    messages: [
      {
        role: "user",
        content: "Give me a short checklist for testing an API endpoint.",
      },
    ],
    reasoning_effort: "low",
  }),
});

const data = await response.json();
console.log(data.choices?.[0]?.message?.content);

Pro dan kontra

Pro	Kontra
API produksi nyata	Jumlah kredit terbatas
Mendukung kemampuan Grok 4.3 penuh seperti konteks 1M, video, dan function calling	Ketentuan promosi dapat berubah
Migrasi ke penggunaan berbayar mudah	Tidak cocok untuk traffic produksi berkelanjutan

Rekomendasi: gunakan Konsol xAI jika Anda ingin memvalidasi perilaku API produksi. Untuk skema request lengkap, lihat Cara menggunakan API Grok 4.3.

Jalur 2: Puter.js

Puter.js adalah opsi paling praktis untuk aplikasi web publik karena developer tidak membayar penggunaan model. Pengguna akhir menggunakan akun Puter mereka sendiri.

Cara kerjanya

Puter.js menyediakan client JavaScript untuk memanggil berbagai LLM seperti Grok, GPT, Claude, Gemini, dan DeepSeek.

Perbedaannya ada di model biaya:

Anda menyematkan script Puter.js.
User login ke akun Puter.
Pemakaian AI dibebankan ke akun user tersebut.
Anda tidak perlu menyimpan API key.
Anda tidak perlu mengelola billing untuk setiap user.

Ini cocok untuk:

Tool web gratis.
Demo publik.
Side project.
Aplikasi edukasi.
Prototype frontend yang ingin langsung bisa dicoba user.

Langkah 1: Tambahkan script Puter.js

Tambahkan satu tag ini ke HTML Anda:

<script src="https://js.puter.com/v2/"></script>

Tidak perlu API key di sisi developer.

Langkah 2: Panggil Grok 4.3 dari browser

Gunakan puter.ai.chat() dengan model x-ai/grok-4.3.

<script src="https://js.puter.com/v2/"></script>

<script>
  puter.ai.chat(
    "Summarize the trade-offs between SQLite and Postgres in three bullets.",
    { model: "x-ai/grok-4.3" }
  ).then((response) => {
    document.body.innerText = response.message.content;
  });
</script>

Saat user pertama kali menjalankan aplikasi, Puter akan meminta login atau pembuatan akun. Setelah itu, request menggunakan saldo akun user.

Langkah 3: Render output ke UI

Contoh implementasi minimal:

<!doctype html>
<html>
  <head>
    <script src="https://js.puter.com/v2/"></script>
  </head>
  <body>
    <textarea id="prompt" rows="5" cols="60">
Explain how rate limiting works in REST APIs.
    </textarea>

    <button id="run">Ask Grok</button>

    <pre id="output"></pre>

    <script>
      const button = document.getElementById("run");
      const promptInput = document.getElementById("prompt");
      const output = document.getElementById("output");

      button.addEventListener("click", async () => {
        output.textContent = "Loading...";

        try {
          const response = await puter.ai.chat(promptInput.value, {
            model: "x-ai/grok-4.3",
          });

          output.textContent = response.message.content;
        } catch (error) {
          output.textContent = `Error: ${error.message}`;
        }
      });
    </script>
  </body>
</html>

Langkah 4: Gunakan streaming

Jika respons panjang, gunakan streaming agar UI terasa lebih cepat.

const stream = await puter.ai.chat(
  "Walk me through migrating a React app to Next.js.",
  {
    model: "x-ai/grok-4.3",
    stream: true,
    reasoning_effort: "medium",
  }
);

for await (const chunk of stream) {
  process.stdout.write(chunk?.text || "");
}

Di browser, Anda dapat menambahkan chunk ke elemen UI:

const output = document.getElementById("output");

const stream = await puter.ai.chat("Explain OAuth2 step by step.", {
  model: "x-ai/grok-4.3",
  stream: true,
});

output.textContent = "";

for await (const chunk of stream) {
  output.textContent += chunk?.text || "";
}

Pro dan kontra

Pro	Kontra
Developer membayar $0	User harus login ke Puter
Tidak ada API key di repo	Kurang cocok untuk backend-only app
Praktis untuk aplikasi web publik	Latensi bisa sedikit lebih tinggi daripada xAI langsung
Mendukung banyak model melalui pola yang sama	Membutuhkan konteks browser

Rekomendasi: gunakan Puter.js untuk aplikasi web publik, tool gratis, side project, atau demo yang tidak ingin Anda biayai sendiri. Jika request dijalankan oleh server Anda, bukan oleh user di browser, gunakan Konsol xAI atau provider API lain.

Untuk pola serupa dengan model lain, lihat Cara menggunakan API DeepSeek V4 secara gratis dan Cara menggunakan API GPT-5.5 secara gratis.

Jalur 3: grok.com dan aplikasi X

Gunakan jalur ini jika Anda hanya ingin mencoba Grok melalui UI, bukan dari kode.

Pilihan yang tersedia:

grok.com: UI obrolan web. Login dengan akun X.
Aplikasi X: Grok tersedia di aplikasi mobile dan web X melalui tab Grok.

Jalur ini cocok untuk:

Validasi prompt secara manual.
Riset cepat.
Membandingkan gaya output.
Mengecek apakah model cocok untuk use case Anda sebelum menulis integrasi API.

Namun, jalur ini tidak cocok untuk:

Otomatisasi.
Backend service.
Batch processing.
Integrasi CI/CD.
Logging request/response terstruktur.

Tingkat gratis di grok.com secara default menggunakan varian Grok yang lebih kecil, seperti Grok 4.1. Langganan Premium di X membuka Grok 4.3 di UI obrolan dengan kuota lebih tinggi.

Jalur 4: OpenRouter

OpenRouter tidak membuat Grok 4.3 gratis, tetapi berguna jika Anda ingin satu API key untuk beberapa provider model.

Grok 4.3 di OpenRouter berharga sama dengan xAI langsung, yaitu $1.25 / $2.50 per 1M token. Jadi, ini bukan jalur gratis untuk Grok 4.3.

Namun, OpenRouter memiliki beberapa varian model gratis, termasuk model kelas Grok seperti:

grok-4-fast:free

Gunakan ini jika Anda tidak membutuhkan Grok 4.3 secara spesifik, tetapi ingin output kelas Grok tanpa biaya.

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "x-ai/grok-4-fast:free",
    "messages": [
      {
        "role": "user",
        "content": "Hello!"
      }
    ]
  }'

Untuk Grok 4.3 secara spesifik, gunakan salah satu dari tiga jalur sebelumnya:

Konsol xAI dengan kredit promosi.
Puter.js.
UI grok.com atau X.

Perbandingan jalur akses

Jalur	Biaya bagi developer	Biaya bagi user akhir	Cocok untuk
Konsol xAI	$0 selama kredit masih ada	n/a	Prototipe API, backend, validasi produksi
Puter.js	$0	Beberapa sen per sesi	Aplikasi web publik dan side project
grok.com / X	$0	$0 dengan kuota	Penggunaan manual tanpa kode
Model gratis OpenRouter	$0 untuk varian gratis	n/a	Alternatif kelas Grok, bukan Grok 4.3 spesifik

Menguji beberapa jalur di Apidog

Saat Anda mengevaluasi beberapa provider, jangan hanya membandingkan harga. Uji request yang sama dan catat:

Respons model.
Latensi.
Token usage.
Error response.
Rate limit.
Konsistensi output.
Kemudahan migrasi.

Setup environment

Di Apidog, buat environment dengan variabel berikut:

XAI_API_KEY
OPENROUTER_API_KEY
BASE_URL
MODEL

Contoh nilai untuk xAI:

BASE_URL=https://api.x.ai/v1
MODEL=grok-4.3

Contoh nilai untuk OpenRouter:

BASE_URL=https://openrouter.ai/api/v1
MODEL=x-ai/grok-4-fast:free

Request body yang bisa dipakai ulang

Karena xAI dan OpenRouter menggunakan pola Chat Completions, Anda dapat memakai body yang hampir sama:

{
  "model": "{{MODEL}}",
  "messages": [
    {
      "role": "user",
      "content": "Explain the difference between REST and GraphQL in five bullets."
    }
  ]
}

Alur pengujian

Buat koleksi baru di Apidog.
Tambahkan endpoint POST {{BASE_URL}}/chat/completions.
Tambahkan header Authorization: Bearer {{XAI_API_KEY}} untuk xAI.
Duplikasi request untuk OpenRouter dan gunakan OPENROUTER_API_KEY.
Jalankan prompt yang sama.
Bandingkan respons, token, dan latensi.
Saat kredit xAI habis, ganti environment tanpa mengubah struktur request.

Unduh Apidog dan buat koleksi baru. URL dasar xAI adalah https://api.x.ai/v1, sedangkan URL dasar OpenRouter adalah https://openrouter.ai/api/v1.

Untuk pengujian lintas penyedia, lihat Alat pengujian API untuk insinyur QA.

Apa yang Anda korbankan saat memilih jalur gratis

Jalur gratis cocok untuk prototipe, tetapi ada batasan yang perlu diperhitungkan sebelum dipakai di produk.

1. Rate limit lebih ketat

Kredit gratis tidak berarti throughput bebas. Anda masih bisa terkena HTTP 429.

Tambahkan retry sederhana saat testing:

async function requestWithRetry(fn, maxRetries = 3) {
  for (let attempt = 1; attempt <= maxRetries; attempt++) {
    const response = await fn();

    if (response.status !== 429) {
      return response;
    }

    const delay = attempt * 1000;
    await new Promise((resolve) => setTimeout(resolve, delay));
  }

  throw new Error("Rate limit exceeded after retries");
}

2. Prompt caching belum terasa untuk prototipe kecil

Prompt caching seharga $0.20 per 1M token yang di-cache adalah fitur penting untuk beban besar. Namun, untuk prototipe puluhan request, penghematannya tidak terlalu terasa.

Caching mulai relevan jika Anda punya:

System prompt panjang.
Banyak request dengan konteks berulang.
Workflow agentik.
Dokumen referensi yang sama untuk banyak panggilan.

3. Dukungan terbatas

Akun gratis biasanya hanya cocok untuk eksperimen dan debugging mandiri. Jika Anda menjalankan workload produksi, Anda membutuhkan jalur berbayar dan dukungan yang lebih jelas.

Kapan harus pindah ke berbayar

Pindah ke penggunaan berbayar jika salah satu kondisi ini terjadi:

Throughput mulai konsisten. Anda sering terkena rate limit saat testing atau demo.
Prompt sistem panjang dan stabil. Anda punya prompt 50k+ token yang bisa diuntungkan dari caching.
Ada kebutuhan compliance. Anda membutuhkan audit trail, SOC 2, BAA, atau residensi data regional.
Anda menjalankan backend production. Request berasal dari server Anda dan harus stabil.
Anda butuh SLA dan support. Jalur gratis tidak ideal untuk debugging insiden produksi.

Migrasi biasanya sederhana:

Untuk Konsol xAI: gunakan API key berbayar.
Untuk OpenRouter: ubah BASE_URL dan MODEL.
Untuk Puter.js: tetap gunakan model pengguna-membayar jika aplikasi berjalan di browser.

FAQ

Apakah Grok 4.3 benar-benar gratis?

Tergantung jalurnya.

Di Konsol xAI, akses gratis berasal dari kredit promosi yang tidak diperbarui otomatis. Di Puter.js, gratis untuk developer karena user membayar pemakaiannya sendiri. Di grok.com, gratis dalam bentuk kuota pesan harian.

Bisakah saya memakai Grok 4.3 dari backend tanpa membayar?

Bisa selama kredit Konsol xAI masih tersedia. Setelah kredit habis, Anda perlu beralih ke penggunaan berbayar atau memilih model/penyedia lain.

Puter.js lebih cocok untuk browser karena model biayanya berbasis user.

Apakah Puter.js bisa dipakai di Node.js?

Puter.js lebih mengutamakan browser. Ada SDK server yang sedang dalam pengembangan, tetapi model pengguna-membayar paling cocok untuk aplikasi frontend dengan login user.

Untuk backend, jalur gratis paling langsung adalah Konsol xAI dengan kredit promosi.

ID model apa yang dipakai untuk Grok 4.3 di Puter.js?

Gunakan:

x-ai/grok-4.3

Untuk xAI langsung, gunakan:

grok-4.3

Apakah kredit gratis mencakup function calling dan input video?

Ya. Kredit Konsol berlaku untuk fitur Grok 4.3 seperti konteks 1M, function calling, input video, dan reasoning effort. Namun, perhatikan penggunaan token karena input besar seperti video dapat menghabiskan kredit lebih cepat.

Bagaimana ini dibandingkan dengan Grok Voice?

Grok Voice memiliki struktur akses yang berbeda. Untuk detailnya, lihat Cara menggunakan Grok Voice secara gratis.

Apakah ada Grok 4.3 mini gratis?

Belum. xAI belum merilis SKU mini terpisah untuk lini 4.3. Alternatif gratis terdekat adalah grok-4-fast:free di OpenRouter, tetapi itu bukan Grok 4.3 penuh.

Ringkasan

Ada tiga jalur yang paling praktis untuk mencoba Grok 4.3 tanpa biaya langsung:

Gunakan Konsol xAI untuk prototipe API produksi.
Gunakan Puter.js untuk aplikasi web publik di mana user menanggung penggunaan mereka sendiri.
Gunakan grok.com atau X untuk validasi manual tanpa kode.

Jika Anda butuh integrasi backend stabil, mulai dari Konsol xAI lalu pindah ke penggunaan berbayar saat kredit habis. Jika Anda membangun tool frontend publik, Puter.js adalah jalur paling ringan karena tidak membutuhkan API key dan tidak membebankan biaya ke developer.

Untuk panduan API berbayar lengkap, lihat Cara menggunakan API Grok 4.3. Untuk perbandingan langsung dengan OpenAI, lihat Grok Voice vs GPT-Realtime.

Buat request sekali di Apidog, simpan environment per provider, lalu tukar BASE_URL dan MODEL sesuai jalur yang Anda pilih.

Cara Menggunakan API Grok 4.3

Walse — Fri, 08 May 2026 07:45:44 +0000

xAI meluncurkan Grok 4.3 secara bertahap: beta pada 17 April 2026, akses API pada 30 April, dan ketersediaan umum penuh pada 6 Mei. Rilis ini membawa jendela konteks 1.000.000 token, input video asli untuk pertama kalinya di seri Grok, penalaran selalu aktif, dan penurunan harga sekitar 40% dibandingkan Grok 4.20. Delapan model Grok lama akan dihentikan pada 15 Mei, jadi tim yang masih memakai seri grok-3 atau grok-4 perlu menyiapkan migrasi sekarang.

Coba Apidog hari ini

Panduan ini fokus pada implementasi: cara memanggil Grok 4.3 dari kode, endpoint, autentikasi, URL dasar kompatibel OpenAI, reasoning_effort, input video, function calling, dan setup pengujian di Apidog.

Untuk sisi suara dari rilis yang sama, lihat Cara menggunakan Grok Voice secara gratis. Untuk perbandingan langsung dengan model suara unggulan OpenAI, lihat Grok Voice vs GPT-Realtime.

TL;DR

Grok 4.3 tersedia umum pada 6 Mei 2026.
Delapan model lama dihentikan pada 15 Mei 2026.
Harga:
- $1,25 / 1 juta token input
- $2,50 / 1 juta token output
- $0,20 / 1 juta token input cache
Jendela konteks: 1 juta token.
Mendukung input video asli.
Penalaran selalu aktif.
Nilai reasoning_effort: low, medium, high.
Default reasoning_effort: medium.
Endpoint utama:

https://api.x.ai/v1/chat/completions

Throughput sekitar 159 token/detik pada tingkatan standar.
Indeks Intelijen 53 menurut Artificial Analysis, peringkat ke-10 dari 146 model.
Gunakan Apidog untuk menyimpan request, membandingkan konfigurasi penalaran, dan memutar ulang skenario pengujian.

Apa yang berubah di Grok 4.3

Perubahan yang paling relevan untuk developer:

Harga turun sekitar 40%

Input turun 37,5% dibandingkan Grok 4.20. Output turun 58,3%. Tarif input cache menjadi $0,20 per 1 juta token, sehingga prompt sistem panjang yang stabil menjadi jauh lebih murah.

Konteks naik ke 1 juta token

Sebelumnya Grok 4.20 memiliki konteks 256 ribu token. Dengan 1 juta token, Anda bisa mengirim codebase ukuran sedang, transkrip panjang, dokumen hukum, atau konteks agen yang besar dalam satu request.

Input video asli

Grok 4.3 dapat menerima URL video dan melakukan penalaran pada frame video secara native.

Penalaran selalu aktif

Setiap request selalu memakai penalaran dasar. Anda hanya mengatur tingkat kedalaman dengan reasoning_effort.

Peningkatan alur agentic

Grok 4.3 naik +300 poin Elo pada GDPval-AA dibandingkan Grok 4.20. Dampaknya terlihat pada workflow multi-langkah dan pemilihan tool.

Menurut Artificial Analysis, Indeks Intelijen 53 menempatkan Grok 4.3 di atas rata-rata 35 untuk kelas harganya.

Prasyarat

Sebelum memanggil API, siapkan:

Akun xAI Console di console.x.ai.
API key dari tier yang dapat ditagih.
SDK OpenAI atau SDK xAI.
API client untuk menyimpan dan menjalankan ulang request.

Ekspor API key:

export XAI_API_KEY="xai-..."

Jika memakai Python, siapkan environment:

pip install openai

Endpoint dan autentikasi

Grok 4.3 memakai antarmuka Chat Completions yang kompatibel dengan OpenAI.

POST https://api.x.ai/v1/chat/completions

Header yang dibutuhkan:

Authorization: Bearer $XAI_API_KEY
Content-Type: application/json

Karena kompatibel dengan OpenAI, migrasi biasanya hanya membutuhkan dua perubahan:

base_url
model

Contoh Python:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["XAI_API_KEY"],
    base_url="https://api.x.ai/v1",
)

response = client.chat.completions.create(
    model="grok-4.3",
    messages=[
        {
            "role": "user",
            "content": "Summarize the trade-offs of GraphQL vs REST in three bullets."
        }
    ],
    reasoning_effort="medium",
)

print(response.choices[0].message.content)

Parameter request

Parameter utama untuk Grok 4.3:

Parameter	Tipe	Nilai	Catatan
`model`	string	`grok-4.3`	Wajib
`messages`	array	Format pesan OpenAI	Wajib
`reasoning_effort`	string	`low`, `medium`, `high`	Opsional, default `medium`
`max_tokens`	int	`1–32768`	Membatasi output
`temperature`	float	`0.0–2.0`	Default `1.0`
`top_p`	float	`0.0–1.0`	Nucleus sampling
`stream`	bool	`true` / `false`	Streaming jika `true`
`tools`	array	Format tools OpenAI	Untuk function calling
`tool_choice`	string / object	`auto`, `none`, atau tool tertentu	Semantik OpenAI standar
`response_format`	object	`{ "type": "json_object" }`	Output terstruktur
`seed`	int	integer apa pun	Untuk reproduktibilitas saat `temperature: 0`

Contoh curl:

curl https://api.x.ai/v1/chat/completions \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "grok-4.3",
    "messages": [
      {
        "role": "system",
        "content": "You are a senior backend engineer."
      },
      {
        "role": "user",
        "content": "Review this query plan and flag the bottleneck."
      }
    ],
    "reasoning_effort": "high"
  }'

Respons memakai bentuk standar OpenAI:

{
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "..."
      }
    }
  ],
  "usage": {
    "prompt_tokens": 123,
    "completion_tokens": 456,
    "reasoning_tokens": 78,
    "total_tokens": 657
  }
}

Mengatur `reasoning_effort`

Gunakan reasoning_effort untuk mengontrol kedalaman penalaran.

`low`

Cocok untuk:

klasifikasi
ekstraksi field
ringkasan pendek
Q&A sederhana
routing request

Contoh:

response = client.chat.completions.create(
    model="grok-4.3",
    messages=[
        {
            "role": "user",
            "content": "Classify this ticket as billing, technical, or account."
        }
    ],
    reasoning_effort="low",
)

`medium`

Default. Cocok untuk:

customer support
analisis data ringan
function calling satu langkah
review dokumen
workload produksi umum

response = client.chat.completions.create(
    model="grok-4.3",
    messages=[
        {
            "role": "user",
            "content": "Analyze this API error log and suggest the most likely root cause."
        }
    ],
    reasoning_effort="medium",
)

`high`

Cocok untuk:

agen multi-langkah
debugging kompleks
review kode panjang
perencanaan
matematika atau reasoning yang berat

response = client.chat.completions.create(
    model="grok-4.3",
    messages=[
        {
            "role": "user",
            "content": "Plan a safe migration from monolith to service-based architecture."
        }
    ],
    reasoning_effort="high",
)

Catatan penting: penalaran selalu aktif. Bahkan low tetap melakukan penalaran dasar. Jadi jangan mengasumsikan ada mode “tanpa reasoning”.

Function calling

Grok 4.3 mendukung bentuk function calling standar OpenAI.

Alurnya:

Deklarasikan tool.
Kirim request.
Baca tool_calls dari pesan asisten.
Eksekusi fungsi di aplikasi Anda.
Kirim hasil fungsi sebagai pesan role: tool.

Contoh deklarasi tool:

tools = [
    {
        "type": "function",
        "function": {
            "name": "lookup_user",
            "description": "Look up a user by ID.",
            "parameters": {
                "type": "object",
                "properties": {
                    "user_id": {
                        "type": "string"
                    }
                },
                "required": ["user_id"],
            },
        },
    }
]

Request:

response = client.chat.completions.create(
    model="grok-4.3",
    messages=[
        {
            "role": "user",
            "content": "Find user u_42 and tell me their last login."
        }
    ],
    tools=tools,
    reasoning_effort="medium",
)

message = response.choices[0].message
tool_calls = message.tool_calls

print(tool_calls)

Contoh eksekusi sederhana:

def lookup_user(user_id: str):
    return {
        "user_id": user_id,
        "last_login": "2026-05-07T10:15:00Z"
    }

Lalu kirim hasil tool kembali ke model:

import json

tool_call = tool_calls[0]

tool_result = lookup_user(
    user_id=json.loads(tool_call.function.arguments)["user_id"]
)

follow_up = client.chat.completions.create(
    model="grok-4.3",
    messages=[
        {
            "role": "user",
            "content": "Find user u_42 and tell me their last login."
        },
        message,
        {
            "role": "tool",
            "tool_call_id": tool_call.id,
            "content": json.dumps(tool_result),
        },
    ],
    tools=tools,
)

print(follow_up.choices[0].message.content)

Jika Anda menguji workflow tool atau server MCP, lihat pengujian server MCP di Apidog.

Input video

Grok 4.3 adalah model Grok pertama dengan input video asli.

Contoh request:

response = client.chat.completions.create(
    model="grok-4.3",
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Describe what happens in this clip and flag any anomalies."
                },
                {
                    "type": "video_url",
                    "video_url": {
                        "url": "https://example.com/clip.mp4"
                    }
                },
            ],
        }
    ],
)

Hal yang perlu diperhatikan:

Token video dihitung sebagai token input.
Klip panjang dapat menghabiskan konteks dengan cepat.
Jika biaya penting, pangkas video sebelum dikirim.
Anda tidak perlu mengekstrak keyframe manual karena model melakukan penalaran pada frame video secara native.

Memakai konteks 1 juta token

Jendela konteks 1 juta token berguna untuk workload nyata, terutama jika input Anda panjang dan saling bergantung.

Contoh penggunaan:

1. Review codebase

Gabungkan:

diff
file yang berubah
output test
output lint
arsitektur singkat

Lalu minta review:

Review this change for correctness, security issues, and regression risk.
Prioritize findings that can break production.

2. QA dokumen panjang

Masukkan dokumen besar seperti kontrak, SOP, atau laporan audit, lalu ajukan pertanyaan spesifik.

Find all clauses related to data retention, deletion, and third-party processors.
Return clause number, summary, and risk level.

3. Memori percakapan agen

Simpan riwayat percakapan panjang untuk personalisasi atau continuity pada agen.

Input cache seharga $0,20 per 1 juta token membuat prompt stabil lebih murah. Contoh: prompt sistem 400 ribu token yang cacheable akan memakai biaya cache sekitar $0,08 per panggilan, bukan $0,50 jika dihitung sebagai input baru.

Migrasi dari model Grok lama

Delapan model Grok lama akan dihentikan pada 15 Mei 2026 pukul 12:00 PM PT.

Langkah migrasi minimal:

- model="grok-4.20"
+ model="grok-4.3"

Karena format request tidak berubah, sebagian besar integrasi hanya perlu mengganti string model.

Namun, uji dua hal berikut sebelum produksi.

1. `reasoning_effort`

Beberapa model lama tidak menerima reasoning_effort. Grok 4.3 selalu melakukan penalaran.

Jika jalur lama Anda mengandalkan latensi rendah, mulai dengan:

{
  "reasoning_effort": "low"
}

2. Format output

Grok 4.3 cenderung menghasilkan output yang lebih terstruktur dibandingkan Grok 4.20. Jika pipeline Anda memakai regex atau parser rapuh, jalankan regression test.

Untuk perbandingan harga dengan lini OpenAI, lihat Harga GPT-5.5. Untuk model reasoning lain, lihat Cara menggunakan API GPT-5.5.

Pengujian di Apidog

Cara praktis memvalidasi Grok 4.3:

Buat environment Apidog.
Tambahkan variabel:

XAI_API_KEY = xai-...
BASE_URL = https://api.x.ai/v1

Buat request:

POST {{BASE_URL}}/chat/completions

Tambahkan header:

Authorization: Bearer {{XAI_API_KEY}}
Content-Type: application/json

Buat tiga varian body dengan prompt yang sama:

{
  "model": "grok-4.3",
  "messages": [
    {
      "role": "user",
      "content": "Analyze this incident report and identify root cause, impact, and next actions."
    }
  ],
  "reasoning_effort": "low"
}

Ulangi untuk:

"reasoning_effort": "medium"

dan:

"reasoning_effort": "high"

Bandingkan:

kualitas jawaban
latensi
usage.reasoning_tokens
usage.total_tokens
biaya estimasi

Tambahkan varian keempat dengan provider lain jika ingin membandingkan model pada input yang sama.

Unduh Apidog untuk menjalankan perbandingan ini. Untuk strategi pengujian API yang lebih luas, lihat Alat pengujian API untuk insinyur QA.

Batas kecepatan

Batas rate limit di xAI Console bergantung pada tier akun. Rentangnya dapat berubah, jadi gunakan dashboard console sebagai sumber utama.

Throughput sekitar 159 token/detik adalah kecepatan output per stream, bukan total agregat untuk semua request.

Jika terkena rate limit, API mengembalikan status 429 dengan header retry-after.

Contoh backoff sederhana:

import time
from openai import RateLimitError

for attempt in range(5):
    try:
        response = client.chat.completions.create(
            model="grok-4.3",
            messages=[
                {
                    "role": "user",
                    "content": "Summarize this log."
                }
            ],
        )
        break
    except RateLimitError:
        sleep_seconds = 2 ** attempt
        time.sleep(sleep_seconds)

FAQ

Apakah Grok 4.3 kompatibel dengan OpenAI?

Untuk Chat Completions, ya. Gunakan SDK OpenAI, ubah base_url, lalu ubah model.

Function calling, output terstruktur, dan streaming memakai bentuk yang sama.

Apakah Grok 4.3 mendukung Responses API?

Saat ini antarmuka xAI memakai Chat Completions. Responses API adalah antarmuka OpenAI.

Berapa batas konteks dalam praktik?

Batas konteksnya 1.000.000 token. Namun input panjang tetap memiliki biaya, jadi gunakan cache untuk prompt yang stabil.

Bagaimana penalaran selalu aktif memengaruhi latensi?

Latensi token pertama bisa lebih tinggi dibanding model non-reasoning. Namun Grok 4.3 mengalirkan output sekitar 159 token/detik, sehingga waktu respons end-to-end tetap kompetitif untuk workload yang membutuhkan akurasi.

Bisakah Grok 4.3 digunakan dengan Grok Voice?

Ya. Agen suara grok-voice-think-fast-1.0 memanggil Grok 4.3 di balik layar saat melakukan penalaran. Anda juga dapat memanggil Grok 4.3 langsung dari loop suara yang dibangun di atas TTS dan STT.

Apa yang terjadi dengan panggilan Grok lama setelah 15 Mei?

Panggilan ke model yang dihentikan akan gagal dengan 410. Migrasikan sebelum batas waktu.

Apakah Grok 4.3 mendukung input gambar?

Ya. Selain input video baru, Grok 4.3 juga mendukung input gambar. Gunakan URL gambar dalam blok konten dengan pola yang kompatibel dengan OpenAI.

Ringkasan

Grok 4.3 membawa kombinasi yang kuat untuk workload produksi: harga lebih rendah, konteks 1 juta token, penalaran selalu aktif, input video asli, dan kompatibilitas OpenAI.

Jalur migrasi paling cepat:

Ubah base_url ke https://api.x.ai/v1.
Ubah model ke grok-4.3.
Tambahkan atau uji reasoning_effort.
Jalankan regression test pada output.
Bandingkan low, medium, dan high di Apidog.
Migrasi sebelum 15 Mei 2026.

Forem: Walse

GPT-5.5 Pro vs Instant: Kapan Harga 6x Lebih Mahal Sepadan?

TL;DR

Pendahuluan

Dua model di balik keluarga GPT-5.5

Delta akurasi: kapan Pro lebih unggul?

Bandingkan Instant dan Pro pada prompt Anda sendiri

Perhitungan biaya: kapan 6x sepadan?

Fitur 1: bot dukungan pelanggan

Fitur 2: asisten review kode

Fitur 3: ringkasan dokumen hukum

Rule of thumb untuk break-even

Uji tradeoff Pro/Instant dengan Apidog

Teknik lanjutan

1. Route berdasarkan fitur, bukan pengguna

2. Gunakan Pro sebagai jalur eskalasi

3. Cache prompt sistem

4. Gunakan Batch untuk workload non-real-time

5. Jangan selalu memenuhi context window

Kesalahan umum

Kasus penggunaan dunia nyata

Triase klaim asuransi

Asisten review kode

Ringkasan penerimaan rumah sakit

Kesimpulan

FAQ

Cara Memvalidasi Respons API dalam Pengujian Playwright

TL;DR

Pendahuluan

Celah antara tes Playwright dan penegasan API

1. Regresi bentuk payload

2. Penyimpangan logika bisnis

3. Jalur error tidak diuji

Cara berbagi fixture antara Playwright dan Apidog

1. Buat fixture Playwright untuk API

2. Gunakan fixture di spesifikasi Playwright

3. Impor OpenAPI yang sama ke Apidog

Menyiapkan alur kerja Apidog + Playwright

Langkah 1: Simpan satu spesifikasi OpenAPI di repo

Langkah 2: Sambungkan Playwright

Langkah 3: Tambahkan skenario Apidog

Langkah 4: Gunakan page.route untuk isolasi UI

Langkah 5: Jalankan Playwright dan Apidog di CI

Langkah 6: Tambahkan deteksi schema drift

Teknik lanjutan dan kiat profesional

Aktifkan Playwright trace

Gunakan mock server Apidog untuk mode offline

Batasi retry

Gagal tertutup pada schema drift

Tag test berdasarkan prioritas

Kesalahan umum yang harus dihindari

Alternatif dan perbandingan alat

Kasus penggunaan dunia nyata

Checkout e-commerce

Dashboard SaaS dengan data grafik

Workflow berbasis webhook

Kesimpulan

FAQ

Bisakah saya memvalidasi API dalam tes Playwright tanpa Apidog?

Apakah saya memerlukan spesifikasi OpenAPI?

Bagaimana cara menangani autentikasi di kedua alat?

Bisakah skenario Apidog menggantikan Playwright?

Bagaimana jika staging backend tidak stabil?

Bagaimana menjaga CI tetap cepat?

Apakah saya memerlukan paket Apidog berbayar untuk CI?

OpenAI Daybreak vs Claude Mythos: Perbandingan dan Keunggulannya

Jawaban singkat

Perbandingan berdampingan

Apa itu Claude Mythos

Apa itu OpenAI Daybreak

Kemampuan: di mana Mythos unggul

1. Penemuan kerentanan

2. Reproduksi eksploitasi

3. Penalaran jangka panjang

4. Evaluasi independen

Ketersediaan dan workflow: di mana Daybreak unggul

1. Distribusi lebih terbuka

2. Integrasi dengan repository

3. Ekosistem mitra lebih luas

4. Jalur adopsi lebih realistis

Langkah 4: Gunakan `page.route` untuk isolasi UI

Seberapa akurat `response.usage` dibandingkan dashboard OpenAI?

Melewatkan `initialize`