摘要
两次问题表面上没关系：一次是一个渠道上所有模型都不可用，实际只有一个模型坏了；另一次是 /v1/responses 集中返回 502，实际上游返回的是 4xx。但它们形状一样——我的系统在一个更粗的粒度上做了判断，而真实问题发生在更细的粒度上。
Tag: ai 网关
摘要
做网关时我一开始想"给每个上游接口写一个适配器"，列完清单就停住了：embeddings、moderations、images、audio 这些接口的内容我根本不需要理解，原样转发就行。对它们写适配器等于为每个接口维护一套可能与上游产生分歧的结构体。这篇讲这条路——代码只有几十行，但有几个我认为值得说的决定。
摘要
接上游 provider 这件事，我一开始以为是"一家一个适配器"。写到第十家才发现，真正需要单独写协议转换逻辑的只有四家，其余二十多家全是同一个适配器的不同配置。这篇讲这个拆分怎么形成的，以及我在接外部地址时踩到的两条边界——SSRF 防护和流式超时，两条我都做错过。
摘要
并发一上来，上游返回 429，而我当时的逻辑把 429 当失败，重试几次就把一个完全健康的账号标记成不健康、从候选里摘掉。这就是"用满"和"用坏"没分开的后果。这篇讲我最后怎么在限流器、冷却时长、重试策略、健康记录、指标标签每一处把它们分开。
摘要
选路这件事比我想的难。优先级相同的渠道怎么分流量、重试该换谁、换的时候会不会误伤别的渠道、授权要不要再验一次、一个渠道坏到什么程度该被摘掉——这篇按我实际动手的顺序讲，中间有两次返工，还有一个后来 review 时自己揪出来的、后果比较严重的 bug。
v0.30.0 是 v0.29.0 之后的 MINOR 启用与稳定性收口版本。v0.29.0 交付的分组重设计 v2（阶段 A–F）全部能力默认关闭、未经真实链路验收；本版按 v0.30 阶段路线图完成 P0 / P1 / P2 三个优先级共 7 项任务：接通部署开关并完成 MySQL / SQLite 真实服务验收，补齐路由 / outbox 可观测性与告警，收口管理台汇总性能与降级语义，为迁移 runner 增加旧元数据表预检，并补齐分组日常操作与账务解释链路。
摘要
从一次我自己撞的墙讲起：网关把上游的 4xx 改写成了 502，而终止分支缺日志，我完全看不到发生了什么。顺着这个坑，我把 /v1/chat/completions 这条链路从头到尾捋了一遍，这篇记录其中的选择——哪些是当初顺手写下的、哪些是返工回来的、哪些我到现在也还没底。
v0.29.0 是 micro-one-api 的 MINOR 路由分组重设计版本，交付分组重设计 v2 的全部实施阶段（A–F）。
v0.28.0 是 micro-one-api 项目在模型可观测性方向的一个重要版本。本版新增按来源与上游模型粒度的被动模型健康监测与管理台看板，修复了多轮 /v1/responses Websocket 连接按累计 usage 重复计费的问题，并把 404 模型不可用判定收窄到 API 形状响应体，避免误配 base_url 把整渠道模型标红。
v0.27.0 是 micro-one-api 项目面向个人部署者与运维审计场景的一个收口版本。本版修复了 SQLite Lite 从空环境到首个聊天请求之间的结算死锁与方言 schema 缺口，补齐了可重复验证的部署 Quickstart，新增只读的历史账务审计工具，并把 K3 canonical charge 灰度的验收 SQL 口径与安全依赖基线彻底固化。
摘要
micro-one-api 是一个 LLM API 网关，对外同时暴露 OpenAI ChatCompletions（/v1/chat/completions）、OpenAI Responses（/v1/responses）和 Anthropic Messages（/v1/messages）三个端点，对内要对接二十多家协议各异的上游渠道。客户端协议和上游协议任意组合，协议转换就成了网关的核心能力。
摘要
本文从“一次调用为什么产生这笔费用”出发，介绍 Token、价格、缓存、订阅和最终入账之间的关系，适合项目使用者、运营人员和开发者阅读。
摘要
本文整理 micro-one-api 从 v0.24.0 到 v0.26.5 共 8 个版本的发布内容。这个周期先完成控制台可用性、双语界面与用户协议和隐私协议基础，随后补齐模型模态与每 1M tokens 定价注册表，再进入用量语义与计费审计的核心建设，最后收口 Go 1.27 工具链、Relay 路由、控制台性能和 Responses 来源归因。范围覆盖 v0.23.3..v0.26.5，共 436 个文件变更、+18.1k/-5.7k 行。
micro-one-api v0.23.x 系列（v0.23.0 / v0.23.1 / v0.23.2）是项目在 relay-gateway 执行架构上的一个重要里程碑。这个系列为 /v1/chat/completions 与 /v1/responses 引入了一套 transport-neutral 的 executor 执行层，并通过 token allowlist 灰度门禁、失败矩阵测试和生产 canary 观察，在小流量、可回滚的前提下完成了新旧路径的验证与切换准备。与此同时，三个补丁版本持续加固了渠道健康、用量日志安全、协议兼容和失败边界。