from math import isfinite
def admit(tokens, last, now, capacity, rate, cost):
values = (tokens, last, now, capacity, rate, cost)
if not all(type(x) in (int, float) and isfinite(x) for x in values):
raise ValueError("finite numbers required")
if not (capacity > 0 and rate > 0 and 0 < cost <= capacity
and 0 <= tokens <= capacity and now >= last):
raise ValueError("invalid bucket state")
refill = min(capacity, tokens + (now - last) * rate)
allowed = refill >= cost
return (refill - cost if allowed else refill, now), allowed| プロジェクト | ちょうど使い切る場合と補充上限を確認し、時刻の逆行、不正な費用、非有限値を拒否します。 |
|---|---|
| 適用前に確認 | 実際の動作を期待する結果と比較します。検証に失敗した場合は、次の変更を加える前に原因を調べてください。 |
| モデル | OpenAI互換またはAnthropicのエンドポイントを、ベースURLと必要なAPIキーで設定し、接続をテストします。ローカルのモデルサーバーは起動が必要です。リモートツールは別途データを送信する場合があります。 |
from math import isfinite
def admit(tokens, last, now, capacity, rate, cost):
values = (tokens, last, now, capacity, rate, cost)
if not all(type(x) in (int, float) and isfinite(x) for x in values):
raise ValueError("finite numbers required")
if not (capacity > 0 and rate > 0 and 0 < cost <= capacity
and 0 <= tokens <= capacity and now >= last):
raise ValueError("invalid bucket state")
refill = min(capacity, tokens + (now - last) * rate)
allowed = refill >= cost
return (refill - cost if allowed else refill, now), allowed方針を変える前に状態遷移を記述する
TokenCoppiceは、AIモデルと状態を持つアプリケーションのコードを調べるWindows用コーディング作業環境です。処理前の状態と処理後に期待する結果を記録するところから始めます。会話に観察可能な仕様ができ、修正案が方針を扱っているのか、単に計算を組み替えているだけなのかを見分けやすくなります。
トークンバケットによる要求の許可判定関数は作業例の一つです。現在の容量、補充、要求コストのルールを議論に持ち込み、許可または拒否後に返す状態をアシスタントに調べてもらいましょう。この例はソースレビューの枠組みを与えます。レート制限サービスの運用は、引き続きアプリケーションとインフラの責任です。
時刻の前提と、次の要求のために保存する状態に注意して遷移案をレビューしてください。残高がコストとちょうど同じ場合や、時間が経過せずに要求が到着する場合などの境界をテストします。これらを自分のプロジェクトで実行し、単独で正しい補助関数なら同時要求でも正しく動くと考える前に、呼び出し元を確認してください。
対応するOpenAI互換またはAnthropicのエンドポイントが提供していれば、フィルターなしと説明されるモデルを選べます。必要な認証情報を設定し、利用できるツールとコンテキストを確認してください。エンドポイントのモデルの動作と制限は引き続き適用されます。採用基準は、アプリケーションで明示した方針とテスト結果に基づきます。
状態を持つ方針の変更に関する質問
許可判定の方針に関する依頼には何を含めるべきですか？
初期状態、要求コスト、時刻値、期待する判定を示します。その後に保存すべき更新値も明記してください。アシスタントは一つの式から方針を推測するのではなく、完全な遷移について考えられます。
正しい補助関数なら同時実行時のレート制限も保証できますか？
いいえ。アプリケーションが共有状態をどう読み書きし、保存先がどのような同時実行保証を提供するか確認してください。単独でテストした補助関数では、同時要求が同じ利用可能残高を消費しないとは確認できません。
拒否した要求は保存状態にどう影響すべきですか？
経過時間に応じた補充とタイムスタンプ更新も含め、方針で明示してください。一見無害な拒否呼び出しでも次の判定に影響する可能性があるため、モデルに遷移案を説明させ、連続した要求をテストしましょう。
本番の許可ルールを変えずに実験できますか？
方針変更を適用する前に、テストデータと開発用アプリケーションで遷移を比較してください。TokenCoppiceはコーディングの議論を支援します。レビューと運用への展開の判断は、プロジェクトの既存手順に従います。
TokenCoppice · 更新日 2026-10-25