Frappe Studio collapses what is normally a hand-written pile of DocTypes, Vue pages and wiring into one visual surface: drag a frappe-ui layout, bind a Frappe data source with minimal configuration, then drop into a page script mirroring Vue <script setup> with real reactive state and handlers. For developers working inside a bench, the path from prototype to the exported, bench build-studio-app production build stays on machinery they already run.
The AI assistant is why I'm writing. It is already provider-shaped: studio/ai/llm.py calls itself the only place that knows provider quirks, models live in ModelRegistry.AVAILABLE as OpenRouter-prefixed IDs, and one key in Studio Settings feeds them all. Another OpenAI-compatible endpoint there is additive, and would let a bench operator point the assistant at routing and billing they already have.
I'd like to propose OrcaRouter as an optional provider for the AI assistant. To be clear up front: this would not replace, remove or change any existing provider — it is one more entry, and OpenRouter stays exactly as it is today.
A few things that seem genuinely relevant to Studio's users:
- One endpoint, many models. Chat, reasoning, and image-capable models behind a single OpenAI-compatible API, which maps onto
ModelRegistry.AVAILABLE and its vision_capable flag — the chat panel already uses that flag to decide whether a screenshot can be attached.
- Automatic routing and provider failover. Studio already treats an unavailable model as normal (
get_fallbacks() drops to the cheap SIMPLE model). Upstream failover would let that safety net hold across providers, not just across models on one.
- Usage tracking and budgets. The agent loop already requests
stream_options={"include_usage": True} and tallies tokens per turn, so per-key spend and caps have somewhere natural to surface.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so the expected integration point is the existing llm.py adapter plus the ai_api_key field on Studio Settings — no new abstraction required. I have not written or tested any code for this; it is a proposal, not a claim that the work is done.
OrcaRouter is already used in open-source projects including RAGFlow, Dify, goose, and promptfoo.
One transparent note: we run an optional open-source partner program where approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participating is entirely optional and not a precondition for the integration — I'm happy to follow whatever disclosure or governance rules the project has, and glad to skip it if that's your preference.
Details are at https://www.orcarouter.ai/built-with. I'm an engineer on the OrcaRouter team. Would the maintainers be open to this as a provider option? If it fits your direction, I'm glad to open the implementation PR myself.
Frappe Studio collapses what is normally a hand-written pile of DocTypes, Vue pages and wiring into one visual surface: drag a frappe-ui layout, bind a Frappe data source with minimal configuration, then drop into a page script mirroring Vue
<script setup>with real reactive state and handlers. For developers working inside a bench, the path from prototype to the exported,bench build-studio-appproduction build stays on machinery they already run.The AI assistant is why I'm writing. It is already provider-shaped:
studio/ai/llm.pycalls itself the only place that knows provider quirks, models live inModelRegistry.AVAILABLEas OpenRouter-prefixed IDs, and one key in Studio Settings feeds them all. Another OpenAI-compatible endpoint there is additive, and would let a bench operator point the assistant at routing and billing they already have.I'd like to propose OrcaRouter as an optional provider for the AI assistant. To be clear up front: this would not replace, remove or change any existing provider — it is one more entry, and OpenRouter stays exactly as it is today.
A few things that seem genuinely relevant to Studio's users:
ModelRegistry.AVAILABLEand itsvision_capableflag — the chat panel already uses that flag to decide whether a screenshot can be attached.get_fallbacks()drops to the cheapSIMPLEmodel). Upstream failover would let that safety net hold across providers, not just across models on one.stream_options={"include_usage": True}and tallies tokens per turn, so per-key spend and caps have somewhere natural to surface.OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so the expected integration point is the existing
llm.pyadapter plus theai_api_keyfield on Studio Settings — no new abstraction required. I have not written or tested any code for this; it is a proposal, not a claim that the work is done.OrcaRouter is already used in open-source projects including RAGFlow, Dify, goose, and promptfoo.
One transparent note: we run an optional open-source partner program where approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participating is entirely optional and not a precondition for the integration — I'm happy to follow whatever disclosure or governance rules the project has, and glad to skip it if that's your preference.
Details are at https://www.orcarouter.ai/built-with. I'm an engineer on the OrcaRouter team. Would the maintainers be open to this as a provider option? If it fits your direction, I'm glad to open the implementation PR myself.