kaxil opened a new pull request, #74312: URL: https://github.com/apache/airflow/pull/74312
`AgentOperator(code_mode=True)` did one thing: it appended a bare `CodeMode()` from pydantic-ai-harness to the agent's capabilities. Since `capabilities=` became a first-class argument (#73984), that is one line in the Dag file, so this removes the flag and documents the capability instead: ```python from pydantic_ai_harness import CodeMode AgentOperator(..., capabilities=[CodeMode(max_tool_calls=200)]) ``` The flag also hid every `CodeMode` argument, and one of them matters in practice. `max_tool_calls` caps the nested tool calls a single `run_code` snippet can make, and its default of 100 is low for an agent that fans out over a list. In a run that classified 167 issue comments (one listing call, 80 comment fetches, 167 classifier calls), `code_mode=True` hit the cap and the model had to split its work across snippets: 11 model requests and about 39k input tokens, against 7 requests and about 20k tokens with `CodeMode(max_tool_calls=400)`. A snippet that hits the cap also fails after the calls it already made, so their results are lost. Code mode is documented as experimental, so this is a removal rather than a deprecation. The changelog note covers the migration: replace `code_mode=True` with `capabilities=[CodeMode()]`, and move any `agent_params["capabilities"]` into `capabilities=` too, since the two cannot be combined. The `code-mode` extra's floor goes from `pydantic-ai-harness>=0.3.0` to `>=0.24.0`, the first release with `max_tool_calls`; the docs and example now use it, and `uv.lock` already resolves 0.34.0. Two things change for users beyond the argument: - **The harness is imported when the Dag file is parsed**, not when the task runs, so the `code-mode` extra is needed wherever Dag files are parsed. The old flag existed partly to avoid this. The import measured at about 0.02 s; `code_mode.rst` says so and suggests keeping code mode agents in their own Dag file. - **The docs said a tool that needs approval fails the task under code mode. That was wrong.** pydantic-ai-harness catches `ApprovalRequired` inside `run_code` and returns it to the model as a retry, so the gated call does not run and the task can still succeed. `code_mode.rst`, `tool_approval.rst` and the operator docstring now say that, and how to keep such a tool out of `run_code` with `CodeMode(tools=[...])`. The durable and tool-approval guards already recognised a `CodeMode` capability (including one nested in a `CombinedCapability` or `PrefixTools`), so they need no change; only the flag's branches go. --- * Read the **[Pull Request Guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#pull-request-guidelines)** for more information. Note: commit author/co-author name and email in commits become permanently public when merged. * For fundamental code changes, an Airflow Improvement Proposal ([AIP](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals)) is needed. * When adding dependency, check compliance with the [ASF 3rd Party License Policy](https://www.apache.org/legal/resolved.html#category-x). * For significant user-facing changes create newsfragment: `{pr_number}.significant.rst`, in [airflow-core/newsfragments](https://github.com/apache/airflow/tree/main/airflow-core/newsfragments). You can add this file in a follow-up commit after the PR is created so you know the PR number. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
