Satu chat Qwen untuk dua artikel: followup lewat chat URL

Saya lagi asyik membangun pipeline otomatis untuk blog adityo.web.id. Niatnya simpel: translate artikel bahasa Indonesia ke Inggris pakai Qwen. Tapi kenyataannya? Akun free chat.qwen.ai saya jebol dalam waktu singkat. Setiap kali proses generate berjalan, sistem malah membuka chat baru. Ini jelas boros kuota dan nggak efisien buat skala produksi, apalagi kalau artikel yang harus diproses tiap minggu banyak. Bayangin kalau ada 10 artikel, berarti 10 chat baru yang langsung menggerogoti jatah limit harian.

Awalnya saya kira masalahnya ada di prompt yang kurang efisien atau token limit yang kelewat. Saya coba perpendek instruksi, merapikan konteks, bahkan memecah prompt jadi beberapa bagian kecil. Tapi tetap, tiap proses generate memicu sesi baru. Padahal logikanya, konteks percakapan harusnya masih nyambung dan bisa dipakai ulang buat artikel yang masih satu topik atau satu batch pemrosesan.

Masalah Kuota dan Solusi Chat URL

Solusinya ternyata lebih teknis dari sekadar rapikan kalimat prompt. Saya putuskan buat modifikasi tool generate dengan menambahkan opsi --chat-url. Dengan cara ini, instruksi lanjutan (default translate ke EN) dikirim langsung ke chat yang SUDAH ada, bukan membuat sesi baru dari nol yang memakan kuota tambahan.

Hasilnya langsung kerasa di pemakaian harian. Satu chat = 2 artikel (versi bahasa Indonesia dan Inggris). Output generate sekarang otomatis menyertakan field chat_url di dalam metadata-nya. Field ini jadi penanda supaya sesi lama bisa dipanggil lagi kapan aja tanpa perlu mulai percakapan dari awal. Kayak melanjutkan obrolan dengan teman yang udah paham konteks, bukan kenalan baru yang harus dijelaskan dari nol. Sistem jadi lebih ramping karena nggak perlu memuat ulang konteks yang sama berulang kali, yang juga berarti latency proses generate jadi lebih cepat.

Pelajaran Caching Next.js 15 yang Sering Salah Kaprah

Pas nge-push update ini ke repository, saya malah ketemu pelajaran berharga soal caching di Next.js yang selama ini saya anggap remeh. Sejak Next.js 15, fetch di Server Components nggak di-cache by default [1]. Ini perubahan gede dari versi sebelumnya. Sekarang kita harus eksplisit nyebut cache: 'force-cache' per request, atau menetapkan export const fetchCache = 'default-cache' di level layout atau page [2]. Untuk GET Route Handler, kita harus pakai konfigurasi dynamic = 'force-static' agar data bisa di-cache dengan benar di edge atau server.

Dulu saya sering bingung bedain memoization dan persistent cache. Memoization itu GET dengan URL dan options yang sama dalam satu render pass, itu beda total dengan cache persisten antar request, yang dulu sering saya campur adukkan [3]. Mekanisme force-cache nge-match berdasarkan URL, method, headers, dan body, dan hanya menyimpan respons HTTP 200. Bila ada konfigurasi yang konflik kayak { revalidate: 3600, cache: 'no-store' }, Next.js bakal mengabaikan keduanya dan kasih warning di development. Memahami hal ini bikin tuning umur cache dengan next: { revalidate: N } jadi jauh lebih predictable dan nggak lagi nebak-nebak kenapa data lama masih muncul atau kenapa request malah selalu fresh.

Commit ini juga bawa fitur tambahan yang nggak kalah penting: push tldr-tolerant. Field server kayak id, published_at, dan tldr sekarang dibuang diam-diam saat proses push ulang work file. Tujuannya gampang: arsip lokal nggak bakal lagi bikin validasi gagal hanya karena beda metadata server yang emang nggak relevan untuk proses generate ulang. Sistem jadi lebih forgiving terhadap perbedaan state antara lokal dan server, jadi developer nggak perlu edit manual file JSON cuma buat lulus validasi CI/CD.

Pengalaman ngoprek pipeline ini ngasih tahu satu hal: sistem butuh fallback yang solid. Mirip seperti strategi menjaga jawaban tetap hidup saat LLM mati, atau lane fallback ke router9 di cron yang pernah saya bahas. Begitu kita udah pegang kontrol penuh atas sesi chat dan caching data, mengatur router LLM lewat environment variable juga jadi terasa lebih masuk akal.

Dengan pendekatan ini, pipeline artikel bukan cuma lebih hemat kuota, tapi juga lebih stabil, gampang dirawat, dan siap ngadepin perubahan versi framework tanpa panik. Ini bukan sekadar soal hemat kuota, tapi soal fondasi automation yang nggak gampang rusak pas ada perubahan kecil di struktur data.

Sumber

1. Next.js — Upgrading: Version 15, diakses 3 September 2026.
2. Next.js — fungsi fetch (options.cache, next.revalidate, memoization), diakses 3 September 2026.
3. Next.js — Caching (Previous Model), diakses 3 September 2026.