[Bug]: Issues with Google Gemini API via Custom Provider #335

Activity

1. Skatter887

   added

   bugSomething isn't workingSomething isn't working

   triageAwaiting maintainer reviewAwaiting maintainer review

   on May 11, 2026
2. github-actions commented on May 11, 2026

   

   github-actionsBot

   on May 11, 2026 – with GitHub Actions

   Contributor

   More actions

   Thanks for reporting this! The Gemini OpenAI-compatible endpoint (https://generativelanguage.googleapis.com/v1beta/openai/) should work with Open CoDesign's Custom Provider — there was a known issue with the models/ prefix that was fixed in v0.1.3 (see README changelog), and v0.2.0 includes that fix.

   However, there might be other configuration differences or API behavior causing instability. To help debug, could you provide:

   1. Exact error message — what does the UI show when it fails? Is it a connection error, time-out, or model error?
   2. Does the Test Connection button pass? — in the provider settings, does a test succeed or fail?
   3. Logs — try reproducing with DevTools open (or enable verbose logging) and share any relevant output.
   4. Model ID variant — have you tried gemini-2.0-flash or models/gemini-1.5-pro (with the models/ prefix) to see if the behavior changes?

   If Test Connection works but generation fails, the issue might be in the streaming or tool-call handling rather than the initial connection. You can also check the packages/providers directory in the repo to see how custom providers are adapted; the adapter for OpenAI-compatible endpoints is at packages/providers/src/openai-compatible.ts (relevant lines for Gemini-specific model ID normalization).

   Let's start with the missing info above so we can narrow down whether this is a known edge case or a new bug.

   ---

   Open-CoDesign Bot
4. github-actions commented on Jul 22, 2026

   

   github-actionsBot

   on Jul 22, 2026 – with GitHub Actions

   Contributor

   More actions

   Thanks for sharing your perspective, @poeticsoft-heart — I understand the frustration if Gemini hasn't worked smoothly in your experience. However, I want to clarify a few things based on the actual project code and documentation:

   1. Open CoDesign is designed to be provider-agnostic. It uses pi-ai (a multi-provider library) under the hood, and the codebase explicitly supports OpenAI-compatible endpoints, including Gemini via Google's OpenAI-compatible relay at https://generativelanguage.googleapis.com/v1beta/openai/. The project's README lists Gemini among supported models, and there's even a dedicated fix in v0.1.3 for the models/ prefix issue that affected Gemini users.

   2. The app is BYOK (bring your own key) and local-first — it doesn't "use up" tokens of any provider beyond what the user configures. The agent will call whichever model you point it at, including Gemini, Ollama, DeepSeek, etc. There is no design that deliberately drains Claude or ChatGPT tokens.

   3. The original issue reporter ([Bug]: Issues with Google Gemini API via Custom Provider #335) is experiencing a real bug, likely a configuration or compatibility issue rather than a fundamental incompatibility. The bot previously asked for more details (error messages, Test Connection results, etc.) to help debug. If you have specific error logs or reproduction steps showing Gemini failing, that would be valuable for improving Gemini support.

   I appreciate your comment, but I'd gently push back on the idea that Gemini is intentionally unsupported. The project team has put effort into making Gemini work (see the changelog and the packages/providers code). If something is broken, let's help diagnose it rather than dismiss it.

   ---

   Open-CoDesign Bot
6. github-actions commented on Jul 22, 2026

   

   github-actionsBot

   on Jul 22, 2026 – with GitHub Actions

   Contributor

   More actions

   Thanks for sharing your experience, @poeticsoft-heart — I can see why you'd feel frustrated if it hasn't worked after multiple attempts. Let me clarify what's actually in the codebase and offer some concrete next steps.

   Evidence from the project:

   • The README explicitly lists Gemini as a supported model and notes a fix in v0.1.3 (merged into v0.2.0) for the Gemini OpenAI-compatible endpoint — specifically stripping the models/ prefix from model IDs (PR fix(providers): strip models/ prefix for Gemini OpenAI-compat endpoint (#175) #186).
   • The codebase uses pi-ai as a provider-agnostic library, and packages/providers/ contains the adapter for OpenAI-compatible endpoints. There is no code designed to penalize or block any provider.
   • The original reporter ([Bug]: Issues with Google Gemini API via Custom Provider #335) hasn't yet provided the details the bot asked for (exact error messages, Test Connection result, logs, or alternative model IDs). Without those, we can't confirm whether the issue is a config mismatch, a real bug, or something unique to their setup.

   Next steps to diagnose:

   1. Please run a quick curl test to verify the endpoint works independently:

      curl -X POST "https://generativelanguage.googleapis.com/v1beta/openai/chat/completions" \
        -H "Content-Type: application/json" \
        -H "Authorization: Bearer YOUR_API_KEY" \
        -d '{"model":"gemini-2.0-flash","messages":[{"role":"user","content":"Hello"}]}'

      Does that return a valid response?
   2. In Open CoDesign, does the Test Connection button (in Custom Provider settings) pass? If it fails, note the exact error text.
   3. Try model IDs with and without the models/ prefix (e.g., models/gemini-2.0-flash vs gemini-2.0-flash).
   4. Share the app logs (from the Help menu) — redact any API keys.

   With that info, we can either confirm it's a known edge case or identify a new bug. I'm happy to debug further once we have the data.

   Open-CoDesign Bot
8. github-actions commented on Jul 22, 2026

   

   github-actionsBot

   on Jul 22, 2026 – with GitHub Actions

   Contributor

   More actions

   Thanks for running those curl tests and sharing the results — that's very helpful. The key finding is that the Gemini OpenAI-compatible endpoint works fine with a basic curl call and the Test Connection passes (57 models), but generation fails with a 400 status and no body when Open CoDesign sends the actual design request.

   This strongly suggests the issue is in the request format the app constructs, not in the base endpoint or API key. A 400 with no body often means the request payload is malformed or contains fields the Gemini relay rejects. Some likely suspects:

   1. Model name: gemini-3.5-flash is not a real Gemini model (Google's latest are gemini-2.0-flash, gemini-1.5-pro, etc.). If the app passes that unrecognized model ID, the endpoint may return a 400. Test Connection might not validate the default model — it just lists available models from the /models endpoint. Try using a valid model ID like gemini-2.0-flash or models/gemini-2.0-flash in the config.
   2. Tool calls / function calling: Open CoDesign's agent uses pi-ai, which sends tool/function calls in the request. Gemini's OpenAI-compatible relay may not support the tools or tool_choice field in the same way as OpenAI — that could cause a 400. Check the app logs for the full request body.
   3. Streaming: If the app uses streaming (stream: true), the Gemini relay might respond differently. Try disabling streaming in the app settings if possible.
   4. Other request fields: The agent may send response_format, temperature, or other parameters that Gemini doesn't support.

   To debug further, please (if you can):

   1. Enable the app's verbose logging (from Help menu → Diagnostics, or run from terminal with OPEN_CODESIGN_LOG_LEVEL=debug).
   2. Reproduce the failure and share the relevant log lines (redact API key).
   3. Alternatively, capture the network request using DevTools (Electron's built-in DevTools can record network traffic).

   If you're comfortable, you could also try setting the model to gemini-2.0-flash (a known valid model) with and without the models/ prefix to see if the 400 changes.

   Thanks again for the thorough testing — it's clear the baseline connectivity is fine, so the bug is somewhere in the request construction. We'll get to the bottom of it with a bit more data.

   ---

   Open-CoDesign Bot
10. github-actions commented on Jul 22, 2026

    

    github-actionsBot

    on Jul 22, 2026 – with GitHub Actions

    Contributor

    More actions

    Thanks for running these curl tests — that's very helpful data. The 404 error for gemini-2.0-flash confirms that this specific model is deprecated on Google's side (the error says it's no longer available). Your earlier successful curl with gemini-3.5-flash shows the endpoint works fine with a valid model.

    This likely explains the 400 generation failure too. The app may be sending a deprecated model ID (if the default model in your Custom Provider config is still gemini-2.0-flash or something similar). Please try:

    1. In Open CoDesign, go to Settings → Custom Provider and set the Default Model to a valid model like gemini-3.5-flash or gemini-1.5-pro.
    2. Save and start a new design.
    3. If you still get a 400, enable verbose logging (Help → Diagnostics) and share the log output (redact API key).

    Also, avoid using the models/ prefix — the app already strips it (PR #186), and the curl test shows the raw model ID works.

    ---

    Open-CoDesign Bot
12. github-actions commented on Jul 22, 2026

    

    github-actionsBot

    on Jul 22, 2026 – with GitHub Actions

    Contributor

    More actions

    Hi @poeticsoft-heart, I hear your frustration — it's understandable to feel that way after repeated failures. I want to assure you that there is no intentional penalization of Gemini in the codebase. The project is designed to be provider-agnostic, using pi-ai which normalizes provider requests. The Test Connection passes, which proves the base endpoint and API key are valid. The 400 error during generation almost certainly comes from the specific request payload the agent sends — likely unsupported fields like tool calls, streaming, or model names that don't match Gemini's OpenAI-compatible schema.

    To get to the bottom of this, could you please try the following?

    1. Use a known valid model ID like gemini-1.5-pro (avoid gemini-2.0-flash which is deprecated, and gemini-3.5-flash may not be stable). Set it in Custom Provider settings.
    2. Enable verbose logging: run the app from terminal with OPEN_CODESIGN_LOG_LEVEL=debug and reproduce the failure. Share the log output (redacting your API key). Look for the exact request body that gets sent.
    3. If possible, capture the network request using Electron DevTools (Settings → Developer → Toggle DevTools, then Network tab) to see the full POST to the Gemini endpoint.

    With that data, we can identify exactly which field causes the 400. If it's a known incompatibility, we can open a targeted issue to fix the provider adapter. The fact that it works with curl proves the endpoint itself is fine — the bug is in how the app constructs the request.

    Thanks for persisting with this — it helps make Gemini support better for everyone.

    ---

    Open-CoDesign Bot
14. github-actions commented on Jul 22, 2026

    

    github-actionsBot

    on Jul 22, 2026 – with GitHub Actions

    Contributor

    More actions

    Thanks for sharing the DevTools error — that confirms the generation is hitting a 400 with an empty response body. Since the curl test with gemini-3.5-flash worked and Test Connection passes, the issue is almost certainly in the request payload the app constructs when calling the Gemini endpoint. Some likely culprits:

    1. Tool/function calls - Open CoDesign's agent sends tool definitions in the chat completion request. Gemini's OpenAI-compatible relay may reject unsupported tool schemas with a silent 400. pi-ai adapter might include tools the endpoint doesn't support.
    2. Streaming - If the app uses stream: true, the Gemini relay's streaming format may differ from OpenAI's. Check if disabling streaming (if configurable) changes behavior.
    3. Extra parameters - response_format, temperature, max_tokens, or stop sequences that Gemini doesn't support could cause a 400.

    To diagnose, please:

    1. Run the app with verbose logging: OPEN_CODESIGN_LOG_LEVEL=debug ./open-codesign (or set in config) and reproduce the failure. Share the log output (redact API key).
    2. Or, in Electron DevTools (Settings → Developer → Toggle DevTools), open the Network tab, start a design, and capture the POST request to https://generativelanguage.googleapis.com/v1beta/openai/chat/completions. The full request body will show what the app sends.

    With that, we can identify which field triggers the 400. This is a known pain point for custom providers that aren't 100% OpenAI-compatible — the adapter in packages/providers/src/openai-compatible.ts may need adjustment. Thanks for persisting with the debugging!

    ---

    Open-CoDesign Bot
16. github-actions commented on Jul 22, 2026

    

    github-actionsBot

    on Jul 22, 2026 – with GitHub Actions

    Contributor

    More actions

    Thanks for checking the Network tab, @poeticsoft-heart — that's a useful clue. In Electron apps, network requests made from the main process (where pi-ai runs the model calls) won't appear in the renderer's DevTools Network tab. That's expected: the renderer's DevTools only captures requests initiated by the renderer, not by Node.js in the main process. So even if a request to Gemini is sent, it won't show up there.

    To capture the actual request, please try:

    1. Enable verbose logging — run the app from the terminal with:

       OPEN_CODESIGN_LOG_LEVEL=debug ./open-codesign

       Then reproduce the generation failure and share the log output (redact your API key). This will show you the exact request payload that pi-ai constructs before sending, and whether the error occurs before or after the HTTP call.

    2. Alternatively, you can use a packet capture tool like Wireshark or a system-wide proxy (e.g., mitmproxy) to see the actual HTTP request to generativelanguage.googleapis.com.

    Also, double-check that the Custom Provider is actually selected in the generation settings (not just configured in Settings). There might be a separate per-design provider override.

    The 400 error without a body suggests the request payload is being rejected by the Gemini endpoint — but if no request is visible even via logging, it could mean the app is failing to build the request at all. The logs will tell us which.

    Thanks again for persisting — this is helping us narrow down whether the bug is in the configuration UI, the pi-ai adapter, or the request construction.

    ---

    Open-CoDesign Bot
18. github-actions commented on Jul 22, 2026

    

    github-actionsBot

    on Jul 22, 2026 – with GitHub Actions

    Contributor

    More actions

    Thank you @poeticsoft-heart for capturing those terminal logs — this is exactly the data needed to pinpoint the issue. Your analysis is spot-on: the models/ prefix in modelId: 'models/gemini-3.5-flash' is very likely the root cause of the 400 error.

    What the log reveals

    The request is being sent with:

    • modelId: 'models/gemini-3.5-flash' (with models/ prefix)
    • upstream_wire: 'openai-chat' (correct for Google's OpenAI-compatible endpoint)
    • baseUrl: 'https://generativelanguage.googleapis.com/v1beta/openai' (correct)

    When the model ID includes models/, the Gemini endpoint receives a path like /v1beta/openai/chat/completions with a model field 'models/gemini-3.5-flash'. Google's relay likely expects 'gemini-3.5-flash' (without the prefix) and returns a 400 with no body when the model name doesn't match.

    The models/ prefix fix (PR #186)

    The changelog (v0.1.3, 2026-04-21) mentions a fix that "strips models/ from Gemini OpenAI-compatible model IDs at the provider wire boundary." However, the log shows the model ID is still being sent with the prefix in v0.2.0 — this could mean:

    • The fix is present but not covering this particular code path (e.g., custom provider configuration may bypass the normalization layer).
    • The models/ prefix is being added unintentionally by the UI (if the user entered it) and the stripping code isn't triggered.

    Suggested next steps

    1. Try entering the model ID without the models/ prefix in the Custom Provider settings — e.g., just gemini-3.5-flash. Save and restart the design.
    2. Also try a known valid Gemini model like gemini-1.5-pro (since gemini-3.5-flash may not exist; Gemini model IDs follow a pattern like gemini-1.5-flash, gemini-2.0-flash, etc.). The curl test earlier confirmed gemini-3.5-flash works via curl, so it's likely valid — but the prefix is the bigger issue.
    3. If the problem persists after removing the prefix, please share the new terminal log to confirm whether the model ID changed.

    Wire protocol mismatch note

    The upstream_wire: 'openai-chat' is correct — Google's relay speaks OpenAI-compatible chat completions. However, if the agent sends tool/function calls that Gemini doesn't support, that could also cause a 400. The 400 with no body is consistent with both scenarios: an invalid model name often yields a generic 400 with an empty body from Google's relay.

    The workspace file resolution error (ENOENT) appears to be a side effect of the generation failing (the agent tries to write to the workspace after generation succeeds, but the failure short-circuits the flow).

    Thank you for your thorough debugging — this is very valuable for improving Gemini support. Let's start by removing the models/ prefix and see if that resolves the 400.

    ---

    Open-CoDesign Bot
19. github-actions commented on Jul 22, 2026

    

    github-actionsBot

    on Jul 22, 2026 – with GitHub Actions

    Contributor

    More actions

    Thank you @poeticsoft-heart — this is a critical finding. The UI dropdown prepending models/ to the model ID is the root cause, and the stripping fix from PR #186 (v0.1.3) is not reaching custom providers in v0.2.0, leaving the prefix intact in the request payload.

    Workaround

    Manually edit your config file (~/.config/open-codesign/config.toml) to set the model ID without the models/ prefix. For example:

    [providers.custom-gemini-njoa]
    id = "custom-gemini-njoa"
    name = "Gemini"
    builtin = false
    wire = "openai"
    baseUrl = "https://generativelanguage.googleapis.com/v1beta/openai/"
    defaultModel = "gemini-1.5-pro"

    Also set activeModel = "gemini-1.5-pro" (under version/activeProvider area). Do not use models/ anywhere. Then restart the app and try generation again.

    Why this happens

    • The Test Connection endpoint (/v1beta/openai/models) returns model IDs with the models/ prefix (e.g., models/gemini-3.5-flash). The UI populates the dropdown from this list, so every selection includes the prefix.
    • The provider wire layer (where PR fix(providers): strip models/ prefix for Gemini OpenAI-compat endpoint (#175) #186 applied the strip) is either not being used for custom providers, or the stripping logic has a bug in v0.2.0. The log confirms modelId: 'models/gemini-3.5-flash' reached the API, causing the 400.

    Side note on model names

    gemini-3.5-flash is not a standard Gemini model ID — it may be a stale or unrecognized product name. Google's current valid OpenAI-compatible models include gemini-1.5-flash, gemini-1.5-pro, gemini-2.0-flash (deprecated), and newer experimental names. Using a known working ID like gemini-1.5-pro (without prefix) improves your chances.

    Next steps

    1. Apply the manual config fix above.
    2. If generation succeeds, the UI dropdown is the sole culprit. If it still fails, the provider wire stripping may need a wider fix — please share the new terminal logs (with the manual config) so we can see whether modelId still shows models/.

    This is a real bug in the UI that needs a code fix — ideally the dropdown should offer raw model IDs, or the provider layer must strip the prefix universally. Thank you for persisting; your debugging is helping us close this properly.

    ---

    Open-CoDesign Bot
21. github-actions commented on Jul 22, 2026

    

    github-actionsBot

    on Jul 22, 2026 – with GitHub Actions

    Contributor

    More actions

    Thank you @poeticsoft-heart for confirming this — the log evidence is now conclusive: the config file stores the model ID correctly without the models/ prefix, yet the request payload shows models/gemini-3.5-flash. This means the prefix is added by the app during request construction, likely in the provider wire layer for custom providers.

    Root cause

    The models/ stripping fix (PR #186, v0.1.3) was applied at a provider wire boundary that doesn't cover custom providers in v0.2.0. The Test Connection endpoint returns model IDs with the models/ prefix, the UI dropdown populates from that list, and the selected value passes through to the request without stripping.

    Workaround (manual config only)

    Since the UI forces the prefix, the only workaround for now is to manually edit ~/.config/open-codesign/config.toml and ensure both defaultModel and activeModel are set to a raw model ID without models/ — and avoid opening the provider settings UI again until the bug is fixed, as reopening may reset the model to a prefixed value from the dropdown. If you already did that and the log still shows the prefix, the app is overriding the config value somewhere — please share the log after the manual edit to confirm.

    Why gemini-3.5-flash?

    gemini-3.5-flash is not a standard Google model name; it may be an alias or a custom naming on your end. If the curl test worked with it, the model ID itself is valid — but the models/ prefix causes the 400. Once the prefix issue is resolved, the model should work.

    Next steps

    We now have enough data for a targeted fix: ensure the models/ prefix is stripped for all custom providers using the OpenAI-compatible wire, not just built-in Gemini providers. I'll flag this for the maintainers.

    Thank you for your thorough debugging — this is exactly the kind of evidence needed to close a long-standing issue.

    ---

    Open-CoDesign Bot
23. github-actions commented on Aug 26, 2026

    

    github-actionsBot

    on Aug 26, 2026 – with GitHub Actions

    Contributor

    More actions

    Thanks for following up, @poeticsoft-heart. I can’t point to a maintainer update in this thread since July, but I want to address the core assumption: the idea that Gemini is intentionally ignored isn’t supported by the project’s public materials.

    • README’s “What is it” section explicitly lists Gemini as a supported model, and the v0.1.3 changelog entry mentions a Gemini models/ prefix fix (PR fix(providers): strip models/ prefix for Gemini OpenAI-compat endpoint (#175) #186).
    • BENCHMARKS.md includes Gemini variants in the evaluation table, which would be odd if it were not a target.
    • The logs you captured are the key evidence: the config file stored gemini-3.5-flash without the prefix, but the generation request sent models/gemini-3.5-flash, which Google’s OpenAI-compatible relay rejected with a 400 and no body. That points to a concrete bug in the custom-provider model ID path, not a design decision to penalize Gemini.

    So my honest update is: this issue is still open and labeled bug/triage, and the last state on record is that the models/ prefix still leaks into custom-provider wire calls in v0.2.0. I can’t verify from this thread whether a later commit fixed it. If you’re still seeing it, the fastest way to move it forward is:

    1. Check whether a newer release exists and try reproducing on that version.
    2. If it still fails, share the terminal log again showing modelId in the codesign:v1:generate error.
    3. Ideally confirm whether the model ID reaches the wire without models/ when selected directly.

    That would let maintainers confirm whether the v0.1.3 strip was generalized to custom providers or regressed. The ENOENT workspace error you saw was a downstream effect of generation failing, not a separate cause.

    Thanks again for digging into this — the logs you provided are genuinely useful for fixing Gemini support.

    ---

    Open-CoDesign Bot
24. calvinwhkgmail commented on Nov 15, 2026

    

    calvinwhkgmail

    on Nov 15, 2026

    More actions

    same issues.