Feature Requests

I have been losing a significant number of credits due to "Cascade error" and messages indicating "This may be stuck. Please Try cancelling." I would like to request the implementation of a feature that automatically refunds credits for requests that result in these errors.

Let's say i have 500 credits this month that I purchased. I bought them with my subscription. But I couldn't program much this month so I only used 100. Well now the next month you charge me another $15 and delete the 400 credits I didn't use? Come on now. Now if I hit 501 credits this month I'll have to purchase more. When you just stole 400 credits from me. Product is amazing by the way. But you guys have to get the payment structure ironed out. I want you guys to make money because I think the product is great. But you guys need to fix this so people like myself don't want to even think about leaving. Because the competitors will copy/steal whatever innovations you guys come up with eventually. You need to be innovative and honest about your payment structure. At least allow 50% of credits to be rolled over. That way when I see $15 come out of my bank account, I don't think "dang.. they just stole 200 credits from me." Instead I'll think "Yes! Now I have even more credits for when I want to spend a week straight coding!"

Unused Premium User Prompt Credits and Premium Flow Action Credits roll-over to the next month

By all reports right now, it is the most powerful model, but also should be cheaper to use due to it being open source. Please consider adding it as you have other open models.

Invalid argument: an internal error occurred (error ID: 31d39cec17844a91bc8320f527c1c2fc)

There are many times when the Thinking process will reveal what the agent is intending to do, then the output shows that it just arbitrarily made a decision about something that is critical to application flow design. If we had a Pause button, where we could highlight the reasoning of the Agent, and provide specific direction, the process could be more efficient, and less work would need to be done to repair the broad implications a single change can make in a codebase. I know we can just press stop, but that dumps the workflow the agent is doing creating a completely new execution path.

Grok 4 Fast (As of 11/8/2025) is now the best cheap reasoning model with its latency, speed, intelligence and token per second this would be my go to model for most tasks if it were available. Please consider adding it.

Everytime I open my projects, the cascade sidebar is open by default, and takes 5-10 seconds to load before I can close it. Please add a setting to make this closed by default, especially when you open a project in Windsurf

Please integrate GLM-4.6 into Windsurf AI as a selectable model option. GLM-4.6 delivers exceptional multilingual reasoning, complex instruction-following, and cost-efficient performance — outperforming Claude, Gemini, GPT, and xAI in many benchmarks. Adding this model would significantly expand Windsurf’s capability and attract advanced users seeking higher accuracy, speed, and flexibility.

1. Summary of the Request Please fix the authentication mechanism on Linux to prevent an infinite login loop on Arch-based systems. The application currently fails to use two standard authentication methods: It does not correctly interface with the system's libsecret credential store (even when it's fully functional). It completely ignores the CODEIUM_ACCESS_TOKEN environment variable, which should serve as a primary login method. This makes it impossible to log into and use the Windsurf IDE on affected systems. 2. System Environment * Operating System: Arch Linux * Windsurf Version: 1.12.28 * Authentication Backend: libsecret (managed by gnome-keyring-daemon ) 3. Detailed Problem Description & Troubleshooting Journey The user experiences an infinite login loop. After successfully authenticating via the browser or entering a manual token, the IDE returns to the "Sign In" prompt without ever completing the login. Our in-depth troubleshooting has isolated the problem to the Windsurf application itself, not the user's system configuration. Phase 1: Identifying the Credential Storage Failure * Initial logs consistently showed the application was making unauthenticated requests, leading to the gRPC error: metadata.api_key: value length must be at least 1 characters . * We traced this back to a failure in the application's attempt to retrieve a stored token. The logs repeatedly showed: [secrets] no secret found for key: windsurf_auth.sessions . * We initially confirmed that the system's gnome-keyring-daemon was in a non-responsive state (the secret-tool command would hang). We successfully guided the user through a full reset of the keyring service. * Crucial Finding: After fixing the OS keyring (verified by successfully running secret-tool store and secret-tool lookup ), Windsurf **still failed with the exact same [secrets] no secret found error**. This definitively proves the issue is not with the OS keyring itself, but with Windsurf's inability to correctly communicate with the libsecret service. Phase 2: Attempting the Environment Variable Workaround * To bypass the broken secret store integration, we used the documented CODEIUM_ACCESS_TOKEN environment variable. * We set the variable in ~/.bashrc and verified with echo $CODEIUM_ACCESS_TOKEN that it was correctly exported to the shell environment. * We then performed a full cleanup ( rm -rf ~/.config/Windsurf ~/.codeium ) and launched the application from the terminal that had the variable loaded. * Crucial Finding: The application completely ignored the environment variable . It did not log in automatically and instead prompted for a new login. The application's own verbose logs even show the CODEIUM_ACCESS_TOKEN variable is present in the environment it receives, yet it still prioritizes the failed keyring lookup. 4. Summary of the Bug There are two distinct failures in the authentication logic: **Failure to Use libsecret :** The application does not correctly interface with a standard Linux libsecret keyring. It fails to read from or write to it, even when the service is fully operational. **Failure to Honor CODEIUM_ACCESS_TOKEN :** The application ignores the presence of the CODEIUM_ACCESS_TOKEN environment variable at startup, defeating its purpose as a reliable authentication method and workaround. 5. Proposed Solution / Feature Implementation Modify the authentication logic with the following priority order, which is standard for CLI and server-backed desktop applications: **On startup, first check for the CODEIUM_ACCESS_TOKEN environment variable.** If it is present, use it to authenticate the session immediately and bypass any other checks. If the environment variable is not present, then attempt to retrieve the token from the system's libsecret keyring. If both methods fail, only then should the application present the user with the "Sign In" prompt. Implementing this logic will fix this critical bug and make the application usable on a wider range of Linux configurations.