feat(ai): make omniroute primary reviewer model, qwen-3.6-fast fallback - #4309
Conversation
Several free models routed through omniroute (opencode's Kimi/GLM/ DeepSeek-class models) outclass the self-hosted 27B on review quality. Pin the omniroute LiteLLMModel to a specific model instead of "auto" for reproducible output, add litellm router fallback to qwen-3.6-fast so a flaky free provider can't take out the PR review action, and point agent-pr-review.yaml at omniroute.
 |
|
Overall Grade |
Security Reliability Complexity Hygiene |
Code Review Summary
| Analyzer | Status | Updated (UTC) | Details |
|---|---|---|---|
| JavaScript |  |
Aug 2, 2026 6:10p.m. | Review ↗ |
| Shell | |
Aug 2, 2026 6:10p.m. | Review ↗ |
Important
AI Review is run only on demand for your team. We're only showing results of static analysis review right now. To trigger AI Review, comment @deepsourcebot review on this thread.
|
Important Review skippedNo new commits to review since the last review. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughThe PR changes the review workflow to use ChangesOmniRoute routing
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant AgentPRReview
participant LiteLLM
participant QwenProvider
AgentPRReview->>LiteLLM: Request review with omniroute
LiteLLM->>QwenProvider: Fallback after omniroute failure
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
@@ spec.routerSettings @@
# litellm.home-operations.com/v1alpha1/LiteLLMProxy/ai/litellm
! + one map entry added:
+ fallbacks:
+ - omniroute:
+ - qwen-3.6-fast
|
AI Automated Review (incremental)Analysis engine: omniroute@http://litellm.ai.svc.cluster.local/v1 (openai) RecommendationApprove with one minor follow-up. The incremental delta reverts Change-by-change findings
Standards Compliance
Tool Harness FindingsTool harness planning is pending and no harness output was available at review time; no tool-harness-derived issues to report. Unknowns or Needs Verification
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@kubernetes/apps/ai/litellm/instance/models.yaml`:
- Around line 81-82: Update the big-pickle model configuration so maxInputTokens
reserves the 8192 maxOutputTokens from the 200000-token context window, setting
it to 191808; alternatively, explicitly document that 200000 applies to input
tokens only.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: d5b43563-7c0f-4aa4-b37d-6f0bd67f6468
📒 Files selected for processing (3)
.github/workflows/agent-pr-review.yamlkubernetes/apps/ai/litellm/instance/models.yamlkubernetes/apps/ai/litellm/instance/proxy.yaml
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
Tanguille/LLMKube(auto-detected)Tanguille/toolhive(auto-detected)Tanguille/pr-reviewer-action(auto-detected)Tanguille/2x-R9700-RDNA4-GFX1201-sglang-inference(auto-detected)
| maxInputTokens: 200000 | ||
| maxOutputTokens: 8192 |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
rg -n --glob '*.yaml' --glob '*.yml' --glob '*.json' \
'maxInputTokens|maxOutputTokens|context(Window|_length)?'Repository: Tanguille/cluster
Length of output: 155
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
printf '%s\n' '--- candidate files ---'
git ls-files | grep -E '(^|/)models\.(yaml|yml|json)$|litellm' | head -200 || true
printf '%s\n' '--- exact target candidates ---'
find . -type f \( -name 'models.yaml' -o -name 'models.yml' \) -print
printf '%s\n' '--- target content ---'
for f in $(find . -type f \( -path '*/kubernetes/apps/ai/litellm/instance/models.yaml' -o -name 'models.yaml' \) -print); do
echo "FILE: $f"
grep -n -C 12 -E 'big-pickle|maxInputTokens|maxOutputTokens|context' "$f" || true
done
printf '%s\n' '--- repository references ---'
rg -n -i --hidden -g '!*.lock' -g '!node_modules' \
'big-pickle|maxInputTokens|maxOutputTokens|context.?window|context.?length' . || trueRepository: Tanguille/cluster
Length of output: 4796
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
rg -n -i --hidden -g '!*.lock' -g '!node_modules' \
'big-pickle|maxInputTokens|maxOutputTokens|context.?window|context.?length' . || trueRepository: Tanguille/LLMKube
Length of output: 18849
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
rg -n -i --hidden -g '!*.lock' -g '!node_modules' \
'big-pickle|maxInputTokens|maxOutputTokens|context.?window|context.?length' . || trueRepository: Tanguille/toolhive
Length of output: 1516
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
rg -n -i --hidden -g '!*.lock' -g '!node_modules' \
'big-pickle|maxInputTokens|maxOutputTokens|context.?window|context.?length' . || trueRepository: Tanguille/pr-reviewer-action
Length of output: 2472
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
rg -n -i --hidden -g '!*.lock' -g '!node_modules' \
'big-pickle|maxInputTokens|maxOutputTokens|context.?window|context.?length' . || trueRepository: Tanguille/2x-R9700-RDNA4-GFX1201-sglang-inference
Length of output: 47538
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
sed -n '60,95p' kubernetes/apps/ai/litellm/instance/models.yaml
rg -n -i --hidden -g '!*.lock' \
'maxInputTokens|maxOutputTokens|context.?window|context.?length|big-pickle' .Repository: Tanguille/cluster
Length of output: 2207
🌐 Web query:
LiteLLM maxInputTokens maxOutputTokens context window semantics
💡 Result:
In LiteLLM, token limit parameters are used for both runtime API requests and model metadata management. Their semantics are defined as follows: 1. max_input_tokens: Represents the maximum input token limit (often equivalent to the model's context window) [1][2]. This is primarily used for validation, such as checking if a request is within the model's context window before execution when enable_pre_call_checks is set to true [3]. 2. max_output_tokens: Represents the maximum number of tokens that can be generated in the output (completion) [1][2]. 3. max_tokens (Legacy): This is a legacy parameter maintained for backward compatibility [1][4]. Its definition is inconsistent across older model entries in the LiteLLM catalog: - Ideally, if max_output_tokens is specified, max_tokens should match it [1][4]. - If max_output_tokens is absent, it defaults to the value of max_input_tokens [1][4]. - Due to historical inconsistencies, some older catalog entries may set max_tokens to represent the total context window, while others represent the output limit [5][4]. LiteLLM is currently undergoing a migration to replace this legacy field with explicit max_input_tokens and max_output_tokens values to resolve this ambiguity [5][4]. 4. max_completion_tokens: This is a newer parameter (aligning with OpenAI API standards) that represents an upper bound for the number of tokens generated, encompassing both visible output tokens and internal reasoning tokens [6]. When building integrations or configuring LiteLLM, it is recommended to rely on the explicit max_input_tokens and max_output_tokens fields rather than the legacy max_tokens parameter to ensure predictable behavior [1][4]. For runtime request payloads, standard parameters like max_tokens (for generation length) or max_completion_tokens (for newer reasoning models) should be passed according to the target provider's requirements [7][6].
Citations:
- 1: https://docs.litellm.ai/docs/provider_registration/add_model_pricing
- 2: https://deepwiki.com/BerriAI/litellm/2.4.1-provider-detection-and-model-configuration
- 3: https://docs.litellm.ai/docs/proxy/config_settings
- 4: chore: 59 models only have legacy max_tokens parameter, missing max_input_tokens/max_output_tokens BerriAI/litellm#18967
- 5: [Bug]: max_tokens changes definitions BerriAI/litellm#18779
- 6: https://docs.litellm.ai/docs/completion/input
- 7: https://docs.litellm.ai/completion/input
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
printf '%s\n' '--- LiteLLM deployment references ---'
rg -n -C 4 -i \
'litellm|chart:|version:|repository:|kind: LiteLLMModel|maxInputTokens|maxOutputTokens' \
kubernetes/apps/ai/litellm kubernetes/apps/ai/llmkube || true
printf '%s\n' '--- tracked CRD/schema references ---'
git ls-files | grep -Ei 'crd|litellm' | head -200 || true
rg -n -i 'litellmmodel_v1alpha1|maxInputTokens|maxOutputTokens' --hidden . || trueRepository: Tanguille/cluster
Length of output: 50373
🌐 Web query:
site:github.com home-operations charts litellm LitellMModel maxInputTokens maxOutputTokens
💡 Result:
In the context of LiteLLM and the LiteLLM Kubernetes operator, maxInputTokens and maxOutputTokens represent critical token limit parameters for managing model context windows and generation bounds [1][2]. 1. Usage in LiteLLM: max_input_tokens and max_output_tokens are used to define the capacity of models within LiteLLM's internal configuration (often found in model_prices_and_context_window.json) [3][4]. These fields have largely replaced the legacy max_tokens parameter, which historically led to ambiguity as it was inconsistently used to represent either input (context) or output limits [3][4]. LiteLLM now surfaces these explicit fields through the proxy's API (e.g., /v1/models) to allow downstream tools to discover specific model limits [1][2]. 2. Configuration in Kubernetes (LiteLLMOperator): When using the LiteLLMModel custom resource definition in Kubernetes, you can define these limits within the modelInfo section to specify the model's capabilities to the proxy [5]. Example configuration for a LiteLLMModel resource: kind: LiteLLMModel metadata: name: gpt4o spec: instanceRef: name: my-gateway modelName: gpt-4o litellmParams: model: openai/gpt-4o... modelInfo: maxInputTokens: 128000 maxOutputTokens: 16384... 3. Key Distinction: While max_tokens (or max_completion_tokens) remains a valid parameter in completion requests to control the number of tokens generated in a specific response [6], max_input_tokens and max_output_tokens are primarily used for model metadata, service discovery, and configuration management to ensure the system and its clients understand the architectural constraints of the underlying model [1][2][3].
Citations:
- 1: feat(proxy): surface max_input_tokens/max_output_tokens on /v1/models BerriAI/litellm#30272
- 2: Include max_input_tokens / max_output_tokens in /v1/models response BerriAI/litellm#25293
- 3: chore: 59 models only have legacy max_tokens parameter, missing max_input_tokens/max_output_tokens BerriAI/litellm#18967
- 4: [Bug]: max_tokens changes definitions BerriAI/litellm#18779
- 5: https://github.com/PalenaAI/litellm-operator/blob/main/docs/reference/litellmmodel.md
- 6: https://github.com/BerriAI/litellm/blob/4dc9726d/docs/my-website/docs/completion/input.md
🌐 Web query:
LiteLLMModel CRD maxInputTokens maxOutputTokens home-operations
💡 Result:
The LiteLLMModel Custom Resource Definition (CRD) is part of the Kubernetes operator for LiteLLM, which allows managing AI model registrations declaratively [1][2]. In recent versions of the LiteLLM operator (such as v0.16.0), the LiteLLMModel CRD has been updated to expose the full configuration surface supported by the LiteLLM proxy [3][4]. You can manage token limits within the LiteLLMModel manifest using the following fields [3][4]: 1. spec.litellmParams.maxInputTokens: This field is used for context-window-aware routing and fallback logic [3][4]. 2. spec.modelInfo: This section also includes fields related to token management [1][3][4]. Recent operator updates have added support for maxTokens, maxTokensReasoning, and maxTokensNonReasoning, which are flattened into the model_info payload for the LiteLLM proxy [3][4]. For authoritative reference, the LiteLLM proxy itself defines these limits (max_input_tokens and max_output_tokens) as part of its internal model configuration [5][6]. The operator synchronizes these definitions with the LiteLLM REST API (specifically the /model/new and /model/update endpoints) to ensure the proxy's runtime state matches your Kubernetes-managed GitOps configuration [3][7][8]. If you are working with the PalenaAI-maintained operator, ensure you are referencing the latest documentation in their repository, as the CRD surface area has expanded significantly to include these fine-grained token controls [3][4][7].
Citations:
- 1: https://github.com/PalenaAI/litellm-operator/blob/main/docs/reference/litellmmodel.md
- 2: https://github.com/home-operations/litellm-operator
- 3: https://github.com/PalenaAI/litellm-operator/releases/tag/v0.16.0
- 4: https://github.com/PalenaAI/litellm-operator/releases
- 5: Include max_input_tokens / max_output_tokens in /v1/models response BerriAI/litellm#25293
- 6: https://docs.litellm.ai/docs/provider_registration/add_model_pricing
- 7: https://github.com/palenaai/litellm-operator
- 8: https://docs.litellm.ai/docs/proxy/model_management
🌐 Web query:
site:github.com/BerriAI/litellm max_input_tokens max_output_tokens context window validation
💡 Result:
In Large Language Model (LLM) architectures and API integrations, max_input_tokens, max_output_tokens, and the context window serve distinct but interrelated roles [1][2][3]. Understanding their definitions and validation logic is critical for preventing request failures [4][5]. Definitions and Terminology - Context Window: The total number of tokens (input + output) that a model can process in a single interaction [6][1][7]. - Max Input Tokens: The maximum number of tokens allowed as prompt input [1][2]. Some models define this as the full context window, while others, particularly those with high reasoning capacity, reserve a portion of the total context window specifically for output [6][2]. - Max Output Tokens: The maximum number of tokens the model is permitted to generate in the completion [1][8]. This is often configurable via API parameters (e.g., max_tokens or max_completion_tokens) but is bounded by both the model's architectural output limit and the remaining available context window [4][8][9]. - Legacy max_tokens: Often a source of confusion, this term is increasingly deprecated in favor of explicit input/output limits [8][10][11]. Depending on the provider's implementation, it historically mapped to either the total context window or the maximum allowed output [3][7][10]. Validation and Interaction Robust LLM integrations validate these limits before sending a request to avoid ContextWindowExceededError or generic BadRequestError exceptions [12][13][5]. 1. Pre-call Token Counting: Developers typically estimate the token count of input messages and compare it against max_input_tokens (or the total context window) before dispatching the request [4][5]. 2. Dynamic Adjustment: When a user specifies a high max_output_tokens value, many client-side libraries dynamically adjust the request to ensure: - input_tokens + requested_output_tokens <= total_context_window [4][9]. - If the sum exceeds the window, the max_output_tokens is often clamped to total_context_window - input_tokens [4]. 3. Error Handling: Providers return varying error messages when limits are exceeded (e.g., "prompt is too long," "too many input tokens") [12][13]. Effective integrations centralize these error strings to normalize them into a standard ContextWindowExceededError, enabling automated recovery strategies like prompt compression or model fallback [12][13][14]. Because API metadata can sometimes be inconsistent or incomplete (e.g., legacy fields or incorrect documentation in provider-side model registries), it is best practice to rely on verified model documentation and implement conservative buffering (e.g., ensuring a small token buffer) to account for imprecision in tokenization [4][15][11][9].
Citations:
- 1: Update: gpt-4-turbo-preview pricing and context. Included in docs. BerriAI/litellm#2817
- 2: fix(models): correct max_input_tokens for GPT-5 models BerriAI/litellm#19056
- 3: [Bug]: The meaning of "max_tokens" reported by /model/info is inconsistent BerriAI/litellm#2834
- 4: https://github.com/BerriAI/litellm/blob/d251238b/litellm/litellm_core_utils/token_counter.py
- 5: fix(router): enforce context-window pre-call checks for Responses API input BerriAI/litellm#33706
- 6: Inconsistent max_input_tokens semantics in model_prices_and_context_window.json for GPT-5 family BerriAI/litellm#30928
- 7: Diff b/w max_output_tokens and max_tokens? BerriAI/litellm#7034
- 8: [Bug]: Inconsistent use of max tokens BerriAI/litellm#8985
- 9: [Bug]: Bedrock moonshotai.kimi-k2.5 max_output_tokens incorrectly set to context window size (262144) BerriAI/litellm#22478
- 10: [Bug]: max_tokens changes definitions BerriAI/litellm#18779
- 11: chore: 59 models only have legacy max_tokens parameter, missing max_input_tokens/max_output_tokens BerriAI/litellm#18967
- 12: fix: improve context window exceeded error detection BerriAI/litellm#21647
- 13: [Bug]: Context limit error message is not always ContextWindowExceededError BerriAI/litellm#21558
- 14: fix(openrouter): classify 400 context-window errors as ContextWindowExceededError BerriAI/litellm#28064
- 15: [Feature]: Auto-populate max_input_tokens/max_output_tokens for hosted vLLM/OpenAI-like models BerriAI/litellm#27830
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
rg -n -C 4 -i \
'litellm|chart:|version:|repository:|kind: LiteLLMModel|maxInputTokens|maxOutputTokens' \
kubernetes/apps/ai/litellm kubernetes/apps/ai/llmkube || true
git ls-files | grep -Ei 'crd|litellm' | head -200 || true
rg -n -i 'litellmmodel_v1alpha1|maxInputTokens|maxOutputTokens' --hidden . || trueRepository: Tanguille/cluster
Length of output: 50373
🏁 Script executed (no clone):
#!/usr/bin/env bash
set -euo pipefail
python3 - <<'PY'
import json
import urllib.request
def get(url):
req = urllib.request.Request(url, headers={"User-Agent": "review-verifier"})
with urllib.request.urlopen(req, timeout=20) as r:
return json.load(r)
repos = [
("home-operations/litellm-operator", "main"),
("BerriAI/litellm", "v1.95.0"),
]
for repo, ref in repos:
url = f"https://api.github.com/repos/{repo}/git/trees/{ref}?recursive=1"
data = get(url)
print(f"--- {repo}@{ref} ---")
for item in data.get("tree", []):
path = item.get("path", "")
if any(term in path.lower() for term in ("litellmmodel", "model_controller", "model_info", "token_counter", "proxy_server", "model_management")):
print(path)
PY
Length of output: 2445
🏁 Script executed (no clone):
#!/usr/bin/env bash
set -euo pipefail
python3 - <<'PY'
import json
import re
import urllib.request
def fetch(url):
req = urllib.request.Request(url, headers={"User-Agent": "review-verifier"})
with urllib.request.urlopen(url, timeout=20) as r:
return r.read().decode()
# Search the pinned LiteLLM source archive without executing repository code.
url = "https://github.com/BerriAI/litellm/archive/refs/tags/v1.95.0.tar.gz"
import io, tarfile
raw = urllib.request.urlopen(urllib.request.Request(url, headers={"User-Agent": "review-verifier"}), timeout=60).read()
with tarfile.open(fileobj=io.BytesIO(raw), mode="r:gz") as tf:
print("--- LiteLLM v1.95.0 token-limit source matches ---")
for member in tf.getmembers():
if not member.isfile() or not member.name.endswith((".py", ".md", ".yaml", ".yml")):
continue
text = tf.extractfile(member).read().decode("utf-8", "replace")
if re.search(r"max[_A-Za-z]*input[_A-Za-z]*tokens|max[_A-Za-z]*output[_A-Za-z]*tokens", text, re.I):
hits = []
lines = text.splitlines()
for i, line in enumerate(lines):
if re.search(r"max[_A-Za-z]*input[_A-Za-z]*tokens|max[_A-Za-z]*output[_A-Za-z]*tokens", line, re.I):
lo, hi = max(0, i-3), min(len(lines), i+4)
hits.append((lo+1, hi, lines[lo:hi]))
if hits:
print(f"FILE: {member.name}")
for lo, hi, block in hits[:12]:
print(f"LINES {lo}-{hi}")
print("\n".join(block))
PY
Length of output: 2412
🏁 Script executed (no clone):
#!/usr/bin/env bash
set -euo pipefail
python3 - <<'PY'
import json
import urllib.request
def fetch_json(url):
req = urllib.request.Request(url, headers={"User-Agent": "review-verifier"})
with urllib.request.urlopen(url, timeout=20) as r:
return json.load(r)
repo = "home-operations/litellm-operator"
for ref in ("0.0.9", "main"):
try:
data = fetch_json(f"https://api.github.com/repos/{repo}/git/trees/{ref}?recursive=1")
except Exception as exc:
print(f"{ref}: {exc}")
continue
print(f"--- {repo}@{ref} candidate source files ---")
for item in data.get("tree", []):
path = item.get("path", "")
if path.endswith((".go", ".yaml", ".yml", ".md")) and any(
term in path.lower() for term in ("model", "crd", "controller", "litellm")
):
print(path)
PY
Length of output: 408
🏁 Script executed (no clone):
#!/usr/bin/env bash
set -euo pipefail
python3 - <<'PY'
import io, json, re, tarfile, urllib.request
def request(url):
return urllib.request.urlopen(
urllib.request.Request(url, headers={"User-Agent": "review-verifier"}),
timeout=60,
)
for repo, ref in [
("home-operations/litellm-operator", "main"),
("BerriAI/litellm", "v1.95.0"),
]:
data = json.load(request(f"https://api.github.com/repos/{repo}/git/trees/{ref}?recursive=1"))
print(f"--- {repo}@{ref} ---")
for item in data.get("tree", []):
path = item.get("path", "")
if any(x in path.lower() for x in ("litellmmodel", "model_info", "token_counter", "model_management")):
print(path)
raw = request("https://github.com/BerriAI/litellm/archive/refs/tags/v1.95.0.tar.gz").read()
with tarfile.open(fileobj=io.BytesIO(raw), mode="r:gz") as archive:
print("--- LiteLLM v1.95.0 token-limit matches ---")
for member in archive.getmembers():
if not member.isfile() or not member.name.endswith(".py"):
continue
text = archive.extractfile(member).read().decode("utf-8", "replace")
if re.search(r"max[_A-Za-z]*input[_A-Za-z]*tokens|max[_A-Za-z]*output[_A-Za-z]*tokens", text, re.I):
for i, line in enumerate(text.splitlines()):
if re.search(r"max[_A-Za-z]*input[_A-Za-z]*tokens|max[_A-Za-z]*output[_A-Za-z]*tokens", line, re.I):
print(f"{member.name}:{i + 1}:{line.strip()}")
PY
Length of output: 2449
Reserve output tokens from the total context window.
LiteLLM treats maxInputTokens and maxOutputTokens as separate limits. If big-pickle has a 200,000-token total context window, set maxInputTokens to 191808 or document that 200,000 is input-only.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@kubernetes/apps/ai/litellm/instance/models.yaml` around lines 81 - 82, Update
the big-pickle model configuration so maxInputTokens reserves the 8192
maxOutputTokens from the 200000-token context window, setting it to 191808;
alternatively, explicitly document that 200000 applies to input tokens only.
Reverts the big-pickle pin per feedback — auto's live per-request scoring across all connected providers is preferred over pinning a single undocumented free model. That also resolves CodeRabbit's maxInputTokens/maxOutputTokens concern (auto has no fixed context window to declare).
|
@coderabbitai review |
✅ Action performedReview finished.
|
Underlying finding resolved in 4de58d7 (reverted the big-pickle pin, so the maxInputTokens/maxOutputTokens double-counting no longer applies). CodeRabbit's incremental re-scan on that commit passed clean.
1 participant
Summary
agent-pr-review.yamlatomniroute(wasqwen-3.6-fast) — several free models routed through omniroute (Kimi/GLM/DeepSeek-class, via opencode) outclass the self-hosted 27B on review quality.omniroutestays onopenai/auto(OmniRoute's live per-request scoring across all connected providers) rather than pinning a single model.routerSettings.fallbacks: [{omniroute: [qwen-3.6-fast]}]in litellm so a flaky free provider automatically falls back to the self-hosted model instead of failing the run.Test plan
kustomize build kubernetes/apps/ai/litellm/instance— builds clean, fallback presentSummary by CodeRabbit