收到“提示次数已用完”提示时，需等待5小时滚动窗口自动重置、切换API Key分摊压力、引入本地限流中间件、优化Prompt调用模式或临时降级交互频率。

☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜

如果您在使用MiniMax服务时收到“提示次数已用完”的提示，说明您已在当前滚动5小时时间窗口内达到了100次prompt调用上限。以下是应对该限制的具体处理办法：

一、等待滚动时间窗口自动重置

MiniMax的配额机制采用滚动计时方式，即从您第一次发起请求的时间点起，向后推5小时构成一个计时周期；该周期内最多允许100次独立请求，超限后需等待至该周期自然结束才能恢复额度。此过程无需任何操作，系统将自动完成重置。

1、记录下您当日首次调用API或提交prompt的确切时间（例如14:22）。

2、确认该时间点加5小时后的重置时刻（例如19:22）。

3、在此之后发起的新请求将计入下一个独立的5小时周期，额度恢复为100次。

二、切换API Key分摊调用压力

若您拥有多个已通过审核并配置有效的API Key，可通过轮询或按业务模块划分的方式分配请求，使各Key在不同滚动窗口中独立计数，从而规避单Key限流导致的服务中断。

1、登录MiniMax开放平台官网，进入“API密钥管理”页面。

2、检查是否存在处于“启用”状态的备用API Key。

3、在客户端代码中实现Key切换逻辑，例如当检测到429响应时，自动启用下一可用Key重试请求。

4、确保每个API Key均已正确配置至对应环境变量或配置文件中，且未超出各自独立的100次/5小时限额。

三、引入本地限流中间件控制请求节奏

在应用层嵌入基于时间窗口的请求频率控制器，可主动避免触达服务端限流阈值，提升调用稳定性与成功率。该方法适用于高频调用场景，尤其适合批量任务或自动化流程。

1、初始化一个限流器实例，设定每分钟最大请求数（如60次），并维护最近请求的时间戳列表。

2、每次发起请求前，调用限流器的wait_if_needed()方法，自动计算是否需要延迟执行。

3、清理时间戳列表中超过60秒的旧记录，确保仅统计当前分钟内的有效请求。

4、若当前请求数已达上限，则暂停执行直至最早一次请求满60秒，再继续后续调用。

四、检查并优化Prompt调用模式

部分前端或SDK集成方式可能在无感知状态下重复提交相同Prompt，或因错误重试逻辑导致无效调用激增。识别并消除冗余请求可显著延长单个时间窗口内的可用次数。

1、在客户端添加唯一请求ID（如UUID）并打印日志，追踪每次prompt发出的原始来源。

2、审查用户交互逻辑，确认按钮点击、输入框失焦、自动补全等事件未触发多次submit行为。

3、禁用前端默认的连续重试机制，改由服务端返回429时才启动带退避策略的重试流程。

4、对同一语义内容的不同表述进行归一化处理，防止因微小文本差异被识别为多个独立prompt。

五、临时降级至低频交互模式

当必须在当前窗口内继续使用服务但额度已耗尽时，可主动降低交互密度，将多个子任务合并为单次prompt，或改用非实时响应路径，以维持基础功能可用性。

1、将原本分步提问的多轮对话压缩为一段结构化指令，例如使用JSON格式明确任务步骤与约束条件。

2、启用streaming响应模式，在单次请求中接收分块输出，替代多次短请求轮询结果。

3、对非关键路径功能（如预览生成、草稿保存）切换至本地模拟逻辑，暂缓调用远程模型。

4、在UI层显示当前剩余可用次数：0，预计恢复时间：XX:XX，引导用户调整操作节奏。