先把当时的情况摆出来。用 org admin 在控制台把离职同事的子账号设成 disabled，十分钟后用他留下的 sk-proj 开头的 key 调 gpt-4o-mini 仍然返回 200，账单继续挂在原项目上，直到二十分钟后才变成 401。
把日志和配置对完，能解释这个现象的基本就这几处。网关对鉴权结果有短期缓存，停用要等缓存自然过期。另一种情况是停用成员只挡控制台登录，不回收他名下的 API key。
另外，这个 key 实际挂在服务账号下，与成员账号是两个主体。少数情况下是前面还有一层自建代理握着长连接，连接不断就一直放行。
第一件事是确认这个 key 到底属于哪个主体
curl -s https://api.openai.com/v1/models -H "Authorization: Bearer $SK" -o /dev/null -w '%{http_code}\n'随后在组织 key 列表里按尾号定位后直接吊销
curl -X DELETE https://api.openai.com/v1/organization/api_keys/key_abc123 -H "Authorization: Bearer $ADMIN_KEY"接着把代理层缓存的鉴权结果一起清掉
redis-cli --scan --pattern 'auth:sk:*' | xargs -r redis-cli DEL剩下的就是用旧 key 连打三次确认已经失效
for i in 1 2 3; do curl -s -o /dev/null -w '%{http_code} ' https://api.openai.com/v1/models -H "Authorization: Bearer $SK"; done怎么算真的好了，看的是同一批现象。旧 key 在三次请求里都返回 401 invalid_api_key，组织 key 列表里该条状态是 revoked，账单也不再新增。
容易忽略的是，停用成员和吊销 key 是两件事，离职流程里必须写成两步，否则残留 key 能一直用到缓存过期甚至更久。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。