This removes mypy errors in the following files.
ai_gateway/api/middleware/base.pyai_gateway/code_suggestions/processing/ops.pyai_gateway/instrumentators/model_requests.pyai_gateway/integrations/amazon_q/test_chat.py$ make check-mypy
--snip--
ai_gateway/code_suggestions/processing/ops.py:312: error: Argument 1 to "map" has incompatible type "type[tuple[_T_co, ...]]"; expected "Callable[[ndarray[tuple[Any, ...], dtype[signedinteger[_32Bit | _64Bit]]]], ndarray[tuple[Any, ...], dtype[signedinteger[_32Bit | _64Bit]]]]" [arg-type]
ai_gateway/code_suggestions/processing/ops.py:314: error: Incompatible return value type (got "list[ndarray[tuple[Any, ...], dtype[signedinteger[_32Bit | _64Bit]]]]", expected "list[tuple[Any, ...]]") [return-value]
ai_gateway/api/middleware/base.py:80: error: Argument 1 to "float" has incompatible type "str | None"; expected "str | Buffer | SupportsFloat | SupportsIndex" [arg-type]
ai_gateway/api/middleware/base.py:111: error: Incompatible types in assignment (expression has type "Any | BaseExceptionGroup[Any]", variable has type "Exception") [assignment]
ai_gateway/api/middleware/base.py:120: error: Argument 1 to "get_path_with_query_string" has incompatible type "MutableMapping[str, Any]"; expected "HTTPScope | WebSocketScope" [arg-type]
ai_gateway/api/middleware/base.py:121: error: Item "None" of "Address | None" has no attribute "host" [union-attr]
ai_gateway/api/middleware/base.py:122: error: Item "None" of "Address | None" has no attribute "port" [union-attr]
ai_gateway/instrumentators/model_requests.py:165: error: Incompatible types in assignment (expression has type "float", variable has type "None") [assignment]
ai_gateway/instrumentators/model_requests.py:278: error: Unsupported operand types for - ("float" and "None") [operator]
ai_gateway/integrations/amazon_q/test_chat.py:140: error: Need type annotation for "event" [var-annotated]
ai_gateway/integrations/amazon_q/test_chat.py:253: error: Missing named argument "shape" for "ReferenceSpan" [call-arg]
ai_gateway/integrations/amazon_q/test_chat.py:346: error: Argument after ** must be a mapping, not "Collection[str]" [arg-type]
ai_gateway/integrations/amazon_q/test_chat.py:381: error: Dict entry 0 has incompatible type "str": "str"; expected "str": "dict[str, str]" [dict-item]
ai_gateway/integrations/amazon_q/test_chat.py:382: error: Dict entry 1 has incompatible type "str": "str"; expected "str": "dict[str, str]" [dict-item]
ai_gateway/integrations/amazon_q/test_chat.py:383: error: Dict entry 2 has incompatible type "str": "str"; expected "str": "dict[str, str]" [dict-item]
ai_gateway/integrations/amazon_q/test_chat.py:384: error: Dict entry 3 has incompatible type "str": "str"; expected "str": "dict[str, str]" [dict-item]
Found 16 errors in 4 files (checked 927 source files)
make: *** [Makefile:226: check-mypy] Error 1
Numbered steps to set up and validate the change are strongly suggested.
@Joey_Khabie I think this could be rewritten like we did for ai_gateway/prompts/registry.py to use a single structure to keep the mapping, see !4650 (comment 3109049115)
@mikolaj_wawrzyniak thanks! Great feedback. Addressed,
Good point. Changed.
Updated
Alejandro Rodríguez (12e9dfd3) at 17 Mar 15:07
refactor: use plain strings for the HumanInput component
For a retrospective discussion, what could we do to prevent this in the future? In https://gitlab.com/gitlab-com/gl-security/corp/issue-tracker/-/work_items/4152 I see the project was considered for deletion because it was from a sandbox account co-created from an offboarded team member. What process was followed to establish this project was unused, and how can the AI Framework team communicate which projects it depends on? In this thread we proposed previously to move developers to dev-ai-research-0e2f8974 instead, but from the name it seems this one is also a sandbox one, so not sure it's susceptible to the same situation. We also have gitlab-ai-framework-dev, which is not a sandbox project and is managed as IaC. Would that be the preferable option?
/cc @vlad @ajaythomasinc
@tmrrss we restored ai-enablement-dev-69497ba7 (thanks @vlad @rnienaber!), you should be able to go back.
This change adds a new "context management" feature that helps AI models handle long conversations more efficiently by automatically removing old tool usage data when the conversation gets too long.
The feature is specifically designed for Anthropic AI models and includes smart filtering - it only applies context management to Anthropic models and removes the setting for other AI providers that don't support it.
Three new workflow configurations are added (context_builder, executor, and planner) that each have different thresholds for when to start clearing old data - for example, one starts clearing when the conversation reaches 4000 input tokens and keeps only the 2 most recent tool uses.
The system includes comprehensive testing to verify that context management actually reduces the number of input tokens being processed, which should improve performance and reduce costs for long conversations. The tests simulate conversations with multiple tool interactions and confirm that enabling context management results in fewer tokens being sent to the AI model compared to keeping the full conversation history.
Context editing allows you to automatically manage conversation context as it grows, helping you optimize costs and stay within context window limits.
The clear_tool_uses_20250919 strategy, When activated, the API automatically clears the oldest tool results in chronological order, replacing them with placeholder text to let Claude know the tool result was removed.
More information here: https://platform.claude.com/docs/en/build-with-claude/context-editing
closes #1543
Instructions and test results see below: !3969 (comment 2912060215)
@mikolaj_wawrzyniak would you mind reviewing this MR? Related to #1429 (comment 3088609076)
@GitLabDuo it appears this is not the case:
>>> from ai_gateway.prompts import jinja2_formatter
>>> jinja2_formatter("{{x}} {{y}}", x=1)
'1 '
@GitLabDuo the suppression is not needed, and the linter is complaining if we leave the comment.
Opened !4904 for this.
Unrelated to this MR, but the linter was complaining that this suppression is not needed.
refactor: use plain strings for the HumanInput component
This is a currently unused component, but it currently relies on
extracting the jinja template from the Prompt object, which is
an ability we'll remove in
#1429
Numbered steps to set up and validate the change are strongly suggested.
Alejandro Rodríguez (ffaad031) at 16 Mar 23:16
refactor: use plain strings for the HumanInput component
@halilcoban would you mind reviewing this MR? See #1429 (comment 3082788576) for more context.
This is a valid concern, but one that already existed in the code, so keeping the old behavior for now in this MR.
@GitLabDuo then we'll re-add it if/when needed.
@GitLabDuo self.prompt.name is always equal to self.name (or it should always be. It actually doesn't make sense in the current code that we get the name from the prompt, because the prompt file name is supposed to be human readable and may vary by model/provider), and "conversation_history": {self.name: [model_completion]} does NOT drop the history, we have a conversation_history reducer that makes state updates to it an append operation, see https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/blob/316c251a5ec73bd296fab3591d4f240d0e12916b/duo_workflow_service/entities/state.py#L132-156