feat(provider): add built-in LLMTR gateway provider

[knowhycodata]

Closes #9

What

Adds LLMTR — a Turkey-hosted, OpenAI-compatible AI gateway (200+ models, global + Turkey-hosted with data-residency guarantee) — as a built-in provider. It plugs in like the other gateway providers (openrouter/nvidia/zenmux): an @ai-sdk/openai-compatible provider at https://llmtr.com/v1 whose bearer key is resolved from a new llmtr integration.

Changes

• packages/core/src/plugin/provider/llmtr.ts — new provider plugin:
  • Injects the llmtr provider into the catalog (@ai-sdk/openai-compatible, url https://llmtr.com/v1, branding headers).
  • Registers an llmtr integration with API-key + env (LLMTR_API_KEY) auth methods.
  • Discovers the model catalog live from the public /v1/models endpoint (OpenRouter-style schema): converts per-token pricing → per-1M cost, maps modalities, tool support (supported_parameters), and context/output limits.
  • Best-effort, forked fetch (never blocks registration) with a curated offline seed of Turkey-hosted flagship models.
  • LLMTR_BASE_URL overrides the endpoint; LLMTR_SKIP_REMOTE_MODELS=1 disables the live fetch (used by the test).
• packages/core/src/plugin/provider.ts — register LLMTRPlugin in ProviderPlugins.
• packages/core/test/plugin/provider-llmtr.test.ts — hermetic tests: registration, provider api/headers, integration key+env methods, seed model pricing conversion & tool detection.
• README.md — LLMTR configuration section.

Usage

pentestcode auth login    # pick "LLMTR", paste API key   (or export LLMTR_API_KEY=...)

{ "provider": { "llmtr": { "model": "openai/gpt-5.5" } } }

Verification

• tsgo --noEmit (core) — clean.
• bun test test/plugin/ — 217 pass / 0 fail (incl. 4 new).

[s0ld13rr]

Hey, thanks for the PR — went through the diff.

The code itself is solid and well-tested, no issues there. But I have a few concerns about merging it as a built-in provider:

1. fetchModels() fires on every startup regardless of whether anyone has an LLMTR key configured. None of the other providers (groq, nvidia, openrouter) do remote fetches at init. At minimum this needs a guard — skip the fetch entirely if no API key is present.

2. The rewriteLLMTRReasoningBody logic lives in the shared provider.ts, so every request to any provider now passes through if (model.providerID === "llmtr"). This should live inside the plugin itself (via ctx.aisdk.sdk hook, same way openrouter does its SDK override), not in the common path.

3. The seed list includes DeepSeek and GLM models that already have their own provider plugins — could cause duplicate/conflicting entries in the catalog.

4. Broader question: LLMTR is OpenAI-compatible, so users can already connect to it with ~3 lines of config in pentestcode.jsonc without any code changes. Adding a built-in provider means we commit to maintaining it long-term.

Two paths forward:

A) I can add a "Custom providers" section to the README showing how to point at LLMTR (or any OAI-compatible gateway) via existing config. Zero code, works today.

B) If you want first-class support — move the reasoning rewrite into the plugin, gate the fetch behind API key presence, and drop the seed models that overlap with existing providers. Happy to review a v2.

What do you think?

[knowhycodata]

Hey, thank you so much for taking the time to go through this so carefully — genuinely helpful feedback, and you're right on the money with the first two. I pushed a v2 (64cb77d) that takes care of them:

1. Startup fetch — totally agree, it shouldn't do anything before there's a key. It's now gated on API-key presence (env var or an active LLMTR connection), so a user with no key pays zero at init and just gets the seed list. It also re-fetches on auth login so the full catalog fills in the moment a key is added. 👍

2. Reasoning rewrite in the shared path — 100% agree it didn't belong there as a providerID === "llmtr" branch. I pulled it out into a generic per-provider body-rewriter registry, so the shared path no longer knows anything about LLMTR — a provider just registers its own rewriter and the request path looks it up generically. One thing worth flagging (took me a bit to trace): the interactive path builds its SDK through BUNDLED_PROVIDERS, not the V2 ctx.aisdk.sdk hook — so if I'd moved the rewrite into the aisdk hook like openrouter, it'd silently stop firing in the actual TUI. So it stays on that path, just no longer provider-specific. Very open to a better home for it if you know one I missed!

3. DeepSeek / GLM overlap — fair concern, let me make the case for keeping them and you tell me if you disagree. They register under the llmtr namespace (llmtr → deepseek/…, zai/glm-…), so they're separate catalog entries rather than collisions with the models.dev providers. The reason they earn their spot is pricing: LLMTR serves the GLM 5.x family ~10% under list and the DeepSeek family is periodically free, so reaching them through LLMTR is a real cost win, not just a duplicate. That said — totally happy to trim to only the ones with a meaningful price delta if you'd rather keep the list lean.

4. Maintenance — we've got this one long-term, no worries: I work at LLMTR, so keeping the catalog and pricing current is on us rather than the project. And if you'd like to kick the tires end-to-end, I'd be glad to drop some test credit on an LLMTR account for you — just send me the email you'd sign up with. 🙂

Thanks again — really appreciate the thoughtful review.