尧图网站建设 
Composio 平台速率限制与 429 处理组织级配额、响应头与降级策略完全指南【免费下载链接】composioComposio powers 1000 toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composioComposio 对平台 API 实施按组织共享的速率预算所有需要认证的端点工具执行、Connected Accounts、Triggers 等共用同一份配额。本文以 docs/kb/articles/platform-rate-limits.md 为主线结合官方 Rate Limits 参考文档 与仓库源码中的错误提取实现系统讲解各套餐的速率上限、限流响应头X-RateLimit-*与Retry-After、429 的正确处理方式以及升级组织后仍触达旧上限时的排查路径帮助你构建稳定、可观测、不被打爆的 Agent 工作负载。一、限流模型按组织共享的每分钟预算Composio 的速率限制按组织organization维度施加而非按单个 API Key、单个项目或单个工具计算。在固定的 1 分钟窗口内所有经过认证的端点共享同一份预算——工具执行、Connected Accounts、Triggers、Webhook 订阅等全部计入也就是说下表给出的数值是组织在所有 API 调用上的总量而不是某一类调用的单独配额。这一设计意味着并发执行多个 Toolkit 时所有请求共同消耗同一预算高频轮询触发器的应用会与其他业务请求互相挤占配额扩容时应优先评估组织整体用量而不是只看单一端点的调用量。从仓库的 CLI 错误提取实现ts/packages/cli/test/src/utils/api-error-extraction.test.ts可以看到平台将限流错误归类为rate_limitedslug错误码为42901这与 HTTP 语义中的 429 一一对应说明限流是平台错误体系中的一等公民应用层应将其作为可预期、可捕获的错误类型处理。二、各套餐速率上限按组织当前已发布的组织级速率上限如下套餐速率上限窗口Starter / Hobby2,000 请求1 分钟Growth / Pro10,000 请求1 分钟Enterprise自定义Custom-注意KB 文章docs/kb/articles/platform-rate-limits.md使用 Starter / Hobby 与 Growth 的命名而官方 Rate Limits 参考文档 的表格中对应写法为 Hobby 与 ProEnterprise 均为 Custom。套餐命名在不同时期可能调整引用某个套餐的具体数值前务必以当前官方文档为准同时官方明确Enterprise 是自定义Custom配额不应将其描述为无限unlimited。参考文档 docs/content/reference/rate-limits.mdx 中的表格如下PlanRate limitWindowHobby2,000 requests1 minutePro10,000 requests1 minuteEnterpriseCustom-三、限流响应头无需猜测用量每次 API 响应都会携带限流相关的响应头客户端可以据此精确跟踪当前窗口内的用量而无需猜测响应头说明X-RateLimit当前窗口允许的请求总数X-RateLimit-Remaining当前窗口内剩余可用请求数X-RateLimit-Window-Size窗口大小例如60s表示 60 秒Retry-After距窗口重置的秒数仅在 429 响应中出现关键实践在每次响应中读取X-RateLimit-Remaining实时掌握窗口内剩余余量据此动态调整请求节奏当收到429 Too Many Requests时响应体与响应头中包含窗口信息且 429 响应会携带Retry-After——必须在重试前严格遵守Retry-After给出的等待秒数而不是立即重试或密集轰炸端点。超限时的响应体示例来自官方参考文档 docs/content/reference/rate-limits.mdx{ message: Rate limit exceeded. Limit: 10000 requests per 1 minutes }四、429 的标准处理流程结合 docs/kb/articles/platform-rate-limits.md 与官方参考文档 Rate Limits 中的 Best Practices推荐的 429 处理流程如下读取X-RateLimit-Remaining每次响应都检查剩余额度提前预判是否会触顶收到 429 后读取Retry-After按其指示的秒数等待窗口重置等待结束后再重试重试前确认幂等性参考仓库中 sdk-tool-execution-retries.md 的说明——当前 Python SDK0.16.0与 TypeScript SDK0.14.0不会自动重试非幂等的工具执行超时、限流或服务端错误后均不自动重试因此对 send、create、update、delete 等操作手动重试前应通过执行日志或 Provider 状态确认第一次请求是否真的未完成避免重复写入客户端缓存静态数据工具定义tool definitions等不常变化的数据应在客户端缓存避免反复请求消耗配额官方 Best Practices 第 3 条。这套限流感知的节奏控制同样体现在仓库内部的 LLM 调用封装中工作台生成的 Python 辅助代码ts/packages/experimental/src/workbench/python-helpers.generated.ts内置了RATE_LIMIT_PATTERNS可识别rate limit、ratelimit、too many requests、quota exceeded、resource exhausted等限流信号——这说明在真实的多 Provider 场景中限流是一类需要显式识别并纳入退避策略的通用异常。五、Provider 配额与组织配额是两套独立预算组织级速率限制只是其中一层。Provider 侧的配额例如 Google API 的配额限制与 Composio 组织配额相互独立即使 Composio 组织仍有充足容量底层 Provider 的配额耗尽时某个工具依然可能被限流或返回错误。排障时必须区分两层限流Composio 组织配额体现在X-RateLimit-*与Retry-After响应头按组织共享Provider 配额例如 Gmail、Google Sheets 等 Google API 的每日/每分钟配额或 GitHub、Salesforce 等第三方 API 自身限流与组织配额无关也不会出现在 Composio 的限流头中。遇到工具执行被节流时先看错误来自哪一层如果响应包含 Composio 的限流头属于组织配额问题如果错误信息指向 Provider如quota exceeded、resource exhausted则应去 Provider 控制台核查对应 API 配额。六、升级后仍触达旧上限如何与支持团队协作官方 KB 明确指出一个典型问题组织升级套餐后仍观察到旧的 2,000 次/分钟上限。此时不要盲目反复调用测试而是按以下方式收集证据并与支持团队沟通记录错误发生的时间点error time保存该次请求的完整响应限流头response rate-limit headers即X-RateLimit、X-RateLimit-Remaining、X-RateLimit-Window-Size、Retry-After等将时间与响应头一并提供给支持团队用于核对配额生效状态与缓存刷新情况。这两类信息是判断配额是否真正切换的关键证据缺一不可。七、限流相关能力速查需求做法依据查询当前套餐限额查阅官方参考文档docs/content/reference/rate-limits.mdx以当前发布值为准官方文档跟踪窗口剩余量每次响应读取X-RateLimit-RemainingKB 文章 参考文档429 后何时重试严格遵守Retry-AfterKB 文章 参考文档减少无效请求客户端缓存工具定义等静态数据参考文档 Best Practices判断是否重复执行查执行日志与 Provider 状态SDK 不自动重试非幂等操作sdk-tool-execution-retries.md升级后仍限流提供错误时间 限流响应头给支持KB 文章平台侧错误识别429 对应rate_limited42901api-error-extraction.test.ts八、总结Composio 的限流体系可以概括为三条主线组织级共享的每分钟预算Starter/Hobby 2,000、Growth/Pro 10,000、Enterprise 自定义、通过响应头精确感知与优雅降级X-RateLimit-*跟踪余量、Retry-After指导退避、以及组织配额与 Provider 配额相分离的双层模型。实践中只需做到引用套餐数值前核对官方文档、每次请求读取剩余量、429 后严格遵循Retry-After、缓存静态数据减少无效调用并在升级后遇到旧上限时及时携带时间戳与限流头联系支持——即可让 Agent 工作负载在配额之内稳定运行。【免费下载链接】composioComposio powers 1000 toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Composio 平台速率限制与 429 处理：组织级配额、响应头与降级策略完全指南
Composio 平台速率限制与 429 处理组织级配额、响应头与降级策略完全指南【免费下载链接】composioComposio powers 1000 toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composioComposio 对平台 API 实施按组织共享的速率预算所有需要认证的端点工具执行、Connected Accounts、Triggers 等共用同一份配额。本文以 docs/kb/articles/platform-rate-limits.md 为主线结合官方 Rate Limits 参考文档 与仓库源码中的错误提取实现系统讲解各套餐的速率上限、限流响应头X-RateLimit-*与Retry-After、429 的正确处理方式以及升级组织后仍触达旧上限时的排查路径帮助你构建稳定、可观测、不被打爆的 Agent 工作负载。一、限流模型按组织共享的每分钟预算Composio 的速率限制按组织organization维度施加而非按单个 API Key、单个项目或单个工具计算。在固定的 1 分钟窗口内所有经过认证的端点共享同一份预算——工具执行、Connected Accounts、Triggers、Webhook 订阅等全部计入也就是说下表给出的数值是组织在所有 API 调用上的总量而不是某一类调用的单独配额。这一设计意味着并发执行多个 Toolkit 时所有请求共同消耗同一预算高频轮询触发器的应用会与其他业务请求互相挤占配额扩容时应优先评估组织整体用量而不是只看单一端点的调用量。从仓库的 CLI 错误提取实现ts/packages/cli/test/src/utils/api-error-extraction.test.ts可以看到平台将限流错误归类为rate_limitedslug错误码为42901这与 HTTP 语义中的 429 一一对应说明限流是平台错误体系中的一等公民应用层应将其作为可预期、可捕获的错误类型处理。二、各套餐速率上限按组织当前已发布的组织级速率上限如下套餐速率上限窗口Starter / Hobby2,000 请求1 分钟Growth / Pro10,000 请求1 分钟Enterprise自定义Custom-注意KB 文章docs/kb/articles/platform-rate-limits.md使用 Starter / Hobby 与 Growth 的命名而官方 Rate Limits 参考文档 的表格中对应写法为 Hobby 与 ProEnterprise 均为 Custom。套餐命名在不同时期可能调整引用某个套餐的具体数值前务必以当前官方文档为准同时官方明确Enterprise 是自定义Custom配额不应将其描述为无限unlimited。参考文档 docs/content/reference/rate-limits.mdx 中的表格如下PlanRate limitWindowHobby2,000 requests1 minutePro10,000 requests1 minuteEnterpriseCustom-三、限流响应头无需猜测用量每次 API 响应都会携带限流相关的响应头客户端可以据此精确跟踪当前窗口内的用量而无需猜测响应头说明X-RateLimit当前窗口允许的请求总数X-RateLimit-Remaining当前窗口内剩余可用请求数X-RateLimit-Window-Size窗口大小例如60s表示 60 秒Retry-After距窗口重置的秒数仅在 429 响应中出现关键实践在每次响应中读取X-RateLimit-Remaining实时掌握窗口内剩余余量据此动态调整请求节奏当收到429 Too Many Requests时响应体与响应头中包含窗口信息且 429 响应会携带Retry-After——必须在重试前严格遵守Retry-After给出的等待秒数而不是立即重试或密集轰炸端点。超限时的响应体示例来自官方参考文档 docs/content/reference/rate-limits.mdx{ message: Rate limit exceeded. Limit: 10000 requests per 1 minutes }四、429 的标准处理流程结合 docs/kb/articles/platform-rate-limits.md 与官方参考文档 Rate Limits 中的 Best Practices推荐的 429 处理流程如下读取X-RateLimit-Remaining每次响应都检查剩余额度提前预判是否会触顶收到 429 后读取Retry-After按其指示的秒数等待窗口重置等待结束后再重试重试前确认幂等性参考仓库中 sdk-tool-execution-retries.md 的说明——当前 Python SDK0.16.0与 TypeScript SDK0.14.0不会自动重试非幂等的工具执行超时、限流或服务端错误后均不自动重试因此对 send、create、update、delete 等操作手动重试前应通过执行日志或 Provider 状态确认第一次请求是否真的未完成避免重复写入客户端缓存静态数据工具定义tool definitions等不常变化的数据应在客户端缓存避免反复请求消耗配额官方 Best Practices 第 3 条。这套限流感知的节奏控制同样体现在仓库内部的 LLM 调用封装中工作台生成的 Python 辅助代码ts/packages/experimental/src/workbench/python-helpers.generated.ts内置了RATE_LIMIT_PATTERNS可识别rate limit、ratelimit、too many requests、quota exceeded、resource exhausted等限流信号——这说明在真实的多 Provider 场景中限流是一类需要显式识别并纳入退避策略的通用异常。五、Provider 配额与组织配额是两套独立预算组织级速率限制只是其中一层。Provider 侧的配额例如 Google API 的配额限制与 Composio 组织配额相互独立即使 Composio 组织仍有充足容量底层 Provider 的配额耗尽时某个工具依然可能被限流或返回错误。排障时必须区分两层限流Composio 组织配额体现在X-RateLimit-*与Retry-After响应头按组织共享Provider 配额例如 Gmail、Google Sheets 等 Google API 的每日/每分钟配额或 GitHub、Salesforce 等第三方 API 自身限流与组织配额无关也不会出现在 Composio 的限流头中。遇到工具执行被节流时先看错误来自哪一层如果响应包含 Composio 的限流头属于组织配额问题如果错误信息指向 Provider如quota exceeded、resource exhausted则应去 Provider 控制台核查对应 API 配额。六、升级后仍触达旧上限如何与支持团队协作官方 KB 明确指出一个典型问题组织升级套餐后仍观察到旧的 2,000 次/分钟上限。此时不要盲目反复调用测试而是按以下方式收集证据并与支持团队沟通记录错误发生的时间点error time保存该次请求的完整响应限流头response rate-limit headers即X-RateLimit、X-RateLimit-Remaining、X-RateLimit-Window-Size、Retry-After等将时间与响应头一并提供给支持团队用于核对配额生效状态与缓存刷新情况。这两类信息是判断配额是否真正切换的关键证据缺一不可。七、限流相关能力速查需求做法依据查询当前套餐限额查阅官方参考文档docs/content/reference/rate-limits.mdx以当前发布值为准官方文档跟踪窗口剩余量每次响应读取X-RateLimit-RemainingKB 文章 参考文档429 后何时重试严格遵守Retry-AfterKB 文章 参考文档减少无效请求客户端缓存工具定义等静态数据参考文档 Best Practices判断是否重复执行查执行日志与 Provider 状态SDK 不自动重试非幂等操作sdk-tool-execution-retries.md升级后仍限流提供错误时间 限流响应头给支持KB 文章平台侧错误识别429 对应rate_limited42901api-error-extraction.test.ts八、总结Composio 的限流体系可以概括为三条主线组织级共享的每分钟预算Starter/Hobby 2,000、Growth/Pro 10,000、Enterprise 自定义、通过响应头精确感知与优雅降级X-RateLimit-*跟踪余量、Retry-After指导退避、以及组织配额与 Provider 配额相分离的双层模型。实践中只需做到引用套餐数值前核对官方文档、每次请求读取剩余量、429 后严格遵循Retry-After、缓存静态数据减少无效调用并在升级后遇到旧上限时及时携带时间戳与限流头联系支持——即可让 Agent 工作负载在配额之内稳定运行。【免费下载链接】composioComposio powers 1000 toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考