maximhq/bifrost

Description Key.Value and some provider-specific fields (e.g. Azure's endpoint, Vertex's project ID) support env.VARNAME-style resolution via SecretVar. NetworkConfig.BaseURL is a plain string and doesn't get the same treatment — there's no way to point a provider's base_url at an environment variable natively. Why this matters For anyone who wants to keep config.json committed to version control (so provider topology is reviewable, diffable, reproducible across machines) but still have a base_url that varies by environment (dev vs. prod endpoint) or just isn't something they want hardcoded in a git-tracked file, the only option today is an external wrapper that renders the JSON from a template before Bifrost starts. That's exactly what we ended up building — a small script that does placeholder substitution on config.json before every start, purely because base_url can't read from the environment the way value already can. Suggestion Extend SecretVar-style env resolution (the same

Prerequisites I have searched existing issues and discussions to avoid duplicates Problem to solve https://discord.com/channels/1371790330269007932/1535190142489206806/1535255744402817136 Proposed solution Add qwen provider in core following their api docs https://docs.qwencloud.com/developer-guides/getting-started/introduction Alternatives considered No response Area(s) Core (Go) Additional context No response

Prerequisites I have searched existing issues and discussions to avoid duplicates Problem to solve Would really be great to have them listed and have pricing from them. Proposed solution Add them to the provider list? Alternatives considered No response Area(s) Transports (HTTP) Additional context No response

Prerequisites I have searched existing issues and discussions to avoid duplicates Related: #2316 (original request, framed as device-code flow), and the prior implementation attempts #2715 / #2775 (both closed). This reframes the problem more narrowly. Context: raising this on behalf of envelio, where we're evaluating Bifrost for company-wide rollout and the enterprise tier. Routing the official Codex CLI through the gateway is load-bearing for that decision, so I'd like it upstream rather than carried as a fork patch. Problem to solve This isn't "add OAuth to Bifrost". It's forwarding the official client's existing OAuth correctly. Codex already holds a valid "Sign in with ChatGPT" token. Pointing its base_url at Bifrost only breaks because Bifrost forwards to api.openai.com/v1/responses, while a subscription token is accepted only at chatgpt.com/backend-api/codex/responses. Bifrost stores/forges nothing and pools nothing. No new OAuth flow is added. Proposed solution Auto-detect,

Prerequisites I have searched existing issues and discussions to avoid duplicates I am using the latest version (or have tested against main/nightly) Description When an MCP client is configured with is_code_mode_client: true, the code-mode executor (executeToolCode) writes the full raw response of every proxied tool call into the script's captured output (the Print output block returned to the caller), in addition to the script's structured Return value. The script never requests this — the gateway injects it automatically after each tool call. The compiled format strings are: [TOOL] %s.%s raw response: %s [TOOL] %s.%s error result: %s [TOOL] %s.%s error: %v Effect: every byte of every tool's raw payload is sent to the model twice — once in Print output (the auto-injected [TOOL] ... raw response: line) and once in Return value (whatever the script assigns to result). This defeats the core value proposition of code mode. The point of running a script in the sandbox is to reduc