为OpenAI/Anthropic SDK打造无代理成本追踪包装器

我在为团队构建 LLM 功能的成本工具时，反复遇到同样的权衡。这个领域里每个归因工具的实现方式都一样：把 base_url 指向一个代理服务器，然后它就能在请求发出之前看到每一次调用。如果你想在请求发出前拦截或降级某个调用，这种方式确实有用。但这也意味着这个代理的可用性直接变成了你的可用性，而且你给每一次请求都额外增加了一个网络跳数。

我想要的是归因能力，却完全不动请求路径。所以我写了一个封装层来替代。

Cognocient 直接封装了 OpenAI 和 Anthropic 的 Python 客户端。你依然按照以往的方式调用 client.chat.completions.create()。封装层负责计时，然后在你的真实响应已经返回代码之后，在后台线程上发送成本报告。

真正花了我最多时间的部分不是happy path，而是确保一个死的上报端点永远不会影响到你的应用。如果 Cognocient 的摄入 API 变慢、宕机或者干脆不存在，这个失败必须对你正在构建的应用保持不可见。不允许有任何异常向上冒泡，不允许重试堆积阻塞你的真实调用。有一个测试用例 test_reporter_failure_isolation.py，专门把上报器指向一个不可达的主机，然后断言真实的 API 调用依然能干净地返回。写这个测试让我确信这个设计是合理的，而不是反过来。

你得到的：每一次调用的成本，以及如果你以后想做分摊报表所需的 feature/team/user 标签。

你特意不会得到的：调用前拦截。如果一个调用即将超出你的预算，这个封装层是在它已经发生之后才发现的，和任何计费看板的行为一样。如果你需要在调用发出之前就阻止它，你应该用代理，而且说实话 LiteLLM 或 Portkey 在这方面做得很好。这个工具面向的是那些已经决定"不引入关键路径依赖的可见性"是他们场景的正确权衡的人。

还有一个值得了解的前提：流式响应（stream=True）目前还没有上报。如果你的流量大部分是流式的，这个工具现在不会给你完整的数字。非流式的已经稳定，我称其为生产安全级别。流式是下一个要做的。

from cognocient import CognocientOpenAI as OpenAI

client = OpenAI(api_key="sk-...", cognocient_key="sk-cog-...")
# 客户端的其他所有用法和之前完全一样

MIT 许可证，PyPI 发布有签名 provenance，确实是早期版本（v0.1.x）。如果你已经在用一个网关而且它工作得很好，这个工具可能不适合你。如果你一直因为不想在请求路径上增加一个跳数而迟迟没有做成本可见性，我会很乐意听到这个工具是否有用，或者我是否漏掉了什么明显的东西。

GitHub: https://github.com/mandarvshinde/cognocient-python-wrapper PyPI: pip install cognocient