Design discussion: Adding SiliconFlow support to Dayflow

[nameless0120]

Hi @JerryZLiu,

I’m working on the Dayflow integration task from SiliconFlow’s official open-source task list:

siliconflow/siliconflow-open-source-tasks#6

The task is to add SiliconFlow API support to Dayflow. Since Dayflow and SiliconFlow are separate projects, I wanted to discuss the preferred product and code design with the Dayflow maintainer before opening a PR.

I’ve been looking through Dayflow’s onboarding flow. Users can currently choose between Dayflow Pro, ChatGPT, Claude, Gemini, OpenRouter / Custom, and Local AI. The OpenRouter / Custom option already serves as the entry point for OpenAI-compatible APIs.

Dayflow’s main workflow analyzes screenshots, so the integration needs to support multimodal requests rather than text-only requests.

My initial proposal is:

1. Add SiliconFlow as a named preset under the existing OpenRouter / Custom flow instead of creating a new top-level provider.
2. When the user selects SiliconFlow, pre-fill:
   • API endpoint: https://api.siliconflow.cn/v1
   • Default model: Qwen/Qwen3.6-35B-A3B
3. Keep the model ID editable. If this model does not support the image input required by Dayflow, I’m happy to use another vision-capable model you recommend.
4. Reuse Dayflow’s existing OpenAI-compatible request flow, API key storage, connection test, and image request logic rather than adding a separate SiliconFlow client.
5. Add the necessary UI, tests, and documentation updates.

This would let users who already use SiliconFlow configure Dayflow without manually entering the endpoint and model ID. It would also keep the implementation small, preserve the existing OpenRouter, Custom, and local model flows, and avoid introducing another provider-specific code path.

Before I start implementing, could you confirm:

• Would you prefer SiliconFlow as a preset under OpenRouter / Custom, or as a separate top-level option?
• Is https://api.siliconflow.cn/v1 the endpoint you would expect?
• Is Qwen/Qwen3.6-35B-A3B a suitable default model, and does it support the image input required by Dayflow?
• Which UI and configuration areas would you prefer us to extend?
• Should the PR include persistence, connection testing, unit tests, and documentation?

Once the preferred design is confirmed, I can prepare a focused PR that follows Dayflow’s existing provider architecture.

Thanks!