用 SQLite 预占额度，防止模型调用超预算

作者给一个周末完成的副项目加上了模型调用额度闸门：用约 90 行 Python 和 SQLite，在请求发出前预占 token，返回后按实际用量结算。它尝试解决的问题很具体：并发请求和重试同时涌入时，如何在调用前拦住超额支出，而不是事后看账单。

目前能确认什么

方案限定单机、单额度、单个数据库文件。每次调用占一行，未完成时按估算值计入总额，完成后改记实际用量。

预占操作通过 BEGIN IMMEDIATE 把额度检查和记录写入放进同一事务，让写操作依次执行。否则，多个请求可能同时读到剩余额度，各自判断够用，合起来却超限。

异常也有记账规则：超时默认扣估算额度；进程中断留下的过期记录，会被结算为估算值。这里的过期清理不会退还额度，而是保守地保留扣账。

节选列出了拒绝超额、结算释放差额、并发预占三类测试，但并发测试代码被截断，无法确认执行结果。部署检查会观察唤醒耗时和账本是否保留，节选没有给出结果。多租户、金额计费和跨机器协调均不在范围内。

我的判断

这套机制适合借鉴到个人工具或单机代理服务中，但「预占成功」还不能直接等同于「绝不超额」。

关键缺口是计量口径。示例将 max_tokens 设为预占值，却用 usage.total_tokens 结算；如果接口前者只限制输出、后者包含输入，实际用量仍可能超过预占。硬上限是否成立，取决于预占值能否覆盖完整用量。

异常处理也需要核实：代码把 ConnectionError 按零扣账，但仅凭异常名称，不能证明请求没有到达服务端。过期记录结算后，迟到响应又会被当前更新条件忽略。估算如何覆盖输入、异常如何分类，以及重启后数据库能否持久保留，都还需要完整原文或对应接口文档确认。