aws-samples / aws-samples/sample-mobile-ai-assistant
OrcaRouter provider support for Sample Mobile AI Assistant
- Dominant language
- TypeScript
- Stars
- 859
- Forks
- 132
- PR merge metrics
- No merged PRs in 30d
Description
**A natural next step for AI Assistant's provider story**
Sample Mobile AI Assistant is a compelling answer to a real question: what should a personal AI workspace look like on a phone? Real-time streaming chat, AI image generation and one-prompt instant web-app creation on Android, iOS and macOS make an ambitious workflow, and the privacy-first approach (encrypted API keys, local-only data, no tracking) makes it easy to trust.
The README shows an even-handed commitment to model choice too: Amazon Bedrock, Ollama, DeepSeek, OpenAI and up to ten user-defined OpenAI-compatible endpoints. For users who want that breadth without juggling several keys and model lists, an optional single-endpoint gateway would add real convenience.
**Is your feature request related to a problem? Please describe.**
AI Assistant already makes model choice easy. The remaining friction is for users who want several providers without maintaining each one's key and model list, and who have no automatic fallback if an upstream provider is slow or down.
**Describe the solution you'd like**
Add OrcaRouter as an optional provider. It would not replace or change any existing provider: Bedrock, Ollama, DeepSeek, OpenAI and user-defined OpenAI-compatible endpoints all stay as they are. OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so the natural integration point is the OpenAI-compatible path this app already has: chat requests are dispatched by `ChatProviderRouter` to an OpenAI chat-completions client configured with a base URL, an API key and a model ID. Users would enter their OrcaRouter base URL and key in Settings and pick models from the Chat Model dropdown. Three capabilities seem most relevant to AI Assistant users:
- Many chat and reasoning models from different providers through one endpoint and one key.
- Automatic model routing and provider failover, so a slow or unavailable provider does not end a conversation.
- Usage tracking and budgets per key, complementing the usage statistics already shown in Settings.
This is a proposal for discussion; nothing here is implemented or tested in this codebase.
**Describe alternatives you've considered**
Users can already add several OpenAI-compatible providers manually, but key management, model lists and failover are then left to each user. OrcaRouter is one of several gateways already used in the open-source ecosystem (integrated by projects such as Dify, goose and RAGFlow); this issue simply asks whether an optional OrcaRouter entry would be welcome.
**Additional context**
Transparency note: OrcaRouter runs an optional open-source partner program in which approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a precondition for integrating, and I would be happy to follow this project's disclosure or governance requirements. More examples are listed at https://www.orcarouter.ai/built-with. I am an engineer on the OrcaRouter team and would welcome maintainers' thoughts; with approval, I would be glad to open a PR implementing the provider.
Contributor guide
Research direction
Start by reading the existing OpenAI-compatible path and ChatProviderRouter to understand how chat requests use a base URL, API key, and model ID. Then inspect Settings and the Chat Model dropdown. Done should mean OrcaRouter is an optional selectable provider while Bedrock, Ollama, DeepSeek, OpenAI, and user-defined endpoints remain unchanged.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- react-native, typescript
- Domain
- api, mobile-dev
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100