[knowhycodata]

Add LLMTR as an optional built-in OpenAI-compatible provider across onboarding, provider configuration, model discovery, key detection and help links. Users supply their own API key; no new dependency or hosted account is introduced.

The key check uses a minimal chat request because the public model catalog does not validate credentials. Derive its endpoint and model from BUILTIN_PROVIDERS.llmtr so probe defaults stay aligned with generation. Existing 401/403, credit and rate-limit diagnostics remain in use; model discovery remains separate from the validation result.

Integrated current main, including the pi namespace/security migration. Provider tests and all repository typechecks passed locally; full pre-push and current remote CI are tracked on the latest head. The earlier CI failure was in the unrelated workspace-rename coordination test. No paid live model call was made during this maintainer pass; the contributor's original PR reported live generation and invalid-key checks.

Contributor disclosure: the original author works on LLMTR. Closes #539.

Final validation: full local pre-push lint, typecheck and all 11 test tasks passed (desktop: 3,046 passed, 12 skipped); required remote CI and security/dependency checks passed on 867afce. The follow-up review used a stale base SHA (5daa34e); GitHub compare against current main and local merge-base comparison show only the 18 LLMTR-related files. The pi/security/release changes are already merged on main. CI resolves .nvmrc 22 to the current Node 22 release and its install/typecheck/tests passed with the >=22.19.0 engine requirement. Issue #539 acceptance criteria were checked against the implementation.

[github-actions]

Findings

• [Nit] Default model/base-URL literal is duplicated across packages — 'qwen/qwen3.8-27b-free' is hardcoded in packages/shared/src/config.ts:337 (BUILTIN_PROVIDERS.llmtr.defaultModel), packages/shared/src/config.ts:615 (PROVIDER_SHORTLIST.llmtr.defaultPrimary), and packages/providers/src/validate.ts:71 (chat probe), and the validator also hardcodes the root 'https://llmtr.com' instead of the built-in base URL. If the default model is ever changed or retired, the validator can silently probe a stale model while the rest of the app uses a different one.
  Suggested fix: import the shared constant in validate.ts (it already imports from @open-codesign/shared) and use BUILTIN_PROVIDERS.llmtr.defaultModel for the probe, e.g. model: BUILTIN_PROVIDERS.llmtr.defaultModel, and derive the root from BUILTIN_PROVIDERS.llmtr.baseUrl rather than a second literal.

Questions

• pingProvider('llmtr', ...) returns { ok: true, modelCount: 0 } (packages/providers/src/validate.ts:164) even though BUILTIN_PROVIDERS.llmtr.capabilities declares supportsModelsEndpoint: true / modelDiscoveryMode: 'models'. Can you confirm the onboarding model picker is populated from PROVIDER_SHORTLIST / GET /v1/models discovery and not from the validate result, so a successful key check does not leave users with an empty model list?
• Validation now depends on the specific free model qwen/qwen3.8-27b-free. If that model is rate-limited (HTTP 429) or renamed/retired (404), a still-valid key will surface as a generic network error (the added test for 500→network codifies this). Is that acceptable, or would a clearer retry hint for 429 / a fallback be worth adding?
• The PR says Closes #539, but the issue body and acceptance criteria were not part of the provided public review context, so I could not validate the closure claim. Can you confirm the diff covers everything #539 asks for (e.g. provider selection, diagnostics, and any title-generation path), rather than a single onboarding path?

Summary

• Review mode: initial
• Directionally sound and additive: the change mirrors the existing Atlas Cloud built-in pattern (enum, BUILTIN_PROVIDERS, PROVIDER_SHORTLIST, detectProviderFromKey, error key-help URL, model-discovery host, README/zh + changeset). The exhaustive Record<SupportedOnboardingProvider, ...> maps force the new entries, and the added Vitest coverage (detection, validation success/204/401/403/500/transport/custom base, config, model discovery, base URL, onboarding IPC forwarding) is proportional to the change.
• No blocking issues found. Main residual risk is the validation probe's dependence on a single hardcoded free model; otherwise this is mergeable after the nit/question above.

Testing

• Not run (automation). Added tests look adequate for the change.

Open-CoDesign Bot

[github-actions]

Findings

• [Nit] The PR diff against main covers far more than the LLMTR provider — gh pr diff includes the pi 0.79 namespace migration, the undici 8.12.4 / engines bump, a release-pipeline rewrite (.github/workflows/release.yml:79-90, .github/scripts/sync-release-manifests.sh:1), dependency-policy changes (.github/dependabot.yml:1, renovate.json:1) and lifecycle changes in packages/core/src/agent.ts:1388-1540 — 89 files for a provider addition. The PR body says main was integrated; if so those commits are already on the base and a rebase would reduce this to the provider change, making the release-path edits separately reviewable.
  Suggested fix / next action: git fetch origin && git rebase origin/main and force-push; if any of those files are new work rather than merged-in main, split them into their own PR.

Questions

• engines is now node: ">=22.19.0" (package.json:15-17) and CI installs Node from .nvmrc (node-version-file: .nvmrc in .github/workflows/ci.yml:31-33). Was .nvmrc bumped to at least 22.19.0, so local installs and CI do not disagree with the new engine requirement (the installed pi 0.79 packages declare node >=22.19.0 in pnpm-lock.yaml)?

Summary

• Review mode: follow-up after new commits
• The earlier nit is resolved: packages/providers/src/validate.ts:62-75 now derives both the endpoint root and the probe model from BUILTIN_PROVIDERS.llmtr (.baseUrl / .defaultModel), so changing the default model can no longer desync the validator from generation.
• The earlier modelCount: 0 question is answered by the PR body and by the provider config: discovery stays on the shortlist / GET /v1/models path (modelDiscoveryMode: 'models', supportsModelsEndpoint: true in packages/shared/src/config.ts:332-347), covered by packages/shared/src/config.test.ts, model-discovery.test.ts, base-url.test.ts.
• The LLMTR wiring is complete and mirrors the Atlas Cloud precedent: both ProviderId enums (packages/shared/src/config.ts:10, packages/shared/src/index.ts:40), SUPPORTED_ONBOARDING_PROVIDERS, BUILTIN_PROVIDERS, PROVIDER_SHORTLIST (packages/shared/src/config.ts:613-619), key detection (packages/providers/src/index.ts:601), key-help rewrite (packages/core/src/errors.ts:25), LISTING_CAPABLE_OFFICIAL_HOSTS (packages/shared/src/model-discovery.ts:131), onboarding parser messages, README/README.zh-CN and a changeset. Vitest coverage is proportional (probe shape, 204, 401/403, 500, transport failure, custom base URL, IPC forwarding, key detection, error rewrite).
• Residual risk (non-blocking, unchanged from the prior review): the probe depends on a single free model, so a 429 on that model still surfaces as a generic network error with no retry hint. Closes #539 could not be validated against the issue body/acceptance criteria in this run — only the public PR body enumerates the covered paths.
• No blocking issues found in the provider change itself.

Testing

• Not run (automation). Added unit coverage looks adequate for the provider paths; no live provider call was made.

Open-CoDesign Bot