GeezerVison

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Jul 10, 2026 4:08pm

PR Summary

Medium Risk
Z.ai hosted keys and BYOK affect billing and credential paths for all GLM catalog models; the large new provider adapters touch core execution (tools, streaming, structured output) though they follow existing OpenAI-compatible patterns.

Overview
Adds NVIDIA NIM and Z.ai as first-class LLM providers, with catalog entries, icons, registry wiring, and OpenAI-compatible adapters (NIM at integrate.api.nvidia.com, Z.ai at api.z.ai).

NVIDIA ships six nvidia/* Nemotron models (pattern ^nvidia/), tool calling, streaming, and deferred json_schema when tools are active. Attachments are explicitly unsupported like other text-only adapters.

Z.ai ships twelve bare glm-* models with empty modelPatterns so self-hosted glm-* IDs are not misrouted. GLM models are added to getHostedModels() with ZAI_API_KEY_1/2/3 rotation, hosted-key resolution in providers/utils and BYOK (zai in contracts). The Z.ai adapter maps thinking / reasoning_effort, uses json_object instead of strict JSON schema, and always sends tool_choice: 'auto' (forced/none choices are ignored with a warning); post-tool streaming/format calls drop tools rather than using tool_choice: 'none'.

Shared plumbing updates tokenization heuristics, attachment provider lists, and tests for both catalogs plus Z.ai hosted routing.

^{Reviewed by Cursor Bugbot for commit bb0a944. Configure here.}

Greptile Summary

This PR adds NVIDIA NIM and Z.ai as model providers. The main changes are:

• New NVIDIA NIM and Z.ai provider adapters.
• New Nemotron and GLM model catalog entries.
• Z.ai hosted-key rotation and BYOK wiring.
• Provider registry, icon, attachment, and tokenization updates.
• Tests for provider definitions and model routing.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.

Important Files Changed

_{Reviews (4): Last reviewed commit: "fix(providers): route Z.ai through the w..." | Re-trigger Greptile}

Re: Greptile's P1 "Disabled Tools Become Auto" finding (flagged outside the diff, in the summary) — traced this through and don't think it reproduces:

• request.tools is passed through prepareToolsWithUsageControl, which filters OUT any tool whose usageControl === 'none' before returning filteredTools.
• If every tool is disabled, filteredTools.length === 0 and the function takes its early-return branch, returning { tools: undefined, toolChoice: undefined, ... } — not an empty array.
• zai/index.ts's guard is if (filteredTools?.length && toolChoice) — with filteredTools undefined, filteredTools?.length is undefined (falsy), so the block is skipped entirely and payload.tools is never set. Z.ai receives no tools field at all and has nothing to call.
• If only some tools are disabled, the remaining (still-enabled) ones are sent with tool_choice: 'auto' — which is exactly the intended "let the model pick among the tools that are actually enabled" behavior, not a bypass of the disabled ones.

This filtering logic is unmodified shared code (prepareToolsWithUsageControl in providers/utils.ts), identical to how sakana/openai already handle usageControl: 'none' — my change only touches what tool_choice value gets sent for the tools that remain after filtering, not which tools are filtered. Happy to add a regression test here if useful, but wanted to flag the reasoning before making a speculative code change. Let me know if I'm missing a path where this actually triggers.

Fixed the P2 finding (/^glm/ overmatching unrelated self-hosted models) in f6c0117 — thread resolved.

@greptile

@cursor review

@greptile

@cursor review

@greptile

@cursor review