Stigg 2.0 Stigg 2.0 是为AI产品设计的实时用量执行与治理运行时，帮助开发者实现计量、信用控制和权限管理，提升计费效率。 热门评论 PH 用户Hi everyone, Dor here, co-founder and CEO of Stigg.四年前，Anton 和我创立了 Stigg，因为在内部自建定价和权限系统正在悄无声息地消耗工程团队。每次定价调整都要重新部署，每笔企业交易都变成一次定制集成。我们对问题的判断是对的。然后 AI 浪潮让它变得更加尖锐。最前沿的 AI 公司开始从零自建计费和访问控制基础设施，因为市场上没有任何产品能实时判断一个请求是否应该放行。一家前沿实验室的金融工程负责人说得直白：他们需要的是一种接近实时的能力，回答一个问题——你有没有 credits？当一次 API 调用就要真金白银，智能体在毫秒级生成子智能体时，“月底再对账”就不再是策略了。Stigg 2.0 是我们的答案：面向 AI 产品的用量 runtime。它能在每个客户、用户、团队和智能体尝试操作的那一刻，决定他们被允许做什么。Credits、计量、权限和治理——一个系统就能搞定，同时与你已经使用的计费栈并存。对 AI 初创公司永久免费，因为我们希望你们构建自己的产品，而不是重复造轮子。当你们拿下那个会让自建系统崩溃的企业订单时，我们已经在了。我们在 AI World Fair 发布。非常希望听到你们的真实想法：试试看，压一压，然后告诉我们缺了什么。PH 用户Hey PH, Anton here, Stigg's CTO with the under the hood bites behind Stigg 2.0!当 OpenAI 在二月份发表《Beyond Rate Limits》时，他们描述了一个决策瀑布流：每个请求通过单一的评估路径，同步检查 rate limits、验证 credits，并返回一个最终决定，同时借贷异步结算。读到那篇文章时，我们认出了自己的架构。难点从来不是想法，难点在于当一个 AI 智能体向共享 credit 池发起 50 个并行调用时，仍然要在个位数毫秒内做出正确的决策。几个我引以为豪的点：Credits 运行在金融级账本上：API 响应返回前余额就更新了，透支在 wallet 级别强制执行，消耗遵循可配置的优先级规则——先用促销赠送的，快过期的先用，最后用付费的。一个符合 ASC 606 的账本，具有完整来源可溯。Usage Governance 在每次请求的 P99 低于 5ms 内强制执行限制和用户级消费上限。我认为这是最重要的部分。一个高消耗用户一天烧掉整个企业的全部配额，这不是靠发票能解决的。你必须在消费点解决，否则根本解决不了。在你的云上部署一个完整的计量栈：Kafka、Flink 和 ClickHouse。在真正需要的地方，以 exactly-once 保证每秒处理超过 100 万事件。模块化 BYOC——每个模块独立部署到你的 VPC 中。计量、Usage Governance 和 Credits 引擎运行在你的云上，配置和管理留在我们这边。清晰的信任边界，你的拓扑。来试试 demo 吧，阅读文档 docs.stigg.io，告诉我在哪里会崩。这正是我们想要的反馈。PH 用户自己做计量和权限系统，结果搞成了第二款我们不想维护的产品。很喜欢你们把这些变成一个在请求路径中执行（而不是在发票上执行）的 runtime。恭喜发布！PH 用户同步检查、异步结算的拆分是对的。我想挑刺的是并发智能体突发：如果一个智能体在单个 tick 中扇出 50 个调用，它们都能在第一次扣款结算前通过信用检查，那么零透支到底怎么保证？是在检查时设置一个 hold 或预留，还是乐观对账？我们遇到过智能体循环正好在那段时间内超出预算。PH 用户恭喜发布，Stigg 团队！看到你们的创新总是很棒。我刚刚试了一下你们的“Install with AI”功能，这正是当今软件开发应该有的样子。5 分钟内，我就在 2 个智能体之间部署了一个完全去中心化的账本。做得好！PH 用户把使用量强制执行嵌入到 runtime 层而不是纯粹在 API 网关层，这是正确的做法。AI 产品的用量计量尤其困难，因为成本是非确定性的，而且你需要在增加延迟的情况下实时执行。Stigg 如何处理流式响应中预计 token 用量和实际 token 用量之间的差距？大多数配额系统正是在这个问题上变得一团糟。 热门产品Dor Sasson2026-07-01原文 打开互动版
四年前，Anton 和我创立了 Stigg，因为在内部自建定价和权限系统正在悄无声息地消耗工程团队。每次定价调整都要重新部署，每笔企业交易都变成一次定制集成。
我们对问题的判断是对的。然后 AI 浪潮让它变得更加尖锐。
最前沿的 AI 公司开始从零自建计费和访问控制基础设施，因为市场上没有任何产品能实时判断一个请求是否应该放行。
一家前沿实验室的金融工程负责人说得直白：他们需要的是一种接近实时的能力，回答一个问题——你有没有 credits？
当一次 API 调用就要真金白银，智能体在毫秒级生成子智能体时，“月底再对账”就不再是策略了。
Stigg 2.0 是我们的答案：面向 AI 产品的用量 runtime。它能在每个客户、用户、团队和智能体尝试操作的那一刻，决定他们被允许做什么。Credits、计量、权限和治理——一个系统就能搞定，同时与你已经使用的计费栈并存。
对 AI 初创公司永久免费，因为我们希望你们构建自己的产品，而不是重复造轮子。当你们拿下那个会让自建系统崩溃的企业订单时，我们已经在了。
我们在 AI World Fair 发布。非常希望听到你们的真实想法：试试看，压一压，然后告诉我们缺了什么。
当 OpenAI 在二月份发表《Beyond Rate Limits》时，他们描述了一个决策瀑布流：每个请求通过单一的评估路径，同步检查 rate limits、验证 credits，并返回一个最终决定，同时借贷异步结算。读到那篇文章时，我们认出了自己的架构。难点从来不是想法，难点在于当一个 AI 智能体向共享 credit 池发起 50 个并行调用时，仍然要在个位数毫秒内做出正确的决策。
几个我引以为豪的点：Credits 运行在金融级账本上：API 响应返回前余额就更新了，透支在 wallet 级别强制执行，消耗遵循可配置的优先级规则——先用促销赠送的，快过期的先用，最后用付费的。一个符合 ASC 606 的账本，具有完整来源可溯。Usage Governance 在每次请求的 P99 低于 5ms 内强制执行限制和用户级消费上限。我认为这是最重要的部分。一个高消耗用户一天烧掉整个企业的全部配额，这不是靠发票能解决的。你必须在消费点解决，否则根本解决不了。在你的云上部署一个完整的计量栈：Kafka、Flink 和 ClickHouse。在真正需要的地方，以 exactly-once 保证每秒处理超过 100 万事件。模块化 BYOC——每个模块独立部署到你的 VPC 中。计量、Usage Governance 和 Credits 引擎运行在你的云上，配置和管理留在我们这边。清晰的信任边界，你的拓扑。
来试试 demo 吧，阅读文档 docs.stigg.io，告诉我在哪里会崩。这正是我们想要的反馈。
5 分钟内，我就在 2 个智能体之间部署了一个完全去中心化的账本。做得好！