开源 · MIT · 零依赖
挡在失控花费前面的网关。
llm-guard 坐在你的 OpenAI、Anthropic 或 Gemini 调用前面。它记录每个请求实际花了多少，把成本归因到背后的 API key、project 和终端用户，在失控花费还在发生时发现它，并执行硬预算。
运行期依赖
0
只用标准库
额外延迟
4.6ms
最坏情况
测试
214
不需要网络
子命令
15
全部可用
它解决什么问题
一个在请求之间检查的预算，拦不住正在越线的那一个请求。对于一次简短的对话调用，这几乎无所谓。对于一条 200 步的 agent 循环，这就是全部问题：OWASP 记录了一条 200 步循环的成本是单次调用的 100 倍以上，而且 62% 的 agent 账单来自上下文被反复重发。
llm-guard 盯着三种失控花费的形态：
- 上下文循环 —— 持续病态的输入输出 token 比。正常流量在 5:1 到 15:1 之间。已记录的生产事故达到 74:1 和 175:1。
- 速率突发 —— 花费速率远高于你自己账号的基线，而不是高于某个对所有人都不适用的绝对数字。
- 重试风暴 —— 失败调用的爆发。它们仍然消耗延迟，而且常常也消耗 token。
检测永远只是报告。执行是一个单独的、明确的决定：一个带 action=block 的按 key 预算会返回 HTTP 429，而可选的单条流封顶会在流中途掐断一个正在进行的响应。
它有什么不同
| 零运行期依赖 | 只用标准库。一个下午能审完 —— 这很重要，因为请求路径上的网关是高价值目标。 |
| 成本来自计费事实 | 价格来自服务商返回的 usage 块，永远不用本地 token 估算。 |
| 按模型的缓存经济学 | 缓存读按模型不同，是输入价的 2.5% 到 50%。把它当常数就是 4–5 倍的静默误差。 |
| 无法定价就说不 | 如果某个模型没有价格，成本记为 NULL，报为「未定价」。一个看着合理但是错的数字，比一个明显的缺口更糟。 |
| 归因到请求背后的人 | 每一行都带 key、project 和终端用户。没有归因，成本就无法在事故中被诊断。 |
| 能进隔离网络 | 看板是自包含 HTML，图表是内联 SVG。没有 CDN、没有 JS 依赖、没有外部请求。 |
它故意不做什么
一个诚实的限制清单，通常比功能清单更有用。
不终止入站 TLS
负载均衡器做得更好。出站到服务商的 TLS 在进程内完成，并且对着真实 API 验证过。
不读你的 prompt
只有 token 数、模型标识、时间戳和状态。它告诉不了你应用在做什么，因为它看不到。
不悄悄阻塞流量
检测是建议性的。唯一的例外是你自己显式设置的 action=block 预算。
不是可观测性平台
它计量成本并执行预算。它不做提示词实验、评估或向量检索。
超过几百万行就该换
SQLite 在这个量级以上是错的选择，文档里就这么写了。schema 是纯 SQL，可迁移到 Postgres 或 ClickHouse。
不是 LLM 安全工具
PyPI 上的 llm-guard 是另一个项目，做 prompt 注入防护。和这个无关。
三十秒试一下
不需要 API key、不需要网络、不需要注册。
$ git clone https://github.com/leyao-daily/llm-guard.git
$ cd llm-guard
$ python3 -m llmguard seed --reset --compare-days 30
$ python3 -m llmguard anomalies
$ python3 -m llmguard dashboard --out dash.html需要有人帮你看？
如果你的账单难以预测，我们做固定价格的诊断，交付一份书面报告。不需要部署，只读访问用量数据，prompt 和回复永远不离开你的账号。