Cara Kawal Kos Ejen AI Sentiasa Aktif di VPS

Cara mengelakkan ejen AI yang sentiasa aktif daripada menyebabkan bil melambung

Kawalan kos ejen AI pada VPS (virtual private server) bergantung pada had yang anda tetapkan sebelum ejen bermula, kerana tiada siapa yang memantau penggunaan semasa ia berjalan. Hadkan setiap respons dengan max_tokens, bataskan lelaran gelung dalam kod anda sendiri, cache bahagian prompt yang tidak pernah berubah, dan log nombor penggunaan setiap respons untuk melihat tugasan mana yang menggunakan kos. Sewa pelayan adalah harga bulanan tetap. API model pula dikenakan bayaran mengikut token, dan gelung tanpa pengawasan sangat cekap dalam menghabiskan token secara senyap.

Ini mengandaikan ejen sudah wujud dan memanggil Messages API daripada pelayan milik anda. Membina ejen AI dengan Claude pada VPS merangkumi mekanisme tersebut.

Mengapa ejen tanpa pengawasan mempunyai struktur kos yang berbeza

Sesi interaktif melibatkan manusia. Apabila model tersilap langkah atau membaca log sepanjang 40,000 baris, pemerhati akan menghentikannya. Ejen tanpa pengawasan tidak mempunyai mekanisme kawalan sedemikian: ia berjalan sehingga gelung tamat, kemudian pemasa memulakannya semula.

Kekerapan ialah pengganda yang sering terlepas pandang. Tugasan yang dijadualkan setiap lima minit berjalan sebanyak 288 kali sehari dan kira-kira 8,640 kali sebulan. Berapapun kos satu larian, itulah angka yang perlu anda darabkan. Banyak ejen "sentiasa hidup" sebenarnya tidak perlu sentiasa aktif. Ia hanya perlu menjawab dalam tempoh beberapa minit, yang bermaksud ia boleh dijadualkan.

Ejen juga menanggung kos untuk perkara yang tidak wujud dalam tetingkap sembang.

• Definisi alatan disertakan dalam setiap permintaan. Prompt sistem penggunaan alatan menelan kos 290 token pada Claude Opus 4.8 dengan tool_choice daripada auto atau none, dan 410 dengan any atau tool. Alatan bash menambah 325 lagi. Setiap pelayan MCP yang anda lampirkan menambah skema masing-masing kepada beban tersebut, memandangkan MCP ialah model context protocol.
• Hasil alatan adalah token input. Perintah yang mencetak 8,000 baris akan memasukkan 8,000 baris ke dalam permintaan seterusnya, dan ke dalam setiap permintaan selepas itu dalam pusingan tersebut.
• Halaman yang diambil adalah token input. Halaman web bersaiz 10 kB secara purata adalah kira-kira 2,500 token dan PDF penyelidikan bersaiz 500 kB adalah kira-kira 125,000 token. max_content_tokens hanya memotong kandungan teks, kerana ia "terpakai pada kandungan teks, bukan kandungan binari seperti PDF". Hadkan PDF dengan max_uses dan allowed_domains sebaliknya.
• Carian web dikenakan bayaran setiap carian, pada harga $10 bagi setiap 1,000 carian, tidak kira berapa banyak hasil yang diperoleh. Carian yang ralat tidak akan dikenakan bayaran.

Tiada satu pun daripada perkara ini mahal jika dilakukan sekali. Semuanya menjadi mahal apabila dilakukan sebanyak 8,640 kali.

Had siling keras dan siling lembut menyelesaikan masalah yang berbeza

max_tokens dikuatkuasakan. Ini merupakan had keras ke atas jumlah output bagi satu permintaan, termasuk teks pemikiran dan respons. Claude tidak akan menjana teks melebihi had ini, dan model tidak dapat melihat angka tersebut. Mencapainya akan menyebabkan stop_reason: "max_tokens" dan jawapan yang terpotong. Perkara yang perlu diberi perhatian oleh ejen: setiap permintaan dalam gelung penggunaan alat membawa max_tokens tersendiri, jadi ia mengehadkan satu respons dan bukannya keseluruhan tugasan. Sepuluh panggilan alat pada 4,000 token bermakna siling 40,000 token bagi setiap giliran.

Bajet tugasan bersifat nasihat. task_budget terletak di dalam output_config dan memberitahu model berapa banyak token yang ia miliki untuk keseluruhan gelung ejen, termasuk pengiraan pemikiran, panggilan alat, hasil alat dan output.

resp = client.beta.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    betas=["task-budgets-2026-03-13"],
    output_config={"task_budget": {"type": "tokens", "total": 64000}},
    messages=messages,
)

"Bajet tugasan ialah petunjuk lembut, bukan had keras." Claude mungkin melebihi bajet di pertengahan tindakan, dan had yang dikuatkuasakan pada output tetap max_tokens. "Kiraan detik hanya boleh dilihat oleh model", dan respons tidak membawa medan baki bajet. task_budget.total minimum yang diterima ialah 20,000 token, dan nilai yang kurang daripada itu akan mengembalikan ralat 400. Bajet yang terlalu kecil untuk tugasan tersebut akan menyebabkan tingkah laku seperti penolakan, jadi model akan mengecilkan skop tugasan atau berhenti lebih awal.

Satu perincian melibatkan kos dan bukannya penjimatan. Jika klien anda mengurangkan task_budget.remaining pada setiap permintaan susulan, nilai yang berubah itu akan membatalkan mana-mana awalan (prefix) yang dicache yang mengandungi nilai tersebut. Tetapkan nilai itu sekali sahaja, pada permintaan pertama.

Bajet tugasan berada dalam fasa beta pada Claude Fable 5, Claude Opus 4.8 dan Claude Opus 4.7. Claude Sonnet 5 dan Claude Haiku 4.5 disenaraikan sebagai Not supported, dan bajet tugasan tidak terpakai pada Claude Code, jadi sesi Claude Code yang dipisahkan dalam tmux bergantung pada kebersihan sesi sebagai gantinya.

Siling ketiga terletak dalam Claude Console: berikan ejen ruang kerja (workspace) sendiri, kemudian tetapkan had perbelanjaan bulanan dan had kadar per minit ke atasnya. "Anda tidak boleh menetapkan had pada Default Workspace", dan "Had seluruh organisasi sentiasa terpakai, walaupun jumlah had ruang kerja melebihi had tersebut". Tambahkan pemberitahuan perbelanjaan supaya ambang had memberi amaran kepada anda sebelum had sebenar dicapai.

Pemilihan model bagi setiap tugasan, dan usaha yang benar-benar membawa perubahan

Pemilihan model adalah keputusan bagi setiap tugasan. Setakat Julai 2026, bagi setiap juta token, input diikuti output: Claude Fable 5 pada $10 dan $50, Claude Opus 4.8 dan Opus 4.7 pada $5 dan $25, Claude Sonnet 5 pada $3 dan $15, Claude Haiku 4.5 pada $1 dan $5. Sonnet 5 berada di bawah harga labelnya buat masa ini, kerana "Harga pengenalan $2/$10 bagi setiap juta token input/output berkuat kuasa sehingga 31 Ogos 2026". Langkah yang hanya mengelaskan baris log tidak memerlukan Opus. Tiada peruntukan percuma untuk menampung jadual yang sibuk, kerana Claude API tidak mempunyai tier percuma selain kredit kecil yang diberikan semasa pendaftaran.

Usaha adalah tuil kedua. output_config.effort menerima low, medium, high, xhigh dan max, dan lalai ialah high, jadi menetapkan high secara eksplisit adalah sama dengan meninggalkannya. Usaha yang lebih rendah memotong lebih daripada sekadar panjang penaakulan: dokumentasi menyatakan ia membuatkan Claude melakukan lebih sedikit panggilan alat dan menggabungkan operasi menjadi satu. Pada ejen, ini merupakan penjimatan yang lebih besar, kerana panggilan alat yang dielakkan adalah satu permintaan penuh yang tidak pernah berlaku.

Perangkapnya ialah usaha menentang cache. Menukar nilai antara permintaan akan membatalkan prompt caching. Dalam contoh yang didokumenkan, permintaan 2 melaporkan cache_read_input_tokens: 3546; permintaan 3, dengan usaha ditukar daripada tinggi kepada sederhana, melaporkan cache_creation_input_tokens daripada 3546 dan cache_read_input_tokens daripada 0. Jadi, ubah usaha merentas beban kerja, jangan sekali-kali di dalam satu perbualan yang dicache. Untuk mengawal kedalaman tanpa merosakkan cache, lakukannya dalam prompt: baris seperti "Jawab terus tanpa berfikir panjang." pada mesej pengguna terbaharu membiarkan breakpoint sebelumnya tidak terjejas.

Token pemikiran dibilkan pada kadar output dan dikira terhadap max_tokens, itulah sebabnya jawapan yang terpotong sering bermakna pemikiran telah menghabiskan bajet. Baca usage.output_tokens_details.thinking_tokens untuk nombor tersebut. Apa yang sebenarnya mengisi bil token Claude membedah meter tersebut.

Cache awalan stabil, dan berhenti merosakkannya secara tidak sengaja

Penulisan cache menelan kos 1.25 kali ganda harga input asas bagi cache lima minit dan 2 kali ganda bagi cache satu jam. Bacaan cache menelan kos 0.1 kali ganda, jadi "caching berbaloi selepas hanya satu bacaan cache untuk tempoh 5 minit (1.25x penulisan), atau selepas dua bacaan cache untuk tempoh 1 jam (2x penulisan)".

Satu baris menjelaskan mengapa ini sesuai untuk ejen yang sentiasa aktif: "Cache disegarkan tanpa kos tambahan setiap kali kandungan yang dicache digunakan." Tugasan yang dijalankan setiap dua minit terhadap cache lima minit mengekalkan awalan (prefix) yang hangat sepanjang hari dengan hanya satu penulisan.

Tiga cara untuk kehilangan cache tanpa disedari.

Awalan yang berubah. "Awalan cache dicipta mengikut urutan berikut: tools, system, kemudian messages." Sebarang perubahan bait yang lebih awal dalam urutan tersebut akan membatalkan segala-galanya selepasnya, dan menyunting definisi alat akan membatalkan keseluruhan cache. Kesilapan klasik yang dilakukan sendiri ialah meletakkan cap masa atau ID larian dalam system prompt: setiap permintaan kemudiannya membawa awalan yang berbeza, menulis entri baharu pada 1.25x, dan tidak membaca apa-apa kembali. Petandanya ialah usage.cache_read_input_tokens pada 0 merentasi panggilan yang kelihatan serupa. Alihkan teks yang tidak stabil ke dalam mesej pengguna yang terbaharu.

Awalan yang terlalu pendek. Setiap model mempunyai panjang minimum yang boleh dicache, dan di bawah tahap itu permintaan diproses tanpa caching dan "tiada ralat dikembalikan". Angka tersebut termasuk 1,024 token pada Claude Opus 4.8 dan Claude Sonnet 5, serta 4,096 pada Claude Haiku 4.5, jadi memindahkan tugasan daripada Sonnet ke Haiku boleh mematikan caching secara senyap.

Perbualan yang melebihi had imbasan balik (lookback). "Tetingkap imbasan balik adalah 20 blok." Sistem menyemak paling banyak 20 kedudukan bagi setiap breakpoint, kemudian berhenti. Dalam contoh yang didokumenkan, giliran yang memegang 35 blok dengan breakpoint pada blok 35 menyemak blok 35 hingga 16, dan entri giliran sebelumnya pada blok 15 berada di luar tetingkap, jadi tiada hit. Ejen yang menambah beberapa blok penggunaan alat dan hasil alat bagi setiap giliran akan melepasi 20 dalam dua atau tiga giliran. Anda mendapat empat breakpoint bagi setiap permintaan, jadi gunakan satu untuk mesej terkini.

Hantar sebarang tugasan yang boleh ditangguhkan ke Batches API

"Semua penggunaan dikenakan caj pada 50% daripada harga API standard", bagi input dan output. Pemprosesan kelompok adalah tak segerak (asynchronous), "dengan kebanyakan kelompok selesai dalam masa kurang daripada 1 jam", dengan hasil diberikan apabila setiap permintaan selesai atau selepas 24 jam, yang mana dahulu. Ini adalah perkara biasa, bukan jaminan.

Lakukan poll processing_status sehingga ia membaca ended. Permintaan yang mengembalikan errored, canceled atau expired tidak akan dibilkan. Satu peringatan jika anda bergantung pada had perbelanjaan: "kelompok mungkin melebihi sedikit had perbelanjaan yang dikonfigurasikan untuk Workspace anda."

Diskaun tersebut terkumpul, dan memandangkan sesuatu kelompok boleh mengambil masa lebih daripada lima minit, dokumentasi mengesyorkan cache satu jam untuk kelompok yang berkongsi konteks. Oleh itu, bahagikan kerja: apa-apa yang ditunggu oleh pengguna atau webhook kekal pada laluan langsung (live path), manakala ringkasan harian atau klasifikasi log semalam dimasukkan ke dalam kelompok pada harga separuh.

Log setiap medan penggunaan respons ke storan anda sendiri

Anda tidak boleh mengaitkan perbelanjaan yang tidak pernah direkodkan. Setiap respons memberitahu anda kosnya.

u = resp.usage
row = {
    "job": job_name,
    "model": resp.model,
    "uncached_input": u.input_tokens,
    "cache_write": u.cache_creation_input_tokens,
    "cache_read": u.cache_read_input_tokens,
    "output": u.output_tokens,
    "stop_reason": resp.stop_reason,
}

Tambahkan satu baris bagi setiap panggilan API ke dalam fail JSON-lines, ditandakan dengan nama tugasan anda. Seminggu kemudian, anda boleh menyatakan tugasan mana yang membelanjakan kos dan mana yang hanya kelihatan sibuk. Perhatikan cache_read: lajur sifar adalah pepijat kos yang paling biasa dalam ejen yang dihoskan sendiri.

Satu medan mudah disalah tafsir. input_tokens hanya mengira token selepas titik henti cache terakhir, jadi saiz prompt sebenar ialah total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Ejen yang melaporkan input_tokens: 400 pada prompt yang besar bukanlah murah: bakinya datang daripada cache.

Kira sebelum anda menghantar. Pengiraan token adalah percuma dan had kadarnya berasingan daripada penciptaan mesej, jadi gunakan count_tokens untuk menolak lampiran yang terlalu besar daripada membayar untuk mengetahuinya. Hasilnya adalah anggaran, jadi buat ukuran semula bagi setiap model dan jangan sekali-kali menggunakan semula kiraan daripada tokenizer vendor lain. Claude Opus 4.7 dan model Opus terkemudian, Claude Fable 5 dan Claude Sonnet 5 menggunakan tokenizer baharu yang "menghasilkan kira-kira 30% lebih banyak token untuk teks yang sama". Claude Sonnet 4.6 dan sebelumnya, termasuk Claude Haiku 4.5, menggunakan tokenizer yang terdahulu.

Untuk pandangan yang berwibawa, Admin API melaporkan penggunaan pada https://api.anthropic.com/v1/organizations/usage_report/messages dan kos pada https://api.anthropic.com/v1/organizations/cost_report. Kedua-duanya memerlukan kunci admin (sk-ant-admin01-...) sebagai x-api-key: $ANTHROPIC_ADMIN_KEY dengan anthropic-version: 2023-06-01, dan menerima bucket_width=1d, group_by[]=model dan api_key_ids[]=. Satu had: "Admin API tidak tersedia untuk akaun individu."

Parameter terakhir itu ialah helah atribusi yang murah: berikan setiap tugasan kunci API sendiri, tapis dengan api_key_ids[], dan pecahkan laporan mengikut kunci dengan group_by[]=api_key_id. Penapis adalah dalam bentuk jamak, dimensi pengumpulan adalah dalam bentuk tunggal. Simpan kunci dalam persekitaran dan bukannya dalam kod, seperti cara aplikasi API Claude pertama pada VPS mengendalikannya.

Hadkan gelung, kerana tiada mekanisme lain yang akan melakukannya

Kiraan lelaran yang dihadkan bukanlah pilihan di sini. Gelung tersebut adalah milik anda, jadi pembilang (counter) juga adalah milik anda:

for step in range(MAX_STEPS):          # MAX_STEPS = 12, never "while True"
    resp = client.messages.create(...)
    if resp.stop_reason != "tool_use":
        break
else:
    log.warning("job %s hit MAX_STEPS=%d, giving up", job_name, MAX_STEPS)

Tiada had siling di atas yang akan melakukannya untuk anda: max_tokens mengehadkan satu respons, dan model hanya dimaklumkan tentang bajet tugasan. Produk yang dihoskan akan menghentikan anda di sini, seperti cara had Claude pada panggilan alat dalam satu pusingan menghentikan sesi yang telah membuat terlalu banyak panggilan, tetapi gelung yang anda tulis sendiri tidak disertakan dengan mekanisme perlindungan sedemikian sehingga anda menambahkannya.

Letakkan brek kedua di luar proses tersebut. Jalankan kerja daripada systemd timer dan bukannya proses kekal, dan tetapkan RuntimeMaxSec= pada unit servisnya. Dengan RuntimeMaxSec=600, proses yang tergantung akan dimatikan selepas sepuluh minit dan bukannya berputar sehingga anda menyedarinya. Menjalankan program sebagai servis dan timer systemd merangkumi fail unit itu sendiri. Baca apa yang dilakukan oleh sesuatu proses dengan journalctl -u triage-agent.service --since "1 hour ago".

Hadkan juga percubaan semula, kerana pengendali yang mencuba semula selama-lamanya akan mengenakan caj bagi setiap percubaan. Ralat 429 atau 500 wajar diberikan beberapa percubaan dengan backoff. Ralat 400 tidak wajar diberikan sebarang percubaan, kerana permintaan yang sama akan gagal dengan cara yang sama.

Kawalan kos ejen AI bermula dengan membaca angka anda sendiri

Tiada sesiapa boleh memberitahu anda kos ejen yang sentiasa aktif, kerana kosnya ialah token bagi setiap larian didarab dengan bilangan larian sehari, dan kedua-dua bahagian ini adalah milik anda. Jalankan ejen sekali, baca baris penggunaan yang anda log, dan darabkan dengan jadual anda. Semak laporan kos dua hari kemudian berbanding pengiraan tersebut. Apabila kedua-duanya tidak sepadan, jurang tersebut hampir selalu berpunca daripada cache yang rosak atau gelung yang berjalan lebih lama daripada yang anda anggarkan.

Ini mengandaikan penggunaan API key, kerana ejen tersebut ialah program anda sendiri yang memanggil Messages API. Untuk kerja interaktif anda sendiri, pelan Claude yang manakah sesuai dengan cara kerja anda merangkumi bahagian langganan. Setiap harga dan had di sini telah disemak berbanding dokumentasi Anthropic pada Julai 2026, jadi baca semula halaman harga sebelum anda membina bajet.

FAQ

Berapakah kos untuk menjalankan ejen AI yang sentiasa aktif pada VPS?

Terdapat dua bil dan hanya satu yang boleh diramal. Pelayan mempunyai harga bulanan tetap. API model pula diukur mengikut token, jadi kosnya adalah hasil darab penggunaan satu larian dengan kekerapan ia dijalankan. Anthropic tidak menerbitkan angka untuk ejen yang dihoskan sendiri dan sentiasa aktif, jadi anggap sebarang nombor yang dipetik sebagai anggaran sahaja. Rekodkan usage daripada satu larian sebenar dan darabkan dengan jadual anda.

Apakah perbezaan antara max_tokens dan bajet tugasan?

max_tokens dikuatkuasakan dan tidak kelihatan oleh model. Ia mengehadkan output satu permintaan, termasuk proses berfikir, dan jika had ini dicapai, ia akan memberikan stop_reason: "max_tokens". Bajet tugasan adalah sebaliknya: model diberitahu tentang nombor tersebut dan melaraskan gelung ejen mengikutnya, namun "Bajet tugasan hanyalah petunjuk lembut, bukan had keras" dan had yang dikuatkuasakan tetap max_tokens.

Mengapa cache_read_input_tokens sentiasa sifar untuk ejen saya?

Ini kerana awalan (prefix) berubah antara panggilan, atau ia terlalu pendek untuk disimpan dalam cache. Punca biasa ialah cap masa atau id larian yang disisipkan ke dalam system prompt: cache dikunci berdasarkan awalan, jadi sebarang perubahan bait akan membatalkan segala-galanya selepas itu. Menukar definisi alat atau nilai effort juga memberikan kesan yang sama. Jika tidak, ia disebabkan oleh saiz, kerana prompt yang lebih pendek tidak disimpan dalam cache dan tiada ralat dikembalikan.

Bagaimanakah cara untuk menghentikan ejen AI daripada bergelung selama-lamanya?

Kira lelaran dalam kod gelung anda dan berhenti pada maksimum yang ditetapkan, kerana max_tokens mengehadkan satu respons manakala ejen melakukan banyak respons. Tambahkan had masa dinding (wall-clock limit) di luar proses: mulakan kerja daripada systemd timer dengan RuntimeMaxSec= ditetapkan, supaya larian yang tersekat akan ditamatkan mengikut jadual. Hadkan juga percubaan semula (retries), kerana gelung percubaan semula akan mengenakan caj bagi setiap percubaan.

Bolehkah saya menetapkan had perbelanjaan pada satu kunci API Claude?

Had perbelanjaan yang didokumenkan adalah mengikut ruang kerja (workspace) dan bukannya mengikut kunci, jadi berikan ejen ruang kerjanya sendiri dan hadkan perbelanjaan bulanannya di situ. "Anda tidak boleh menetapkan had pada Ruang Kerja Lalai". Tambahkan pemberitahuan perbelanjaan supaya ambang tertentu memberi amaran kepada anda terlebih dahulu. Untuk atribusi, keluarkan kunci sendiri bagi setiap kerja, kemudian kumpulkan laporan penggunaan dengan group_by[]=api_key_id.