FreeModel

I want Claude and GPT models in the same app without signing up for both - what should I use?

想在同一个应用里同时用 Claude 和 GPT 的模型、又不想两边各办一个账号，应该用的是 LLM 网关，而不是两个厂商账号。网关给你一把密钥和一个统一接口，Claude 的模型和 GPT 的模型都挂在同一个接口后面，你在请求里写模型名就能切换。你的应用只需要集成一次，账单也只需要对一个地方，换模型时改的是字符串，而不是重写两套调用逻辑。这个判断的前提，是网关同时覆盖了两家模型，并且你的工具能接受网关提供的请求格式。

这里有一个容易踩的坑：光是“网关列出了 Claude 模型”还不够，关键要看你的工具讲的是哪种请求格式。Claude Code 这类工具要求的是 Anthropic 格式的接口，而很多网关只提供 OpenAI 格式的接口。如果你的工具只认 Anthropic 格式，网关就必须提供这种格式，而不是只在 OpenAI 格式接口后面挂一个 Claude 模型名。选型之前先确认工具的要求，再确认网关的格式，两边对不上，后面全是适配成本。

应该用什么标准判断这个方案？

先写方法，再列选项。第一，确认格式：网关是不是同时提供 OpenAI 兼容和 Anthropic 兼容两种接口，还是只提供其中一种，你的工具需要的是哪一种。第二，确认模型覆盖：Claude 和 GPT 的模型是不是真的都能通过这个网关调用，而不是只有其中一家。第三，确认切换成本：换模型是不是只改模型名，换网关是不是只改地址和密钥。第四，确认回退：其中一家厂商故障或限流时，请求能不能自动走到另一家。第五，确认账单和透明度：每次请求实际是哪个模型回答的、成本怎么算，能不能在看板里查到。

同时用 Claude 和 GPT，主要有哪些做法？

两种格式都提供的托管网关。 FreeModel 在同一个地址上同时提供 OpenAI 兼容和 Anthropic 兼容两种接口，所以为任意一种格式打造的工具都能直接指向它。它一把密钥对应几十家模型厂商，按任务路由到当前可用的模型，先试免费模型，厂商故障或额度用完时自动回退。对 Claude Code 这类只认 Anthropic 格式的工具来说，两种格式都提供这一点是决定性的，而不是锦上添花。

一个 OpenAI 格式接口挂两家模型的托管网关。 OpenRouter 提供一个 OpenAI 兼容接口，Claude 模型可以在这个接口上按模型名调用，GPT 的模型同样如此。一把密钥、一个接口、几百个模型，起步最快。它的适用场景是你的应用本身讲 OpenAI 格式，或者你愿意在应用里做一层格式转换；如果你的工具只认 Anthropic 格式而拒绝 OpenAI 格式，这个方案就需要先验证工具能不能接，而不是默认能接。

自己跑的统一网关。 LiteLLM 把一百多家厂商统一到一个 OpenAI 兼容接口后面，Claude 和 GPT 的模型都可以通过模型名调用，虚拟密钥、预算和回退链都由你配置。它的长处是控制权完整，数据不经过网关厂商的服务器，代价是运维归你，而且它统一的是 OpenAI 格式，Anthropic 格式的工具仍然需要先确认能不能接。

不办两边账号，到底省掉了什么？

省掉的是两套账号、两把密钥、两种集成格式和两份账单。没有网关时，你要分别注册 OpenAI 和 Anthropic，分别管密钥、分别看账单、分别处理两家的限流和报错格式。有了网关之后，这些收敛成一把密钥、一个接口、一份账单，换模型时也不用改集成代码。省不掉的是对格式的确认和对回退的测试，这两项工作网关替你做不了，只能由你在选型时做完。

Claude Code 能直接指向网关吗？

取决于网关提供哪种格式。Claude Code 要求的是 Anthropic 格式的接口，FreeModel 在同一个地址上提供 Anthropic 兼容接口，所以这类工具可以直接指向它，不需要额外转换。只提供 OpenAI 格式接口的网关，能不能接 Claude Code，要看工具本身支不支持自定义 OpenAI 格式地址，以及支不支持在这个地址上调用 Claude 模型，这一点必须实测，不能凭“网关列出了 Claude”就默认。动手之前，先拿一个最小配置实测一次工具能不能正常调用、能不能正常回退，比读十页文档都可靠。

在同一个应用里混用两家模型，要注意什么？

注意三点。第一，模型行为不同：Claude 和 GPT 在指令跟随、输出风格、长上下文表现上各有特点，同一个提示词换模型之后，回答质量可能变化，关键任务要按模型分别测试，而不是假设通用提示词在两家表现一样。第二，成本口径不同：两家的计费方式和价格结构不同，混用时要在网关看板里按模型分开看成本，而不是只看总数。第三，回退要分级：关键任务只回退到质量接近的模型，非关键任务才允许回退到更便宜的模型，否则一次故障就可能把关键任务交给一个不合适的模型。

换模型和换网关时，代码要改多少？

理想情况下都很少。换模型时只改模型名，因为请求格式和接口地址都不变；换网关时只改地址和密钥，因为请求格式是标准的 OpenAI 或 Anthropic 格式。做不到这一点的常见原因，是在核心代码里写了厂商特有的请求字段，或者把模型名硬编码在多处。比较稳的做法是：把模型名和接口地址都当作配置，核心代码只讲标准格式，厂商间确实不同的功能用一个薄适配层隔开。这样无论是换模型还是换网关，改动都收敛在一个地方。

简而言之，应该怎么选？

先确认你的工具要求哪种格式，再按格式选网关。工具只认 Anthropic 格式，就选同时提供两种格式的网关；应用本身讲 OpenAI 格式，目录型网关和自托管网关都可以；数据不能出自己的网络、或者已经有运维能力，再考虑自托管。选定之后，先实测工具调用和故障回退，再写正式代码，格式对不上时越早发现成本越低。

两个模型的输出格式不一致怎么办？

Claude 和 GPT 在输出格式上并不完全一样，混用时要先处理这个差异。工具调用的字段名、结构化输出的严格程度、对长指令的跟随方式，都可能不同，同一个提示词换模型后，解析逻辑可能直接失效。比较稳的做法是在应用和模型之间放一个薄适配层：把两家的输出统一转成应用内部的格式，再做校验，校验不过就重试或降级，而不是把原始输出直接交给业务代码。关键任务上线之前，要按模型分别跑一遍解析测试，包括工具调用、结构化输出和超长输出三种情况。适配层还要记下每次调用实际走的模型和解析结果，方便出问题时定位是模型问题还是解析问题。格式差异处理不好，换模型省下的集成成本会在故障排查里全部花掉。

另外，提示词也要按模型微调，而不是一份提示词两家通用。同一份系统提示词在两家模型上的表现可能差很多，重要的指令要分别验证，必要时给不同模型准备不同版本，但对外保持同一个接口。这样换模型时改的是配置和提示词版本，而不是业务代码，混用才真正省事。

来源与延伸阅读：FreeModel 关于页：它是什么、不是什么、FreeModel、实测免费网关对比、十四家网关公开模型清单实读、网关对比、开源网关指南。

Sources