3 Commits

Include renames

Author	SHA1	Message	Date
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
Charan RathoreandCursor Agent	20fe8b4fac	provider: a second Codex account's prompts stay cached when two saves share an mtime - the list on disk was merged, but the in-process cache re-read it only when ModTime changed, so a second write in the same tick left the first account's list in memory; a successful save now drops that cache, and a test puts the mtime back with Chtimes so the collision happens every run (#74) ... Co-authored-by: Cursor Agent <cursoragent@cursor.com>	2026-09-26 00:26:41 +08:00
yetone	2b80641dfc	codex: a ChatGPT account's requests are made as Codex CLI makes them, as Alma's Codex plugin does — the backend gates its newest models on a Codex User-Agent (gpt-5.6-luna answered 404 "Model not found" to magpie's), so a request now says it comes from codex_cli_rs, carries the instructions the account's model list gives each model (kept on disk beside the list, for the gateway to find though another process asked, else Codex CLI's copy, else Codex's generic prompt) with the client's own riding first in the input, and is shaped the way Codex sends one: no stored references or item ids, a tool output without its call told as a note, reasoning summaries and encrypted content asked for, tool_choice auto; and a conversation whose client names none gets a prompt_cache_key of its own, the same on every turn, taken from how the conversation starts, so its cached prompt is found again (Claude Code through magpie went from 74% of its input cached to 96%, where requests without one landed on caches that didn't have it)	2026-09-25 11:44:17 +08:00