Tugas Rutin Tidak Butuh AI: Memindahkan Cek Cuaca dari Agent ke Script, dari 32 Ribu Token ke Nol

Setiap dua jam, sebuah agent AI di server saya bangun, mengecek cuaca di sekitar rumah, lalu memutuskan apakah perlu mengirim peringatan hujan lebat ke grup keluarga. Hampir selalu jawabannya tidak. Agent menulis NO_REPLY, lalu tidur lagi.

Kedengarannya ringan. Lalu saya melihat catatan run-nya. Satu kali cek menghabiskan sekitar 32.700 token dan butuh lebih dari 20 detik. Dua belas kali sehari, hanya untuk satu pekerjaan, dan hasilnya hampir selalu sama: diam.

Ada satu cek lagi dengan pola yang sama, untuk cuaca kering, setiap tiga jam. Keduanya memakai agent penuh: system prompt, daftar tool, file konteks, lalu model yang membaca data cuaca dan menimbang apakah kondisinya "ekstrem".

Artikel ini membahas kenapa pekerjaan seperti ini boros sejak desainnya, bagaimana saya memindahkannya ke script biasa, angka sebelum dan sesudahnya dari catatan run asli, dan cara mengenali tugas lain di sistem kamu yang bernasib sama.

Kenapa satu cek cuaca bisa makan 32 ribu token

Yang mahal bukan pertanyaannya. Yang mahal adalah semua yang ikut dikirim bersama pertanyaan itu.

Bulan Juni, saya mengaudit pemakaian token semua jadwal di server. Untuk cek cuaca hujan lebat, rinciannya kira-kira begini: system prompt agent sekitar 3.000 token, definisi tool sekitar 6.300 token, file konteks seperti profil pengguna sekitar 4.700 token, dan data cuaca mentah sekitar 10.900 token. Instruksi tugasnya sendiri hanya sekitar 270 token. Jawabannya satu token.

Polanya sama di beberapa pekerjaan lain: input di atas 10.000 token, output di bawah 1.000. Itu tanda paling jelas bahwa sebagian besar yang dibaca model tidak mengubah hasilnya.

Masalah kedua lebih diam. Pekerjaan berbasis agent ikut mewarisi model default agent. Saat audit Juni, cek cuaca berjalan di model kecil dan memakai sekitar 25.000 token per run. Bulan Oktober, model default agent sudah berganti ke model yang jauh lebih besar, dan tidak ada yang menyentuh jadwal cuaca. Tagihannya naik sendiri.

Masalah ketiga paling berbahaya. Pada 14 sampai 16 Oktober, model yang dipakai sempat tidak bisa diakses. Selama dua hari itu, setidaknya 42 run cek cuaca berakhir error. Kalau hujan lebat datang di jam-jam itu, tidak ada peringatan sama sekali. Pengingat lain di rumah ikut mati dengan cara yang sama, dan ceritanya saya tulis di artikel tentang pengingat yang mati diam-diam.

Padahal keputusan yang diminta dari model sebenarnya hanya aturan: kalau ada kode cuaca badai petir, atau hujan di atas angka tertentu, kirim peringatan. Aturan seperti itu tidak butuh kecerdasan. Cukup if.

Dari agent ke script 90 baris

Audit Juni sudah merekomendasikan pemindahan ke script, dan script versi awalnya sempat dijalankan dalam mode bayangan: menghitung keputusan tanpa mengirim apa pun, untuk dibandingkan dengan agent. Tapi peralihannya tidak pernah diselesaikan, dan agent tetap berjalan sampai Oktober. Itu pelajaran tersendiri: rencana penghematan yang berhenti di tengah tidak menghemat apa pun.

Pada 18 Oktober saya menyelesaikannya. Kedua cek cuaca, bersama 17 pengingat lain yang isinya selalu sama, dipindahkan dari agent ke jadwal tipe command: scheduler langsung menjalankan program, dan apa pun yang dicetak program ke stdout dikirim ke grup WhatsApp. Kalau program tidak mencetak apa-apa, tidak ada yang dikirim. Tidak ada model yang terlibat.

Script cuacanya hanya sekitar 90 baris Python. Ia mengambil data dari Open-Meteo (gratis, tanpa API key), memeriksa kondisi sekarang dan tiga jam ke depan, lalu menerapkan aturan:

• Hujan lebat: kode cuaca badai petir atau hujan deras, atau hujan 10 mm atau lebih dalam satu jam (batas "lebat" yang dipakai BMKG), atau hembusan angin 50 km/jam atau lebih saat hujan.
• Kering: suhu 33°C atau lebih, kelembapan 50% atau kurang, tidak hujan sekarang, total hujan tiga jam ke depan di bawah 0,5 mm, dan peluang hujan di bawah 30%.

Ada jeda supaya peringatan yang sama tidak terkirim berulang selama kondisinya bertahan: tiga jam untuk hujan lebat, dua belas jam untuk kering. Kalau pengambilan data gagal, script mencatat error ke log dan diam, supaya grup keluarga tidak menerima pesan teknis.

Ini catatan run cek hujan lebat sebelum peralihan:

Dan sesudahnya:

Dari 37 run cek hujan lebat setelah peralihan sampai saat artikel ini ditulis, semuanya berhasil, rata-rata 1,4 detik, nol token. Sebelumnya, enam run terakhir rata-rata 22 detik dan sekitar 32.700 token. Untuk dua cek cuaca, dengan 20 run per hari, itu sekitar 650 ribu token sehari yang sekarang tidak dipakai.

Dan script itu tetap bekerja saat dibutuhkan. Pada 19 Oktober jam 12.03, suhu 35,5°C dan kelembapan 38%. Script cuaca kering memicu peringatan, dan peringatan itu terkirim ke grup.

Cara memindahkan tugas rutin dari agent

Contoh ini memakai Python dan scheduler OpenClaw, tapi polanya berlaku untuk cron biasa, GitHub Actions, atau scheduler apa pun yang bisa menjalankan program.

Langkah 1: cari kandidatnya dari catatan run

Kandidat terbaik adalah pekerjaan dengan input besar, output kecil, dan hasil yang hampir selalu sama. Ambil catatan run, lalu hitung rata-rata token dan seberapa sering hasilnya "tidak ada yang dikirim". Script kecil yang saya pakai untuk tabel di atas:

import json, sys
path, start, end, n = sys.argv[1], sys.argv[2], sys.argv[3], int(sys.argv[4])
rows = [x for x in json.load(open(path))['entries'] if start <= x['runAtIso'] < end]
rows.sort(key=lambda x: x['runAtIso'])
for x in rows[-n:]:
    who = x.get('model') or 'script'
    tok = x['usage']['total_tokens'] if x.get('usage') else 0
    print(x['runAtIso'][5:16], who, x['status'], tok, x['durationMs'] / 1000)

Langkah 2: tulis keputusannya sebagai aturan

Baca instruksi yang selama ini diberikan ke agent. Biasanya aturannya sudah ada di sana dalam bahasa manusia, misalnya "trigger hanya jika ada hujan lebat atau badai petir". Terjemahkan menjadi kondisi yang bisa dihitung:

HEAVY_CODES = {65, 67, 82, 95, 96, 99}  # hujan deras dan badai petir (kode WMO)

def triggered(kind, w):
    cur, hr = w['current'], w['hourly']
    rain_h = [p or 0 for p in hr['precipitation']]
    if kind == 'heavy':
        codes = {cur['weather_code'], *hr['weather_code']}
        gust = max([cur['wind_gusts_10m'] or 0, *[g or 0 for g in hr['wind_gusts_10m']]])
        wet = (cur['precipitation'] or 0) > 0 or any(p > 0 for p in rain_h)
        return (bool(codes & HEAVY_CODES)
                or max(rain_h + [cur['precipitation'] or 0]) >= 10
                or (gust >= 50 and wet))
    chance = max([c or 0 for c in hr['precipitation_probability']] or [0])
    return (cur['temperature_2m'] >= 33 and cur['relative_humidity_2m'] <= 50
            and (cur['precipitation'] or 0) == 0 and sum(rain_h) < 0.5 and chance < 30)

Kalau ada bagian instruksi yang tidak bisa diterjemahkan menjadi kondisi, misalnya "nilai apakah situasinya mengkhawatirkan", itu bagian yang masih butuh penilaian. Pisahkan, dan hanya bagian itu yang tetap memakai model.

Langkah 3: uji aturannya dengan contoh kondisi

Sebelum mengganti agent, jalankan fungsi aturan yang sama terhadap beberapa contoh cuaca, termasuk kasus batas seperti gerimis dan angin kencang:

Gerimis tidak memicu apa-apa. Angin 55 km/jam baru memicu karena disertai hujan. Kondisi 19 Oktober memicu peringatan kering. Kalau hasilnya tidak sesuai harapan, perbaiki ambangnya sekarang, bukan setelah ada hujan lebat yang terlewat.

Langkah 4: buat program diam kalau tidak ada yang perlu dikirim

Kontraknya sederhana: cetak teks peringatan ke stdout hanya kalau aturan terpenuhi. Kalau tidak, jangan cetak apa pun. Scheduler yang mengirim stdout ke chat akan otomatis diam. Error dicatat ke file log, bukan ke stdout, supaya tidak sampai ke grup.

Langkah 5: tambahkan jeda untuk peringatan yang sama

Hujan lebat bisa bertahan beberapa jam. Tanpa jeda, grup menerima peringatan yang sama setiap dua jam. Simpan waktu peringatan terakhir di file state, dan lewati kalau belum lewat masa jedanya.

Langkah 6: ganti jadwalnya, lalu bandingkan catatan run

Ubah jadwal dari agent menjadi command. Setelah beberapa hari, bandingkan catatan run sebelum dan sesudah: status, durasi, token, dan apakah peringatan yang seharusnya terkirim benar-benar terkirim. Jangan berhenti di mode bayangan.

Checklist memilih: AI atau script

Pindahkan ke script kalau:

• Output hampir selalu sama, atau hampir selalu kosong.
• Keputusannya bisa ditulis sebagai if dengan angka atau daftar nilai.
• Inputnya data terstruktur, misalnya JSON dari API.
• Kesalahan kecil dalam penilaian tidak bisa ditoleransi, misalnya peringatan keselamatan.
• Pekerjaannya harus tetap jalan walaupun layanan AI sedang bermasalah.

Pertahankan AI kalau:

• Inputnya teks bebas yang harus dipahami, misalnya berita atau pesan orang.
• Outputnya harus ditulis, bukan dipilih dari templat.
• Aturannya terlalu banyak pengecualian untuk ditulis sebagai kondisi.

Kalau setengah-setengah, gabungkan: script menyaring dan menghitung, AI hanya dipanggil untuk kasus yang lolos saringan, dengan input yang sudah diringkas.

Kapan script bukan jawaban

• Angka token sebelum peralihan berasal dari model yang sedang dipakai saat itu. Di model yang lebih kecil, seperti saat audit Juni, angkanya sekitar 25.000 token per run. Penghematannya tetap hampir seluruhnya, karena sesudahnya nol.
• Aturan hanya sebaik ambangnya. Ambang 10 mm per jam dan 33°C adalah pilihan saya untuk lokasi rumah kami. Lokasi lain mungkin butuh angka lain, dan aturan ini belum diuji melewati satu musim hujan penuh.
• Script tidak menjelaskan dirinya. Agent kadang menulis alasannya di catatan run, misalnya bahwa yang terdeteksi hanya gerimis ringan sehingga tidak perlu peringatan. Script hanya mencatat angka di log. Untuk peringatan, saya memilih yang bisa diprediksi.
• Sumber data bisa berubah atau mati. Kalau API cuaca berubah format, script diam dan hanya mencatat error di log. Log itu perlu dicek sesekali, atau ditambah pemeriksaan kesehatan terpisah.

Pekerjaan AI terjadwal yang lebih dari 90% run-nya berakhir tanpa mengirim apa pun hampir selalu kandidat pertama untuk dipindah ke script.