1. Bertanya soal maskot situs, AI malah menciptakan tokoh baru
Sebuah situs kecil terus menerbitkan artikel dengan bantuan AI. Sebagian artikelnya membandingkan kepribadian dengan tokoh Chiikawa, termasuk Hachiware. Ketika AI lain ditanya mengenai maskot situs tersebut, ia justru menyarankan bahwa nama itu mungkin merujuk pada sosok “Hachiware yang merepotkan” dari Chiikawa.
Lho, siapa pula itu?
Maskot buatan situs seolah direkrut masuk ke cerita orang lain. Tanpa melamar, tanpa wawancara, langsung diangkat oleh AI.
Yang bisa dipastikan hanyalah AI memberikan jawaban itu. Tidak ada bukti bahwa AI benar-benar membaca artikel terkait; mungkin ia hanya menghubungkan nama, mungkin juga sekadar mengarang. Tidak ada dasar di sini untuk menganggap sosok tersebut tokoh resmi. Jawaban AI yang terdengar yakin bukan bukti kebenaran.
2. Di belakang layar, pabrik artikelnya terus bekerja
Alurnya menulis artikel, memperjelas bahasa, membuat versi lengkap dalam dua belas bahasa, memeriksa, menerbitkan, lalu membagikan tautan. Kalau proses berhenti, penyebabnya dicari, diperbaiki, dan diperiksa lagi.
Laporan kemajuan pun berubah menjadi drama berseri.
AI A: “Masalah penerbitan sudah diperbaiki.”
AI B: “Semua pemeriksaan lulus.”
AI C: “Ada penyebab berhenti yang lain.”
Pengawas: “Tambahkan petugas perbaikan.”
Pembaca: “Laporan kemajuannya sebentar lagi lebih panjang daripada artikelnya.”
Di balik lelucon itu ada perbedaan penting: menyimpan perbaikan tidak sama dengan membuktikan halaman publik sudah benar. Pabrik konten juga memerlukan bengkel perawatan.
3. “Sudah 1.900 artikel?” Periksa dulu cara menghitungnya
Setidaknya ada lima jenis angka yang sering disebut jumlah artikel:
- Artikel asli: tulisan berbeda dengan gagasannya sendiri.
- Halaman per bahasa: terjemahan dari artikel yang sama.
- Selesai tetapi belum tayang: tulisan yang masih menunggu pemeriksaan atau penerbitan.
- Sudah tayang: halaman yang benar-benar bisa dibuka pembaca.
- Rute situs: mungkin termasuk halaman menu, aplikasi, dan halaman nonartikel.
Contohnya, 1.000 artikel asli yang tayang dalam dua belas bahasa dapat menghasilkan sampai 12.000 halaman berbahasa. Itu bukan 12.000 gagasan yang berbeda.
Dalam satu catatan operasional terlihat 15.862 rute situs. Angka itu bukan berarti ada 15.862 artikel asli berbahasa Jepang. Klaim “1.900 artikel” perlu dilengkapi tanggal, satuan, dan status tayang. Kalau semuanya dijumlahkan begitu saja, bagian statistik pasti pusing.
4. Repositori GitHub ternyata mencapai sekitar 2,46 GB
Pada contoh yang telah dianonimkan, GitHub melaporkan ukuran 2.400.972 KiB, sekitar 2,29 GiB atau 2,46 GB dalam satuan desimal, per 8 Oktober 2026.
“Bukankah artikel hanya berisi teks?”
Repositori bisa juga menyimpan program, terjemahan, daftar penerbitan, hasil pemeriksaan, gambar, audio, dan riwayat perubahan. Namun, angka total itu tidak menunjukkan bagian mana yang paling besar. Perlu pemeriksaan tersendiri. Ukuran yang dilaporkan GitHub juga tidak selalu sama dengan ukuran folder di komputer.
Artikel: “Aku cuma beberapa KB.”
Riwayat: “Versi lamamu kusimpan semua.”
Terjemahan: “Aku mengajak sebelas teman.”
Gudang: “Siapa yang mengizinkan rombongan ini?”
5. Jawabannya: GitHub Free bukan “total 5 GB, lalu otomatis bayar”
Untuk repositori Git biasa, GitHub tidak menetapkan satu jatah total penyimpanan gratis dalam GB yang otomatis berubah menjadi tagihan ketika dilewati. Lima gigabita adalah anjuran ukuran, bukan ambang penagihan.
Menurut dokumentasi resmi, ukuran ideal repositori adalah di bawah 1 GB, dan sangat dianjurkan di bawah 5 GB. Dokumen batas operasional lain menyarankan ukuran maksimum 10 GB pada penyimpanan Git yang telah dikompresi di disk. Angka 10 GB juga bukan janji kapasitas gratis yang dijamin.
Jika repositori terlalu membebani layanan, GitHub dapat meminta pemiliknya melakukan perbaikan. Jadi “melewati 5 GB langsung bayar” keliru, dan “gratis berarti gudang tanpa batas” juga keliru.
6. Batas sebenarnya ada dalam kotak berbeda
| Jenis penggunaan | Batas atau jatah gratis |
|---|---|
| Repositori Git biasa secara keseluruhan | Tidak ada satu batas penagihan total GB; ideal di bawah 1 GB, sangat dianjurkan di bawah 5 GB |
| Data Git di disk | Batas maksimum yang dianjurkan 10 GB, bukan ambang biaya |
| Satu berkas biasa | Peringatan di atas 50 MiB, ditolak di atas 100 MiB; unggah lewat peramban maksimal 25 MiB |
| Satu kali pengiriman perubahan | Batas 2 GiB |
| Git LFS untuk berkas besar | GitHub Free mencakup penyimpanan 10 GiB dan transfer 10 GiB; terpisah dari Git biasa |
| Hasil proses GitHub Actions | GitHub Free mencakup penyimpanan hasil 500 MB; biasanya tersedia 2.000 menit eksekusi per bulan |
Semua angka ini bukan satu kuota yang sama. Pemakaian berlebih pada Git LFS, Actions, dan layanan lain mengikuti pengaturan anggaran dan penagihan masing-masing. Repositori biasa sebesar 2,46 GB tidak otomatis menghabiskan kuota hasil Actions 500 MB. Sebaliknya, repositori di bawah 5 GB bisa saja sudah menghabiskan kuota layanan lainnya.
7. Mengapa ukuran tumbuh lebih cepat daripada jumlah artikel
Git menyimpan berkas saat ini sekaligus riwayat perubahannya. Daftar besar yang dibuat ulang tiap jam mungkin terlihat seperti satu berkas pada versi terbaru, tetapi versi lamanya dapat bertahan dalam riwayat. Revisi artikel, terjemahan yang dibuat ulang, catatan pemeriksaan, dan hasil kerja berulang dapat membuat pertumbuhan ukuran tidak sebanding dengan artikel baru.
Namun, Git juga mengompresi dan menyimpan versi yang mirip secara efisien. Satu kali mengubah berkas tidak otomatis menggandakan ukurannya. Penyebab utama tetap perlu diukur.
Naskah asli dan kode cocok disimpan di Git apabila jejak perubahannya bernilai. Hasil yang terus dibuat ulang dan media berukuran besar, bila sesuai, bisa disimpan di luar Git.
8. Bentrokan pekerjaan bisa terjadi sebelum gudang penuh
Ketika beberapa AI hampir bersamaan mengubah berkas yang sama, perubahan bisa saling bertabrakan. Satu perbaikan berhasil, tetapi pekerjaan lain masih membaca daftar penerbitan lama. Artikelnya siap, halaman publik belum berubah.
Jangan langsung menyimpulkan “GitHub kehabisan kapasitas”. Ukuran, frekuensi perubahan, penulisan bersamaan, dan keberhasilan penerbitan adalah masalah yang berbeda.
Periksa urutannya: apakah naskah terbaru ada; apakah lolos pemeriksaan; apakah benar-benar dikirim ke sistem publik; dan apakah halaman yang dibuka pembaca menampilkan isi baru? Rayakan laporan “berhasil diperbaiki” setelah tahap keempat.
9. Empat cara agar sistem gratis tetap sehat
Ukur sebelum menghapus. Periksa berkas besar dan riwayat, bukan hanya angka ukuran total. GitHub juga memperkenalkan alat seperti git-sizer.
Pisahkan hasil sementara. Daftar otomatis yang sering dibuat ulang, catatan sesaat, gambar, dan audio tidak selalu perlu tersimpan selamanya dalam riwayat Git.
Kurangi penulisan ulang yang sia-sia. Perubahan kecil yang tidak terkait seharusnya tidak memicu pembuatan ulang daftar besar. Setelah bentrok, baca kembali keadaan terbaru dan periksa hasil akhirnya.
Jangan sembarangan mengubah riwayat. Menghapus berkas pada versi terbaru bisa meninggalkannya dalam perubahan lama. Mengganti riwayat bersama dapat merusak rujukan dan salinan orang lain; periksa dampaknya dan siapkan cadangan terlebih dahulu.
10. Jumlah tulisan kalah penting dari manfaat untuk pembaca
Ribuan naskah dan puluhan ribu halaman terjemahan tidak otomatis menghasilkan pengunjung. Apakah halamannya bisa ditemukan? Apakah informasinya benar? Apakah bahasa terjemahannya alami? Apakah ada gagasan baru, bukan sekadar pengulangan?
Panduan resmi Google menekankan konten orisinal yang bermanfaat bagi manusia. Kebijakannya juga memperingatkan pembuatan banyak halaman bernilai rendah terutama untuk memanipulasi peringkat pencarian. Masalahnya bukan penggunaan AI itu sendiri, melainkan produksi besar-besaran tanpa nilai bagi pembaca.
Kisah “Hachiware yang merepotkan” mengingatkan bahwa jawaban AI yang lucu boleh dinikmati sebagai lelucon, tetapi jangan langsung dijadikan informasi resmi.
Pabrik: “Aku akan menambah artikel.”
GitHub: “Aku akan menambah riwayat.”
Pemeriksa: “Aku akan mengurangi kesalahan.”
AI pencari: “Aku akan menambah tokoh!”
Semua: “Yang itu tak perlu ditambah!”
Intinya, 5 GB bukan batas biaya GitHub Free. Kapasitas, penerbitan, kualitas, dan dugaan AI harus diperiksa secara terpisah. Keberhasilan sesungguhnya adalah informasi tepercaya yang sampai kepada pembaca, bukan sekadar jumlah berkas tersimpan.
