2026-09-27 20:28:38 +08:00
..
2026-09-25 20:59:08 +08:00
2026-09-27 04:24:03 +08:00
2026-09-27 04:24:03 +08:00
2026-09-26 23:01:53 +08:00
2026-09-24 00:20:59 +08:00
2026-09-24 00:20:59 +08:00
2026-09-27 04:24:03 +08:00
2026-09-27 16:11:23 +08:00
2026-09-27 16:11:23 +08:00
2026-09-26 15:51:13 +08:00
2026-09-27 01:39:22 +08:00
2026-09-27 19:41:12 +08:00
2026-09-25 15:53:33 +08:00
2026-09-27 04:24:03 +08:00
2026-09-26 21:32:42 +08:00
2026-09-27 14:46:22 +08:00
2026-09-27 15:28:33 +08:00
gateway: count_tokens counts the masked prompt, and a count that cannot be had is told apart — the count Claude Code asks for before every turn went to the vendor as the conversation was written, so Mask secrets was defeated on every one; it now goes masked, the same prompt the turn it counts sends. An endpoint that doesn't implement counting (404/405/501, or a 400 that says so, in English or Chinese) falls back to the local estimate as before; a limited key or a broken connection yields to the next checked key and rests the one that failed, as a generation would, while a client's own cancellation rests nothing; and a real error — a wrong key, a prompt past the model's context, an image it won't take — reaches the agent. The gateway tests are isolated from the machine now (a temp HOME, inert stubs for the sign-in CLIs and the keychain) so a cache that outlives a test can't reach a real login, and the redaction tests' cold starts run in parallel. (#103)
2026-09-27 18:58:23 +08:00
2026-09-24 15:49:47 +08:00
2026-09-27 17:42:01 +08:00
2026-09-27 02:25:24 +08:00
2026-09-27 02:25:24 +08:00
devin: served straight through Devin's API, not the CLI over ACP — each request goes to the GetChatMessage RPC the devin CLI itself uses, with its sign-in: the conversation as it is, the caller's tools, images and all, and the reply streamed back text, thinking and tool calls as they come. A family's name is sent as its variant at the effort asked for; Adaptive and Fusion, which the API doesn't serve, are no longer listed. The instructions go at the head of the first message, as Kiro's do, since Devin turns away Claude Code's own in its system field. Tested live from a sandbox: Claude Code and OpenCode on Opus 5.5, SWE-2 and GPT-6 Sol list, read and write files through several tool rounds; images and a tool round trip answered on Claude, SWE, GPT and Gemini models
2026-09-27 15:30:24 +08:00
devin: served straight through Devin's API, not the CLI over ACP — each request goes to the GetChatMessage RPC the devin CLI itself uses, with its sign-in: the conversation as it is, the caller's tools, images and all, and the reply streamed back text, thinking and tool calls as they come. A family's name is sent as its variant at the effort asked for; Adaptive and Fusion, which the API doesn't serve, are no longer listed. The instructions go at the head of the first message, as Kiro's do, since Devin turns away Claude Code's own in its system field. Tested live from a sandbox: Claude Code and OpenCode on Opus 5.5, SWE-2 and GPT-6 Sol list, read and write files through several tool rounds; images and a tool round trip answered on Claude, SWE, GPT and Gemini models
2026-09-27 15:30:24 +08:00
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
2026-09-27 01:29:33 +08:00
2026-09-25 00:07:09 +08:00
2026-09-25 01:15:02 +08:00
2026-09-26 21:32:42 +08:00
2026-09-27 17:51:38 +08:00
2026-09-27 14:46:22 +08:00
2026-09-27 20:28:38 +08:00
2026-09-27 04:24:03 +08:00
2026-09-26 11:09:13 +08:00
2026-09-26 13:41:17 +08:00
2026-09-27 04:24:03 +08:00
2026-09-27 04:24:03 +08:00
2026-09-27 17:51:38 +08:00
providers: Kiro is served through Kiro's own API, as pi-provider-kiro does, not kiro-cli over ACP — magpie reads the sign-in kiro-cli or the Kiro IDE keeps (Google, GitHub, AWS Builder ID / IAM Identity Center, or an external IdP), or takes a Kiro API key saved on the provider, and calls generateAssistantResponse itself: the caller's system prompt, whole history, tools, tool calls and results and images go to the model as they are, with no agent's own prompt and tools between, and its event stream comes back as text, thinking (asked for with Kiro's thinking mode), tool calls streamed as they are written, and usage. kiro-cli no longer has to be installed. A token near its end is refreshed — by kiro-cli when it is its sign-in, else directly, the new one written back where it came from — and one Kiro turns down is refreshed once and the call tried again. History is made the shape Kiro takes: it opens and ends with the user, every call is answered in the next message (an interrupted one said to be so), orphan results go, tools the conversation used but no longer offers are described, ids Kiro rejects are hashed, only the latest images are sent again. Kiro's usage limit is a 429, a prompt too long the error the rest of magpie takes for it. The models are Kiro's list with their context and image support; the account is its email and plan; the Usage page shows its credits and free trial. Issue #90
2026-09-27 01:25:37 +08:00
2026-09-27 04:24:03 +08:00
2026-09-27 15:28:33 +08:00
2026-09-27 13:48:57 +08:00
2026-09-25 21:40:20 +08:00
2026-09-25 21:40:20 +08:00
gateway: count_tokens counts the masked prompt, and a count that cannot be had is told apart — the count Claude Code asks for before every turn went to the vendor as the conversation was written, so Mask secrets was defeated on every one; it now goes masked, the same prompt the turn it counts sends. An endpoint that doesn't implement counting (404/405/501, or a 400 that says so, in English or Chinese) falls back to the local estimate as before; a limited key or a broken connection yields to the next checked key and rests the one that failed, as a generation would, while a client's own cancellation rests nothing; and a real error — a wrong key, a prompt past the model's context, an image it won't take — reaches the agent. The gateway tests are isolated from the machine now (a temp HOME, inert stubs for the sign-in CLIs and the keychain) so a cache that outlives a test can't reach a real login, and the redaction tests' cold starts run in parallel. (#103)
2026-09-27 18:58:23 +08:00
models: a provider's model can go by a name of the user's, and offer only some of its reasoning levels — Claude Opus 5.5 · Claude Code can be Opus 5.5, and a model with six levels can offer just low, medium and high. Both are kept in settings.json by provider/model (modelNames, modelEfforts), apart from the vendor's list, so a Refresh, a restart or an upgrade leaves them, and the same model from another provider keeps its own; a provider renamed takes them along. They are applied where the catalog is made, so the gateway's /v1/models, the lists magpie writes into the agents (Codex's model catalog, ZCode, Pi, OpenCode, OMP …) and magpie's own pages all show them, and a change rewrites the agents' lists as any other change of the catalog does. Only what is shown changes: the id, where requests go, and the levels the vendor is asked at stay as they were; a found routing group keeps the model's own name. The provider's editor has Names & levels under its models — a name typed in place, a tick per level, Restore default — and the terminal has magpie model name <provider/model> <name>|--reset and magpie model efforts <provider/model> low,medium,high|--reset. Issue #92
2026-09-26 23:23:45 +08:00
gateway: count_tokens counts the masked prompt, and a count that cannot be had is told apart — the count Claude Code asks for before every turn went to the vendor as the conversation was written, so Mask secrets was defeated on every one; it now goes masked, the same prompt the turn it counts sends. An endpoint that doesn't implement counting (404/405/501, or a 400 that says so, in English or Chinese) falls back to the local estimate as before; a limited key or a broken connection yields to the next checked key and rests the one that failed, as a generation would, while a client's own cancellation rests nothing; and a real error — a wrong key, a prompt past the model's context, an image it won't take — reaches the agent. The gateway tests are isolated from the machine now (a temp HOME, inert stubs for the sign-in CLIs and the keychain) so a cache that outlives a test can't reach a real login, and the redaction tests' cold starts run in parallel. (#103)
2026-09-27 18:58:23 +08:00
gateway: count_tokens counts the masked prompt, and a count that cannot be had is told apart — the count Claude Code asks for before every turn went to the vendor as the conversation was written, so Mask secrets was defeated on every one; it now goes masked, the same prompt the turn it counts sends. An endpoint that doesn't implement counting (404/405/501, or a 400 that says so, in English or Chinese) falls back to the local estimate as before; a limited key or a broken connection yields to the next checked key and rests the one that failed, as a generation would, while a client's own cancellation rests nothing; and a real error — a wrong key, a prompt past the model's context, an image it won't take — reaches the agent. The gateway tests are isolated from the machine now (a temp HOME, inert stubs for the sign-in CLIs and the keychain) so a cache that outlives a test can't reach a real login, and the redaction tests' cold starts run in parallel. (#103)
2026-09-27 18:58:23 +08:00
2026-09-27 17:51:38 +08:00
gateway: a request an upstream fails is failed over rather than handed back — a model the provider says it doesn't serve (Copilot's "not accessible via the /chat/completions endpoint", "model does not exist" and the like) goes on to the next one, as a 401, 404, 429 or 5xx already did; an error a stream begins with, before any of its content (Anthropic's overloaded error after message_start, a Chat error chunk, Responses' response.failed), is held and failed over as an error status is, while one after content has begun reaches the agent as it came; the last one left, or the only one, is tried again twice after a failure that may pass (408, 5xx, 529, a 429 that says when), a second and then two apart or as Retry-After says; and an agent that goes away mid-request is counted as canceled, resting nobody and asking nobody else. One that answers stops resting. The Routing view tells each of these
2026-09-25 05:24:44 +08:00
2026-09-26 21:32:42 +08:00
2026-09-26 21:32:42 +08:00
2026-09-27 20:28:38 +08:00
2026-09-27 20:28:38 +08:00
2026-09-27 03:41:53 +08:00
2026-09-27 19:41:12 +08:00
2026-09-27 03:29:23 +08:00
2026-09-27 03:29:23 +08:00
2026-09-22 22:43:51 +08:00
2026-09-26 18:59:26 +08:00
2026-09-25 21:29:05 +08:00
2026-09-26 01:38:37 +08:00
gateway(routing, live): the Gateway view plays what routing does with each request as it happens — the site's Model Routing stage, driven by the gateway's own trace: the agent, magpie with the provider's routing, and its accounts or keys in the order routing weighed them, each saying what it was weighed by (how much is used and when it renews, kept for last, not known yet, resting and until when, left out as its plan doesn't list the model); a request travels to the one put first, one that fails shows what it answered and hands it on, and the story beside it says why the first went first, why each other stands where it does, how long a failed one rests and what said so, and what the agent got; recent requests can be picked to see how each was routed, and the counts are the gateway's since it started. Nothing is worked out again in the page: the gateway records each decision where it makes it. A vendor's Retry-After and rate-limit reset headers now come through with its error, so a rate-limited key or account rests as long as the vendor says rather than a minute
2026-09-25 02:28:32 +08:00
2026-09-27 01:53:04 +08:00
2026-09-26 02:14:52 +08:00
2026-09-25 12:20:50 +08:00
2026-09-27 06:28:14 +08:00
