yetone
4c69ff336b
agent: Codex's subagents can start at an effort of their own, and Claude Code's subagents can have a model of their own ( #468 , #469 ) — Codex reads [agents] default_subagent_reasoning_effort, the effort a spawned subagent starts at when the spawn names none (openai/codex core/src/agent/child_config.rs, config_toml.rs; in codex 0.159.2), and magpie never wrote it. Codex gets a subagent effort field: a square beside its subagents' one that opens the effort slider, unset said to mean the session's effort, or the subagent model's own default. Codex refuses a spawn at a level the subagents' model lacks, so only one it has is taken, and one a new subagent or main model lacks is dropped. Claude Code takes the Agent call's model, then the agent's frontmatter, then CLAUDE_CODE_SUBAGENT_MODEL, then the session's (2.1.287); magpie wrote that env only by itself, the main model while every tier followed it. It gets a subagents field, offered once routed through magpie, whose model outlives a new main model and a tier of its own; unset, the env is written as before. Claude Code has no setting for its subagents' effort beyond each agent's own frontmatter, and omp's task role already takes a thinking level, so neither changes. TestCodexSubagentEffort, TestClaudeSubagentModel and subagent-effort.test.cjs fail without the change. go vet, go build -tags nogui (darwin, GOOS=linux), GOOS=windows go build, go test -tags nogui ./... pass; subagent-effort, omp-roles, claude-effort, panel-effort, agent-layout, model-pick, click-scroll, old-webkit pass.
2026-10-02 03:18:26 +08:00
yetone
953bce2cfb
agents: Codex signed in with only an API key gets magpie as its provider, its picker listing magpie's models ( #322 , dakango: switching the Codex app to one of its own models went to OpenAI, 502) — magpie counted an API key in auth.json as a ChatGPT sign-in and only set openai_base_url, counting on Codex to ask the gateway for its models; but Codex asks for none with an API key (models-manager refresh_available_models returns early), so the picker showed Codex's built-in models and the one magpie model, and a built-in one went to OpenAI with the relay's key. Now only a ChatGPT sign-in takes that route; with an API key alone magpie is the model_provider with model_catalog_json listing every magpie model on for Codex, as when signed out, and a sync moves a setup an older magpie wrote; going back to Codex's own model restores the user's model_provider. A Codex model whose OpenAI can't be reached now fails naming the model and what to do instead of a bare 502. TestCodexAPIKeyUsesProvider, TestCodexAPIKeyBaseURLMoved and TestCodexOwnModelUnreached fail without the change. go vet, go build -tags nogui (darwin, GOOS=linux), GOOS=windows go build, go test -tags nogui ./... pass.
2026-09-30 20:08:27 +08:00
yetone
6c5ed2acf5
agents: CC Switch's provider tables in Codex's config go through magpie too, and the Library brings in every skill found at once (JasonLeeForOnly on Discord: after moving from CC Switch, Codex threads still went to the relay, "model not found" for a magpie model) — CC Switch writes a [model_providers.custom] table (cc-switch, cc-switch-N in older versions) and moves every third-party Codex thread onto it, and a reopened thread takes the provider it was saved with, not model_provider; magpie left those tables pointing at the relay. While a magpie model is on, signed in or not, their base_url is magpie's /v1, the relay's kept in the stash and the table's other keys as they were; a table a profile names, and cc-switch-official, are left alone; Codex's own model or a reset puts the URL back, unless the table was changed since; one pointed away again is named on the agent row and taken back on sync. The Skills tab's "In your agents" gets Bring in all (2+ found), one library write, one that fails named and the others brought in. TestCodexTakesCCSwitchTables, TestImportSkills and import-all-skills.test.cjs (Chromium, WebKit, en/zh) fail without the change. go vet, go build -tags nogui (darwin, GOOS=linux), GOOS=windows go build, go test -tags nogui ./... pass; click-scroll, old-webkit, shared-skills pass.
2026-09-30 18:16:22 +08:00
yetone
98cbea0ffb
agents: Pi's models go to PI_CODING_AGENT_DIR ( #304 ), and the Codex app offers magpie's models' efforts ( #310 ) — Pi keeps settings.json and models.json in PI_CODING_AGENT_DIR when set (~ expanded; @earendil-works/pi-coding-agent config.js), and magpie wrote ~/.pi/agent regardless; omp is read by its own rules (PI_CONFIG_DIR, OMP_PROFILE/PI_PROFILE, then PI_CODING_AGENT_DIR), and the library's Pi and omp targets follow. The Codex app's model picker offers only the efforts in [desktop] enabled-reasoning-efforts of config.toml (ChatGPT.app 26.924: default low…xhigh, ultra, persistent), so a magpie model's max or minimal was never offered; routed through magpie, the efforts its models take are added to the user's list (or the default), nothing else changed, only values the app knows (it drops the setting for any other), comments kept, nothing written when nothing is missing. TestPiAgentDir, TestOmpAgentDir and TestCodexDesktopEfforts fail without the change. go vet, go build -tags nogui (darwin, GOOS=linux), GOOS=windows go build, go test -tags nogui ./... pass.
2026-09-30 18:09:09 +08:00
yetone
e31384b1f9
gateway: Codex on magpie as its provider has its approvals auto-reviewed again (shihao H on X: 自动审批未执行 … 404: magpie knows no model "codex-auto-review") — Codex asks for its guardian review by OpenAI's reviewer model, codex-auto-review, whatever the provider ("independent of current login"), and magpie, knowing no such model, answered 404, which Codex reports as the review service failing. A model Codex names that magpie does not serve now goes to the model Codex is set to (config.toml model), when magpie is its provider, as Codex itself reviews with the turn's model when its catalog lacks the reviewer; the Routing view shows it as the Approval check. Signed in, Codex's own names go on to OpenAI as before. TestCodexStandIn fails without the change; TestCodexAutoReviewStandIn has the Codex request go to the stand-in. go vet, go build -tags nogui (darwin, GOOS=linux), GOOS=windows go build, go test -tags nogui ./... pass.
2026-09-30 16:55:50 +08:00
yetone
3df75514b9
agents: each agent's own model list — under an agent's name on the Agents page, "Showing 5 / 32 models" (or "All 41 models") opens a list to take models out of that agent's picker one by one and put them back (@ChongkaiX on X: 在 magpie 里选哪些模型出现在 Codex 的模型列表里) — until now an agent's list could only be narrowed by whole providers or families (Visible). settings.HiddenModels holds, by agent, the catalog entries taken out, after Visible: a deny list, so a new model is shown. provider.CatalogFor drops them, so the gateway's /models, the agents' files and pickers and Codex's catalog all follow in one place, and catalog.Touched rewrites the agents' files; Codex's own ChatGPT models are dropped from the backend's list too (CodexNativeHidden), and the list's ETag and models_cache tag carry them (CodexListTag) so Codex asks again. The model an agent is set to is marked 在用 and never taken out, on the server as well. The list groups routing groups first, then providers with their logos and on/total, a long group folded; search, 全部/已显示, a group's 全部显示/全部隐藏 on hover, 恢复全部显示; a click on a row applies at once, Esc or a click elsewhere closes it, and nothing scrolls. A renamed provider's hidden models follow it. Tested with agent-models.test.cjs in Chromium and WebKit, English and Chinese; TestHiddenModels (provider), TestCodexModelListHidesOnAgentsPage (gateway) and TestAgentModelsAPI (gui) in sandbox HOMEs. click-scroll, panel-fold, old-webkit, model-pick, menu-scroll, add-button pass; GOOS=linux go vet, linux and windows builds, go test -tags nogui ./... pass. Not tried in the real Wails window or against a real Codex.
2026-09-30 12:44:59 +08:00
Zhaofeng
99a6c0d354
codex: a subscription switched off narrows nothing, its models kept whole (switching the codex provider off left the one picked ChatGPT model as the only one Codex listed) — the codex provider's picks narrow the ChatGPT account's own model list as well as magpie's added models (CodexNativePicked, aed12ac), and ownCodex narrows the picker's OpenAI half the same way. Neither looked at Off, so a provider switched off — which serves no agent anything, by Provider.Off's own promise — still narrowed the account's list to the picks it kept, and a single pick left Codex listing that one model alone. Both now treat a switched-off provider as picking nothing: the account's list is left whole, and the picks stay in providers.json, narrowing again as soon as it is switched on. Tested with a new TestCodexModelListNotNarrowedWhileOff in internal/gateway (a fake backend listing two models; switched off with picks=[gpt-6-sol] both come through, switched on just the pick; fails on main with [gpt-6-sol]) and a new TestCodexOwnModelsNotNarrowedWhileOff in internal/agent (Codex's own picker: both models while off, just the pick while on; fails on main with [gpt-b]). go build -tags nogui ./..., go vet ./internal/agent ./internal/provider ./internal/gateway and go test -tags nogui -count=1 ./... pass ( #274 )
2026-09-30 12:24:56 +08:00
yetone
fd1427de0b
codex: with magpie as Codex's provider, openai_base_url points at magpie as well, so a thread started on Codex's built-in provider and reopened sends a magpie model to magpie, not to ChatGPT's backend ( #259 isymbo: ChatGPT Desktop, "The 'xiaomi/mimo-v2.6-pro' model is not supported when using Codex with a ChatGPT account")
...
ChatGPT Desktop 26.924.22138 is the Codex app renamed (bundle com.openai.codex, codex-cli 0.158.0-alpha.2.1): it reads ~/.codex and honours openai_base_url, model_provider and chatgpt_base_url; the error text comes from chatgpt.com. Codex keeps a thread on the provider it was started on, so an old ChatGPT conversation reopened while magpie is Codex's provider (signed out, allowance used up, or the sign-in set to api) stays on the built-in provider, and magpie removed openai_base_url in that mode, so a magpie model picked in it went to chatgpt.com, which refused it. Provider mode now sets openai_base_url to magpie's gateway too (whose /backend-api/codex serves "provider/model" and passes Codex's own models on), unless the user has one of their own; picking one of Codex's own models or a reset still removes magpie's. Sync adds it to configs an older magpie wrote in provider mode, when the catalog file is magpie's. Verified by driving ChatGPT Desktop's bundled `codex app-server` in a sandbox HOME with a fake ChatGPT auth.json and fake servers: before, a thread started on the built-in provider and reopened with model_provider = "magpie" went to the built-in base URL; now it reaches magpie's /backend-api/codex/responses, and a new thread /v1/responses. Tests: codex_thread_test.go (TestCodexProviderAlsoSetsBaseURL signed out and api, TestCodexProviderKeepsOwnBaseURL, TestCodexSyncAddsBaseURLToProvider; the first and third fail without the change), codex_route_test.go updated for the base URL in provider mode. go vet, go build -tags nogui (and GOOS=linux, GOOS=windows) and go test -tags nogui ./... pass. Not tried in the real ChatGPT Desktop window or with a real account; a thread already open in a running app keeps the settings it was loaded with, and cloud threads never read the local config.
2026-09-30 11:16:59 +08:00
yetone
d37b821908
toml: Codex's config.toml with a multi-line array (notify = [ … ]) is edited right, and an edit that fails leaves every file as it was ( #253 kerwinliu00001: "edited TOML is invalid: line 2, column 1: incomplete number", config.toml left with model_provider gone and [model_providers.magpie] added but no model) — the top-level key edits (GetTOMLTop, SetTOMLTop, DelTOMLTop) went line by line with regexes: a new key went after the last line that looked like key = …, which for notify = [ was inside the array; key = value lines inside a multi-line string were read as keys and a line starting with [ as a table; replacing or deleting a multi-line value touched only its first line. They now locate the top-level keys with the TOML parser, as the table edits already did, each with its value's whole range however many lines it takes (parseTOMLFile, the unnamed root table beside the tables); SetTOMLTop finds all its keys in the file as read and writes once. A file the parser refuses is still read line by line, so a broken config keeps showing its model, and writes to it are refused untouched. And a pick is several writes (Codex: drop model_provider, add magpie's provider table, set openai_base_url and model), each checked, so one failing left the earlier ones on disk: edit.Atomically(fn, paths…) puts each file back to its bytes and mode, or removes one it created, when fn fails, and every field set and Sync of Codex (config.toml and magpie-models.json, so Codex in WSL too), Kimi and Grok goes through it, as do Codex's MCP server writes (putCodex, delCodex). Tested in temp dirs and a temp HOME: the reporter's file read, set and deleted directly and through Codex's model field (signed in, with model_provider and model above the array, with magpie as the provider), the array's text kept and the TOML valid, and back to a Codex model; nested arrays, trailing commas, comments in arrays, [x] and a = b in strings, an inline table in an array; """ and ''' strings holding model = … and [table] lines not read as keys, new keys after their closing quotes, one deleted whole; a forced failure of Codex's last write leaving config.toml byte-identical; TestAtomically. They fail on main (the Codex ones with the reporter's error). go vet ./internal/..., go build -tags nogui (and GOOS=linux, GOOS=windows) and go test -tags nogui ./... pass. Not tried against a real ~/.codex, in WSL or in the GUI; multi-line inline tables (TOML 1.1) are refused by the parser and so left untouched with an error.
2026-09-30 09:31:59 +08:00
yetone
52b3ad3a9e
agent: on Windows, Codex installed in a WSL distro is an agent of its own, codex@wsl:<distro> ("Codex · WSL Ubuntu") — the distros are listed with wsl.exe -l -q (UTF-16LE, or UTF-8 under WSL_UTF8), each asked once through proc for its $HOME, its ~/.codex, a codex on its PATH and its default route, and shown only where Codex is; its files are Codex's own reading and writing (codexIn, at a place rather than a home) through \\wsl.localhost\<distro> (\\wsl$ before that), with the catalog path written in as the distro spells it and what was there stashed under the distro's agent; the gateway written in is 127.0.0.1 when .wslconfig has networkingMode=mirrored and otherwise the Windows host by the distro's default route, with a notice that NAT needs the gateway beyond loopback and through Windows' firewall and that mirrored is the way; its requests stay counted as Codex's, and a profile key is split at its last dot for distro names like Ubuntu-24.04. Nothing runs off Windows. Kimi CLI isn't an agent magpie has yet, so there is no Kimi in WSL. Tested on a Windows box under NAT with a throwaway Alpine distro: detected (the real distros without Codex left out), a magpie model set and reset from the CLI and a test binary, the catalog read inside WSL at /root/.codex; mirrored networking tested only in unit tests
2026-09-28 17:22:30 +08:00
yetone
6e677aabb6
codex: a thread started with magpie as Codex's provider opens again, and Codex can be kept in its API state ( #129 ) — signed in to ChatGPT, a magpie model is routed with openai_base_url ( c3931c9), and moving there from magpie as the provider (an older magpie's wiring, or one made while the account had used its allowance up, bd5bf42) took [model_providers.magpie] away, so the Codex app, which resumes a thread on the provider it was started on, said "Model provider magpie not found" for every one of them and came back signed in to ChatGPT. The table now stays once written, a base-URL wiring writes it too, and a sync puts back one an older magpie took away. Codex gets a sign-in field (magpie codex login api, a small square beside its pickers): api keeps magpie as Codex's provider while it is signed in, the app in its API state with magpie's models only; ChatGPT, the default, is as before
2026-09-28 14:11:17 +08:00
yetone
0f0b8fc87e
gateway: Codex on one of its own models moves on to the next ChatGPT account when the one it is signed in to has used its allowance up — with more of Codex's accounts on in magpie, Codex's requests go through magpie even for its own models (openai_base_url kept, and put back or taken out as accounts are switched on or off) and are served as the codex subscription's, which fails over as its other models do; the account out of allowance rests until ChatGPT says it resets (resets_at), up to an hour at a time. Asked on Discord
2026-09-26 21:11:42 +08:00
yetone
73be42eca8
models: each agent can be shown only some of them — a provider or group gets a family (magpie provider set relay-x family=relay), and magpie visible zcode relay shows zcode only that family's models (or named providers and groups): in the files magpie writes for it and in what /v1/models answers it, told apart by its User-Agent; magpie models zcode lists what it is shown and what is kept from it, and magpie visible zcode all shows it everything again. A model kept from an agent is still served when asked for by name. Asked for on Discord
2026-09-26 16:02:29 +08:00
Zhizhen He and Claude Code
f3d567e07e
agent: TOML tables magpie edits end where the parser says — a table no longer swallows the [[skills.config]] blocks that follow it. A write that would leave an invalid config is refused with its file, line and column
...
Co-Authored-By: Claude Code <noreply@anthropic.com >
2026-09-26 13:46:03 +08:00
yetone
a9aeb4d45f
agent(codex): a Codex that couldn't reach magpie says so — the Codex app writes no history.jsonl, so a Codex it started while magpie wasn't running (the gateway refused it, and it built its model list without magpie's) or before magpie set it up (its requests still went to chatgpt.com or an old port) looked fine; magpie now reads the newest model request Codex logged since it was set (logs_*.sqlite, read-only, a day at most) and shows Apply again with the time and why, and to quit and reopen Codex
2026-09-26 01:16:27 +08:00
yetone
1b5d1f87db
agent: every agent on a magpie model says when it was taken off magpie behind its back, not only Codex — each checks what magpie wired into it to reach the gateway (Claude Code's env base URL and token, and a managed-settings base URL that wins over them; Gemini CLI's .env and its auth type; OpenCode, Pi, Crush, Command Code, Hermes, omp and Grok Build's magpie provider; DeepSeek Harness's llm-deepseek entry and its key in .env), and one pointed elsewhere or gone shows Apply again with what is off in its tooltip; Claude Code, like Codex, is also said to be bypassed when it was used and nothing of it reached the gateway (its history.jsonl), and slash commands no longer count as use. A test takes every such agent off the gateway and back
2026-09-26 01:10:40 +08:00
yetone
04302b1e63
agent(codex): a Codex taken off magpie behind its back says so, with Apply again — something else rewriting config.toml (another switcher, an installer, a profile of its own) left the row showing a magpie model while Codex asked OpenAI for it, and the user blamed magpie; magpie now remembers what it set on each agent (applied.json) and tells three kinds of drift apart: the wiring gone (the provider table, catalog or base URL, or a profile overriding them), a magpie model replaced by one of Codex's own, and a Codex used since with none of its requests reaching the gateway (history.jsonl against when the gateway last saw it — an old process on an old config). A drifted row carries a coral Apply again pill on its name's line (a badge on the logo in the panel), the reason in its tooltip, Keep current settings in the row menu; the window asks /api/drift every 15s, so it shows without a reload
2026-09-26 01:05:19 +08:00
yetone
d6784bd114
codex: a model a custom provider serves takes the reasoning levels models.dev gives it from the others serving it, so the Codex app offers an effort for it (a Volcengine endpoint's glm-5.3-flash showed 中 with nothing to pick, and magpie's effort control a "none" Codex never used) — levels were only taken from models.dev's entry for the vendor itself, and a vendor it doesn't list (a custom provider, a proxy) had none, so Codex's catalog carried no supported_reasoning_levels; a model models.dev doesn't list for its vendor now takes, by bare id as the context window is found, the levels most of the providers giving any give it (glm-5.3-flash: low, high, max, default high), one no one gives levels for keeps none. Codex's effort is settled on one the model takes when a model is picked and when the catalog is synced, magpie shows the catalog's default where none is set, and the gateway sends a Chat vendor reasoning_effort at the model's nearest level (Codex's medium goes to glm-5.3-flash as high), as asked where the model's are not known
2026-09-25 14:54:47 +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
00744ca373
codex: subagents can be put on a magpie model of their own — Codex's spawn_agent tool lists only the first five models it knows, its own ahead of magpie's, so signed in a model spawning a subagent never saw a magpie model to pick; Codex gets a subagents field that writes [agents] default_subagent_model, the model a subagent starts on when none is asked for, offered once Codex runs through magpie and taken out again when it steps back to its own models
2026-09-25 09:23:33 +08:00
yetone
bd5bf422ed
codex: a ChatGPT account out of allowance gets magpie as a provider of Codex's, and a routing group is named as one in the Codex app's list — signed in through openai_base_url, the Codex app won't send anything once the account has used its allowance up, a magpie model's request too, so magpie is then wired as it is when signed out (model_provider, as the account's own models can't run anyway); and the gateway's model list for the signed-in app named a group after its first member's provider ("z-ai/glm-5.3 · nvidia"), reading as that provider's own model, where it now says routing group, as magpie's other lists do
2026-09-25 06:49:01 +08:00
yetone
a9e1a6769a
agent + usage: each agent says what its User-Agent begins with, beside its name and icon, and the gateway tells requests apart by that — usage kept a list of its own, which had to be kept in step with the agents by hand and wasn't (DeepSeek Harness, omp and Command Code were missing from it, so they were drawn with no logo); a new agent is now known by its requests as soon as it is described
2026-09-25 05:51:32 +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
yetone
4a0719f236
codex: its own models, picked in Codex through magpie beside third-party ones, keep what Codex knows of them — image input, context window, tools, as its models cache has them — under magpie's id; they were given the entry of a third-party model, text only
2026-09-25 01:09:22 +08:00
yetone
82a109eab5
picker: a model starred in one agent is a favorite in every agent — magpie's models are starred by their catalog id, not the agent's own spelling of it, so the favorites tab no longer comes up empty ( #33 ); Codex's own models follow the ones ticked on its ChatGPT subscription ( #36 ); the effort slider shows a dot at every level ( #37 ); and a relay Claude Code was pointed at in its own settings.json can be brought in from Import from other apps, as a provider like any other ( #35 )
2026-09-24 22:27:59 +08:00
yetone
402a96c39d
Rename dial to magpie, with a magpie for a logo
...
The product, module path (github.com/yetone/magpie), binaries, env vars
(MAGPIE_ADDR, MAGPIE_DEV_UI, MAGPIE_THEME, MAGPIE_DEBUG), config and cache
folders (~/.config/magpie, ~/.cache/magpie), bundle id (com.yetone.magpie),
gateway provider id and token, and every UI string now say magpie.
On first run magpie copies ~/.config/dial and ~/.cache/dial to the new
folders when they don't exist yet (copy, not move, so a still-running dial
keeps working; the old folders can be deleted by hand later).
The logo is a small round magpie in profile: one path for the header and
the tray, and the app tile adds the white belly and the blue-green tail.
The header mark is drawn in ink rather than the accent colour, which
fought the text in light mode.
2026-09-23 23:55:11 +08:00
yetone
9174a6510b
provider: signed-in agents (Codex, Copilot) become providers
...
A Codex (ChatGPT) or Copilot login is a subscription with models behind
it, so dial offers it as a provider: every other agent can use its models
through the gateway. The agent's own credential file is read each time,
tokens are refreshed the way the agent does it, and only the model picks
are stored. Claude Code is found but deliberately not offered (Anthropic's
terms), and the CLI and API say so.
The gateway signs upstream requests through the provider (Sign/Prepare),
translates non-streaming requests for backends that only stream, and now
recognises an event stream by its body when the vendor sends no
Content-Type, which is what the ChatGPT backend does.
2026-09-23 15:25:05 +08:00
yetone
0b1626be6d
agents: a Default entry that puts an agent back the way it shipped
...
Setting a field to nothing now means the agent's own default: dial's
wiring (gateway provider, model catalog, env) comes out and the key is
removed, so Codex is back on OpenAI's catalog and Claude Code on
Anthropic's. The picker lists it first; the CLI takes `dial <agent>
default`. Also the vendor icon inside a field pill was 22px, not 14px:
the row icon rule outranked it.
2026-09-23 14:37:42 +08:00
yetone
8fb93f8fc2
Make dial a local LLM gateway with preset providers and one catalog
...
dial now serves OpenAI chat completions, OpenAI Responses and the
Anthropic Messages API on 127.0.0.1:3425 and forwards each request to the
vendor that serves the model, translating between the APIs when the vendor
speaks a different one (streaming, tool calls and reasoning included).
Every agent points at that one URL; models are spelled provider/model.
Providers are added from presets (vendors, relays, local servers) with
just an API key, or as custom OpenAI/Anthropic-compatible endpoints.
Keys live in ~/.config/dial/providers.json; nothing is read from the
shell environment. Each provider chooses which of its models to expose.
Agents get gateway wiring instead of vendor-specific tables: Claude Code
via the env block, Codex via a dial model provider plus a model catalog
file, OpenCode/Pi/Crush via a dial provider entry; native settings are
stashed and restored when a native model is picked again.
The Providers page shows the gateway, each provider with the agents on it,
an inline editor with model chips, and an add sheet of preset tiles.
CLI: dial presets | providers | provider add|key|models|test|rm | models | serve.
2026-09-22 22:43:51 +08:00
yetone and Claude
0a234ce41d
dial: one dial for every coding agent's model
...
Wails v3 tray panel and window, TUI and CLI. Switches model, effort and
provider for Claude Code, Codex, Gemini CLI, OpenCode, Pi, Goose, Cursor,
Copilot CLI and Crush with format-preserving config edits. Providers page
and registry, stored keys, live vendor model lists, profiles.
Co-Authored-By: Claude <noreply@anthropic.com >
2026-09-22 21:47:29 +08:00
yetone