Repository navigation
Add LLMTR as a built-in cloud provider #7176
Description
I work on LLMTR (built by Knowhy.co), so weigh this request accordingly.
Summary
Add LLMTR as a built-in BYOK provider so it appears in Settings → AI → Add provider and needs only a key, the same way SumoPod and ModelScope (#3773) work today.
LLMTR is an OpenAI-compatible gateway at https://llmtr.com/v1 with Authorization: Bearer keys. Some of its models are hosted in Türkiye and some are Turkish-focused. It also serves models from other labs through the same key.
Problem
People in Türkiye who need requests processed in the country, for example because of KVKK, can use LLMTR with OpenHuman today only through the custom-provider form, where they enter the name, URL and key by hand. OpenHuman already ships a Turkish locale (app/src/lib/i18n/tr.ts, docs/README.tr.md), but none of the built-in providers is hosted in Türkiye.
Solution
Scope: core and app. The change is data only:
- Core: one
BuiltinCloudProviderentry (slug: "llmtr",AuthStyle::Bearer) at the end ofcrates/openhuman-core/src/config/schema/cloud_providers.rs, plus its row in the hand-maintained preset test. The registry-driven checks (unique slugs, host recognition, the Responses-API gate) cover it automatically. LLMTR is chat-completions-only for this purpose, which matches the built-in default. - App: the matching entry in
builtinCloudProviders.tsand its test, which also covers near-miss slugs (LLMTR,llm-tr,llmtr.com,""). A monochrome icon taken from LLMTR's published brand assets (checksum-matched againsthttps://llmtr.com/brand/manifest.json) is bundled locally, so it makes no runtime network request. - Docs: the BYOK slug lists in
gitbooks/and the provider count inREADME.md/docs/README.tr.md(26 → 27).
What it does not change: defaults, routing, request headers (no x-sdk-name or other attribution, per AGENTS.md), the factory, credentials, or any vendor crate. The entry goes last in the list. Models are discovered through the existing GET {endpoint}/models path, and LLMTR returns the standard OpenAI list shape.
I saw that #6620 (another gateway preset) was reverted in #6778. That is why this change covers the Rust catalog and the frontend together, the way ModelScope did. If there is a policy for gateway or router presets that this doesn't meet, I'm happy to adjust or close it.
I'm opening a PR that links here. The focused Rust and Vitest suites pass, as do clippy and rustfmt. I also tested it end to end against a local core and the web UI:
- Connecting with a key works.
- Model discovery returns 347 models.
- Chat turns stream, including one with a tool call (
resolve_time). - An invalid key fails fast with the existing auth-error message.
Acceptance criteria
- Provider preset: LLMTR appears in the add-provider list with its icon, and saving a key resolves
https://llmtr.com/v1with bearer auth. - Catalog parity: the Rust registry and
builtinCloudProviders.tsagree on the slug, endpoint and auth style, and tests pin both. - Model discovery:
openhuman.inference_list_modelsforllmtrreturns the provider's models through the existing catalog path. - No default changes: no new headers, no routing or default-provider changes, and existing presets are untouched.
- Diff coverage ≥ 80%: the implementing PR meets the changed-lines coverage gate.
Related
- Same pattern: feat: add ModelScope API support #3773 (ModelScope)
- Prior gateway preset: feat(settings): add Cheaper Inference as a built-in cloud provider #6620, reverted in Revert "Add Cheaper Inference as a built-in cloud provider" #6778
Activity
tinysweeper commentedon Oct 9, 2026
Request to add LLMTR (a Turkish BYOK OpenAI-compatible gateway) as a built-in cloud provider entry in core and app, following the ModelScope pattern. No duplicate among candidates; no known resolving PR.
Labelled
priority: p3.vineet-008 commentedon Oct 9, 2026
Hi @knowhycodata I'd like to work on this issue and implement LLMTR as a built-in BYOK provider in OpenHumanI work on LLMTR at Knowhy.co, so I'm familiar with the service and its OpenAI-compatible API. I believe this integration can be implemented cleanly using OpenHuman's existing provider architecture without introducing any provider-specific runtime logic.
Implementation plan
Core provider registration (Rust)
Add llmtr to crates/openhuman-core/src/config/schema/cloud_providers.rs as a BuiltinCloudProvider.
Configure the endpoint as https://llmtr.com/v1 and authentication as AuthStyle::Bearer.
Keep the provider chat-completions-only, following the existing built-in default.
Add the corresponding entry to the hand-maintained preset tests and ensure the registry remains consistent.
Frontend provider registration
Add the matching llmtr entry to builtinCloudProviders.ts.
Bundle a monochrome provider icon locally, verifying it against LLMTR's published brand assets and checksum manifest.
Extend the frontend tests to cover the valid slug and the specified near-miss inputs: LLMTR, llm-tr, llmtr.com, and an empty string.
Ensure the provider appears correctly in Settings → AI → Add provider and that saving a key uses the expected endpoint and authentication style.
Documentation updates
Update the BYOK provider slug lists in the relevant gitbooks/ documentation.
Update the provider counts in README.md and docs/README.tr.md from 26 to 27, checking the actual current counts before making changes.
Keep the documentation consistent across the English and Turkish versions.
Testing and validation
Run the focused Rust provider-catalog tests.
Run the relevant frontend Vitest suites.
Run cargo fmt --check and the applicable Clippy checks.
Verify that Rust and frontend provider definitions agree on the slug, endpoint and authentication style.
Test model discovery through the existing GET /models flow.
Where the development environment permits, test a complete connection using an LLMTR API key, including streaming responses and error handling for invalid credentials.
Verify that existing providers and default-provider behavior remain unchanged. I will also check the changed-lines coverage requirement and add focused tests to meet the project's coverage threshold.
Scope and compatibility
I intend to keep this a data-only integration, limited to the core provider catalog, frontend preset, associated tests, and documentation.
Specifically, I will not modify routing, defaults, the provider factory, credential handling, or request headers. I will not introduce x-sdk-name or other attribution headers, and I will not add a new vendor dependency or make the icon dependent on a runtime network request.
Regarding the previous gateway-preset revertI noticed that the earlier gateway preset in #6620 was reverted in #6778. I will review the relevant discussion and repository contribution guidelines before implementation, so the change follows the project's expectations for built-in gateway providers.If there is a policy concern specific to inference gateways, I'm happy to discuss it with the maintainers before proceeding.
knowhycodata commentedon Oct 9, 2026
Thanks for the interest. This is already implemented in #7177, which is open and waiting for maintainer review, so there's nothing left to pick up here.
senamakel commentedon Oct 9, 2026
Triage: needs opinion — “Add LLMTR as a built-in cloud provider” needs a maintainer decision on product scope/priority or fresh reproduction evidence before its status can be settled. Please advise whether to pursue, narrow, or close it.
knowhycodata commentedon Oct 9, 2026
I'd suggest pursuing it. #7177 is ready and rebased onto current main:
builtinCloudProviders.ts, kept in parity, plus a bundled icon and the doc counts. Defaults, routing and headers don't change, and the provider is opt-in and listed last.module-pinsandsaas-ambient, plus the hostedrust-covzombie issue described on the PR), not from this diff.If you'd rather narrow it, I can keep only the catalog entries and drop the README and docs changes. If built-in gateway presets are out of scope, I'll close both; the custom-provider form still works for LLMTR.