Add maxTokens - #375
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Greptile Summary
This PR adds a new
max_tokensparameter to the prompt parameter classes in the test suite, specifically for versions 3 and 4 of the_PromptBasicParamsclasses. The change introduces a general token limit field alongside the existingmax_completion_tokensfield.The
max_tokensfield is defined as a requiredUnion[float, int]with a camelCase alias "maxTokens", following the same pattern as other parameters in these classes. This addition appears to be testing the prompt system's ability to handle different token limit configurations that may be required by various LLM APIs.The change is isolated to the test infrastructure (
tests/e2e/prompts_v2/apps/ci_app/prompts.py) and only affects the newer parameter schema versions (3 and 4), while leaving the older versions (1 and 2) unchanged. This suggests a deliberate design decision to support backward compatibility while extending functionality for newer prompt configurations.The implementation follows established conventions in the codebase - using Pydantic field definitions with proper type hints, required field markers (
...), and camelCase aliases that likely match the expected API format. This change enables testing scenarios where both general token limits and completion-specific token limits need to be supported simultaneously.Confidence score: 5/5
• This PR is very safe to merge as it only adds test parameters without affecting production code
• The implementation follows existing patterns perfectly and is limited to test infrastructure
• No files need additional attention - the change is straightforward and well-contained