* fix: align max_tokens with max_output_tokens for consistency
Fixed inconsistent max_tokens definitions in model_prices_and_context_window.json.
According to LiteLLM convention, max_tokens should equal max_output_tokens when available.
Models fixed:
- deepseek-chat: 131072 → 8192 (now equals max_output_tokens)
- dashscope/qwen-flash: 1000000 → 32768 (now equals max_output_tokens)
- databricks/databricks-gemma-3-12b: 128000 → 32000 (now equals max_output_tokens)
This ensures consistency across all providers where max_tokens represents
the maximum number of tokens that can be generated in the output.
* fix(workflow): Update issue labeling with working regex pattern
- Replace contains() with regex pattern using \s* for flexible whitespace matching
- Consolidate 4 separate steps into single unified component labeling step
- Tested and verified pattern works for all components: SDK, Proxy, UI Dashboard, Docs
- Pattern handles GitHub's issue body formatting with ### headers and variable newlines
* Fix component label automation to prevent false positives
The GitHub Actions workflow was applying component labels (SDK, Proxy, UI Dashboard, Docs) too broadly by only checking if the component name appeared anywhere in the issue body. This caused issues to be mislabeled when users mentioned these terms in their descriptions.
Changes:
- Add more specific condition that checks for both the dropdown field header "What part of LiteLLM is this about?" AND the component name
- Applied to all 4 component labels: SDK, Proxy, UI Dashboard, and Docs
- Labels will now only be applied when users actually select the option from the dropdown
Fixes issues being incorrectly labeled with 'docs' and other component labels.
* Use more specific pattern to match dropdown selection exactly
Updated the label conditions to use a more precise pattern that matches
the dropdown header immediately followed by the selected value. This
prevents false positives when users mention component names in their
descriptions but select a different component.
Before: Checked for header AND component name anywhere in body
After: Checks for exact pattern "header\n\ncomponent"
This ensures labels are only applied when the component is actually
selected from the dropdown, not just mentioned in the issue text.
* Fix component label automation and require explicit user selection
This PR fixes two issues with component labeling:
1. **Improved label accuracy**: Updated the workflow to use exact pattern
matching ("### What part of LiteLLM is this about?\n\nDocs") instead of
broad substring matching. This prevents false positives where issues were
mislabeled when users mentioned component names in their descriptions.
2. **Require explicit component selection**: Added empty string ('') as the
first dropdown option to prevent GitHub from auto-selecting "SDK" as the
default. Users must now consciously select which component their issue
relates to.
Changes:
- Updated all component label conditions in label-component.yml workflow
- Added empty string as first option in bug_report.yml dropdown
- Added empty string as first option in feature_request.yml dropdown
- Labels only apply when users actually select a component from the dropdown
This ensures accurate labeling and prevents the default SDK label from
being applied to all new issues.
- Replace "ML Ops Team" dropdown with "What part of LiteLLM is this about?"
with options: SDK, Proxy, UI Dashboard, Docs, Other
- Add component dropdown to feature_request.yml template
- Rename label-mlops.yml to label-component.yml and update to auto-label
issues with sdk, proxy, ui-dashboard, or docs based on selection
- Add more provider keywords to issue-keyword-labeler: gemini, cohere,
mistral, groq, ollama, deepseek
Yuneng Jiang