Add support for Qoder Oauth

[PKFireBarry]

I have a working version that i can share that i reverse engineered from the cli tool the have via npm. should be and easy port and build. its written in python and again in go after i ported it to CLIPORXYAPI. get in touch

Models:
Qwen
Kimi K2.5
GLM-5
MiniMax 2.7

[diegosouzapw]

Hey @PKFireBarry! This is great timing - we just received Issue #660 about iFlow shutting down and migrating to Qoder.

We are very interested in your implementation! If you have a working Qoder OAuth flow, the best way to contribute would be:

1. Fork the repo
2. 2. Add the Qoder provider following the existing patterns in:
3. • src/shared/constants/providers.ts (provider registration)
4. • open-sse/executors/ (request executor)
5. • src/lib/oauth/constants/oauth.ts (OAuth config)
6. 3. Open a Pull Request
      Since Qoder supports models like Qwen, Kimi K2.5, GLM-5, MiniMax 2.7 - this would be a valuable addition for users migrating from iFlow.

If you want, you can also share the Python/Go code here and we can help port it to our TypeScript patterns. Looking forward to the contribution!

[PKFireBarry]

Here is where im at with the intergration

🚀 Key Highlights:

Zero-Dependency Core: I’ve reverse-engineered the COSY v0.9 hybrid-encryption signing in Go/python, completely removing the need for the external 96MB Go binary or Python scripts.

Native OAuth Flow: Full Device Flow with PKCE support. Users can authenticate via -qoder-login, which handles the browser-based selection and token storage.

Multi-Account Rotation: Supports multiple qoder-{email}.json files with automatic token refresh via the Conductor scheduler.

Issues/Needs Fixes

1. Protocol vs. Schema Native

The implementation is "Protocol Compatible" but not "Schema Native." This means that while it handles the HTTP handshake and SSE (Server-Sent Events) streaming correctly, it doesn't yet translate the internal data structures to match OpenAI’s expectations perfectly. It currently acts as a high-speed transparent proxy rather than a full semantic translator.
2. Statefulness and Identity (Machine ID)

Native OpenAI is stateless; you provide an API key, and the request is processed. Qoder requires a persistent machine_id (UUID) and session-linked tokens. The implementation handles this using a "Slot" system to manage these identities, but this introduces a layer of state management that doesn't exist in a standard OpenAI-compatible provider. If a client doesn't support this specific stateful rotation, they may hit rate limits (Error 110) that the current proxy has to catch and retry silently.
3. Lack of Message-to-Prompt Translation

OpenAI uses a structured messages array. However, the models Qoder serves (like Qwen and GLM) often perform best with specific ChatML templates or a flattened string prompt. Currently, the implementation passes the raw OpenAI array directly to the Qoder endpoint. Without a dedicated translator to format these into the model-specific tags (like <|im_start|> and <|im_end|>), the model may struggle with multi-turn conversations or following complex system instructions compared to a native implementation.
4. Tool Calling via "Prompt Injection"

In a native OpenAI environment, tools are handled via a dedicated tools field in the JSON. Qoder’s direct API doesn't natively parse this field. To make tools work, they must be "injected" into the system prompt as text instructions. Since the implementation currently lacks this translation layer, any OpenAI-standard tool calls sent by a client (like Cursor or Claude Code) will likely be ignored by the model, causing it to fail or hallucinate an answer instead of executing the function.
5. Metadata and Usage Extraction

The response from Qoder does not currently map its token usage back to the standard OpenAI usage object. This means that while the chat works, the client receives 0 for prompt_tokens and completion_tokens. For users who rely on token counting for context window management or cost tracking, the implementation will appear broken or incomplete.
6. Inline Reasoning vs. Dedicated Fields

Modern OpenAI models use a reasoning_content field to separate "thinking" from the final answer. Qoder models stream their reasoning "inline" within the standard content block. While this is functional, it isn't "native" because the client cannot distinguish between the two, meaning UIs cannot hide the chain-of-thought text as they would with a native OpenAI reasoning model.
Suggested summary for the GitHub message:

"While the OAuth and COSY signing layers are fully functional, the implementation currently operates as an OpenAI-compatible proxy. It lacks the internal Translators required for full feature parity in areas like tool-calling (which requires prompt injection), token usage reporting, and model-specific ChatML formatting.

I will push a version later today for you guys to took at and help build the integration into something my robust. Does work great for simple things but i tried to use it in openclaw and it just sucks for tool calling due to the parsing issues. TTYS

[diegosouzapw]

Hey @omnergy! Thanks for the feature request. I have opened Issue #687 to track the implementation of team-level quotas. Follow along there for updates!

[PKFireBarry]

@diegosouzapw Here is the PR from the other repo where i implemented the qoder oauth
if this is not enough let me know and ill push the original build i need of the implementation

router-for-me/CLIProxyAPI@main...PKFireBarry:CLIProxyAPI:qoder-provider

[k0valik]

@diegosouzapw Here is the PR from the other repo where i implemented the qoder oauth if this is not enough let me know and ill push the original build i need of the implementation

router-for-me/CLIProxyAPI@main...PKFireBarry:CLIProxyAPI:qoder-provider

@PKFireBarry
Just letting you know, probably they will not merge this into CLIProxyAPI, you should try it at:
https://github.com/router-for-me/CLIProxyAPIPlus
this is the fork waiting for community submissions and other providers

[PKFireBarry]

@k0valik Thanks for the heads up! I’m currently working on the omnirouter branch where it replaced iflow with qoder to get the implementation fully functional, as it doesn't seem to be working correctly at the moment. I was told they might merge the PR if I update the login flow (CLIProxyapi), but I believe omnirouter is the better path forward, so I’m focusing on that first.

[diegosouzapw]

Hey @PKFireBarry! Thanks for sharing the PR link from the other repo. I'll take a look at your Qoder OAuth implementation there, and we can work on integrating the provider into OmniRoute. Much appreciated!

[diegosouzapw]

Hey everyone! Just a quick follow-up to let you know that complete support for Qoder AI has been officially shipped in v3.2.4! You can upgrade your installation or pull the latest Docker image to start routing to Qoder seamlessly. Cheers!