yetone
|
ab7dd01506
|
codex: /fast works on a routing group too — a group with a ChatGPT account's GPT model in it is listed to Codex with the Fast tier, and the service_tier Codex then sends is kept through the group's routing and passed on to OpenAI's own backends (a ChatGPT account, api.openai.com) only; before, the request was rebuilt without it and Fast did nothing
|
2026-09-27 17:51:38 +08:00 |
|
yetone
|
0ce1888a32
|
codex: Fast mode through a ChatGPT account — a GPT model Codex's own catalog doesn't list carries the Fast tier Codex gives its GPT models, and the priority service_tier Codex sends for /fast reaches the backend instead of being dropped; other providers' models don't offer it, and other tiers are still left out
|
2026-09-27 17:42:43 +08:00 |
|
yetone
|
09c635cf03
|
agents: a model through magpie tells Pi, Crush, omp and Codex how much it holds, and a provider added, edited or removed reaches the model lists agents keep in files of their own — the catalog carried no context window, so Pi took every model through magpie for a 128K one (a CLIProxyAPI's gpt-5.5 holds 922K) and Crush for a 200K one; each model now carries models.dev's input limit, else its context, looked up by bare id as most of the providers serving it give it (a proxy's "openai/gpt-5.4", "gpt-5.4(high)", "glm-4.6:free" find it too; a group holds the least of its members'). And those lists were written only when a model was picked: Codex's magpie-models.json, Pi's models.json, OpenCode's, Crush's, Command Code's, omp's and Hermes' provider blocks and dsh's llm-deepseek entry kept the catalog as it was then, so a provider added later never showed. Saving a provider, a vendor's list fetched anew or models.dev synced now rewrites each one magpie wrote, where it differs, and the app does once at start-up; a Codex signed in to ChatGPT, which asks the gateway, kept its cached list under the backend's ETag, which a change of magpie's never changed — the ETag (and a reply's X-Models-Etag) now carries a tag of magpie's models, and a cache from before a change is aged so the next Codex asks again
|
2026-09-25 12:32:14 +08:00 |
|
yetone
|
626933ff2b
|
codex: a magpie model that takes images says so in the catalog magpie gives Codex, which otherwise drops an attached image before sending — every magpie model was listed as text-only, so a picture pasted into Codex never reached a vision model; whether a model takes images is what its vendor's models.dev entry says, or for one served by a vendor models.dev doesn't list, what most of the providers serving that model say, and a routing group takes them only when every member does
|
2026-09-25 06:59:45 +08:00 |
|
yetone
|
c3931c91df
|
codex: magpie's models join Codex's own rather than replacing them — signed in (ChatGPT or an API key), Codex keeps its built-in OpenAI provider and sign-in and is pointed at magpie with openai_base_url alone, so its official models still go to OpenAI on the user's own account, its threads (listed per provider) stay together, and the Codex app keeps its model picker; magpie's gateway answers at /backend-api/codex, passing Codex's own models through as they came, serving magpie's (provider/model) itself, and handing out OpenAI's model list with magpie's after it for /model. Compacting a magpie model's conversation is done by that model with Codex's own prompt; Codex's compressed request bodies are read, and usage is counted for both. Not signed in, magpie stays a provider of Codex's as before; a magpie set up that way moves over the next time a magpie model is picked
|
2026-09-25 02:42:24 +08:00 |
|