BerriAI

LiteLLMのHook/Callback/Guardrail入門：発火タイミングと選び方を解説 フックの一覧は公式にある。でも「どこで発火して、何に副作用があって、自作スクリプトをどこへ置くのか」を1枚にした資料は意外と無い。 本記事は、LiteLLM の主要なフック（Hook / Callback）を横断で整理し、発火タイミングと副作用で再分類したうえで、自作ロガーの配置先まで通しでまとめます。前記事「ログ出力のマスク」の続編にあたる、フック選定の地図です。 はじめに LiteLLM には多くのフック（Hook / Callback）があり、公式ドキュメントに一覧も「Which Hook Should I Use?」という表もあります。素材は一次情報として揃っています。 一方で公式は目的別にページが分かれていて（Call Hooks / Custom Callbacks / Guardrails / Observability…）、主要なフックを1枚で、ライフサイクルの発火位置つきで、副作用の有無で再分類したものは見当たりません。「ログだけマスクしたいのに、どのフックを使えばいいのか」で迷った経験から、本記事はその地図を作ります。 ! この記事と前記事の役割分担：マスクの実装詳細（完全版コード・standard_logging_object 問題の原因特定・パススルー経路・fail-closed）は前記事で扱いました。本記事はフックの選び方の地図に専念します。実装の落とし穴は要点だけ触れ、詳細は前記事に誘導します。あわせて読むと「選ぶ→実装する」が一本につながります。 対象読者 LiteLLM でカスタムロガーやガードレールを自作したい方 フックが多すぎて「どれを選べばいいか」で迷っている方 前記事（ログ出力のマスク）を読み、フック全体の地図を掴みたい方 この記事で扱う範囲 主要なフックの3カテゴリ分類（発火タイミング・副作用で再整理） どのフックを選ぶかの判断軸 フックと実装スクリプト（基底クラス）・config.yaml 登録の対応 自作フックの論理配置と、実機（ECS）での物理配布 この記事で扱わないこと ログマスクの実装詳細・完全版コード（前記事を参照） async_logging_hook が効かない原因の深掘り（前記事§4.2。本記事は結論だけ） 検証バージョンについて 本記事の挙動は LiteLLM コンテナイメージ ghcr.io/berriai/litellm:main-latest（main ブランチ先端ビルド、検証日 2026-10-07〜09）で確認した内容です。main-latest は可変タグで、同じタグでも取得時期で中身が変わります。フックの一覧・挙動はバージョンで変わり得るので、再現する場合は digest（@sha256:...）や litellm --version で版を固定してください（固定手順の詳細は前記事の検証環境節にまとめています）。バージョン依存の記述（§5.4 など）は、上記時期の観測結果として扱ってください。 結論 LiteLLM のフックは 3カテゴリ（ロギング系 / Proxy コールフック系 / デプロイメント単位系）で捉えると、候補を素早く絞り込めると判断できる。 選ぶ軸は「発火タイミング」と「回答に副作用があるか」の2つだとわかる。 「回答を壊してよいか」を最初に問えば、ロギング系か改変系かを即断できる。 カスタム実装は多くを CustomLogger 1つで書け、並列モデレーションだけ CustomGuardrail を使うと整理できる。 継承した基底クラスで登録先（callbacks: か guardrails: か）が決まるとわかる。 ! TL;DR LiteLLM のフックは 3カテゴリ で捉えると迷わない。①ロギング系（記録が目的、レスポンスを壊さない）②Proxy 専用コールフック系（リクエスト/レスポンスの改変・拒否ができる）③デプロイメント単位フック系（リトライ・フォールバックの「試行ごと」に発火）。 分類の軸は「発火タイミング」と「呼び出し元への回答に副作用があるか」。この2軸で候補を大きく絞れる。 「ログだけ加工して回答は壊さない」はロギング系、「入力を止める/匿名化する」は Proxy コールフック or Guardrails。役割を混同すると不具合につながる。 自作フックは CustomLogger / CustomGuardrail を継承した .py を書き、config.yaml の callbacks: に インスタンスのドットパスで登録する。実機（ECS）では SSM 経由でコンテナへ配布する方式が運用しやすい。 0. LiteLLM のフックとは（Hook / Callback / Guardrail） 本編に入る前に、3つの言葉を先に整理します。ここが曖昧なまま進むと、後半の「どのフックを、どう登録するか」で迷子になります。 用語 ひとことで 役割 Hook（フック） 「どこで呼ばれるか」 ライフサイクル上の決まった地点で呼ばれる拡張ポイント（メソッド）の総称 Callback（コールバック） 「どう登録するか」 Hook を束ねた実装を LiteLLM に登録する仕組み・登録枠 Guardrail（ガードレール） 「検査・マスクという役割」 入出力の検査・マスク・ブロックを担う機能レイヤー もう少しかみ砕くと、次のとおりです。 Hook … async_pre_call_hook のように、メソッド名が _hook で終わるものが多い。LiteLLM が「この地点に来たらこのメソッドを呼ぶ」と決めた差し込み口。 Callback … config.yaml の callbacks: に CustomLogger 継承クラスのインスタンスを登録すると、そのクラスが実装した各 Hook が呼ばれる。success_callback: ["s3"] のように名前指定で使える組み込み Callback もある（自作不要）。 Guardrail … LiteLLM 側の CustomGuardrail（guardrails: に登録）と、その委譲先の Bedrock Guardrails のような外部サービスの両方を指す。 ! 初見でつまずきやすいのが「Hook と Callback は別物か」という点です。Hook = 差し込み口（メソッド）、Callback = その差し込み口を持つクラスの登録枠、と分けて捉えると混乱しません。本記事は主に「どの Hook を、どの Callback 枠で登録するか」を扱います。 1. 全体像：3カテゴリ × ライフサイクル まずは1枚の図で、フックが発火する位置と役割を俯瞰します。 ! この図は役割と発火位置を掴むための概念図です。成功／ストリーミング／失敗は実際にはどれか1つの経路をたどります（直列ではありません）。ログ系フックどうしの厳密な内部実行順はバージョンや経路に依存するため、並び順は実行順を保証するものではありません。 LiteLLM フックのライフサイクル全体像 図の読み方 上→下が1リクエストの流れ。呼び出し結果 の分岐は、成功（非ストリーミング／ストリーミング）か失敗のいずれか1経路だけをたどる。 オレンジの async_post_call_success_hook は回答本文に副作用がある（ここでマスクすると回答が壊れる）。 緑の async_log_success_event は記録専用で、本文を触っても回答は無傷。本 PoC はここでマスクし、マスク済みデータを自前で S3 に書いた。 灰色のデプロイメント単位フックは、リトライ・フォールバックのたびに発火する別契約。 async_logging_hook（灰色）は設計意図としては「ログ分岐だけに介入する」位置づけだが、本 PoC 環境では書き換えがログ出力に反映されなかった（§5.4・詳細は前記事）。 2. カテゴリ別リスト（主要なフック） 以下は本記事で扱う主要なフックの一覧です。LiteLLM は継続的に機能追加されるため、網羅性は保証しません。各フックの対応範囲（SDK / Proxy）や発火回数は、利用するバージョンの公式ドキュメントで確認してください。 A. ロギング系（記録用・レスポンスは壊さない） CustomLogger を継承して実装。ロギング系の多くは SDK / Proxy の両方で利用できますが、フックごとに対応範囲が異なる場合があります。ここで本文を書き換えても呼び出し元への回答には影響しないのがこのカテゴリの特徴です。 フック名 発火タイミング 典型用途 log_pre_api_call LLM 呼び出し直前（同期） 入力の記録 log_post_api_call LLM 呼び出し直後（同期） 事後記録 log_success_event 成功時（同期） 成功ログ・コスト集計 log_failure_event 失敗時（同期） 失敗ログ async_log_success_event 成功時（非同期） 成功ログ（I/O 向け） async_log_failure_event 失敗時（非同期） 失敗ログ async_logging_hook / logging_hook ログ基盤へ送る直前（分岐のみ） ログ専用マスク（設計意図）。ただし本 PoC 環境では出力に反映されず単体では不可→§5.4 関数ベースの簡易版: litellm.input_callback / litellm.success_callback / litellm.failure_callback。 B. Proxy 専用コールフック系（改変・拒否ができる） CustomLogger（一部 CustomGuardrail）を継承。Proxy のみで動く。リクエスト/レスポンスを改変・拒否できる＝副作用がある。 フック名 発火タイミング 典型用途 async_pre_call_hook LLM 呼び出し前 入力の改変 / リクエスト拒否 / モデル差し替え async_moderation_hook LLM 呼び出しと並列 入力の並列モデレーション（mode: during_call） async_post_call_success_hook 成功後（非ストリーミング） 応答本文の改変・メタデータ付与 async_post_call_streaming_hook 成功後（ストリーミング） ストリーム応答の改変 async_post_call_streaming_iterator_hook ストリーム全体を受け取る ストリーム全体を見るプラグイン async_post_call_failure_hook 失敗後 エラー応答をユーザー向けに変換 async_post_call_response_headers_hook 成功・失敗の両方 HTTP レスポンスヘッダ注入 async_filter_listed_models モデル一覧取得時 呼び出し元ごとにモデルを一覧から隠す ! async_pre_call_hook や async_post_call_success_hook は「改変・拒否」が役割なのに、継承元が CustomLogger（名前は「ログ係」）です。名前と実態がズレて見えますが、LiteLLM では CustomLogger がログ記録とコールフックを束ねた総合ベースクラスになっているための仕様です（公式 Issue でも async_pre_call_hook を「CustomLogger に定義されたフック」と記述）。継承元ではなく override したメソッド名で役割が決まると捉えてください。 C. デプロイメント単位フック系（試行ごとに発火） A の *_log_success/failure_event が「論理リクエスト単位」で呼ばれるのに対し、こちらは「リトライ・フォールバックの実呼び出しごと」に発火するのが基本的な位置づけです。ただし retry / fallback 時に各フックが実際に何回呼ばれるかは、バージョンや設定で挙動が変わり得ます。発火回数に依存した設計をする場合は、対象バージョンで実測して確認してください。 フック名 発火タイミング 典型用途 async_pre_call_deployment_hook 各デプロイ呼び出しの前 試行ごとのリクエスト改変 async_post_call_success_deployment_hook 各デプロイ成功後 試行ごとの成功計測 async_post_call_failure_deployment_hook 各デプロイ失敗後（fallback_depth 付き） 試行ごとの失敗カウント・サーキットブレーカー ! ここでの「デプロイメント」はリリース作業ではなく、ルーティング設定上の個々のモデル接続先（1つの model エントリ）を指す LiteLLM 用語です。1リクエストでも、失敗してリトライ・別接続先へフォールバックすると、その試行回数分だけこのフック群が発火します。 3. どのフックを選ぶか：判断の軸 どのフックを選ぶか：判断フロー 要するに、「回答を壊してよいか」を最初に問うのが近道です。ログだけ加工したいのに post_call 系を触ると、ユーザーが受け取る回答まで変わってしまう——これが前記事で指摘したバグの本質でした。 4. フックとスクリプトの対応関係 「どのフックを、どのスクリプト（基底クラス）で実装し、config.yaml にどう登録するか」を1枚で押さえます。フック名（メソッド）だけ覚えても、継承すべき基底クラスと登録キーがずれると動きません。 フックとスクリプトの対応関係 4.1 対応表 カテゴリ / 代表フック 継承する基底クラス 実装するメソッド config.yaml の登録 スクリプト A. ロギング（async_log_success_event / async_logging_hook 等） CustomLogger 同名メソッドを override litellm_settings.callbacks: {mod}.{instance} 要（自作） B. Proxy コールフック（async_pre_call_hook / async_post_call_success_hook 等） CustomLogger 同名メソッドを override litellm_settings.callbacks: {mod}.{instance} 要（自作・Proxyのみ） B. 並列モデレーション（async_moderation_hook） CustomGuardrail async_moderation_hook guardrails: - guardrail: {mod}.{Class} ＋ mode: during_call 要（自作） C. デプロイメント単位（async_*_deployment_hook） CustomLogger 同名メソッドを override litellm_settings.callbacks: {mod}.{instance} 要（自作） 組み込みログ連携（langfuse / s3 / datadog…） — — litellm_settings.success_callback: ["langfuse"] 等 不要（名前だけ） ポイントは3つです。 本記事で扱うカスタム実装では、A・B・C の多くを CustomLogger で実装できる。その場合、登録は callbacks: にインスタンスのドットパスで済み、実装するメソッド名が役割を決める。 並列モデレーション（async_moderation_hook）だけは別系統。CustomGuardrail を継承し、callbacks: ではなく guardrails: に mode: during_call で登録する。 ただログ基盤に送るだけなら組み込み連携で済み、スクリプトは要らない（success_callback: ["langfuse"]）。ロジックを差し込みたいときだけ自作する。 ! 「フック名・基底クラス・登録キー」の3点セットが噛み合わないと、コードが書けてエラーが出なくてもフックが一度も呼ばれないという形で静かに失敗します。特に並列モデレーションは、他と同じ感覚で CustomLogger ＋ callbacks: にすると動きません。 4.2 1つのクラスに複数フックを同居させてよい フックごとにファイルを分ける必要はありません。CustomLogger を継承した1クラスに必要なメソッドをまとめて override し、インスタンスを1つ登録すればすべて有効になります。PoC の log_masker.py も、同期・非同期の成功イベントを1クラスに同居させています。 1クラスに複数フックを同居させる例（クリックで展開） log_masker.py（1クラスに複数フックを同居させる例・要点） from litellm.integrations.custom_logger import CustomLogger class LogMaskingHandler(CustomLogger): def _handle(self, kwargs, response_obj): ... # マスク → 自前で put_object（共通処理） 非同期パス（acompletion） async def async_log_success_event(self, kwargs, response_obj, start_time, end_time): self._handle(kwargs, response_obj) 同期パス（completion） def log_success_event(self, kwargs, response_obj, start_time, end_time): self._handle(kwargs, response_obj) proxy_handler_instance = LogMaskingHandler() # ← これ1つを callbacks に登録 litellm_settings: callbacks: log_masker.proxy_handler_instance 同期（log_success_event）と非同期（async_log_success_event）の両方を実装しているのは、completion と acompletion のどちらで呼ばれても取りこぼさないためです。共通処理を _handle() に寄せ、各フックは入口として薄く保つのが運用しやすい形です。 5. 自作フックはどこに配置するのか フックの実体は Python クラスです。「論理的な置き場所」と「実機での物理配布」を分けて考えます。 5.1 論理的な置き場所（LiteLLM からどう見えるか） config.yaml から import できる場所（カレント or PYTHONPATH 上）に .py を置き、callbacks: にドットパスで登録します。基本は config.yaml と同階層です。 litellm/ ├── config.yaml └── log_masker.py ← config.yaml と同階層（import できる場所） litellm_settings: callbacks: log_masker.proxy_handler_instance └ファイル名─┘ └インスタンス名────┘ success_callback: [] # ★標準の "s3" は使わない（理由は §5.4） ! callbacks: はクラスではなくインスタンスを指すのが安全です。ファイル末尾で proxy_handler_instance = LogMaskingHandler() を作り、それを参照します。本 PoC では公式のカスタムコールバック手順に従いインスタンスを登録する形で安定動作を確認しました。登録形式を変える場合は、対象バージョンでフックが実際に発火するか（CloudWatch 等のログで）必ず確認してください。 サブディレクトリに置くならパッケージパスで書きます（例：handlers.log_masker.proxy_handler_instance）。 5.2 クラスの骨格（実装の要点だけ） PoC では「ログだけマスク」を確実に効かせるため、async_logging_hook ではなく async_log_success_event の中でマスク済みデータを自分で S3 に書く方式を採りました（理由は §5.4）。 クラスの骨格（抜粋・クリックで展開）# log_masker.py（抜粋・要点のみ。完全版は前記事を参照） from litellm.integrations.custom_logger import CustomLogger class LogMaskingHandler(CustomLogger): def _handle(self, kwargs, response_obj): masked_messages = _mask_messages(kwargs.get("messages")) # 入力をマスク masked_response = _mask_response_text(response_obj) # 応答をマスク record = {"call_id": kwargs.get("litellm_call_id"), "messages": masked_messages, "response": masked_response, "mask": "bedrock-guardrail"} _write_s3(record, record["call_id"]) # 自前で put_object async def async_log_success_event(self, kwargs, response_obj, start_time, end_time): self._handle(kwargs, response_obj) proxy_handler_instance = LogMaskingHandler() # ★ここを callbacks から参照 マスクは Bedrock Guardrails の ApplyGuardrail に委ねます。Guardrail ID / バージョン / S3 バケットは環境変数で注入します（コードに機微情報を書かない）。 ! 本 PoC では ApplyGuardrail を入力・出力とも source="OUTPUT" で呼んでいます（本 PoC の Guardrail が OUTPUT 側でのみ PII 検知有効だったため）。source の選び方・fail-closed 設計・パススルー経路での本文の在り処（request_data）といった実装の勘所は、前記事で完全版コードとともに詳説しています。移植時は必ず自分の Guardrail で検証してください。 5.3 実機（ECS）での物理配布：SSM 経由 PoC（ECS Fargate）では、log_masker.py をイメージに焼き込まず、Terraform テンプレート → SSM Parameter Store → ECS 起動時にコンテナへ書き出しという流れにしました。イメージを作り直さずスクリプトを差し替えられ、Terraform で一元管理できるためです。 自作フックの配置：SSM 経由でコンテナへ配布 ! SSM Parameter Store の値サイズ上限は Standard tier が最大 4 KB、Advanced tier が最大 8 KB です。log_masker.py が 4 KB を超えて Standard tier でエラーになったため、Advanced tier に切り替えて解決しました（低額課金）。8 KB も超えるならコメント圧縮か S3 配布に切り替えます。 ローカルや単純な Docker 構成なら、「config.yaml と同じフォルダに .py を置いてイメージに同梱」で十分です。SSM 経由は運用の都合であって、フックの仕組み上の必須要件ではありません。 5.4 落とし穴：async_logging_hook 単体では効かない（結論） 「ログだけ加工する」なら設計意図上は async_logging_hook が正解に見えます。しかし本 PoC（main-latest ＋ success_callback: ["s3"]）では、ここで kwargs["messages"] をマスクしても S3 ログに生 PII が残りました。 結論だけ示すと、原因は次のとおりです。 S3 ロガーが参照するのは kwargs["messages"] ではなく standard_logging_object という別ペイロード。 async_logging_hook の書き換えはそちらに伝播しないため、出力に反映されない。 対処：標準の success_callback: ["s3"] を使わず、async_log_success_event の中でマスクして自前で put_object する（§5.2）。これで内部の順序や standard_logging_object に依存しなくなります。 ! 原因特定の過程（デバッグログでフックは呼ばれマスクも成功していたのに S3 は生のまま、という切り分け）と、同趣旨の公式 Issue（standard_logging_object にマスクが伝播しない、LiteLLM 1.90.6 / 1.95.0 で確認）の詳細は、前記事§4.2 にまとめています。内部実装はバージョンで変わり得るため、本記事の記述は上記時期の観測結果として扱ってください。 教訓は明快です。「フックが呼ばれる」ことと「ログ出力に反映される」ことは別物。検証は必ず実際の保存先（S3 の中身）を見て行います。 6. 配置とつなぎ方のまとめ 観点 内容 論理配置 config.yaml と同階層（import できる PYTHONPATH 上）。callbacks: {ファイル名}.{インスタンス名} 参照形式 クラスではなくインスタンスを指す（proxy_handler_instance） 標準コールバック 組み込みログ連携は success_callback: ["langfuse"] 等（Python 不要）。ただし本件は未マスクで書かれるため使わない 実機配布（PoC） ソースは Terraform テンプレート → SSM(Advanced) → ECS 起動時にコンテナへ書き出し 機密の扱い Guardrail ID / S3 バケット等は環境変数で注入、コードに直書きしない まとめ LiteLLM のフックは A. ロギング / B. Proxy コールフック / C. デプロイメント単位 の3カテゴリで捉える。 選ぶ基準は「回答を壊してよいか」と「いつ介入するか」の2軸。ログだけ加工ならロギング系、入力を止める/匿名化するなら pre_call 系。 カスタム実装は A/B/C の多くを CustomLogger で書け（callbacks: に登録）、並列モデレーションだけ CustomGuardrail（guardrails: に during_call）、ただのログ連携は組み込みでスクリプト不要。 自作フックは CustomLogger を継承した .py を書き、config.yaml の callbacks: にインスタンスのドットパスで登録。1クラスに複数フックを同居させてよい。実機は SSM 経由配布が扱いやすい。 「フックが呼ばれる」と「出力に反映される」は別物。保存先の中身で検証する。 フックの一覧を眺めるだけでは選べません。発火タイミングと副作用で地図を持っておくと、実装でもトラブルシュートでも迷わなくなります。 次に試すなら、この地図を手元に置いて「回答を壊してよいか」から1つフックを選び、CustomLogger を継承した最小クラスを callbacks: に登録してみてください。ログマスクの具体的な実装（完全版コード・fail-closed・パススルー経路）と「公式手順が効かない落とし穴」は前記事で詳しく扱っています。 参考リンク Call Hooks（LiteLLM 公式ドキュメント） Custom Callbacks（LiteLLM 公式ドキュメント） Scrub Logged Data（LiteLLM 公式ドキュメント） Bedrock Guardrails（LiteLLM 公式ドキュメント） Logging spec（LiteLLM 公式ドキュメント） standard_logging_object にマスクが伝播しない挙動（BerriAI/litellm Issue #35951、LiteLLM 1.90.6 / 1.95.0 で確認） ! 本記事の外部情報は、ライセンス順守のため各出典の内容を要約・言い換えしています（Content was rephrased for compliance with licensing restrictions）。コード例は PoC 実装（log_masker.py）および公式ドキュメントの構造を参考に、本記事向けに書き起こしたものです。

Deleting the File Didn't Revoke the Key: How LiteLLM 1.107.0 Shipped Malware - Book: System Design Pocket Guide: Fundamentals - The series: Pocket Guides for Developers — 8 short books on agents, RAG, prompts, observability, events, databases and system design — the whole series - My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools - Me: xgabriel.com | GitHub --- On May 27, 2026, at 18:53 UTC, a file called opencode.json landed in the public LiteLLM-Labs/lite-harness repository. It held an administrative key for an internal deployment of the LiteLLM Agent Platform. About three hours later, a follow-up commit deleted the file. In LiteLLM's own words, "nobody followed through on revoking the administrative key" (LiteLLM, Oct 23). On October 21, that key turned out to be the first link in a chain that ended with a malicious litellm==1.107.0 on PyPI and the Docker latest tag pointing at a compromised image (LiteLLM, Oct 21). Everything about the incident below comes from LiteLLM's two postmortems and its October 30 follow-up, plus one download estimate from Wiz. The chain, step by step All times are UTC, from the attack-chain postmortem unless marked otherwise. 1. May 27. The opencode.json commit. The file is deleted three hours later, but the commit stays in public history until October 22, and the key stays valid. 2. October 10, 21:13 to 21:28. The attacker makes authenticated requests to the Agent Platform API with that key. At 21:27:10, one call, GET /api/v1/managed_agents/agents?limit=100, returns the configuration of every managed agent. One of those configs holds the GitHub CLI OAuth token of one of the two owners of LiteLLM's GitHub organization. 3. Why that token was there. The platform opened pull requests, so it needed a GitHub token. It was given the owner's GitHub CLI token instead of a personal access token scoped to the right repositories. The postmortem says "GitHub CLI tokens are not scoped," and that with this one the attacker "had owner capabilities over our GitHub organization." 4. October 10, 22:11 to 22:14. Two throwaway branches, ci-tmp-a351cc and ci-tmp-be33e9, run workflows that post repository secrets to a webhook.site endpoint. The haul includes tokens belonging to two more maintainers. Both runs are deleted within three minutes. 5. October 21, 10:08. Branch protection rejects a push to the private release repository. Five seconds later the owner token pushes it anyway. The change adds a source_owner input to the release workflow, so it can build from any organization. 6. 10:46 to 11:11. Staging runs against the lookalike Berri-AI/litellm, not BerriAI/litellm. At 11:11:18 a second stolen token approves the production gate. LiteLLM had recently relaxed that gate so "any two engineers" could trigger and approve a release. 7. 11:39 to 11:47. Seven malicious wheels go to PyPI. Images go to Docker Hub and GHCR under v1.107.0, latest, main-latest and main-stable (LiteLLM, Oct 21). 8. 11:53 onward. A third stolen token deletes the workflow run records. PyPI has removed the release by 13:23, and the last Docker Hub tags are repointed to clean images at 14:20 (LiteLLM, Oct 21). The compromised artifacts were live for "about two hours" (LiteLLM, Oct 23). The release "contained compiled malware which steals credentials and loads remote-code execution tools," and the official v1.107.0 source tag on GitHub never contained the malicious files (LiteLLM, Oct 21). Wiz, citing ClickPy data, put downloads of 1.107.0 at about 49,000 in that window (Security Boulevard). LiteLLM's first post got the token source wrong. It suspected the tokens came from the logs of an internal deployment. The October 23 post says the request logs show the first token came from a different service, the Agent Platform in step 2 (LiteLLM, Oct 23). The steps above follow the corrected account. !A single small key at the start of a long chain whose links pass through a server, a token, a gear and end at a sealed shipping box From one unrevoked key in May to a poisoned release in October. Why deleting the file did nothing A commit that deletes a file adds a new snapshot. The old snapshot, with the key in it, is still reachable by its hash from every clone and fork made in between. GitHub's guide to removing sensitive data lists where an old commit survives even after you rewrite history and force-push: clones, forks, cached views reachable by SHA, and pull requests that reference it. That is why the same guide puts one step first: revoke and/or rotate the secret. Once the key is dead, it says, rewriting history "may not be warranted." A revoked key in public history is harmless. A live key whose file was deleted is still a live key, and this one stayed live for more than four months. Coding agents make the pattern easier to miss. An agent session can add a config file in one turn and remove it in a later one. The pull request's final diff nets the two out, so a reviewer who reads only that diff never sees the key. LiteLLM doesn't say who or what made the May commit, and this post doesn't assume an agent did. The point is that a review of the final diff would have missed it either way. Keep the key out of the file opencode.json is the project config for OpenCode. OpenCode looks for it in the current directory and walks up to the nearest git root, so it sits next to your code by design (OpenCode docs). The same docs give you a way to keep the key out of it: {env:VAR} and {file:path} substitution. This is their example: { "$schema": "https://opencode.ai/config.json", "model": "{env:OPENCODE_MODEL}", "provider": { "anthropic": { "models": {}, "options": { "apiKey": "{env:ANTHROPIC_API_KEY}" } } } } That file can be committed, reviewed and diffed. The key lives in your environment, or in a file under ~ that never enters the repo. Other agents' config files have their own ways to reference a secret; check yours before an agent writes the literal value in for you. Find it in your history, then revoke first git log can search every commit for a string. -S finds commits that change the number of times a string appears, so it catches both the commit that added a key and the one that removed it. -G matches added or removed lines against a regex. -p prints the patch, and --all walks every ref you have locally, not only the current branch. # commits that added or removed the string, any ref git log --all --oneline -S 'sk-' # same commits, with the lines themselves git log --all -p -S 'sk-' # looser: added or removed lines matching a regex git log --all -p -G '(api|API)_?(key|KEY)' # files that were deleted, and in which commit git log --all --diff-filter=D --name-only --oneline Swap sk- for the prefix your provider uses. The last command is the one that surfaces the LiteLLM shape: a config file that exists in history but not in the tree. When something turns up, the order is: 1. Revoke or rotate the key at the provider. Before anything else. 2. Check the provider's logs for use of that key since the commit date. 3. Only then decide whether to rewrite history, knowing clones and forks keep the old commit anyway (GitHub). LiteLLM's October 30 post turns step 1 into process: "Secret scanning must open tickets automatically, and the ticket is only closed when revocation is confirmed" (LiteLLM, Oct 30). !A stack of translucent file layers with a gap where a file was removed from the top layer, while a magnifier shows a key still sitting in a lower layer Deleting the file adds a layer. The key is still in the one below. Scope the gh token your agent session can see Step 3 of the chain is where a leaked platform key became control of a GitHub organization. A service that only needed to open pull requests was holding an owner's CLI login. The same shape exists on a laptop at a smaller scale. A coding agent in your terminal runs as you. If you are logged in with gh, the agent can run gh auth token, which "outputs the authentication token" for your account. And if no credential store is available, gh falls back to writing the token to a plain text file (gh docs). gh reads GH_TOKEN first: the gh environment docs say it "takes precedence over previously stored credentials." So for an agent session, export a fine-grained personal access token limited to one repository, with only the permissions the task needs and an expiry date: # in the shell you start the agent from export GH_TOKEN="$(cat ~/.config/gh-agent/app-repo.token)" gh auth status Two caveats. This changes which token gh uses, not what a process running as you can read; a sandbox or a separate OS user is the stronger boundary. And for automations that act for an organization, GitHub recommends a GitHub App over any personal token (GitHub). LiteLLM landed on the same rules. "Automations will authenticate as a GitHub App or with a fine-grained, expiring token with minimal scopes," and people who run agents in their daily work don't get owner or admin roles (LiteLLM, Oct 30). The same post says the release controls added after March worked as designed but couldn't fully prevent this one, and is blunt about why: "no pipeline controls can defend against an attacker who is an organization owner, because the owner owns the pipeline." Where Hermes fits, and where it doesn't I build Hermes IDE, so weigh this with that in mind. Hermes runs Claude Code, Codex, OpenCode and other agents, each in its own terminal and its own worktree. Hermes never asks for tokens: agents use their own CLI sign-in (README). That also means it doesn't scope what an agent can reach. The GH_TOKEN step above is still yours to do. What it changes is the review. Every agent turn is saved, and the Review Desk (⌘G, or Ctrl+Shift+G on Windows and Linux) shows changes by turn or by file, with risk flags (README). The add-then-delete pattern from earlier doesn't net out there: the turn that wrote the config file shows its own diff, even if a later turn removed the file. !The Hermes Review Desk in By turn view, listing two turns of a Claude Code task with the first turn's diff open The Review Desk (⌘G) in By turn view for a Claude Code task in orders-api: two turns listed, turn 1's diff of src/db.ts open, the changed-files list, and a commit message drafted from the turns. If a turn like that shows a key, the review has done its job, and the next step is still the provider's revoke button. Deleting the file afterwards is what happened in May. Hermes is free, source-available (BSL 1.1), runs on macOS, Windows and Linux, and isn't affiliated with any agent vendor. Download it or read the code on GitHub. --- If this was useful The LiteLLM chain is a design story as much as a security one: one credential reached much further than the service holding it ever needed, and every gate after it trusted that credential. System Design Pocket Guide: Fundamentals is my short read on the core building blocks those systems are made of. It's one of eight short Pocket Guides, covering agents, RAG, prompts, observability, events, databases and system design: the whole series is here. 

LLMJacking: Stolen Credentials Fuel LLM Access Resale and $1M in Cumulative Charges 1. Overview - Article: The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources - Source: Google Threat Intelligence Group - Published: 2026-11-02 - Original: Google Threat Intelligence Group - Related Source: LiteLLM Official Advisory: CVE Matching Check - Related Malware: ai-relay - Related Threat Group: UNC6993 - Related CVE: CVE-2026-40217 (Discrepancy noted between Google's report and LiteLLM's official advisory response) - Related Products: Cloud IAM, LLM API, LiteLLM, new-api, gcli2api - Severity: critical 2. Executive Summary Multiple threat actors are abusing stolen cloud credentials, LLM API keys, and public endpoints to resell LLM quotas to third parties. Mandiant confirmed an incident where a victim organization incurred approximately $1 million in unauthorized usage charges before access was revoked. Note that pathways involving privilege escalation or persistence in cloud environments must be distinguished from pathways that directly abuse LLM API keys or public endpoints. 3. Attack Flow Alternative pathways and monetization flows compiled by Google from multiple response cases. Path A, Path B, and subsequent monetization have different prerequisites and scopes, and the observed tools and actions were not all executed consecutively in a single incident. | Pathway / Phase | Initial Target | Prerequisites and Required Privileges | Confirmed Scope of Impact and Limitations | | --- | --- | --- | --- | | Attack Path A: Compromising Environments via Cloud Credentials | Exposed or stolen IAM credentials, service account keys, GitHub PATs, session tokens, acquired Virtual Keys | Operating permissions allowed by the target ID or vulnerability exploitation (service enablement, key creation, GPU creation require respective privileges) | Credential theft, persistence via admin privileges or SSH keys, LLM enablement and quota expansion (aggregation of multiple incidents) | | Attack Path B: Direct Abuse of LLM API Keys or Public Endpoints | LLM API keys in public repositories, public Ollama endpoints reachable without authentication | Valid API key with inference privileges and quota, or public endpoint accepting requests | Unauthorized execution of inference and attempts to register custom models via /api/create (does not imply obtaining cloud management privileges or GPU creation rights) | | Subsequent Monetization: Resale via LLM Mixers and Proxies | LLM access and quotas secured through Path A, B, etc. | Aggregation and routing of multiple keys via gateways or relay tools | Resale of quotas to third parties and generation of heavy charges (distinct from direct sale of stolen tokens; not all threat actors use the same tools) | Attack Path A: Compromising Environments via Cloud Credentials 1. Using exposed or stolen IAM credentials, service account keys, PATs, or session tokens to access corresponding cloud environments or repositories. 2. Enumerating cloud services, repositories, and data stores depending on the incident to search for additional credentials or high-privilege IDs. 3. When the required privileges are available, attackers expand their privileges or persistence through service account creation, administrator policy attachment, SSH key injection, and token generation. A separate threat cluster was reported to have escalated to LiteLLM administrative privileges using pre-acquired Virtual Keys. 4. Enabling managed LLM services with obtained privileges, creating additional API keys and GPU instances, and requesting quota increases. These operations were observed across multiple separate incidents and were not all executed in a single attack. Attack Path B: Direct Abuse of LLM API Keys or Public Endpoints 1. Sending minimal requests such as max_tokens=1 to LLM API keys found in public repositories to verify their validity has been confirmed. 2. Executing inference within the scope of privileges and quotas of validated API keys. This path alone does not grant cloud-wide management console privileges or GPU instance creation rights. 3. In a separate incident involving a public Ollama endpoint, an attacker called /api/create to attempt registering and executing a custom model. Subsequent Monetization: Resale via LLM Mixers and Proxies 1. Bundling unauthorized LLM access via gateways or relay infrastructure to resell inference quotas to third parties. This is distinct from directly selling stolen tokens themselves. 2. UNC6993 utilizes new-api and gcli2api. Google infers the aggregation and load balancing of stolen keys alongside sales via underground storefronts, though this does not mean all threat actors use the same toolset. 3. In another incident, stolen API keys were used on resale platforms such as jet-night.com and newapi.pro via ai-relay. 4. Attacker Positioning and Execution Locations - Depending on the attack path, access targets include public repositories, public LLM endpoints, cloud IAM, model gateways, and containerized workloads. In paths abusing only LLM API keys, compromise of management consoles or compute instances within the victim's cloud was not confirmed. 5. Perspective of Victims and Administrators Victims - Manifests as a sudden spike in LLM API usage fees, exhausted quotas, unfamiliar model usage, or service suspensions. Administrators - Observed as the enablement of unused LLM services, creation of API keys or service accounts, changes to IAM policies, addition of SSH metadata, repository cloning, access to secret management infrastructure, and creation of GPU instances. 6. Conditions for Success and Failure Success Conditions - In pathways abusing cloud credentials, cloud/repository operations permitted by the ID serve as the starting point. Privilege escalation, LLM service enablement, key creation, and compute creation each require corresponding privileges or vulnerability exploitation. - Pathways abusing LLM API keys require valid keys along with model invocation privileges and quotas, while public endpoint pathways require states that accept requests without authentication or similar constraints. Cloud management privileges are not mandatory for these paths. - In the LiteLLM privilege escalation incident, attackers used pre-acquired Virtual Keys. For discrepancies between CVE numbers and patched version mappings, refer to the caveats in Sections 12 and 14. Failure Conditions and Countermeasures - Apply secret scanning, short-lived credentials, phishing-resistant MFA, the principle of least privilege, explicit Deny rules for unused LLM privileges, and key scope isolation. - Contain damage expansion through model-specific quota limits, budget alerts, rate limits, network allowlists, and prompt updates and protection of model gateways. 7. What Happens Upon Success - Secrets, database passwords, and external service API keys on the cloud are stolen. - Access is persisted via the creation of administrator privilege IDs or the addition of SSH keys. - LLM quotas and GPU compute are abused and resold. Mandiant reported unauthorized usage exceeding $100,000 per day and unauthorized charges reaching approximately $1 million for certain organizations before access was revoked (it is not explained that the entire $1 million occurred in under 8 hours). - The victim organization's account is abused for third-party activities through the resold resources. 8. Observable Logs - Email: Invitation emails or fake portal URL guidance prompting the pasting of raw JSON tokens. - Proxy / SWG / DNS: Traffic records to jet-night.com, newapi.pro, unknown LLM proxies, and public Ollama endpoints. - Endpoint / EDR: Execution of cloud CLIs, repository cloning, external transmission of archives via curl/wget, and modification of SSH keys. - Identity / IdP: Creation of service accounts or access keys, token generation, issuance of federation tokens, administrator policy attachment, and suspicious sessions. - SaaS / Cloud: Enablement of LLM services, model invocations, API key creation, quota increase requests, GPU instance launches, access to secret management infrastructure, and surges in billing amounts. - Network: High-frequency inference requests following validation traffic via minimal requests such as max_tokens=1, burst traffic to multiple regions, and outbound traffic to unknown relay servers. 9. Attack Success Assessment Malware Execution or Authentication Success Confirmed - Judgment Stage: Malware Execution or Authentication Success Confirmed (malware_or_authentication_success) / Scope: Multiple cloud compromise incidents - Basis: Public Information: Google reported multiple incidents where attackers actually accessed cloud environments and LLM APIs using stolen tokens and API keys. Information Theft or Session Compromise Confirmed - Judgment Stage: Information Theft or Session Compromise Confirmed (data_or_session_compromise) / Scope: Multiple cloud compromise incidents - Basis: Public Information: Theft of credentials and secrets from repositories, secret management infrastructure, and data stores has been confirmed. Follow-on Compromise Confirmed - Judgment Stage: Follow-on Compromise Confirmed (follow_on_compromise) / Scope: Monetization of LLM resources - Basis: Public Information: Creation of unauthorized accounts, API keys, and GPU instances, enablement of LLM services, and resale and billing generation via LLM Mixers have all been confirmed. 10. Investigation Playbook Trigger - Use sudden surges in LLM billing, enablement of unused services, creation of unfamiliar API keys or service accounts, and validation traffic with max_tokens=1 as investigation triggers. Initial Triage - Identify billed accounts, invoked models, key IDs, execution principals, source IPs, User-Agents, request frequencies, and the timestamp when services were initially enabled. Endpoint - Preserve processes, SSH keys, startup scripts, containers, repository clone artifacts, archive creation logs, and outbound traffic records for related workloads. Identity / Cloud - Cross-reference IAM change histories, token generation, federation settings, secret access events, PAT usage histories, and GitHub audit logs. Follow-on Compromise - Track the deployment or abuse of new-api, gcli2api, LiteLLM, and ai-relay, unauthorized GPU instances, connections to public proxies, and the theft of credentials for other clouds. Containment - Revoke abused keys, sessions, and tokens, isolate unauthorized IDs and instances, disable unnecessary LLM services and quotas, and rotate related secrets. Assessment - Evaluate key validity checks, cloud logins, secret theft, persistence, resource abuse, and external resale as distinct stages. 11. Defense and Detection Ideas Single Event Detection - Detect the enablement of normally disabled LLM services, generation of PROXY_ADMIN keys, attachment of administrator policies, and addition of SSH keys project-wide. Time-Series Correlation - Correlate key validation via minimal requests, service enablement, key/account creation, quota increases, massive inference invocations, and billing surges as an integrated attack chain. Hunting Perspectives - Uncover LLM API keys, service account JSON files, and PATs lingering in public and private repositories, and cross-reference them with unknown sources in usage logs. Blind Spots in Log Design - Missing model gateway request bodies, key IDs, cloud audit logs, or billing exports will delay the discovery of unauthorized use and the identification of cost sources. Priority Countermeasures - Prioritize migration to short-lived credentials, enforcement of least privilege and key scope limitations, setting quota and budget limits, secret scanning, and gateway vulnerability remediation. 12. Facts / Inference / Hypothesis Facts - In 2026, Mandiant responded to LLMJacking incidents across multiple organizations in North America, South America, and the Asia-Pacific region spanning financial, retail, technology, and transportation sectors. - The primary initial access vector across multiple incidents consisted of exposed or stolen cloud credentials, including IAM credentials, service account keys, GitHub PATs, and valid session tokens. Additionally, public LLM endpoints and LLM API keys found in public repositories were abused. - UNC6993 breached cloud instances using misconfigured service account keys, while another tactic bypassed passwords and MFA via fake portals prompting users to paste raw JSON containing valid access tokens. - Attackers verified LLM API key validity using minimal requests with max_tokens=1 to evade detection triggered by normal traffic volume anomalies. - Following intrusion, activities confirmed included cloud service, repository, and data store enumeration, cloning of private repositories, credential theft from secret management infrastructure, creation of IAM/service accounts, SSH key injection, and administrator policy attachment. - Google reported an incident where pre-acquired Virtual Keys were used to exploit user ID rebind in LiteLLM's /key/regenerate, escalating privileges to PROXY_ADMIN and mapping it to CVE-2026-40217. Meanwhile, LiteLLM's official advisory GHSA-wxxx-gvqv-xp7p describes the same CVE number as a sandbox escape in /guardrails/test_custom_code, meaning target endpoints, prerequisite privileges, and impacts differ, leaving the mapping unresolved. - Attackers enabled managed LLM services, added API keys, created GPU instances, increased quotas, executed burn-and-rotate of service accounts, and resold secured quotas via LLM Mixers or reverse proxies. - Google reported that an attacker performed over 500,000 LLM API invocations in under 8 hours, utilizing stolen API keys for token routing on jet-night.com. In the same Jet Night incident, approximately $1 million in costs was shifted to the victim organization. However, it is not explicitly stated that this billing aggregation period matches the under-8-hour window. In other separate incidents, unauthorized usage exceeding $100,000 per day was observed. Inference - While not all low-priced LLM gateways utilize stolen resources, Google assesses based on matching pricing, scale of usage, and outage patterns that Jet Night relies on stolen keys. Hypothesis No additional hypotheses. Unverified items are documented under "Uncertainties and Limitations". 13. MITRE ATT&CK Mapping | ID | Technique | Confidence | Basis | | --- | --- | --- | --- | | T1078 | Valid Accounts | high | Accessed the cloud using stolen IAM credentials, service account keys, PATs, and session tokens. | | T1098 | Account Manipulation | high | Established persistence through IAM/service account creation, administrator policy attachment, and SSH key injection. | | T1552.001 | Credentials In Files | high | Searched for and stole keys and credentials stored in files within public and private repositories. API access to secret management infrastructure is not included in this mapping. | | T1496 | Resource Hijacking | high | Diverted LLM API quotas and GPU compute to third-party services. | 14. Uncertainties and Limitations - Individual victim organization names, details of all threat clusters, purchasers of resold resources, and total financial damages have not been publicly disclosed. The ~$1 million figure for the Jet Night incident represents an individual case cost reported by Google and is not a general value across all incidents. It remains unspecified whether the billing aggregation period matches the under-8-hour window during which over 500,000 API calls were observed. - Regarding the privilege escalation in LiteLLM /key/regenerate reported by Google, the correct CVE mapping, affected versions, and fixed versions remain unconfirmed. Care must be taken not to directly apply patched versions for alternative endpoints described in the official GHSA as a countermeasure for this vector. 15. Impact on SOCs and Organizations Organizations should treat LLM API keys as high-value cloud resources and monitor service enablement, API key creation, low-volume key-validation requests, quota increases, spikes in inference-token consumption, and billing changes together. They should also investigate GitHub PATs, service account keys, federation tokens, and model gateways across the different intrusion paths that can lead to LLM abuse. 16. Summary by Role - SOC: Correlate validation traffic with max_tokens=1, LLM service enablement, API key creation, quota increases, and spikes in inference requests across a timeline. - Administrators: Design out unnecessary LLM API privileges via explicit Deny rules, enforce key scope isolation, quotas, budget limits, and rotation, and ensure thorough protection and updates for model gateways. - Users: Do not trust external portals demanding cloud tokens or raw JSON pasting, and immediately revoke keys suspected of exposure.

LiteLLM Supply Chain Attack: How Poisoned Version 1.107.0 Stole AI Keys, and How to Check Your Systems On 21 October 2026, a poisoned release of LiteLLM, the open-source gateway many teams put between their apps and OpenAI, Anthropic or Google, sat on PyPI and Docker Hub for about two hours, long enough for roughly 49,000 downloads. It stole whatever keys the machine could reach, and it ran even if your code never imported LiteLLM. This LiteLLM supply chain attack is the project's second of 2026. Below: a quick self-check, the timeline, what to rotate and the build habits that stop the next one. Most of those habits live in your pipeline, which our CI/CD pipelines work sets up. Am I affected by the LiteLLM attack? The 30-second answer You're at risk if any environment installed litellm 1.107.0, or ran a LiteLLM Docker image on a floating tag, on 21 October 2026 during the roughly two-hour window. The malware ran whenever Python started, so if that machine had internet access, assume the keys it could reach were stolen. Pinning 1.106.2 or earlier kept you out of this incident. You're probably affected if: - An environment installed litellm==1.107.0 from PyPI on 21 October 2026, roughly between 11:39 and 13:23 UTC. - A container ran ghcr.io/berriai/litellm or the Docker Hub image with the tag v1.107.0, latest, main-latest or main-stable, pulled between 11:46 and 14:20 UTC that day. - A dependency pulled in LiteLLM unpinned and got 1.107.0. LiteLLM says its private enterprise registry was not touched. The LiteLLM supply chain attack, minute by minute This timeline follows LiteLLM's canonical record of 23 October, which corrected early assumptions it called "inaccurate or incomplete" (times UTC). | When | What happened | | --- | --- | | 27 May 2026 | A master key for LiteLLM's experimental Agent Platform is committed to a public repository in an opencode.json file. The commit is overwritten; the key is never revoked. | | 10 October, 21:27 | Using that key, the attacker gets the Agent Platform API to return a GitHub organisation owner's GitHub CLI token. | | 10 October, 22:11 | With the owner's token, the attacker runs workflows that post CI secrets, including GitHub tokens, to webhook.site, then deletes the runs. A second round follows on 12 October. | | 21 October, 10:08 | The owner's token overrides branch protection on the private release workflow. | | 21 October, 10:46 | A build runs from a lookalike repository, Berri-AI/litellm (the real one is BerriAI/litellm). | | 21 October, 11:11 | A maintainer's stolen token approves the production release gate. | | 21 October, 11:39:51 | Seven malicious litellm==1.107.0 wheels go up on PyPI over 22 seconds. | | 21 October, 11:46:56 | Poisoned images are published to Docker Hub and GHCR. | | 21 October, 11:53 | Another stolen credential deletes the workflow records. | | 21 October, 12:06 | A community member opens GitHub issue #47826 reporting the compromise. | | 21 October, by 13:23 | PyPI quarantines 1.107.0. | | 21 October, 14:20 | The last Docker Hub tags are removed or repointed. | Sources differ on the clean-up times. Datadog and Wiz put PyPI's quarantine at about 13:20 and image removal at about 13:53; LiteLLM says GHCR was clean by 13:51 but Docker Hub tags pointed at the bad image until 14:20. If you pull from Docker Hub, use the later time. The stolen data was used fast. Wiz saw AWS instance-role credentials taken from victims being tested from two IP addresses between 16:20 and 17:01 UTC. Early coverage blamed stolen GitHub CLI tokens from three engineers: broadly right, but the 23 October record adds the first link (an unrevoked key leaked nearly five months earlier) and rules out an early theory that the tokens came from an internal deployment's logs. Why Python .pth startup hooks make this nastier than a normal malicious package Most malicious packages need importing; this one didn't. The wheel dropped three files into site-packages, outside the litellm folder: - cook.pth, containing one line, import cook. - cook.py, the credential stealer. - sitecustomize.py, a backdoor loader. Python reads every .pth file in site-packages each time it starts, executes any line beginning with import, and imports any module called sitecustomize. Python's documentation says these lines "are always run at Python startup ... regardless of whether a particular module is actually going to be used." They're now marked deprecated, but they still run. In practice: - Any Python process ran the stealer: tests, a Jupyter kernel, a cron job. Microsoft saw a Windows case where installing an unrelated dependency triggered it. - pip uninstall litellm doesn't remove it. The files sit outside the package folder. - Checking with Python can re-trigger it. Running python or pip in a suspect environment starts the hooks again. - The source code looked clean. The official v1.107.0 tag never contained the payload. Endor Labs found one added line in the build settings, data = "cook" in pyproject.toml, copied a cook/ folder that isn't in the public source into the wheel. The line worth remembering: with a .pth hook, installing the package is the same as running it, every time Python starts. What the malware stole Microsoft, Datadog and Wiz agree on what cook.py collected: - Cloud: AWS, Google Cloud and Azure credentials, including instance-role credentials from metadata services; Kubernetes, Docker, Vault and Terraform secrets. - Developer secrets: SSH, GPG and TLS keys; Git, npm and PyPI tokens; .env files; shell history; process environment variables. - AI tools: provider API keys and sessions for AI coding assistants, IDEs and MCP configs. - Browsers: saved passwords and cookies. - LiteLLM's own database: up to 500 rows per query from LiteLLM_CredentialsTable and LiteLLM_ProxyModelTable, where the upstream provider keys live. The haul was encrypted and posted to www.litellm.dev/healthcheck, an attacker-controlled lookalike domain. Separately, sitecustomize.py started a background process on Unix-like systems that checked a GitHub file hourly for a server address, then would download and run code from it. That file only ever held test values, so no second stage was seen. Why AI gateways are prime targets An AI gateway exists to hold every provider key so your apps don't have to. One compromised LiteLLM proxy can hand over your OpenAI, Anthropic, Google and Bedrock keys at once, plus its database password and cloud role. In August 2026, Microsoft told defenders to "treat AI gateways as Tier-0 secrets stores", the most sensitive tier, and this payload carried code written specifically to read LiteLLM's credential tables. Prompt injection attacks what an AI system says; this attacked the keys behind it (our prompt injection attack examples cover the other side). How to check if LiteLLM 1.107.0 is on your systems, step by step Microsoft advises inspecting a suspect environment from a clean machine, not by running Python inside it. Even LiteLLM's suggested pip show litellm restarts the hooks, so use it only where you're rebuilding anyway. 1. Search lock files. Look for litellm 1.107.0 in uv.lock, poetry.lock, Pipfile.lock and requirements*.txt in every repository. 2. Look for the files. Search every site-packages for cook.pth, cook.py, sitecustomize.py, __pycache__/cook*.pyc and a litellm-1.107.0.dist-info folder. On Linux or macOS, find / -name cook.pth 2>/dev/null is a start. 3. Check temp files and processes. A Python daemon holding /tmp/remote_code_loader.lock means the backdoor is running. The marker /tmp/.pc_once_72129118c59f5636c0bb means data was sent; its absence proves nothing. 4. Check images by digest. Run docker image ls --digests and look for sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. LiteLLM's post lists separate digests for the litellm-database and litellm-non_root images. 5. Search CI logs and caches. Any job between 11:39 and 14:20 UTC on 21 October that installed LiteLLM unpinned or pulled a floating tag is suspect. Check pip and uv caches and internal mirrors too, because a cached copy can be installed later. 6. Check network logs for connections to www.litellm.dev or the header X-Token: XWiA8gZNa7NcX2XRoAEb. For the March incident, look for versions 1.82.7 and 1.82.8 and a file called litellm_init.pth. What to do if you find it: the response checklist LiteLLM's rule: if 1.107.0 ran on a host with outbound internet access, assume the theft succeeded. 1. Isolate affected laptops, build agents, containers and gateway hosts, and stop automation restarting Python on them. 2. Kill and delete. Stop the daemon holding the lock file and delete cook.pth, cook.py, sitecustomize.py and their .pyc files. Don't run pip install first: it re-runs the hooks. 3. Rebuild, don't repair. Rebuild from scratch, pinned to litellm==1.106.2 or one of the signed releases LiteLLM has shipped since 24 October (such as 1.106.4). 4. Rotate from a clean machine everything the malware could reach (see "What the malware stole" above, and the list below). 5. Hunt for misuse. In AWS CloudTrail, look for GetCallerIdentity and Bedrock listing calls from your roles around install time, and any use of those credentials from outside your network. Check provider dashboards for unexpected spend. Pay special attention to: - Cloud: the instance or task IAM role, not just access keys. - LLM keys: every provider key in the proxy database, plus the master key and all virtual keys. - Database and GitHub: the DATABASE_URL password and gh CLI logins. - Sessions: revoke browser and AI tool sessions too; Microsoft notes that rotating a key doesn't always end live sessions. It's a long list, but it's finite, and every step closes a specific door. How to stop the next one After March, LiteLLM had moved to trusted publishing, immutable Docker tags and signed images. The attacker didn't break those controls; they drove the real pipeline with real credentials, and the build provenance honestly recorded Berri-AI/litellm as the source. The answer is layers, not one control. | Control | What it does | Would it have helped here? | | --- | --- | --- | | Lock files with hashes | Installs exactly the files you tested (uv.lock, poetry.lock, or pip install --require-hashes) | Yes, if you were pinned to 1.106.2 | | Delayed adoption | Ignores releases younger than a set age: uv's exclude-newer = "7 days", pip's --uploaded-prior-to P7D | Yes: both poisoned LiteLLM releases were pulled within hours | | Image digests, not tags | Runs image@sha256:... instead of latest | Yes: floating tags were repointed at the bad image | | Check provenance, not just signatures | Confirms the source repository named in the attestation is the real one | Yes: the provenance named the lookalike fork | | Scoped, short-lived tokens | Uses fine-grained tokens with expiry and OIDC instead of personal CLI logins | Partly: the chain started with a personal owner token and an unrevoked key | | Egress allowlists | Lets gateway and build hosts reach only the APIs they need | Yes: posts to www.litellm.dev would have failed | | Two-person release approval | Requires a second human for each release | Partly: that week LiteLLM had relaxed this rule and temporarily widened release permissions | Three habits matter most: - Delayed adoption is the cheapest win. Both LiteLLM compromises this year were caught the same day, so a seven-day wait would have skipped both. Keep a fast path for real security fixes. - Revoke leaked keys; don't just delete the commit. An overwritten commit doesn't make a key useless; only revoking does. - Fence off the gateway. Give each app its own virtual key with a spend limit, and run the gateway as a non-root container with no other credentials on the host, as in our Docker containerisation work. For CI, our guide to GitHub Actions and AWS OIDC replaces stored keys with short-lived ones. The npm ecosystem learned the same lessons in 2025; our npm supply chain attacks article covers the JavaScript side. The March 2026 incident: same project, different route On 24 March 2026, versions 1.82.7 and 1.82.8 appeared on PyPI from 10:39 UTC and were live for about 40 minutes before quarantine, LiteLLM says. It treats anyone who installed between 10:39 and 16:00 UTC as possibly affected. That attacker skipped the release pipeline: LiteLLM believes the compromise came through Trivy, a security scanner in its CI, and the packages were uploaded straight to PyPI. Version 1.82.8 used the same trick, a litellm_init.pth startup hook. Datadog links March to a campaign called TeamPCP and says no connection to October has been established. Frequently asked questions Is LiteLLM safe to use now? As of 26 October 2026, the malicious 1.107.0 has been removed, 1.106.2 is the last version published before the incident, and LiteLLM resumed releases on 24 October (1.106.4 is the latest) with a new image-signing key. LiteLLM says it is revoking every internal token and has removed GitHub permissions from its release workflow. The problem was the release process, not the code, so pin exact versions by hash and wait a few days before upgrading, whichever gateway you use. What is a .pth file in Python, and why is it dangerous? A .pth file in site-packages normally just adds folders to Python's import path, but any line in it starting with import runs every time Python starts, whether or not your code uses that package. That turns one tiny file into code that runs in every Python process, and it survives pip uninstall. Was the LiteLLM Docker image affected? In October, yes. The images on Docker Hub and GHCR tagged v1.107.0, latest, main-latest and main-stable pointed at a poisoned image from 11:46 UTC until between about 13:51 and 14:20 UTC on 21 October 2026, so anyone running a floating tag could have pulled it without choosing 1.107.0. In the March 2026 incident, the official Docker image was not affected because it pinned its dependencies. The bottom line The way into the LiteLLM supply chain attack wasn't clever: a leaked key nobody revoked, a few personal tokens, and a build tool told to copy one extra folder. The defences are just as ordinary: pin by hash, wait before upgrading, run images by digest, scope your tokens and limit where your gateway can talk to. Treat the box that holds every AI key like the box that holds every password, because it is one. Start today with step 1 of the check above: search your lock files for 1.107.0. Running an AI gateway or a Python build pipeline and not sure how exposed it is? Book a free consultation and we'll go through your dependency pinning, secrets and egress rules with you. Sources - LiteLLM, Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised (21 October 2026, updated 23 October 2026): docs.litellm.ai - LiteLLM, The attack chain behind the v1.107.0 LiteLLM release (23 October 2026): docs.litellm.ai - LiteLLM, Security Update: Suspected Supply Chain Incident (24 March 2026, updated 27 March 2026): docs.litellm.ai - LiteLLM, Announcing CI/CD v2 for LiteLLM (30 March 2026): docs.litellm.ai - GitHub, BerriAI/litellm release v1.106.4 (25 October 2026): github.com/BerriAI/litellm/releases/tag/v1.106.4 - GitHub, BerriAI/litellm issue #47826, litellm 1.107.0 compromised (21 October 2026): litellm#47826 - Microsoft Security Blog, Inside the LiteLLM 1.107.0 supply chain compromise: Credential theft through Python startup hooks (23 October 2026): microsoft.com - Microsoft Security Blog, When AI infrastructure becomes the target: Securing gateways and control points (26 August 2026): microsoft.com - Datadog Security Labs, LiteLLM supply chain compromise: What you need to know (21 October 2026): securitylabs.datadoghq.com - Wiz, LiteLLM Compromised, Steals Credentials (21 October 2026, updated 22 October 2026): wiz.io - Endor Labs, LiteLLM 1.107.0 Compromised: Python Startup Hooks Steal Cloud, AI, and Proxy Credentials (21 October 2026): endorlabs.com - Python documentation, site: Site-specific configuration hook: docs.python.org - pip documentation, pip install (--uploaded-prior-to, --require-hashes): pip.pypa.io - uv documentation, Settings reference (exclude-newer): docs.astral.sh --- Originally published on znovastudio.com.

【一次資料・GitHub】 ■ 実際の不具合報告と再現結果 litellm#48543 ■ 私の独自指摘：料金を決める対象と課金すべき操作の区別 litellm#48543 ■ 開発者による修正・実接続検証・マージ litellm#49392 ■ メンテナによる承認 litellm#49392

LiteLLM 10月28日的补丁修了一个卡请求的细节：原先部分响应在事件循环里做 gzip 压缩，现在只压缩仪表盘统计，交给工作线程处理。 代价也明确：模型推理响应不再压缩，走公网部署时得重新看流量。 BerriAI/litellm

LambdaとBedrockで自作するLLMプロキシ(キー発行・予算・管理UI) 社内でClaude CodeやCodex CLIを使う人が増えてくると、「誰がどのモデルにいくら使っているかわからない」「キーを配るしくみがない」「危ないツールを禁止したい」という話になります。 LiteLLMを立てれば解決しますが、常時起動のコンテナとDBを運用するほどの規模ではなく、依存パッケージの脆弱性を追いかけ続けるのも避けたいと考えました。 そこでAWS LambdaとAmazon Bedrockで、必要な機能だけを持つLLMプロキシを自前で作ってみました。 できあがったものは、Anthropic形式とOpenAI形式の両方を受け付けるプロキシです。Claude以外のBedrockモデルも同じキーで使え、キーやチームごとに使えるモデルやツール、予算などを絞り、1リクエスト1行のログを残します。 キーの発行や利用量の確認は管理UIとCLIからでき、予算の消化が進むと通知が飛びます。固定費はかからず、コードは依存パッケージなしの6ファイル、インフラはTerraformです。 コードはGitHubで公開しています。 upgradeinc-c-m/simple-llm-proxy 構成を決めるまで LiteLLMを使わなかった理由 最初の候補はLiteLLMでした。Virtual Keyの発行、キーごとの予算、Admin UIと、欲しいものは一通りそろっています。 ただし本格的に使うにはECSかEC2で常時起動させ、キー管理のためにPostgreSQLも必要です。使わない時間帯にも課金が続き、LiteLLM本体と依存パッケージのアップデートも追い続けることになります。 今回の要件は「ログと最低限の制限、キーの配布と予算」で、ルーティングやフォールバックのような高度な機能は不要でした。 OpenAI形式とAnthropic形式の変換の対応関係は、LiteLLMの実装を参考にしています。 Lambda Function URLにした理由 サーバレスで受け口を作る選択肢を並べました。 構成 固定費 ストリーミング 所感 ECS/Fargate + LiteLLM 常時起動分 可 機能は豊富だが今回の要件には重い API Gateway + Lambda なし REST APIは可、HTTP APIは非対応 認証をプロキシ側で持つならAPI Gatewayの出番が少ない Lambda Function URL なし 可(RESPONSE_STREAM) 今回はこれ 決め手はストリーミングです。Claude CodeもCodexもストリーミング前提のため、Function URLのInvokeMode: RESPONSE_STREAMでBedrockのイベントストリームをそのまま流せるのが効きました。 詳細はレスポンスストリーミングのドキュメントにあります。 認証はプロキシの中で独自のAPIキーを見るので、Function URLのAuthTypeはNONEにしています。 公開エンドポイントを守っているのはAPIキーの照合と送信元CIDRだけのため、WAFが必要ならCloudFrontを前へ置き、Function URLをAWS_IAMへ変える構成になります(今回は試していません)。 BedrockにはAnthropic形式をそのまま渡せる 転送先をBedrockにしたのは、Anthropic Messages APIのボディをほぼそのまま受けてくれるからです(Bedrockのドキュメント)。 modelを外してanthropic_versionを足すだけのため、プロキシは認証・制限・ログだけを担当し、本文は透過できます。先に直接投げて確かめました。 aws bedrock-runtime invoke-model \ --model-id jp.anthropic.claude-haiku-4-5-20251001-v1:0 \ --body '{"anthropic_version":"bedrock-2023-05-31","max_tokens":64,"messages":[{"role":"user","content":"1+1は？数字だけ答えて"}]}' \ --cli-binary-format raw-in-base64-out /dev/stdout {"model":"anthropic.claude-haiku-4-5-20251001-v1:0","id":"msg_bdrk_...","type":"message","role":"assistant","content":[{"type":"text","text":"2"}],...,"stop_reason":"end_turn",...,"usage":{"input_tokens":21,...,"output_tokens":5,...}} OpenAI形式(Chat Completions、Responses)はLambdaの中でAnthropic形式に変換してから、同じ経路に流します。 モデルは国内で処理したかったのでjp.の推論プロファイルを使っています。 Claude以外のモデル(NovaやLlama)も使いたかったので、モデルIDにanthropic.を含まないものはBedrockのConverse APIに変換して呼ぶようにしました。 Converseはモデル非依存のAPIで、入力も出力もAnthropic形式に機械的に対応づけられます。入口の形式は3つ、上流は2つですが、間はすべてAnthropic形式で統一しているので、組み合わせが増えても変換は増えません。 キーと利用量はDynamoDBに置く 最初はキー設定をSSMパラメータのJSONに手書きしていました。試すには十分でしたが、人に配るには「発行して渡す」「使いすぎたら停止する」が欠かせません。 そこでDynamoDBに1テーブルを用意し、キーの設定(SHA-256ハッシュで引く)、期間ごとの利用量、モデル単価を置きました。平文のキーは発行時に1回表示するだけで、保存しません。 あとからチーム(所属キー全体の予算とレート)、ロール付きの管理トークン、管理操作の監査ログも同じテーブルに足しています。項目の種類は増えましたが、テーブルは1つのままです。 予算の判定に使う費用はこの単価テーブルから計算します。Bedrockの請求とは丸めや単価改定でずれうるので、請求はCost Explorerで見る前提です。 管理操作はプロキシと同じエンドポイントには置かず、IAM権限で動くCLI(keyctl.py)と、別のFunction URLで動く管理UIに分けました。プロキシ本体のLambdaはキーの作成と削除の権限を持ちません。 環境 リージョンはap-northeast-1、Lambdaランタイムはnodejs22.x。 aws-cli 2.38.5、Terraform 1.17.1(AWSプロバイダ6.71.0)、Node.js 22.23.3。 Claude Code 2.1.309、@anthropic-ai/sdk 1.3.0、openai 7.45.1、Codex CLI 0.165.0。 検証日は2026-10-29〜31。 やってみた Terraformでデプロイする リソースはDynamoDBテーブル、ロググループ、IAMロール、Lambda関数、Function URL、ダッシュボード、予算通知用のSNSトピックと、管理UI用のLambda一式です。 コードはarchive_fileでzipにするだけで、ビルドもパッケージ用のS3バケットも不要です。 cd terraform && terraform init && terraform apply Outputs: function_url = "xxxxxxxx.lambda-url.ap-northeast-1.on.aws" admin_url = "yyyyyyyy.lambda-url.ap-northeast-1.on.aws" dashboard_url = "ap-northeast-1.console.aws.amazon.com" keys_table_name = "llm-proxy-keys" log_group_name = "/aws/lambda/llm-proxy" alert_topic_arn = "arn:aws:sns:ap-northeast-1:<account>:llm-proxy-alerts" Function URLをauthorization_type = "NONE"で作ると、AWSプロバイダがlambda:InvokeFunctionUrlとlambda:InvokeFunctionの2つの許可を自動で付けてくれます。 CloudFormationで組んでいたときはこの2つ目を書き忘れて全リクエストが403になりました(後述)。CloudFormationならInvokedViaFunctionUrl: trueのAWS::Lambda::Permissionを追加します。 Claude Codeから使う場合は、Bedrockが受け付けるanthropic-betaだけを許可リストに入れておきます。 terraform apply -var 'allowed_betas=context-management-2025-06-27,interleaved-thinking-2025-05-14' モデル単価を登録してAPIキーを発行する 予算の判定に使う単価を先に入れます。使うモデルの単価を料金ページから転記します。 python3 keyctl.py set-prices 'jp.anthropic.claude-haiku-4-5-20251001-v1:0=1.1:5.5,jp.anthropic.claude-sonnet-4-5-20250929-v1:0=3.3:16.5' キーはCLIか管理UIで発行します。CLIだとこうなります。平文はこのとき1回しか表示されません。 python3 keyctl.py create --name team-a \ --models 'claude-haiku-4-5=jp.anthropic.claude-haiku-4-5-20251001-v1:0,claude-sonnet-4-5=jp.anthropic.claude-sonnet-4-5-20250929-v1:0' \ --deny-tools Bash,exec_command --cidrs 203.0.113.0/24 \ --budget-usd 50 --budget-period monthly --rpm 60 --tpm 200000 --expires-in-days 90 created key_xxxxxxxxxxxx (team-a) API key (shown once, store it securely): llmp_................................................ --modelsはクライアントが送る短い名前とBedrockモデルIDの対応表で、そのまま許可リストにもなります。モデルを差し替えるときにクライアント側の設定を触らずに済みます。 --deny-toolsはリクエストに含まれるツール定義の名前で判定します。大文字小文字を区別するので、Claude CodeならBash、Codexならexec_commandです。 発行後はlistで一覧、usageで期間別の利用量、updateで制限の変更、disableで一時停止、revokeで失効ができます。 平文の漏えいが疑われるときはregenerateで、keyIdと設定と利用量を保ったまま平文だけ作り直せます。旧平文はキャッシュが切れる60秒以内に使えなくなります。 管理UIから発行する場合は、admin_urlを開いてkeyctl.py admin-tokenで作った管理トークンを貼り付けます。 キーごとの状態、モデル、ツール制限、今月のリクエスト数とトークン数、推定費用、予算の消化率が1行で見える 発行直後に平文が1回だけ出る。閉じると二度と取り出せない Claude Codeからつなぐ 接続先と認証トークンの環境変数を差し替えるだけです。モデル名はプロキシ側で決めたエイリアスを指定します。 export ANTHROPIC_BASE_URL=xxxxxxxx.lambda-url.ap-northeast-1.on.aws export ANTHROPIC_AUTH_TOKEN=llmp_... export ANTHROPIC_MODEL=claude-haiku-4-5 export ANTHROPIC_SMALL_FAST_MODEL=claude-haiku-4-5 claude -p "1+1は？数字だけ答えて" 2 ログのtoolsには、Claude Codeがモデルに渡したツール定義の名前が全部並びます。Agent、Bash、Edit、Read、Write、WebFetchにMCPのツール名まで見えるので、プロキシ側からクライアントの顔ぶれがわかります。 ここでBashをdenyしたキーに切り替えると、Claude Codeは起動時に止まります。 Failed to authenticate. API Error: 403 tools not allowed: Bash Codex CLIからつなぐ CodexはOpenAIのResponses APIを話すので、/v1/responsesで受けてAnthropic形式に変換しています。~/.codex/config.tomlでプロバイダを差し替えます。 ~/.codex/config.toml model_provider = "llmproxy" model = "claude-haiku-4-5" [model_providers.llmproxy] name = "llm-proxy" base_url = "xxxxxxxx.lambda-url.ap-northeast-1.on.aws" env_key = "LLM_PROXY_KEY" wire_api = "responses" export LLM_PROXY_KEY=llmp_... codex exec --dangerously-bypass-approvals-and-sandbox "このディレクトリにあるファイル名を列挙して、ファイル名だけ答えて" codex 現在のディレクトリのファイルを確認します。 exec /bin/bash -lc 'ls -1' in /tmp/codex-test succeeded in 0ms: sample.txt # codex sample.txt exec_commandのfunction_call、実行結果の返却、最終回答という往復がプロキシ越しに通りました。 サンドボックスを外すフラグを付けたのは、検証に使ったコンテナでbubblewrapが動かなかったためです。通常のLinuxやmacOSでデフォルトのまま動くかは試していません。 exec_commandをdenyしたキーだと、CodexはERROR: Reconnecting... 1/5から5/5まで再接続を繰り返します。 そのあとでunexpected status 403 Forbidden: tools not allowed: exec_command, write_stdinと出て終了します。Claude Codeのように即座には出ません。 OpenAI SDKからもbaseURLに<Function URL>/v1を指定すれば、Chat CompletionsとResponsesの両方でツール呼び出しの往復とストリームが通りました。 予算とRPMで制限する 小さい上限を付けたキーで、超過時の応答を確かめました。RPM 3のキーで同じ分に5回投げると、4回目から429です。 req1 14:15:35: content="Hello! " HTTP 200 req2 14:15:43: content="# Hey! " HTTP 200 req3 14:15:43: content="Hey! " HTTP 200 req4 14:15:44: {"error":{"message":"rpm limit exceeded for key (3 requests per minute)","type":"rate_limit_error","param":null,"code":null}} HTTP 429 req5 14:15:44: {"error":{"message":"rpm limit exceeded for key (3 requests per minute)","type":"rate_limit_error","param":null,"code":null}} HTTP 429 日次予算を0.00005ドルにしたキーは、1回目(費用0.000053ドル)で予算を超え、2回目から429になりました。 {"type":"error","error":{"type":"insufficient_quota","message":"budget exceeded for key (spent 0.000053 of 0.00005 USD daily)"}} 有効期限切れと無効化は403、失効したキーは401です。ただしキー設定はLambdaコンテナごとに60秒キャッシュしているので、失効直後の1分間は通ります。 判定はBedrockを呼ぶ前にその時点の累計で行い、利用量の加算は応答が終わってからです。並列にリクエストが来ると上限を多少超えることがありますが、ここは割り切りました。 Claude以外のモデルを同じキーで使う モデルの対応表にNovaを足すだけです。IDにanthropic.が含まれないので、プロキシはConverse APIで呼びます。クライアント側はmodelを変えるだけで、Anthropic形式とChat Completionsのどちらからも同じように動きました。 python3 keyctl.py update key_xxxxxxxxxxxx --models 'claude-haiku-4-5=jp.anthropic.claude-haiku-4-5-20251001-v1:0,nova-lite=apac.amazon.nova-lite-v1:0,titan-embed=amazon.titan-embed-text-v2:0' curl "$URL/v1/chat/completions" -H "authorization: Bearer $KEY" -d '{"model":"nova-lite","messages":[{"role":"user","content":"東京の天気を教えて"}],"tools":[...]}' {"choices":[{"message":{"role":"assistant","content":"<thinking> ... </thinking>\n","tool_calls":[{"id":"tooluse_...","type":"function","function":{"name":"get_weather","arguments":"{\"city\":\"東京\"}"}}]},"finish_reason":"tool_calls"}],"usage":{"prompt_tokens":398,"completion_tokens":59,...}} Novaはツール呼び出しの前に<thinking>を本文に書く癖がありますが、それはモデルの挙動なので手を入れていません。モデルを足すたびにプロキシを触らずに済むのは、途中をAnthropic形式で統一しておいた効果でした。ストリーミングもResponses APIも同じ経路で通りました。 埋め込みは/v1/embeddingsで受け、TitanかCohereのモデルに流します。Titan v2で2件入力すると1,024次元のベクトルが2本返りました。 モデルの対応表はalias=modelA|modelBと書くとフォールバックになります。1本目がスロットリングや5xx、またはモデルIDの無効化(廃止)で失敗したら2本目を試し、ログにfallbackToを残します。 存在しないIDを1本目に置いて試すと、2本目のNovaで200が返りました。 チームで予算をまとめる 個人のキーに加えて、チーム単位の上限が欲しくなります。チームを作って予算とRPMを持たせ、キーを所属させると、キー自身の制限とチーム合計の両方で判定します。 python3 keyctl.py team create --name platform --budget-usd 200 --budget-period monthly --rpm 300 python3 keyctl.py create --name alice --team team_xxxxxxxxxxxx --models '...' python3 keyctl.py team usage team_xxxxxxxxxxxx RPMはDynamoDBの条件付き書き込みで数えています。分ごとの項目にreservedを加算するとき、reserved < rpmを条件にして、失敗したら429です。 チームRPMを2にして、2本のキーから同時に6リクエスト投げると、200が2件、429が4件で、並列でも上限を超えませんでした。 k2 200 k2 429 k1 429 k2 429 k1 429 k1 200 {"type":"error","error":{"type":"rate_limit_error","message":"rpm limit exceeded for team test-team (2 requests per minute)"}} 予算はその時点までの累計で見るので、ストリーミングの途中で超えた分は次のリクエストから効きます。 チームの一覧と監査ログ。チームの行には所属キー数と今月の合計が出る 予算の消化を通知する 429になって初めて気付くのは不親切なため、予算の80%と100%へ達したときにSNSへ1回だけ通知するようにしました。 利用量を加算したあと、alerted80やalerted100のフラグを条件付き書き込みで立て、立てられたときだけPublishします。並列でも通知は1回です。 日次予算0.00006ドルのキーに3回投げたときの結果です。SNSのメトリクス上の発行数も2件でした。 1回目: 200。消化率88%になり、80%の通知。 2回目: 200。消化率176%になり、100%の通知。 3回目: 429。 {"alert":"[llm-proxy] key \"alert-test\" reached 80% of budget"} {"alert":"[llm-proxy] key \"alert-test\" reached 100% of budget"} メールで受け取るならTerraformのalert_emailを設定します。購読確認のメールが届くので、そこだけ手作業です。 Guardrailsをキーに付ける Bedrock GuardrailsのIDとバージョンをキーの設定に持たせると、Claude(InvokeModel)とNova(Converse)の両方へ同じガードレールが付きます。 python3 keyctl.py update key_xxxxxxxxxxxx --guardrail abcd1234efgh:2 語句フィルタに社外秘を入れたガードレールで試すと、どちらの経路でも本文がブロック文言に置き換わりました。 Nova(Converse)をChat Completions形式で呼ぶとfinish_reasonはcontent_filterになります。Claude(InvokeModel)ではstop_reasonはend_turnのままで、本文だけが置き換わります。 {"id":"bedrock-guardrails-...","content":[{"type":"text","text":"このリクエストはガードレールでブロックされました。"}],"stop_reason":"end_turn",...} 管理トークンにロールを付けて操作を記録する 管理UIのトークンは複数発行でき、viewerロールは参照だけです。POSTやDELETEは403で返ります。 管理APIで何かを変えるたびに、誰が・いつ・何を・どのキーに対して行ったかを監査ログとして同じテーブルに残し、UIとCLIの両方から月ごとに見られます。 python3 keyctl.py admin-token --name auditor --role viewer python3 keyctl.py audit --month 2026-10 2026-10-31T13:55:44.734Z ops POST /api/keys/key_adef5aa8dbc0/regenerate key_adef5aa8dbc0 {} 利用者が自分の利用量を確認したいときは、プロキシのGET /v1/usageに自分のキーで問い合わせます。自分とチームの日・月の利用量、上限、有効期限が返るので、管理者に聞かなくて済みます。 利用状況を見る ログが1リクエスト1行のJSONのため、Logs Insightsのクエリをそのまま並べたダッシュボードをTerraformで作っています。 {"ts":"2026-10-31T01:20:55.032Z","requestId":"...","sourceIp":"203.0.113.10","method":"POST","path":"/v1/chat/completions","format":"chat","keyName":"limits-test","keyId":"key_14a5527775be","model":"claude-haiku-4-5","stream":false,"tools":[],"modelId":"jp.anthropic.claude-haiku-4-5-20251001-v1:0","costUsd":3.1e-05,"decision":"allow","inputTokens":8,"outputTokens":4,"stopReason":"max_tokens","cacheReadTokens":0,"cacheWriteTokens":0,"status":200,"latencyMs":661} キー別の件数とトークン数、拒否理由、推移、レイテンシ、キー別の費用、制限による拒否、渡されたツール名。制限のテストで出した429や403がそのまま並ぶ コンソールを開かずに共有したいときはusage-report.pyで同じ集計をMarkdownにします。AWS CLIの認証情報だけで動きます。 python3 usage-report.py --hours 24 --region ap-northeast-1 実装のポイント コードはプロキシ本体が4ファイルです。index.mjsはルーティングと認証と転送、keys.mjsはキーとチームの照合・制限判定・費用計上・アラートを担当します。 openai.mjsはOpenAI形式の変換、converse.mjsはConverse APIとの変換です。管理UIはadmin.mjsとadmin-ui.mjsの2ファイルです。 AWS SDK v3はLambdaのNode.jsランタイムに同梱されているので、依存パッケージはありません。全体はリポジトリを見てもらうとして、要点だけ書きます。 モデル・ツール・CIDRの判定はこれだけです。拒否理由をそのままクライアントへ返し、ログにも残します。 src/index.mjs(抜粋) function authorize(keyConfig, sourceIp, alias, toolNames) { if (keyConfig.cidrs?.length && !keyConfig.cidrs.some((c) => ipInCidr(sourceIp, c))) { return { status: 403, type: "permission_error", message: source ip ${sourceIp} is not allowed }; } if (!keyConfig.models?.[alias]) { return { status: 403, type: "permission_error", message: model "${alias}" is not allowed. allowed: ${Object.keys(keyConfig.models ?? {}).join(", ")}, }; } const { allow, deny } = keyConfig.tools ?? {}; const blocked = toolNames.filter((n) => (allow && !allow.includes(n)) || (deny && deny.includes(n))); if (blocked.length) { return { status: 403, type: "permission_error", message: tools not allowed: ${blocked.join(", ")} }; } return null; } DynamoDBのテーブルの主な項目は次のとおりです。種類は増えましたが、どれもpkの接頭辞で見分けられます。 pk sk 内容 KEY#<sha256(key)> META 名前、所属チーム、モデル、ツール、CIDR、予算・RPM・TPM、Guardrail、有効期限、無効化 KEY#<sha256(key)> / TEAM#<teamId> USAGE#min#… / day#… / month#… リクエスト数、RPM用の予約数、トークン数、費用(マイクロドル)、通知済みフラグ。分の項目はTTLで消える TEAM#<teamId> META チーム名と予算・RPM・TPM ADMIN#<sha256(token)> META 管理トークンの名前とロール AUDIT#<yyyy-mm> <時刻>#<乱数> 管理操作の記録(操作者、操作、対象) CONFIG PRICES モデルIDごとの単価(100万トークンあたりUSD) 利用量制限はこのテーブルから当該分と当該期間の項目を読んで比べます。RPMだけは読んで比べるのではなく、分の項目に予約数を条件付きで加算して、失敗したら429にしています。超過はBedrockを呼ぶ前に返すので、無駄なトークン課金は起きません。 src/keys.mjs(抜粋) // RPM: 分の項目に reserved を条件付きで加算する(並列でも上限を超えない) for (const s of scopes) { if (!s.limits.rpm) continue; try { await ddb.send(new UpdateItemCommand({ TableName: TABLE, Key: marshall({ pk: s.pk, sk: USAGE#${p.minute} }), UpdateExpression: "ADD reserved :one SET #ttl = if_not_exists(#ttl, :ttl)", ConditionExpression: "attribute_not_exists(reserved) OR reserved < :rpm", ExpressionAttributeNames: { "#ttl": "ttl" }, ExpressionAttributeValues: marshall({ ":one": 1, ":rpm": s.limits.rpm, ":ttl": Math.floor(now.getTime() / 1000) + 3600 }), })); } catch (e) { if (e.name === "ConditionalCheckFailedException") { return { status: 429, type: "rate_limit_error", message: rpm limit exceeded for ${s.label} (${s.limits.rpm} requests per minute) }; } throw e; } } Converseへの変換で気を付けたのは、ストリームの形です。ConverseStreamはテキストブロックの開始イベントを送らないので、最初のdeltaが来たときにcontent_block_startを補ってからAnthropicのイベント列に戻します。これで後段のChat CompletionsやResponsesへの変換には手を入れずに済みました。 ストリーミングは、Bedrockから届くチャンクをJSONとして読み、Anthropic形式の入口ならevent: <type>\ndata: <json>\n\nに組み直すだけです。 OpenAI形式の入口では、同じイベントをchat.completion.chunkやResponses APIのresponse.output_text.deltaなどに変換して流します。 awslambda.streamifyResponseとawslambda.HttpResponseStream.fromはランタイムが提供するグローバルで、importは不要です。 管理UIは別のLambdaで、HTML(約23KB)をJavaScriptのテンプレート文字列として同梱し、同じ関数が/api/*でJSONを返します。フレームワークもビルドもCDNも使っていません。 管理トークンはDynamoDBにハッシュだけを置いて定数時間で比較し、Terraformのadmin_cidrsで送信元を絞れます。SSOで守りたい場合はCognitoなどを前へ置く構成に差し替えます。 1リクエストの流れをまとめると次の図になります。 Claudeを呼ぶときの流れ。Claude以外ではInvokeModelの部分がConverseに変わる 対応しているルートは、会話用の/v1/messages、/v1/chat/completions、/v1/responsesと、埋め込みの/v1/embeddingsです。 補助として/v1/messages/count_tokens、/v1/models、/v1/usage、/healthがあります。 未対応なのは、画像生成や音声、バッチのエンドポイントと、OpenAI側のprevious_response_id、response_formatのtext以外、n > 1、ホスト型ツールです。 キーの一覧とkeyIdからの検索はテーブルのScanで済ませているので、キーが数千件を超えるならGSIを足すことになります。 ハマったところ Function URLが全リクエストで403を返す 最初はCloudFormationで組んでいました。デプロイ直後は、匿名リクエストもIAM署名付きリクエストも次の応答しか返しません。 {"Message":"Forbidden. For troubleshooting Function URL authorization issues, see: docs.aws.amazon.com"} aws lambda invokeで直接呼ぶと関数は正常で、CloudWatchにログストリームもありません。URLの手前で止まっています。 リソースポリシーにはlambda:InvokeFunctionUrlを付けてあり、ドキュメントどおりに見えました。 原因は、同じアカウントでコンソールから作った別のFunction URLのポリシーと見比べてわかりました。そちらにはlambda:InvokeFunction(条件lambda:InvokedViaFunctionUrl: true)という2つ目のステートメントがあります。 CloudTrailにはInvokeFunctionUrlの失敗が記録されない(データイベントはデフォルトで記録されない)ので、手元に「動いているFunction URL」がないと気付きにくいです。Terraformのaws_lambda_function_urlはこの2つを自動で付けてくれます。 anthropic-betaヘッダをそのまま渡すとBedrockが400を返す 最初はクライアントのanthropic-betaヘッダをBedrockのanthropic_betaにそのまま渡していました。curlとSDKでは問題なかったのですが、Claude Codeの初回リクエストでBedrockが400を返します。 ValidationException: Unexpected value(s) advanced-tool-use-2025-11-20 for the anthropic-beta header. Claude Codeはinterleaved-thinking-2025-05-14やadvanced-tool-use-2025-11-20など5つのbetaを送ってきて、Bedrockの知らない値が1つでも混ざると丸ごと400です。 環境変数の許可リストと一致する値だけ渡し、落とした値はdroppedBetasとしてログへ残すようにしました。許可リストを空にすると今度はcontext_management: Extra inputs are not permittedになります。betaを落としてもボディ側のcontext_managementは残るためです。 Claude Codeは400を受けると該当機能を外して自動で再試行するので動作はしますが、毎回エラーログが1行残ります。 context-management-2025-06-27とinterleaved-thinking-2025-05-14を許可すると初回から200で通りました。どのbetaをBedrockが受けるかはモデルと時期で変わるので、droppedBetasを見ながら増やす運用にしています。 OpenAI経路でanthropic_versionを付け忘れた OpenAI互換を足した最初のデプロイで、Chat CompletionsもResponsesもすべてValidationException: anthropic_version: Field required(400)でした。Anthropic形式の入口だけがこのフィールドを付けていたからです。 Bedrockへ送る直前で共通して付けるよう直しましたが、この400を受けたCodexはリトライを続け、180秒のタイムアウトまで終わりません。原因に気付くまで少し時間がかかりました。 Codexが送るnamespaceとweb_search Codexをつないだ直後、プロキシがunsupported tool types: namespace, web_searchを返しました。ローカルのダミーサーバに向けてリクエストを捕まえると、ツール定義にfunction以外の2種類が混ざっています。 namespaceは複数のfunctionをまとめた入れ物のため、中身を平坦に展開します。web_searchはOpenAIのホスト型ツールで提供できないので、落としてログへ残すようにしました。 Codex側のweb_search = "disabled"も試しましたが、0.165.0ではツール定義は送られてきたままでした。 上流のエラー文にIAMロールのARNが入っていた count_tokensの検証で403が返ったとき、クライアント側にBedrockのエラー文がそのまま見えました。 文面はUser: arn:aws:sts::<アカウントID>:assumed-role/... is not authorized to perform: bedrock:CountTokensです。実行ロールのARNとアカウントIDが含まれています。 原因はBedrockのエラーメッセージを転送していたことでした。403と5xxは詳細をログにだけ残し、クライアントには「upstream access denied (check the IAM policy)」のような一般的な文言を返すように変えました。 count_tokensは推論プロファイルIDを受け付けない /v1/messages/count_tokensをBedrockのCountTokensに流したところ、まずIAMにbedrock:CountTokensがなくて403でした。 次にjp.付きの推論プロファイルIDでは「The provided model doesn't support counting tokens」と返ります。 接頭辞を外した基盤モデルIDで呼ぶと通りましたが、今度はmax_tokens: Field requiredです。数えるだけなのに必須のため、省略時は1を補っています。 Guardrailsのトピック拒否が効かない 日本語で「特定の株式や暗号資産の売買を勧める投資助言」を拒否トピックにしたガードレールは、ApplyGuardrailで直接試してもaction: NONEでした。モデル自身が投資助言を断るので、一見ブロックされたように見えて紛らわしいところです。 プロキシ経由の配線を確かめたかったので、確実に効く語句フィルタに切り替えて検証しました。トピック拒否の精度は定義文と例文の書き方で変わるため、本番で使うなら先にApplyGuardrail単体で当たり方を確かめたほうがよさそうです。 キー一覧にチームと管理トークンが混ざる キー一覧はsk = METAでScanしていたので、同じテーブルに足したチームと管理トークンの項目まで一覧に出てきました。begins_with(pk, "KEY#")を条件に足して直しています。1テーブルに種類の違う項目を同居させるときの定番の落とし穴でした。 Function URLの末尾スラッシュ 管理UIの/api/*が全部404でした。Terraformのfunction_url出力は末尾に/が付くので、/api/keysをつなぐと//api/keysになります。 ハンドラは末尾のスラッシュしか正規化しておらず、startsWith("/api/")に引っかかりませんでした。連続するスラッシュもまとめるようにして解決です。 ダッシュボードの遅延描画 ヘッドレスブラウザでダッシュボードを確認していて、最下段のウィジェットだけ「No data found」のままでした。クエリの不具合だと思って書き直しましたが、原因は画面外のウィジェットがスクロールするまで描画されないことでした。コンソールで確認するときは最下段までスクロールしてから判断します。 料金 プロキシ自体の費用だけを見積もります。Bedrockのトークン課金は使うモデルと使い方で決まるので、ここでは扱いません。 単価は2026-10-30時点のPrice List APIから取り、計算はリポジトリのcost-estimate.pyでしました。 項目 単価(ap-northeast-1) Lambdaリクエスト / 実行時間 $0.20 / 100万、$0.0000166667 / GB秒(月100万リクエストと40万GB秒まで無料) CloudWatch Logs 取り込み$0.76 / GB、保存$0.033 / GB月 DynamoDB(オンデマンド) 書き込み$0.715 / 100万、読み込み$0.1425 / 100万、保存25GBまで無料 1リクエストあたりLambda 3秒×256MB、ログ700バイト、DynamoDB読み込み1単位・書き込み3単位と置いた試算です。 月間リクエスト Lambda CloudWatch Logs DynamoDB 合計 1万 $0.00 $0.01 $0.02 $0.03 10万 $0.00 $0.05 $0.23 $0.28 100万 $5.83 $0.52 $2.29 $8.64 月10万リクエストでも30セント弱で、Lambdaの無料枠に収まります。なお2025年7月以降に作成したアカウントは無料利用枠がクレジット制のため、常時無料の枠が同じ形で使えるかはアカウントの種類で変わります。 CloudWatchダッシュボードはアカウントで3枚まで無料、4枚目以降は1枚$3/月で、create_dashboard = falseで外せます。管理UIのLambdaは管理者が開いたときだけ動くので、こちらも無料枠内です。 SNSはAPIリクエストが月100万件、メール通知が月1,000件まで無料枠があり、予算通知の費用は0円とみなせます。 Guardrailsを付ける場合はポリシーの種類ごとに別途課金があります。Price List APIの東京の単価では、語句フィルタは無料、トピック拒否とコンテンツフィルタは1,000テキストユニットあたり$0.15でした。 まとめ Lambda Function URLとBedrockにDynamoDBを1テーブル足すだけで、キーの発行、予算、通知、管理UIまでそろいました。Claude以外のモデルもConverse APIへの変換で同じキーから使えます。 LiteLLMにあってこちらにないものは、応答キャッシュ、ルーティングの重み付け、管理UIのSSOです。キャッシュとSSOはRedisやCognitoのような常時動く基盤が前提になるので、固定費ゼロの範囲では持たないと決めました。重み付けは、フォールバックで足りる規模だったので見送っています。 作り込まれた機能は当然ありませんが、固定費ゼロで、追いかける依存もない状態を維持できるのは小さなチームには合っていると感じました。 予算の判定は事後計上で厳密ではないので目安として使い、請求はCost Explorerで確認するのがよさそうです。どなたかの参考になれば幸いです。

Cancel Cloud API Subscriptions: Run 100% Free Self-Host #1 Stop paying expensive monthly API subscriptions! In today's deep dive, we put Litellm (28,500 GitHub Stars) through the ultimate real-world developer capability benchmark on DailyDev AI. 👉 Grab the official GitHub Repository: BerriAI/litellm ========================================================================= ⏳ TIMESTAMPS & CHAPTERS (WATCH BEFORE YOU DEPLOY): 00:00 The Closed AI Subscription Trap & Monthly API Bills 00:48 Why Developers Are Switching to Litellm 01:35 Codebase Architecture & Under-The-Hood Tour 02:20 Step-by-Step Live Terminal Sandbox Installation 03:45 Real-World Capability Benchmark & Memory Consumption 04:50 Production Score, Gotchas & Final Engineering Verdict ========================================================================= 🔍 WHAT IS LITELLM & HOW DOES IT WORK? Call 100+ LLM APIs using the OpenAI format. Unified load balancing, fallback routing, and spend tracking. ⚡ KEY DEVELOPER HIGHLIGHTS: • 100% Free & Open-Source: Full codebase transparency under open license • Localhost Privacy: Zero data tracking, zero telemetry, full offline support • Written in Python: Exceptional performance with minimal system overhead • Massive Community Adoption: 28,500+ developers on GitHub 💻 STEP-BY-STEP TERMINAL INSTALLATION COMMANDS: git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # On Linux/macOS: source .venv/bin/activate pip install -e . ========================================================================= 🔔 SUBSCRIBE TO DAILYDEV AI: We test and break down two brand-new trending open-source AI repositories every single day at US Peak Time (11:00 AM EST & 5:00 PM EST). Subscribe and hit the bell so you never miss the next viral open-source AI tool! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [ar] ألغِ اشتراكات واجهات برمجة تطبيقات السحاب: شغّل نظاماً مستضافاً ذاتياً ومجانياً 100% #1 توقف عن دفع اشتراكات واجهات برمجة التطبيقات الشهرية الباهظة! في هذا التحليل المعمق، قمنا باختبار قدرات مطوري Litellm (الحائزة على 28,500 نجمة على GitHub) باستخدام منصة DailyDev AI. 👈 حمّل مستودع GitHub الرسمي: BerriAI/litellm ========================================================================== ⏳ الفواصل الزمنية والفصول (شاهد قبل النشر): 00:00 فخ اشتراك الذكاء الاصطناعي المغلق وفواتير واجهة برمجة التطبيقات الشهرية 00:48 لماذا يتحول المطورون إلى Litellm 01:35 بنية قاعدة البيانات وجولة في تفاصيلها الداخلية 02:20 تثبيت بيئة الاختبار الطرفية المباشرة خطوة بخطوة 03:45 معيار الأداء العملي واستهلاك الذاكرة 04:50 نتيجة الإنتاج، والمشاكل المحتملة، والهندسة النهائية الخلاصة ========================================================================= 🔍 ما هو LITELLM وكيف يعمل؟ استدعاء أكثر من 100 واجهة برمجة تطبيقات لإدارة دورة حياة التطبيقات (LLM) باستخدام تنسيق OpenAI. موازنة موحدة للأحمال، وتوجيه احتياطي، وتتبع للإنفاق. ما هو LITELLM وكيف يعمل؟ استدعاء أكثر من 100 واجهة برمجة تطبيقات لإدارة دورة حياة التطبيقات (LLM) باستخدام تنسيق OpenAI. موازنة موحدة للأحمال، وتوجيه احتياطي، وتتبع للإنفاق. ⚡ أبرز مميزات المطورين: • مجاني بالكامل ومفتوح المصدر: شفافية كاملة لقاعدة الكود بموجب ترخيص مفتوح المصدر • خصوصية تامة على الخادم المحلي: لا تتبع للبيانات، ولا قياس عن بُعد، ودعم كامل للعمل دون اتصال بالإنترنت • مكتوب بلغة بايثون: أداء استثنائي مع أقل قدر من استهلاك موارد النظام • اعتماد واسع النطاق من قبل المجتمع: أكثر من 28,500 مطور على GitHub 💻 أوامر التثبيت الطرفية خطوة بخطوة: git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # على أنظمة Linux/macOS: source .venv/bin/activate pip install -e . ========================================================================= 🔔 اشترك في قناة DailyDev AI: نختبر ونحلل مستودعين جديدين من مستودعات الذكاء الاصطناعي مفتوحة المصدر الرائجة يوميًا في أوقات الذروة في الولايات المتحدة (11:00 صباحًا و5:00 مساءً بتوقيت شرق الولايات المتحدة). اشترك وفعل جرس التنبيهات لتصلك آخر أخبار أدوات الذكاء الاصطناعي مفتوحة المصدر الرائجة! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [bn] ক্লাউড এপিআই সাবস্ক্রিপশন বাতিল করুন: ১০০% ফ্রি সেলফ-হোস্ট করুন #১ দামী মাসিক এপিআই সাবস্ক্রিপশনের টাকা দেওয়া বন্ধ করুন! আজকের এই গভীর বিশ্লেষণে, আমরা ডেইলিডেভ এআই-তে লিটেলম (২৮,৫০০ গিটহাব স্টার)-কে চূড়ান্ত বাস্তব-জগতের ডেভেলপার সক্ষমতা বেঞ্চমার্কের মধ্যে দিয়ে নিয়েছি। 👉 অফিসিয়াল গিটহাব রিপোজিটরি ডাউনলোড করুন: BerriAI/litellm ========================================================================= ⏳ টাইমস্ট্যাম্প ও অধ্যায়সমূহ (ডিপ্লয় করার আগে দেখুন): ০০:০০ ক্লোজড এআই সাবস্ক্রিপশনের ফাঁদ এবং মাসিক এপিআই বিল ০০:৪৮ কেন ডেভেলপাররা লিটেলম-এ ঝুঁকছেন ০১:৩৫ কোডবেস আর্কিটেকচার এবং এর ভেতরের কার্যপ্রণালী ০২:২০ ধাপে ধাপে লাইভ টার্মিনাল স্যান্ডবক্স ইনস্টলেশন ০৩:৪৫ বাস্তব-জগতের সক্ষমতা বেঞ্চমার্ক এবং মেমরি খরচ ০৪:৫০ প্রোডাকশন স্কোর, সম্ভাব্য সমস্যা এবং চূড়ান্ত ইঞ্জিনিয়ারিং রায় ========================================================================= 🔍 লিটেলম কী এবং এটি কীভাবে কাজ করে? ওপেনএআই ফরম্যাট ব্যবহার করে ১০০টিরও বেশি এলএলএম এপিআই কল করুন। সমন্বিত লোড ব্যালান্সিং, ফলব্যাক রাউটিং এবং ব্যয় ট্র্যাকিং। ⚡ ডেভেলপারদের জন্য বিশেষ আকর্ষণ: • ১০০% ফ্রি ও ওপেন-সোর্স: ওপেন লাইসেন্সের অধীনে সম্পূর্ণ কোডবেস স্বচ্ছতা • লোকালহোস্টের গোপনীয়তা: কোনো ডেটা ট্র্যাকিং নেই, কোনো টেলিমেট্রি নেই, সম্পূর্ণ অফলাইন সাপোর্ট • পাইথনে লেখা: ন্যূনতম সিস্টেম ওভারহেড সহ অসাধারণ পারফরম্যান্স • বিশাল কমিউনিটির সমর্থন: গিটহাবে ২৮,৫০০-এর বেশি ডেভেলপার 💻 ধাপে ধাপে টার্মিনাল ইনস্টলেশনের কমান্ড: git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # লিনাক্স/ম্যাকওএস-এ: source .venv/bin/activate pip install -e . ========================================================================= 🔔 ডেইলিডেভ এআই-তে সাবস্ক্রাইব করুন: আমরা প্রতিদিন ইউএস পিক টাইমে (সকাল ১১:০০ EST এবং বিকাল ৫:০০ EST) দুটি একেবারে নতুন এবং ট্রেন্ডিং ওপেন-সোর্স এআই রিপোজিটরি পরীক্ষা ও বিশ্লেষণ করি। সাবস্ক্রাইব করুন এবং বেল আইকনে ক্লিক করুন, যাতে আপনি পরবর্তী ভাইরাল ওপেন-সোর্স এআই টুলটি কখনো মিস না করেন! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [de-DE] Cloud-API-Abos kündigen: 100 % kostenloses Self-Hosting #1 Schluss mit teuren monatlichen API-Abonnements! In unserem heutigen Deep Dive unterziehen wir Litellm (28.500 GitHub-Sterne) dem ultimativen Praxistest für Entwickler auf DailyDev AI. ... 👉 Offizielles GitHub-Repository herunterladen: BerriAI/litellm ============================================================================ ⏳ ZEITSTEMPEL & KAPITEL (VOR DEM SETUP ANSEHEN): 00:00 Die Falle geschlossener KI-Abonnements & monatliche API-Rechnungen 00:48 Warum Entwickler zu Litellm wechseln 01:35 Codebasis-Architektur & Einblick in die Funktionsweise 02:20 Schritt-für-Schritt-Installation in der Live-Terminal-Sandbox 03:45 Benchmark der Leistungsfähigkeit im realen Einsatz & Speicherverbrauch 04:50 Ergebnisse in der Produktion, Fallstricke & abschließende technische Optimierung Urteil ========================================================================== 🔍 WAS IST LITELLM UND WIE FUNKTIONIERT ES? Über 100 LLM-APIs im OpenAI-Format aufrufen. Einheitliches Load Balancing, Fallback-Routing und Kostenverfolgung. ⚡ WICHTIGSTE ENTWICKLER-HIGHLIGHTS: • 100 % kostenlos & Open Source: Volle Transparenz des Quellcodes unter einer offenen Lizenz • Datenschutz auf dem lokalen Rechner: Keine Datenerfassung, keine Telemetrie, volle Offline-Unterstützung • Geschrieben in Python: Hervorragende Performance bei minimalem Systemaufwand • Große Community: Über 28.500 Entwickler auf GitHub 💻 SCHRITT-FÜR-SCHRITT-ANLEITUNG ZUR TERMINALINSTALLATION: git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # Unter Linux/macOS: source .venv/bin/activate pip install -e . ========================================================================== 🔔 ABONNIEREN SIE DAILYDEV AI: Wir testen und analysieren täglich zwei brandneue, trendige Open-Source-KI-Repositories zur US-amerikanischen Spitzenzeit (11:00 Uhr EST & 17:00 Uhr EST). Abonnieren Sie uns und aktivieren Sie die Benachrichtigungen, um kein virales Open-Source-KI-Tool mehr zu verpassen! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [es-US] Cancela las suscripciones a la API de la nube: Ejecuta Self-Host 100% gratis #1 ¡Deja de pagar costosas suscripciones mensuales a API! En este análisis exhaustivo, sometimos a Litellm (28.500 estrellas en GitHub) a la prueba de rendimiento definitiva para desarrolladores en el mundo real, realizada por DailyDev AI. 👉 Descarga el repositorio oficial de GitHub: BerriAI/litellm =========================================================================== ⏳ MARCAS DE TIEMPO Y CAPÍTULOS (VER ANTES DE IMPLEMENTAR): 00:00 La trampa de las suscripciones de IA cerradas y las facturas mensuales de la API 00:48 Por qué los desarrolladores se están pasando a Litellm 01:35 Arquitectura del código base y análisis interno 02:20 Instalación paso a paso del entorno de pruebas en vivo 03:45 Prueba de rendimiento y consumo de memoria en entornos reales 04:50 Puntuación en producción, posibles problemas y análisis final de ingeniería Veredicto ========================================================================== 🔍 ¿QUÉ ES LITELLM Y CÓMO FUNCIONA? Llama a más de 100 API de LLM usando el formato OpenAI. Balanceo de carga unificado, enrutamiento alternativo y seguimiento de gastos. ⚡ CARACTERÍSTICAS PRINCIPALES PARA DESARROLLADORES: • 100 % gratuito y de código abierto: Transparencia total del código bajo licencia abierta • Privacidad en localhost: Sin seguimiento de datos, sin telemetría, soporte completo sin conexión • Escrito en Python: Rendimiento excepcional con mínima sobrecarga del sistema • Gran adopción por parte de la comunidad: Más de 28.500 desarrolladores en GitHub 💻 INSTRUCCIONES DE INSTALACIÓN PASO A PASO EN LA TERMINAL: git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # En Linux/macOS: source .venv/bin/activate pip install -e . =========================================================================== 🔔 SUSCRÍBETE A DAILYDEV AI: Probamos y analizamos dos nuevos repositorios de IA de código abierto que marcan tendencia todos los días durante la hora pico en EE. UU. (11:00 a. m. EST y 5:00 p. m. EST). ¡Suscríbete y activa las notificaciones para no perderte la próxima herramienta viral de IA de código abierto! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [fr-FR] Arrêtez vos abonnements aux API Cloud : hébergez tout gratuitement à 100 % #1 Arrêtez de payer des abonnements API mensuels hors de prix ! Dans cette analyse approfondie, nous avons soumis Litellm (28 500 étoiles sur GitHub) au test ultime de performance des développeurs en conditions réelles sur DailyDev AI. 👉 Téléchargez le dépôt GitHub officiel : BerriAI/litellm ========================================================================= ⏳ HORODATAGE ET CHAPITRES (À VISIONNER AVANT LE DÉPLOIEMENT) : 00:00 Le piège des abonnements IA fermés et les factures API mensuelles 00:48 Pourquoi les développeurs adoptent Litellm 01:35 Architecture du code et visite guidée 02:20 Installation pas à pas du bac à sable en direct 03:45 Évaluation des performances en conditions réelles et consommation de mémoire 04:50 Résultats en production, points faibles et verdict technique final ========================================================================= 🔍 QU'EST-CE QUE LITELLM ET COMMENT ÇA MARCHE ? Appelez plus de 100 API LLM au format OpenAI. Équilibrage de charge unifié, routage de secours et suivi des dépenses. ⚡ POINTS FORTS POUR LES DÉVELOPPEURS : • 100 % gratuit et open source : transparence totale du code source sous licence libre • Confidentialité en local : aucune donnée collectée, aucune télémétrie, fonctionnement hors ligne complet • Écrit en Python : performances exceptionnelles avec une charge système minimale • Forte adoption par la communauté : plus de 28 500 développeurs sur GitHub 💻 COMMANDES D'INSTALLATION PAS À PAS : git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # Sous Linux/macOS : source .venv/bin/activate pip install -e . ========================================================================= 🔔 ABONNEZ-VOUS À DAILYDEV AI : Chaque jour, aux heures de pointe aux États-Unis (11 h et 17 h HNE), nous testons et analysons deux nouveaux dépôts d’IA open source très populaires. Abonnez-vous et activez les notifications pour ne manquer aucun outil d’IA open source viral ! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [hi] क्लाउड API सब्सक्रिप्शन कैंसिल करें: 100% फ्री सेल्फ-होस्ट चलाएं #1 महंगे मासिक API सब्सक्रिप्शन का भुगतान करना बंद करें! आज के इस विस्तृत विश्लेषण में, हम DailyDev AI पर Litellm (28,500 GitHub स्टार्स) की वास्तविक दुनिया की डेवलपर क्षमता का सबसे कठिन परीक्षण करेंगे। 👉 आधिकारिक GitHub रिपॉजिटरी डाउनलोड करें: BerriAI/litellm ========================================================================= ⏳ टाइमस्टैम्प और अध्याय (तैनाती से पहले देखें): 00:00 बंद AI सदस्यता का जाल और मासिक API बिल 00:48 डेवलपर Litellm की ओर क्यों रुख कर रहे हैं 01:35 कोडबेस आर्किटेक्चर और आंतरिक कार्यप्रणाली 02:20 चरण-दर-चरण लाइव टर्मिनल सैंडबॉक्स इंस्टॉलेशन 03:45 वास्तविक दुनिया में क्षमता का बेंचमार्क और मेमोरी खपत 04:50 प्रोडक्शन स्कोर, कमियां और अंतिम इंजीनियरिंग निर्णय ========================================================================= 🔍 Litellm क्या है और यह कैसे काम करता है? OpenAI प्रारूप का उपयोग करके 100+ LLM API को कॉल करें। एकीकृत लोड बैलेंसिंग, फ़ॉलबैक रूटिंग और खर्च ट्रैकिंग। ⚡ प्रमुख डेवलपर विशेषताएँ: • 100% मुफ़्त और ओपन-सोर्स: ओपन लाइसेंस के तहत पूर्ण कोडबेस पारदर्शिता • लोकलहोस्ट गोपनीयता: शून्य डेटा ट्रैकिंग, शून्य टेलीमेट्री, पूर्ण ऑफ़लाइन समर्थन • पायथन में लिखा गया: न्यूनतम सिस्टम ओवरहेड के साथ असाधारण प्रदर्शन • व्यापक सामुदायिक स्वीकृति: GitHub पर 28,500+ डेवलपर 💻 चरण-दर-चरण टर्मिनल इंस्टॉलेशन कमांड: git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # Linux/macOS पर: source .venv/bin/activate pip install -e . ========================================================================= 🔔 डेलीडेव एआई को सब्सक्राइब करें: हम हर दिन अमेरिका के पीक टाइम (सुबह 11:00 बजे ईएसटी और शाम 5:00 बजे ईएसटी) पर दो बिल्कुल नए और ट्रेंडिंग ओपन-सोर्स एआई रिपॉजिटरी का परीक्षण और विश्लेषण करते हैं। सब्सक्राइब करें और बेल आइकन दबाएं ताकि आप किसी भी नए वायरल ओपन-सोर्स एआई टूल को मिस न करें! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [id] Berhenti Berlangganan API Cloud: Jalankan Self-Host 100% Gratis #1 Berhenti membayar biaya langganan API bulanan yang mahal! Dalam ulasan mendalam hari ini, kami menguji Litellm (28.500 Bintang GitHub) melalui tolok ukur kemampuan pengembang dunia nyata terbaik di DailyDev AI. 👉 Unduh Repositori GitHub resmi: BerriAI/litellm ========================================================================= ⏳ CAP WAKTU & BAB (TONTON SEBELUM ANDA MENGGUNAKANNYA): 00:00 Jebakan Langganan AI Tertutup & Tagihan API Bulanan 00:48 Mengapa Pengembang Beralih ke Litellm 01:35 Arsitektur Basis Kode & Tur di Balik Layar 02:20 Instalasi Sandbox Terminal Langsung Langkah demi Langkah 03:45 Tolok Ukur Kemampuan Dunia Nyata & Konsumsi Memori 04:50 Skor Produksi, Masalah yang Perlu Diperhatikan & Keputusan Rekayasa Akhir ========================================================================= 🔍 APA ITU LITELLM & BAGAIMANA CARA KERJANYA? Panggil 100+ API LLM menggunakan format OpenAI. Penyeimbangan beban terpadu, perutean cadangan, dan pelacakan pengeluaran. ⚡ SOROTAN PENGEMBANG UTAMA: • 100% Gratis & Sumber Terbuka: Transparansi basis kode penuh di bawah lisensi terbuka • Privasi Localhost: Nol pelacakan data, nol telemetri, dukungan offline penuh • Ditulis dalam Python: Kinerja luar biasa dengan overhead sistem minimal • Adopsi Komunitas Besar: 28.500+ pengembang di GitHub 💻 PERINTAH INSTALASI TERMINAL LANGKAH DEMI LANGKAH: git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # Di Linux/macOS: source .venv/bin/activate pip install -e . ========================================================================= 🔔 BERLANGGANAN DAILYDEV AI: Kami menguji dan menganalisis dua repositori AI open-source terbaru yang sedang tren setiap hari pada Waktu Puncak AS (11:00 AM EST & 5:00 PM EST). Berlangganan dan tekan lonceng agar Anda tidak pernah melewatkan alat AI open-source viral berikutnya! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [it] Annulla gli abbonamenti alle API cloud: esegui l'hosting self-hosting #1 completamente gratuito Smettetela di pagare costosi abbonamenti mensili alle API! Nell'analisi approfondita di oggi, abbiamo sottoposto Litellm (28.500 stelle su GitHub) al test definitivo di capacità di sviluppo nel mondo reale su DailyDev AI. 👉 Scarica il repository GitHub ufficiale: BerriAI/litellm ========================================================================== ⏳ INDICE DEI CONTENUTI E CAPITOLI (GUARDA PRIMA DI DISTRIBUIRE): 00:00 La trappola dell'abbonamento AI chiuso e i costi mensili delle API 00:48 Perché gli sviluppatori stanno passando a Litellm 01:35 Architettura del codice e analisi dettagliata 02:20 Installazione passo passo della sandbox del terminale live 03:45 Benchmark delle prestazioni reali e consumo di memoria 04:50 Punteggio di produzione, insidie ​​e ingegneria finale Verdetto =========================================================================== 🔍 COS'È LITELLM E COME FUNZIONA? Chiama oltre 100 API LLM utilizzando il formato OpenAI. Bilanciamento del carico unificato, routing di fallback e monitoraggio della spesa. ⚡ PUNTI SALIENTI DELLO SVILUPPATORE: • 100% gratuito e open source: completa trasparenza del codice sorgente con licenza open source • Privacy in locale: nessun tracciamento dei dati, nessuna telemetria, supporto offline completo • Scritto in Python: prestazioni eccezionali con un sovraccarico di sistema minimo • Ampia adozione da parte della community: oltre 28.500 sviluppatori su GitHub 💻 COMANDI DI INSTALLAZIONE DA TERMINALE PASSO PASSO: git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # Su Linux/macOS: source .venv/bin/activate pip install -e . =========================================================================== 🔔 ISCRIVITI A DAILYDEV AI: Ogni giorno, durante l'orario di punta negli Stati Uniti (11:00 EST e 17:00 EST), testiamo e analizziamo due nuovissimi repository di IA open source di tendenza. Iscriviti e attiva le notifiche per non perderti il ​​prossimo strumento di IA open source virale! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [iw] לבטל מנויי Cloud API: להריץ ב-100% אירוח עצמי חינמי #1 הפסיקו לשלם מנויים חודשיים יקרים על API! בבדיקה מעמיקה של היום, בדקנו את Litellm (28,500 כוכבי GitHub) באמצעות מדד היכולות האולטימטיבי של פיתוח בעולם האמיתי בבינה מלאכותית של DailyDev. 👉 הורידו את מאגר GitHub הרשמי: BerriAI/litellm ======================================================================== ⏳ חותמות זמן ופרקים (צפו לפני הפריסה): 00:00 מלכודת המנוי הסגורה לבינה מלאכותית וחיובי API חודשיים 00:48 מדוע מפתחים עוברים ל-Litellm 01:35 ארכיטקטורת בסיס קוד וסיור מתחת למכסה המנוע 02:20 התקנת ארגז חול של טרמינל חי שלב אחר שלב 03:45 מדד יכולות בעולם האמיתי וצריכת זיכרון 04:50 ציון ייצור, תקלות ופסק דין הנדסי סופי ======================================================================== 🔍 מה זה LITELLM ואיך זה עובד? קריאה ל-100+ ממשקי API של LLM באמצעות פורמט OpenAI. איזון עומסים מאוחד, ניתוב גיבוי ומעקב אחר הוצאות. ⚡ נקודות עיקריות של המפתחים: • 100% חופשי וקוד פתוח: שקיפות מלאה של בסיס הקוד תחת רישיון פתוח • פרטיות של Localhost: אפס מעקב אחר נתונים, אפס טלמטריה, תמיכה מלאה במצב לא מקוון • כתוב ב-Python: ביצועים יוצאי דופן עם תקורת מערכת מינימלית • אימוץ קהילתי מסיבי: 28,500+ מפתחים ב-GitHub 💻 פקודות התקנה שלב אחר שלב של הטרמינל: git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # ב-Linux/macOS: source .venv/bin/activate pip install -e . ========================================================================== 🔔 הירשמו ל-DAILYDEV AI: אנו בודקים ומנתחים שני מאגרי קוד פתוח חדשים ומגוונים בכל יום בשעות השיא של ארה"ב (11:00 בבוקר שעון EST ו-17:00 אחר הצהריים שעון EST). הירשמו ולחצו על הפעמון כדי שלעולם לא תפספסו את כלי ה-AI הוויראלי הבא בקוד פתוח! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [ja] クラウドAPIのサブスクを解約：100%無料のセルフホスト環境を構築する方法 #1 高額な月額API利用料はもう不要！今回の徹底検証では、Litellm（GitHubスター数28,500）をDailyDev AI上で究極の実世界開発者能力ベンチマークテストにかけました。 👉 公式GitHubリポジトリはこちら：BerriAI/litellm =========================================================================== ⏳ タイムスタンプとチャプター（デプロイ前に必ずご覧ください）： 00:00 クローズドAIサブスクリプションの落とし穴と月額API料金 00:48 開発者がLitellmに移行する理由 01:35 コードベースアーキテクチャと内部構造ツアー 02:20 ライブターミナルサンドボックスへのステップバイステップインストール 03:45 実環境での機能ベンチマークとメモリ消費量 04:50 本番環境スコア、注意点、最終エンジニアリング結論 =========================================================================== 🔍 LITELLMとは？その仕組みは？ OpenAIフォーマットを使用して100以上のLLM APIを呼び出します。統合ロードバランシング、フォールバックルーティング、および支出追跡機能を提供します。 ⚡ 主な開発者向け特長： • 100%無料＆オープンソース：オープンライセンスによる完全なコードベース透明性 • ローカルホストのプライバシー：データ追跡なし、テレメトリなし、完全オフライン対応 • Pythonで記述：最小限のシステム負荷で卓越したパフォーマンスを実現 • 大規模なコミュニティによる採用：GitHubには28,500人以上の開発者が参加 💻 ターミナルでのインストール手順： git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # Linux/macOSの場合：source .venv/bin/activate pip install -e . ============================================================================ 🔔 DAILYDEV AI を購読してください: 私たちは、米国ピークタイム (東部標準時午前 11:00 と午後 5:00) に、毎日 2 つの最新の話題のオープンソース AI リポジトリをテストし、分析しています。購読してベルマークをクリックすれば、次に話題のオープンソース AI ツールを見逃すことはありません！ #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [ko] 클라우드 API 구독 해지하기: 100% 무료 셀프 호스팅 실행 #1 더 이상 비싼 월별 API 구독료를 지불하지 마세요! 이번 심층 분석에서는 DailyDev AI를 사용하여 Litellm(GitHub 스타 28,500개)의 실제 개발자 역량을 극한까지 평가해 보았습니다. 👉 공식 GitHub 저장소에서 다운로드하세요: BerriAI/litellm ============================================================================ ⏳ 타임스탬프 및 목차 (배포 전 시청): 00:00 폐쇄형 AI 구독의 함정 및 월별 API 요금 00:48 개발자들이 Litellm으로 전환하는 이유 01:35 코드베이스 아키텍처 및 내부 작동 방식 살펴보기 02:20 단계별 라이브 터미널 샌드박스 설치 03:45 실제 성능 벤치마크 및 메모리 사용량 04:50 실제 운영 환경 점수, 주의 사항 및 최종 엔지니어링 결론 ============================================================================= 🔍 LITELLM이란 무엇이며 어떻게 작동하나요? OpenAI 형식을 사용하여 100개 이상의 LLM API를 호출할 수 있습니다. 통합 로드 밸런싱, 폴백 라우팅 및 비용 추적 기능을 제공합니다. ⚡ 주요 개발자 특징: • 100% 무료 오픈 소스: 오픈 라이선스 하에 코드베이스 전체 공개 • 로컬 환경 개인정보 보호: 데이터 추적 및 원격 측정 없음, 완벽한 오프라인 지원 • Python으로 작성: 최소한의 시스템 오버헤드로 뛰어난 성능 제공 • 활발한 커뮤니티 참여: GitHub에 28,500명 이상의 개발자 참여 💻 단계별 터미널 설치 명령어: git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # Linux/macOS: source .venv/bin/activate pip install -e . =========================================================================== 🔔 DAILYDEV AI 구독하기: 저희는 매일 미국 피크 시간대(오전 11시 및 오후 5시, 동부 표준시)에 새롭게 떠오르는 오픈 소스 AI 저장소 두 개를 테스트하고 분석합니다. 구독하고 알림 벨을 눌러 새롭게 주목받는 오픈 소스 AI 도구를 놓치지 마세요! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [ml] ക്ലൗഡ് API സബ്‌സ്‌ക്രിപ്‌ഷനുകൾ റദ്ദാക്കൂ: 100% സൗജന്യമായി സെൽഫ്-ഹോസ്റ്റ് ചെയ്യൂ #1 ചെലവേറിയ പ്രതിമാസ API സബ്‌സ്‌ക്രിപ്‌ഷനുകൾ നൽകുന്നത് നിർത്തൂ! ഇന്നത്തെ ആഴത്തിലുള്ള പഠനത്തിൽ, DailyDev AI-യിലെ ആത്യന്തിക യഥാർത്ഥ ലോക ഡെവലപ്പർ ശേഷി മാനദണ്ഡത്തിൽ ഞങ്ങൾ Litellm (28,500 GitHub Stars) ഉൾപ്പെടുത്തുന്നു. 👉 ഔദ്യോഗിക GitHub ശേഖരം നേടുക: BerriAI/litellm ===================================================================================================================== ⏳ ടൈംസ്റ്റാമ്പുകളും അധ്യായങ്ങളും (നിങ്ങൾ വിന്യസിക്കുന്നതിന് മുമ്പ് കാണുക): 00:00 അടച്ച AI സബ്‌സ്‌ക്രിപ്‌ഷൻ ട്രാപ്പും പ്രതിമാസ API ബില്ലുകളും 00:48 ഡെവലപ്പർമാർ Litellm-ലേക്ക് മാറുന്നതിന്റെ കാരണം 01:35 കോഡ്‌ബേസ് ആർക്കിടെക്ചറും അണ്ടർ-ദി-ഹുഡ് ടൂറും 02:20 ഘട്ടം ഘട്ടമായുള്ള ലൈവ് ടെർമിനൽ സാൻഡ്‌ബോക്‌സ് ഇൻസ്റ്റാളേഷൻ 03:45 റിയൽ-വേൾഡ് കപ്പാബിലിറ്റി ബെഞ്ച്മാർക്കും മെമ്മറി ഉപഭോഗവും 04:50 പ്രൊഡക്ഷൻ സ്‌കോർ, ഗോച്ചകളും അന്തിമ എഞ്ചിനീയറിംഗും വിധി ============================================================================ 🔍 LITELLM എന്താണ് & അത് എങ്ങനെ പ്രവർത്തിക്കുന്നു? OpenAI ഫോർമാറ്റ് ഉപയോഗിച്ച് 100+ LLM API-കൾ വിളിക്കുക. ഏകീകൃത ലോഡ് ബാലൻസിംഗ്, ഫാൾബാക്ക് റൂട്ടിംഗ്, ചെലവ് ട്രാക്കിംഗ്. ⚡ പ്രധാന ഡെവലപ്പർ ഹൈലൈറ്റുകൾ: • 100% സൗജന്യവും ഓപ്പൺ സോഴ്‌സും: ഓപ്പൺ ലൈസൻസിന് കീഴിൽ പൂർണ്ണ കോഡ്‌ബേസ് സുതാര്യത • ലോക്കൽഹോസ്റ്റ് സ്വകാര്യത: സീറോ ഡാറ്റ ട്രാക്കിംഗ്, സീറോ ടെലിമെട്രി, പൂർണ്ണ ഓഫ്‌ലൈൻ പിന്തുണ • പൈത്തണിൽ എഴുതിയത്: കുറഞ്ഞ സിസ്റ്റം ഓവർഹെഡുള്ള അസാധാരണമായ പ്രകടനം • വൻതോതിലുള്ള കമ്മ്യൂണിറ്റി അഡോപ്ഷൻ: GitHub-ൽ 28,500+ ഡെവലപ്പർമാർ 💻 ഘട്ടം ഘട്ടമായുള്ള ടെർമിനൽ ഇൻസ്റ്റാളേഷൻ കമാൻഡുകൾ: git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # Linux/macOS-ൽ: source .venv/bin/activate pip install -e . ================================================================================= 🔔 DAILYDEV AI-ലേക്ക് സബ്‌സ്‌ക്രൈബ് ചെയ്യുക: US പീക്ക് ടൈമിൽ (11:00 AM EST & 5:00 PM EST) ഞങ്ങൾ എല്ലാ ദിവസവും രണ്ട് പുതിയ ട്രെൻഡിംഗ് ഓപ്പൺ സോഴ്‌സ് AI ശേഖരണങ്ങൾ പരീക്ഷിച്ച് വിശകലനം ചെയ്യുന്നു. അടുത്ത വൈറൽ ഓപ്പൺ സോഴ്‌സ് AI ടൂൾ ഒരിക്കലും നഷ്ടപ്പെടുത്താതിരിക്കാൻ സബ്‌സ്‌ക്രൈബ് ചെയ്‌ത് ബെൽ അമർത്തുക! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [nl-NL] Annuleer cloud-API-abonnementen: Voer 100% gratis zelfhosting uit #1 Stop met het betalen van dure maandelijkse API-abonnementen! In deze diepgaande analyse onderwerpen we Litellm (28.500 GitHub-sterren) aan de ultieme praktijktest voor ontwikkelaarsvaardigheden op DailyDev AI. 👉 Download de officiële GitHub-repository: BerriAI/litellm =========================================================================== ⏳ TIJDSTEMPELS & HOOFDSTUKKEN (BEKIJK DIT VOORDAT JE IMPLEMENTEERT): 00:00 De valkuil van gesloten AI-abonnementen en maandelijkse API-kosten 00:48 Waarom ontwikkelaars overstappen op Litellm 01:35 Codearchitectuur en een kijkje achter de schermen 02:20 Stapsgewijze installatie in een live terminal sandbox 03:45 Benchmark van de mogelijkheden in de praktijk en geheugenverbruik 04:50 Productiescore, valkuilen en de uiteindelijke technische specificaties Oordeel ========================================================================== 🔍 WAT IS LITELLM EN HOE WERKT HET? Roep meer dan 100 LLM API's aan met het OpenAI-formaat. Geïntegreerde load balancing, fallback-routering en uitgavenregistratie. ⚡ BELANGRIJKSTE ONTWIKKELAARSPUNTEN: • 100% gratis en open source: Volledige transparantie van de codebase onder een open licentie • Privacy op localhost: Geen gegevensregistratie, geen telemetrie, volledige offline ondersteuning • Geschreven in Python: Uitzonderlijke prestaties met minimale systeembelasting • Massale community: Meer dan 28.500 ontwikkelaars op GitHub 💻 STAP-VOOR-STAP INSTALLATIECOMMANDO'S VIA DE TERMINAL: git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # Op Linux/macOS: source .venv/bin/activate pip install -e . ============================================================================ 🔔 ABONNEER JE OP DAILYDEV AI: We testen en analyseren elke dag twee gloednieuwe, trending open-source AI-repositories tijdens de Amerikaanse piekuren (11:00 uur EST en 17:00 uur EST). Abonneer je en klik op het belletje, zodat je nooit meer de volgende virale open-source AI-tool mist! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [pa] ਕਲਾਉਡ API ਸਬਸਕ੍ਰਿਪਸ਼ਨਾਂ ਨੂੰ ਰੱਦ ਕਰੋ: 100% ਮੁਫ਼ਤ ਸੈਲਫ-ਹੋਸਟ ਚਲਾਓ #1 ਮਹਿੰਗੇ ਮਾਸਿਕ API ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਦਾ ਭੁਗਤਾਨ ਕਰਨਾ ਬੰਦ ਕਰੋ! ਅੱਜ ਦੀ ਡੂੰਘੀ ਖੋਜ ਵਿੱਚ, ਅਸੀਂ ਡੇਲੀਡੇਵ ਏਆਈ 'ਤੇ ਲਿਟੇਲਮ (28,500 ਗਿੱਟਹੱਬ ਸਟਾਰ) ਨੂੰ ਅਸਲ-ਸੰਸਾਰ ਵਿਕਾਸਕਾਰ ਸਮਰੱਥਾ ਬੈਂਚਮਾਰਕ ਦੇ ਜ਼ਰੀਏ ਪੇਸ਼ ਕੀਤਾ। 👉 ਅਧਿਕਾਰਤ GitHub ਰਿਪੋਜ਼ਟਰੀ ਪ੍ਰਾਪਤ ਕਰੋ: BerriAI/litellm = ਫੈਸਲਾ ================================================================================================== 🔍 LITELLM ਕੀ ਹੈ ਅਤੇ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ? OpenAI ਫਾਰਮੈਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ 100+ LLM API ਨੂੰ ਕਾਲ ਕਰੋ। ਯੂਨੀਫਾਈਡ ਲੋਡ ਬੈਲੇਂਸਿੰਗ, ਫਾਲਬੈਕ ਰੂਟਿੰਗ, ਅਤੇ ਖਰਚ ਟਰੈਕਿੰਗ। ⚡ ਮੁੱਖ ਡਿਵੈਲਪਰ ਹਾਈਲਾਈਟਸ: • 100% ਮੁਫ਼ਤ ਅਤੇ ਓਪਨ-ਸੋਰਸ: ਓਪਨ ਲਾਇਸੈਂਸ ਅਧੀਨ ਪੂਰੀ ਕੋਡਬੇਸ ਪਾਰਦਰਸ਼ਤਾ • ਲੋਕਲਹੋਸਟ ਗੋਪਨੀਯਤਾ: ਜ਼ੀਰੋ ਡਾਟਾ ਟਰੈਕਿੰਗ, ਜ਼ੀਰੋ ਟੈਲੀਮੈਟਰੀ, ਪੂਰੀ ਔਫਲਾਈਨ ਸਹਾਇਤਾ • ਪਾਈਥਨ ਵਿੱਚ ਲਿਖਿਆ: ਘੱਟੋ-ਘੱਟ ਸਿਸਟਮ ਓਵਰਹੈੱਡ ਦੇ ਨਾਲ ਬੇਮਿਸਾਲ ਪ੍ਰਦਰਸ਼ਨ • ਵਿਸ਼ਾਲ ਕਮਿਊਨਿਟੀ ਗੋਦ: GitHub 'ਤੇ 28,500+ ਡਿਵੈਲਪਰ 💻 ਕਦਮ-ਦਰ-ਕਦਮ ਟਰਮੀਨਲ ਇੰਸਟਾਲੇਸ਼ਨ ਹੁਕਮ: git ਕਲੋਨ BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # Linux/macOS 'ਤੇ: source .venv/bin/activate pip install -e . == [pl] Anuluj subskrypcje Cloud API: Uruchom w 100% darmowy self-host #1 Przestań płacić drogie, miesięczne subskrypcje API! W dzisiejszym dogłębnym badaniu poddaliśmy Litellm (28 500 gwiazdek GitHub) najbardziej zaawansowanemu testowi porównawczemu możliwości programistów w świecie rzeczywistym na platformie DailyDev AI. 👉 Pobierz oficjalne repozytorium GitHub: BerriAI/litellm ================================================================================== ⏳ ZNACZNIKI CZASU I ROZDZIAŁY (OBEJRZYJ PRZED WDROŻENIEM): 00:00 Pułapka zamkniętej subskrypcji AI i miesięczne rachunki za API 00:48 Dlaczego programiści przechodzą na Litellm 01:35 Architektura bazy kodu i przewodnik po systemie 02:20 Instalacja terminala na żywo krok po kroku w środowisku testowym 03:45 Test wydajności w warunkach rzeczywistych i zużycie pamięci 04:50 Wynik produkcyjny, pułapki i inżynieria końcowa Werdykt ================================================================================ 🔍 CZYM JEST LITELLM I JAK DZIAŁA? Wywołuj ponad 100 interfejsów API LLM za pomocą formatu OpenAI. Ujednolicone równoważenie obciążenia, routing awaryjny i śledzenie wydatków. ⚡ NAJWAŻNIEJSZE INFORMACJE DLA DEWELOPERÓW: • 100% darmowy i open-source: Pełna transparentność kodu na podstawie otwartej licencji • Prywatność hosta lokalnego: Brak śledzenia danych, brak telemetrii, pełne wsparcie offline • Napisany w Pythonie: Wyjątkowa wydajność przy minimalnym obciążeniu systemu • Masowa adaptacja społeczności: Ponad 28 500 programistów na GitHubie 💻 POLECENIA INSTALACJI KROK PO KROKU W TERMINALU: git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # W systemie Linux/macOS: source .venv/bin/activate pip install -e . ================================================================================ 🔔 SUBSKRYBUJ DAILYDEV AI: Testujemy i analizujemy dwa zupełnie nowe, popularne repozytoria AI typu open source każdego dnia w godzinach szczytu w USA (11:00 EST i 17:00 EST). Zasubskrybuj i kliknij dzwonek, aby nigdy nie przegapić kolejnego viralowego narzędzia AI typu open source! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [pt-BR] Cancele Assinaturas de APIs na Nuvem: Hospede Gratuitamente 100% #1 Pare de pagar assinaturas mensais caras de API! Nesta análise detalhada, colocamos o Litellm (28.500 estrelas no GitHub) à prova no teste definitivo de capacidade de desenvolvimento do DailyDev AI. 👉 Baixe o repositório oficial do GitHub: BerriAI/litellm ========================================================================== ⏳ MARCAÇÕES DE TEMPO E CAPÍTULOS (ASSISTA ANTES DE IMPLANTAR): 00:00 A armadilha da assinatura fechada de IA e as faturas mensais da API 00:48 Por que os desenvolvedores estão migrando para o Litellm 01:35 Arquitetura do código-fonte e tour pelos bastidores 02:20 Instalação passo a passo do sandbox do terminal ao vivo 03:45 Benchmark de capacidade no mundo real e consumo de memória 04:50 Pontuação de produção, armadilhas e engenharia final Veredito ========================================================================== 🔍 O QUE É O LITELLM E COMO FUNCIONA? Chame mais de 100 APIs do LLM usando o formato OpenAI. Balanceamento de carga unificado, roteamento alternativo e rastreamento de gastos. ⚡ PRINCIPAIS DESTAQUES DO DESENVOLVEDOR: • 100% Gratuito e de Código Aberto: Transparência total do código-fonte sob licença aberta • Privacidade em Localhost: Zero rastreamento de dados, zero telemetria, suporte completo offline • Escrito em Python: Desempenho excepcional com sobrecarga mínima do sistema • Adoção Massiva da Comunidade: Mais de 28.500 desenvolvedores no GitHub 💻 COMANDOS DE INSTALAÇÃO PASSO A PASSO NO TERMINAL: git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # No Linux/macOS: source .venv/bin/activate pip install -e . ========================================================================== 🔔 INSCREVA-SE NO DAILYDEV AI: Testamos e analisamos dois novos repositórios de IA de código aberto que estão em alta todos os dias no horário de pico dos EUA (11h e 17h EST). Inscreva-se e ative o sino para nunca perder a próxima ferramenta de IA de código aberto viral! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [ru] Откажитесь от платных облачных API: запустите 100% бесплатный self-hosted проект №1 Прекратите платить за дорогие ежемесячные подписки на API! В сегодняшнем подробном обзоре мы протестировали Litellm (28 500 звезд на GitHub) на DailyDev AI, проведя строгий тест на проверку навыков разработчиков в реальных условиях. 👉 Скачайте официальный репозиторий GitHub: BerriAI/litellm ========================================================================== ⏳ ВРЕМЕННЫЕ МЕТКИ И РАЗДЕЛЫ (ПРОСМОТРИТЕ ПЕРЕД РАЗВЕРТЫВАНИЕМ): 00:00 Ловушка закрытой подписки на ИИ и ежемесячные счета за API 00:48 Почему разработчики переходят на Litellm 01:35 Архитектура кодовой базы и подробный обзор 02:20 Пошаговая установка песочницы в реальном терминале 03:45 Тест производительности в реальных условиях и потребление памяти 04:50 Оценка производительности в производственной среде, подводные камни и финальная разработка Вердикт ========================================================================= 🔍 ЧТО ТАКОЕ LITELLM И КАК ОН РАБОТАЕТ? Вызов более 100 LLM API с использованием формата OpenAI. Единая балансировка нагрузки, резервная маршрутизация и отслеживание расходов. ⚡ ОСНОВНЫЕ ПРЕИМУЩЕСТВА ДЛЯ РАЗРАБОТЧИКОВ: • 100% бесплатно и с открытым исходным кодом: Полная прозрачность кода под открытой лицензией • Конфиденциальность на локальном хосте: Отсутствие отслеживания данных, отсутствие телеметрии, полная поддержка работы в автономном режиме • Написано на Python: Исключительная производительность с минимальными системными затратами • Широкое распространение в сообществе: Более 28 500 разработчиков на GitHub 💻 ПОШАГОВЫЕ КОМАНДЫ УСТАНОВКИ В ТЕРМИНАЛЕ: git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # В Linux/macOS: source .venv/bin/activate pip install -e . ========================================================================= 🔔 ПОДПИСЫВАЙТЕСЬ НА DAILYDEV AI: Мы ежедневно тестируем и анализируем два новых популярных репозитория с открытым исходным кодом для ИИ в часы пик в США (11:00 и 17:00 EST). Подпишитесь и нажмите на колокольчик, чтобы не пропустить следующий вирусный инструмент с открытым исходным кодом для ИИ! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [ta] கிளவுட் API சந்தாக்களை ரத்து செய்யுங்கள்: 100% இலவசமாக நீங்களே ஹோஸ்ட் செய்யுங்கள் #1 விலையுயர்ந்த மாதாந்திர API சந்தாக்களைச் செலுத்துவதை நிறுத்துங்கள்! இன்றைய ஆழமான ஆய்வில், DailyDev AI-இல் Litellm-ஐ (28,500 GitHub Stars) ஒரு மிகச்சிறந்த நிஜ-உலக டெவலப்பர் திறன் அளவீட்டு சோதனைக்கு உட்படுத்துகிறோம். 👉 அதிகாரப்பூர்வ GitHub ரெபாசிட்டரியைப் பெறுங்கள்: BerriAI/litellm ====================================================================================== ⏳ நேரக்குறிப்புகள் & அத்தியாயங்கள் (செயல்படுத்துவதற்கு முன் பார்க்கவும்): 00:00 மூடிய AI சந்தா பொறி & மாதாந்திர API கட்டணங்கள் 00:48 டெவலப்பர்கள் ஏன் Litellm-க்கு மாறுகிறார்கள் 01:35 கோட்பேஸ் கட்டமைப்பு & உள்ளகச் செயல்பாடு 02:20 படிப்படியான லைவ் டெர்மினல் சாண்ட்பாக்ஸ் நிறுவல் 03:45 நிஜ-உலக திறன் அளவீடு & நினைவகப் பயன்பாடு 04:50 உற்பத்தி மதிப்பெண், சிக்கல்கள் & இறுதிப் பொறியியல் தீர்ப்பு ========================================================================= 🔍 LITELLM என்றால் என்ன & அது எப்படி வேலை செய்கிறது? OpenAI வடிவமைப்பைப் பயன்படுத்தி 100-க்கும் மேற்பட்ட LLM API-களை அழைக்கவும். ஒருங்கிணைந்த சுமை சமநிலைப்படுத்தல், மாற்று வழித்தடம் மற்றும் செலவினக் கண்காணிப்பு. ⚡ முக்கிய உருவாக்குநர் சிறப்பம்சங்கள்: • 100% இலவசம் & திறந்த மூல மென்பொருள்: திறந்த உரிமத்தின் கீழ் முழுமையான குறியீட்டுத் தொகுப்பு வெளிப்படைத்தன்மை • உள்ளூர் ஹோஸ்ட் தனியுரிமை: தரவுக் கண்காணிப்பு இல்லை, தொலை அளவீடு இல்லை, முழுமையான ஆஃப்லைன் ஆதரவு • பைத்தானில் எழுதப்பட்டது: குறைந்தபட்ச கணினி மேல்சுமையுடன் சிறப்பான செயல்திறன் • பரந்த சமூக ஏற்பு: GitHub-இல் 28,500-க்கும் மேற்பட்ட உருவாக்குநர்கள் 💻 படிப்படியான டெர்மினல் நிறுவல் கட்டளைகள்: git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # லினக்ஸ்/macOS-இல்: source .venv/bin/activate pip install -e . ========================================================================= 🔔 டெய்லிடெவ் ஏஐ-க்கு சப்ஸ்கிரைப் செய்யுங்கள்: ஒவ்வொரு நாளும் அமெரிக்காவின் உச்ச நேரத்தில் (காலை 11:00 EST & மாலை 5:00 EST) இரண்டு புத்தம் புதிய, பிரபலமாகி வரும் ஓப்பன்-சோர்ஸ் ஏஐ ரெபாசிட்டரிகளை நாங்கள் சோதித்து, விரிவாக விளக்குகிறோம். சப்ஸ்கிரைப் செய்து பெல் ஐகானை அழுத்தவும், இதன் மூலம் அடுத்த வைரலான ஓப்பன்-சோர்ஸ் ஏஐ கருவியை நீங்கள் ஒருபோதும் தவறவிட மாட்டீர்கள்! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [te] క్లౌడ్ API సబ్‌స్క్రిప్షన్‌లను రద్దు చేయండి: 100% ఉచితంగా సొంతంగా రన్ చేసుకోండి #1 ఖరీదైన నెలవారీ API సబ్‌స్క్రిప్షన్‌లు చెల్లించడం ఆపండి! నేటి లోతైన విశ్లేషణలో, మేము డైలీడెవ్ AIలో లిటెల్మ్ (28,500 గిట్‌హబ్ స్టార్స్)ను అంతిమ వాస్తవ-ప్రపంచ డెవలపర్ సామర్థ్య బెంచ్‌మార్క్‌కు గురిచేశాము. 👉 అధికారిక గిట్‌హబ్ రిపోజిటరీని పొందండి: BerriAI/litellm ====================================================================================== ⏳ టైమ్‌స్టాంప్‌లు & అధ్యాయాలు (డిప్లాయ్ చేసే ముందు చూడండి): 00:00 క్లోజ్డ్ AI సబ్‌స్క్రిప్షన్ ఉచ్చు & నెలవారీ API బిల్లులు 00:48 డెవలపర్లు Litellmకు ఎందుకు మారుతున్నారు 01:35 కోడ్‌బేస్ ఆర్కిటెక్చర్ & అంతర్గత పనితీరు 02:20 దశలవారీగా లైవ్ టెర్మినల్ శాండ్‌బాక్స్ ఇన్‌స్టాలేషన్ 03:45 వాస్తవ ప్రపంచ సామర్థ్య బెంచ్‌మార్క్ & మెమరీ వినియోగం 04:50 ప్రొడక్షన్ స్కోర్, ఎదురైన సమస్యలు & తుది ఇంజనీరింగ్ తీర్పు ========================================================================= 🔍 Litellm అంటే ఏమిటి & అది ఎలా పనిచేస్తుంది? OpenAI ఫార్మాట్‌ను ఉపయోగించి 100+ LLM APIలను కాల్ చేయండి. ఏకీకృత లోడ్ బ్యాలెన్సింగ్, ఫాల్‌బ్యాక్ రూటింగ్, మరియు ఖర్చు ట్రాకింగ్. ⚡ డెవలపర్ యొక్క ముఖ్య ముఖ్యాంశాలు: • 100% ఉచితం & ఓపెన్-సోర్స్: ఓపెన్ లైసెన్స్ కింద పూర్తి కోడ్‌బేస్ పారదర్శకత • లోకల్‌హోస్ట్ గోప్యత: డేటా ట్రాకింగ్ లేదు, టెలిమెట్రీ లేదు, పూర్తి ఆఫ్‌లైన్ మద్దతు • పైథాన్‌లో వ్రాయబడింది: కనీస సిస్టమ్ ఓవర్‌హెడ్‌తో అసాధారణమైన పనితీరు • భారీ కమ్యూనిటీ ఆదరణ: GitHubలో 28,500+ డెవలపర్లు 💻 దశలవారీ టెర్మినల్ ఇన్‌స్టాలేషన్ ఆదేశాలు: git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # Linux/macOSలో: source .venv/bin/activate pip install -e . ========================================================================= 🔔 డైలీడెవ్ ఏఐకి సబ్స్క్రయిబ్ చేసుకోండి: మేము ప్రతిరోజూ యూఎస్ పీక్ టైమ్ (ఉదయం 11:00 EST & సాయంత్రం 5:00 EST)లో రెండు సరికొత్త ట్రెండింగ్ ఓపెన్-సోర్స్ ఏఐ రిపోజిటరీలను పరీక్షిస్తాము మరియు విశ్లేషిస్తాము. సబ్స్క్రయిబ్ చేసుకొని, బెల్ ఐకాన్‌ను నొక్కండి, తద్వారా మీరు తదుపరి వైరల్ ఓపెన్-సోర్స్ ఏఐ టూల్‌ను ఎప్పటికీ మిస్ అవ్వరు! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI [uk] Скасуйте підписки на хмарні API: Запустіть 100% безкоштовний селф-хостинг #1 Припиніть платити дорогі щомісячні підписки на API! У сьогоднішньому глибокому аналізі ми провели Litellm (28 500 зірок GitHub) через найкращий реальний бенчмарк можливостей розробників на DailyDev AI. 👉 Завантажте офіційний репозиторій GitHub: BerriAI/litellm ====================================================================== ⏳ ЧАСОВІ МІТКИ ТА РОЗДІЛИ (ПЕРЕГЛЯНЬТЕ ПЕРЕД РОЗГОРТАННЯМ): 00:00 Закрита пастка підписки на ШІ та щомісячні рахунки за API 00:48 Чому розробники переходять на Litellm 01:35 Архітектура кодової бази та огляд «під капотом» 02:20 Покрокове встановлення в «пісочниці» терміналу 03:45 Реальний бенчмарк можливостей та споживання пам’яті 04:50 Оцінка продукції, підводні камені та остаточна інженерія Висновок ======================================================================== 🔍 ЩО ТАКЕ LITELLM І ЯК ВОНО ПРАЦЮЄ? Викликайте понад 100 LLM API за допомогою формату OpenAI. Уніфіковане балансування навантаження, резервна маршрутизація та відстеження витрат. ⚡ КЛЮЧОВІ ПЕРЕВАГИ РОЗРОБНИКА: • 100% безкоштовно та з відкритим вихідним кодом: повна прозорість кодової бази за відкритою ліцензією • Конфіденційність локального хоста: нульове відстеження даних, нульова телеметрія, повна підтримка офлайн • Написано на Python: виняткова продуктивність з мінімальними системними накладними витратами • Масове впровадження спільнотою: понад 28 500 розробників на GitHub 💻 ПОКРОКОВІ КОМАНДИ ВСТАНОВЛЕННЯ В ТЕРМІНАЛІ: git clone BerriAI/litellm cd LiteLLM python -m venv .venv .venv\Scripts\activate # У Linux/macOS: source .venv/bin/activate pip install -e . ========================================================================== 🔔 ПІДПИСУЙТЕСЬ НА DAILYDEV AI: Ми тестуємо та аналізуємо два абсолютно нові трендові репозиторії з відкритим кодом для штучного інтелекту щодня у піковий час у США (11:00 за східним часом та 17:00 за східним часом). Підпишіться та натисніть на дзвіночок, щоб ніколи не пропустити наступний вірусний інструмент для ШІ з відкритим кодом! #OpenSourceAI #LocalLLM #AIAgents #Python #DeveloperTools #DailyDevAI

【一次資料・GitHub】 ■ 利用額の誤記録と予算管理への影響 litellm#48937 ■ 私が指摘した「0円設定」の盲点 litellm#48953 ■ 開発者による対応の明言 litellm#48953 ■ 実際のコード変更・追加テスト・マージ litellm#48953

AI セルフホスト 5 製品を公式 compose で立てた直後、最初に来た人が管理者になれたのは n8n と Open WebUI だった n8n・Open WebUI・LiteLLM・Langflow・Flowise を、公式の compose ファイルと .env の例のまま起動して確かめました。 | 製品（版） | 立てた直後 | 例のパスワード | |---|---|---| | n8n 2.44.5 | ログインなしで owner を作れる。2 人目は拒否 | Postgres が changePassword で入れる | | Open WebUI 0.12.3 | 最初にサインアップした人が admin。2 人目は 403 | なし | | LiteLLM 1.106.2 | マスターキーが空だと起動を拒否する | Postgres が dbpassword9090 で入れる | | Langflow 1.12.7 | 自動ログインは既定で無効（403） | Postgres が langflow で入れる | | Flowise 3.1.4 | 公式の手順では起動しなかった（後述） | なし（SQLite） | - n8n と Open WebUI は、管理者を作るまでの間なら、外から先に来た人が管理者になれます。「まだ誰もいない」ことも、ログインなしの API で分かります。 - LiteLLM と Langflow は、最近の版で安全な既定に変わっていました。ただし Langflow は、古い版のイメージや LANGFLOW_AUTO_LOGIN=true で、誰でもスーパーユーザーになります。 - データベースの例のパスワードは、3 製品で .env や compose に書かれたまま通りました。 - 5 つとも、公式の compose ファイルはアプリのポートをホストの全インターフェースに公開しています。 これらをセルフホストしていて、外に出す前に何を変えるか決めたい人向けです。 Intruder が 2026 年 3 月 27 日に公開した調査 From enterprise chatbots to gooner caves: exposed AI infrastructure is rampant は、インターネットに公開された AI 関連のサービスに、認証なしで使えるものが多いと報告しています。その中の "an alarming number of hosts appearing to be in a freshly installed setup, without any authentication"（入れたばかりの状態のまま、認証なしで公開されているホストが驚くほど多い）という一文を見て、公式の手順で立てた直後の内側がどうなっているかを確かめることにしました。外から見た数の話は、Intruder の調査を紹介した 【悲報】100万台のAIサービスをスキャンしたら「史上最悪のセキュリティ」だった件 に詳しく書かれています。点検に使った CLI と検証のワークフローは OTA-EITA/ai-selfhost-audit に置いてあります。 対象と前提 - 各プロジェクトの公式の compose ファイルと .env の例を、次の版のまま使いました（2026 年 10 月 29 日時点で、公開から 7 日以上たっている最新の安定版）。 - n8n: n8n-hosting の withPostgres（.env の N8N_VERSION=2.44.5） - Open WebUI: v0.12.3 の docker-compose.yaml - LiteLLM: v1.106.2 の docker-compose.yml と .env.example - Langflow: v1.12.7 の docker_example - Flowise: 3.1.4 の docker/ - 起動したのは 2026 年 10 月 29 日、GitHub Actions の使い捨てのランナーです。外から届かないよう、公開ポートは override ファイルですべて 127.0.0.1 に付け替えています。付け替える前の compose が全インターフェースに公開していることは、docker compose config で確かめました。 - イメージが latest や main の製品は、上の版のタグに固定しました。 立てるときに変えること 先に、確かめた結果から決めた手順を載せます。理由は製品ごとの節にあります。 | 製品 | 外に出す前にやること | |---|---| | 共通 | 管理者を作るまではポートを 127.0.0.1: で公開する。DB のポートは公開しない。例のパスワードを作り直す | | n8n | 先に owner を作る（または N8N_INSTANCE_OWNER_MANAGED_BY_ENV=true で env から作る）。N8N_ENCRYPTION_KEY と N8N_RUNNERS_AUTH_TOKEN を生成する。2.45.5 以降にする | | Open WebUI | WEBUI_ADMIN_EMAIL と WEBUI_ADMIN_PASSWORD を設定する。WEBUI_SECRET_KEY を生成する。CORS_ALLOW_ORIGIN を自分のオリジンにする | | LiteLLM | LITELLM_MASTER_KEY と LITELLM_SALT_KEY を生成する。DATABASE_URL のパスワードを変える | | Langflow | イメージを 1.10.3 以降に固定する。LANGFLOW_AUTO_LOGIN を true にしない | | Flowise | 先に owner を登録する。TRUST_PROXY をプロキシのアドレスにする | n8n: ログインなしで owner を作れる n8n は、最初に owner（管理者）を作るまでの間、owner を作る API を認証なしで受け付けます（owner.controller.ts L25-29、ownership.service.ts L227-232）。条件は「まだ owner がいないこと」だけです。 curl -s http://127.0.0.1:5678/rest/settings | jq .data.userManagement.showSetupOnFirstLoad curl -s -o /dev/null -w '%{http_code}\n' -X POST http://127.0.0.1:5678/rest/owner/setup \ -H 'content-type: application/json' \ -d '{"email":"lab-owner@example.com","firstName":"Lab","lastName":"Owner","password":"Lab-Owner-Passw0rd"}' | 確かめたこと | 結果 | |---|---| | ログインなしで GET /rest/settings | showSetupOnFirstLoad: true | | ログインなしで POST /rest/owner/setup | 200。送ったメールアドレスで owner ができた | | もう一度 POST /rest/owner/setup | 400 Instance owner already setup | | owner を作ったあと、ログインなしで GET /rest/workflows | 401 | /rest/settings は誰でも読めるので、「この n8n にはまだ owner がいない」ことが外から分かります。owner を作ったあとは、ほかの API は 401 になりました。危ないのは、立ててから owner を作るまでの間です。 .env には、POSTGRES_PASSWORD=changePassword や RUNNERS_AUTH_TOKEN=changeRunnerAuthToken のような例の値が入っています。Postgres には実際に changePassword でログインできました。 なお、n8n の基本認証（N8N_BASIC_AUTH_*）は 2023 年 6 月の #6362 で削除されています。今の n8n でこの変数を設定しても、何も変わりません。 Open WebUI: 最初にサインアップした人が admin Open WebUI は、最初に登録したユーザーを admin にして、そのあとのサインアップを止めます（auths.py L811-827）。 curl -s http://127.0.0.1:3000/api/config | jq .onboarding curl -s -X POST http://127.0.0.1:3000/api/v1/auths/signup -H 'content-type: application/json' \ -d '{"name":"first","email":"first@example.com","password":"Lab-First-Passw0rd"}' | jq .role | 確かめたこと | 結果 | |---|---| | ログインなしで GET /api/config | onboarding: true | | 最初の POST /api/v1/auths/signup | 200、role: admin | | 2 人目の POST /api/v1/auths/signup | 403 | n8n と同じで、/api/config から「まだ誰も登録していない」ことが分かります。WEBUI_ADMIN_EMAIL と WEBUI_ADMIN_PASSWORD を設定すると、起動時に admin が作られてサインアップも止まります（env.py L804-806）。 LiteLLM: マスターキーがないと起動しない LiteLLM は、マスターキーが未設定・空・sk-1234 のときは起動を拒否します（master_key_boot_check.py）。公式の .env.example は LITELLM_MASTER_KEY = "" なので、そのまま起動すると次のように止まりました。 LiteLLM proxy refused to start: the master key is empty. マスターキーを設定して起動し直すと、/health と /metrics はキーなしでは 401 でした。安全側に倒した既定です。 一方、compose ファイルには DATABASE_URL: "postgresql://llmproxy:dbpassword9090@db:5432/litellm" が直接書かれていて、Postgres は 5432:5432 で全インターフェースに公開されています。実際に dbpassword9090 でログインできました。Postgres にはキーのハッシュや、暗号化されたプロバイダーの認証情報が入ります。 LITELLM_SALT_KEY を設定しないと、その暗号化にもマスターキーが使われます（encrypt_decrypt_utils.py L32-40）。 Langflow: 既定では安全、ただし 1.10.2 より前のイメージに注意 Langflow のコードの既定は今も AUTO_LOGIN=True です（auth.py L96-104）。公式のイメージは 1.10.2 から LANGFLOW_AUTO_LOGIN=false を入れていて（build_and_push.Dockerfile L234-235）、イメージで動かす限りは無効です。 | 確かめたこと | 結果 | |---|---| | 1.12.7 のイメージのまま GET /api/v1/auto_login | 403 | | LANGFLOW_AUTO_LOGIN=true にして同じリクエスト | 200。スーパーユーザーのアクセストークンが返った | | 例のパスワード langflow で Postgres にログイン | できた | 公式の docker_example はイメージが langflowai/langflow:latest なので、今 pull すれば安全な既定になります。古いタグに固定しているなら注意が必要です。2026 年 10 月 30 日の時点で、CISA の 悪用が確認された脆弱性のカタログ（KEV）には Langflow の脆弱性が 6 件載っています。 | CVE | KEV に載った日 | 対象の版 | |---|---|---| | CVE-2025-3248 | 2025-05-05 | 1.3.0 未満 | | CVE-2026-33017 | 2026-03-25 | 1.8.2 以前 | | CVE-2025-34291 | 2026-05-21 | 1.6.9 以前 | | CVE-2026-55255 | 2026-07-07 | 1.9.1 未満 | | CVE-2026-0770 | 2026-07-21 | 1.7.3 以前 | | CVE-2026-9198 | 2026-08-04 | 1.10.0 以前 | 対象の版は GitHub Advisory Database の記載です。KEV の 6 件を外すだけなら 1.10.1 以降で足りますが、自動ログインが既定で無効になるのは 1.10.2 から、MCP の stdio サーバーの設定からのコマンド実行（GHSA-w794-rj3p-xv45、critical）が直ったのは 1.10.3 からです。固定するなら 1.10.3 以降にします。 Flowise: 公式の手順では起動しなかった Flowise も、最初に登録した人が owner になる作りです（account.service.ts L178-197）。これを確かめるつもりでしたが、起動できませんでした。 1. 公式の compose と .env.example のままでは、ログのディレクトリを作るところで mkdir '' に失敗して落ちます。compose が全変数を LOG_PATH=${LOG_PATH} の形で渡すので、.env.example でコメントアウトされている変数が空文字になるためです（#6030、修正の PR #6031 はまだ開いています）。 2. issue のとおりパスを .env に入れると先へ進みますが、3.1.4 のイメージ自体が依存パッケージのエラーで起動に失敗しました。これも既知の問題です（#6688）。 そのため Flowise は、ソースを読んだ結果だけを点検ツールのルールにしています。なお Flowise の FLOWISE_USERNAME / FLOWISE_PASSWORD による基本認証は、ドキュメントで 3.0.1 から非推奨とされていて（app-level.md）、3.1.4 のソースにはもう参照がありません。設定しても効きません。 設定から見つける ここまでのことは、compose ファイルと .env を読めば分かります。ai-selfhost-audit は、compose ファイルの image から製品を見分けて、製品ごとの設定とイメージの版を調べます。Docker にもネットワークにも触りません。 go install github.com/OTA-EITA/ai-selfhost-audit/cmd/ai-selfhost-audit@latest cd your-compose-dir ai-selfhost-audit n8n の公式の compose ファイルに使うと、次のようになります。 SEVERITY ID SERVICE LOCATION FINDING HIGH N8N010 n8n docker-compose.yml:27 n8n version has an unpatched expression sandbox escape MEDIUM GEN007 n8n .env:8 Database password is an example from an official compose file MEDIUM GEN007 postgres .env:4 Database password is an example from an official compose file MEDIUM GEN007 postgres .env:8 Database password is an example from an official compose file MEDIUM N8N001 n8n docker-compose.yml:27 First visitor can claim the n8n owner account MEDIUM N8N003 n8n .env:10 Task runner auth token is an example value MEDIUM N8N008 n8n docker-compose.yml:27 n8n SSRF protection is off INFO GEN002 n8n docker-compose.yml:42 Application port published on all host interfaces 8 findings: 1 high, 6 medium, 0 low, 1 info HIGH の N8N010 は、.env が指定している 2.44.5 に、まだ修正されていない式のサンドボックス脱出（GHSA-gx3v-3x3v-f8r5）があるという指摘です。2.44 系には修正版がなく、2.45.5 以降に上げる必要があります。 ルールは全部で 50 個です。製品ごとに、上で見た「最初の訪問者」「例の値」のほか、コード実行やファイルアクセスの制限を外す設定、既知の脆弱性がある版などを見ます。各ルールには、根拠になるソースの行や advisory へのリンクを付けました。 確かめていないこと - Flowise の「最初に登録した人が owner」の挙動。上のとおり起動できなかったので、ソースを読んだだけです - 公開されている「入れたばかり」のホストが、実際にこの時間差で残ったものかどうか。立ててから管理者を作るまでの間に外から見えていれば同じ状態になる、というところまでしか言えません - 公式の compose 以外の立て方（Helm チャート、各社のマネージド版、ワンクリックのテンプレート） 参考 - From enterprise chatbots to gooner caves: exposed AI infrastructure is rampant（Intruder） - n8n-io/n8n-hosting withPostgres - open-webui/open-webui v0.12.3 - BerriAI/litellm v1.106.2 - langflow-ai/langflow v1.12.7 - FlowiseAI/Flowise 3.1.4、#6030、#6688 - CISA Known Exploited Vulnerabilities Catalog - GitHub Advisory Database: Langflow - OTA-EITA/ai-selfhost-audit