Is your feature request related to a problem? Please describe.
TimeTracker is a self-hosted, web-based time tracking application for freelancers, small teams, and agencies that want professional time management without handing data to a cloud vendor. What stands out is how the built-in invoicing closes the loop from timer to invoice, and that even the optional AI helper stays local-first: deterministic time-entry suggestions always work, and an LLM is layered on only when an admin opts in.
Admins already configure the AI helper through AI_PROVIDER, AI_BASE_URL, and AI_API_KEY, including an openai_compatible mode that targets {base_url}/v1/chat/completions, so OrcaRouter would be another choice for that same setting. Self-hosters who prefer not to run an Ollama container gain a hosted option serving many models through one endpoint, with no new configuration surface.
Describe the solution you'd like
I would like to see OrcaRouter supported as an optional AI provider: an admin would point the existing hosted-provider settings at OrcaRouter's base URL with a standard API key. OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, which matches how LLMService already builds requests and attaches a Bearer token for hosted providers. To be clear, this is a proposal and no code exists yet; I would welcome maintainers' input on where it best fits in app/services/llm_service.py and the Admin -> System Settings -> AI Helper form.
For TimeTracker users, the most relevant OrcaRouter capabilities are: multiple chat, reasoning, image, and video models through one endpoint; automatic routing with provider failover; and usage tracking with budgets. For an optional feature whose appeal is helpful AI with almost no maintenance, failover keeps autofill working when an upstream model is unavailable, and budgets give users a predictable cost ceiling.
Describe alternatives you've considered
TimeTracker already supports a self-hosted Ollama model and any OpenAI-compatible hosted provider. OrcaRouter would extend the second path as an additive choice rather than an alternative. It is already integrated into open-source projects such as Dify, RAGFlow, goose, and promptfoo, so treating it as an OpenAI-compatible endpoint is an established pattern.
Additional context
Full transparency: I'm an engineer on the OrcaRouter team. 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 entirely optional and not a prerequisite for this integration, and I'm happy to follow whatever disclosure or governance requirements TimeTracker prefers. Examples of existing integrations are listed at https://www.orcarouter.ai/built-with.
I would value your thoughts on whether this fits TimeTracker's direction, and with your approval I would be glad to submit an implementation PR following the contributing guidelines.
Is your feature request related to a problem? Please describe.
TimeTracker is a self-hosted, web-based time tracking application for freelancers, small teams, and agencies that want professional time management without handing data to a cloud vendor. What stands out is how the built-in invoicing closes the loop from timer to invoice, and that even the optional AI helper stays local-first: deterministic time-entry suggestions always work, and an LLM is layered on only when an admin opts in.
Admins already configure the AI helper through
AI_PROVIDER,AI_BASE_URL, andAI_API_KEY, including anopenai_compatiblemode that targets{base_url}/v1/chat/completions, so OrcaRouter would be another choice for that same setting. Self-hosters who prefer not to run an Ollama container gain a hosted option serving many models through one endpoint, with no new configuration surface.Describe the solution you'd like
I would like to see OrcaRouter supported as an optional AI provider: an admin would point the existing hosted-provider settings at OrcaRouter's base URL with a standard API key. OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, which matches how
LLMServicealready builds requests and attaches aBearertoken for hosted providers. To be clear, this is a proposal and no code exists yet; I would welcome maintainers' input on where it best fits inapp/services/llm_service.pyand the Admin -> System Settings -> AI Helper form.For TimeTracker users, the most relevant OrcaRouter capabilities are: multiple chat, reasoning, image, and video models through one endpoint; automatic routing with provider failover; and usage tracking with budgets. For an optional feature whose appeal is helpful AI with almost no maintenance, failover keeps autofill working when an upstream model is unavailable, and budgets give users a predictable cost ceiling.
Describe alternatives you've considered
TimeTracker already supports a self-hosted Ollama model and any OpenAI-compatible hosted provider. OrcaRouter would extend the second path as an additive choice rather than an alternative. It is already integrated into open-source projects such as Dify, RAGFlow, goose, and promptfoo, so treating it as an OpenAI-compatible endpoint is an established pattern.
Additional context
Full transparency: I'm an engineer on the OrcaRouter team. 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 entirely optional and not a prerequisite for this integration, and I'm happy to follow whatever disclosure or governance requirements TimeTracker prefers. Examples of existing integrations are listed at https://www.orcarouter.ai/built-with.
I would value your thoughts on whether this fits TimeTracker's direction, and with your approval I would be glad to submit an implementation PR following the contributing guidelines.