Cap gateway vision preprocessing output

[HOYALIM]

Problem

Fixes #10809. The gateway's automatic image preprocessing asks for a detailed description and uses the vision tool's 2000 token default, which can produce large intermediate context before the user's actual model call.

Solution

Add an internal per-call max_tokens override to vision_analyze_tool and use a concise 2-4 sentence prompt with a 500 token cap only for the gateway auto-preprocessing path. The public tool schema and default 2000 token behavior remain unchanged.

Impact

Caps gateway auto-preprocessing output at 500 tokens instead of 2000, a 75% lower ceiling for this intermediate vision context.

Validation

• PYTHONDONTWRITEBYTECODE=1 /Users/holim/code/hermes-agent/.venv/bin/python -m pytest tests/gateway/test_vision_memory_leak.py -q
• scripts/run_tests.sh tests/gateway/test_vision_memory_leak.py tests/tools/test_vision_tools.py -q
• /Users/holim/code/hermes-agent/.venv/bin/ruff check gateway/run.py tools/vision_tools.py tests/gateway/test_vision_memory_leak.py tests/tools/test_vision_tools.py
• git diff --check

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[alt-glitch]

This was generated by AI during triage.

Duplicate of #10852 -- both cap the gateway auto image-preprocess path at max_tokens=500 with a concise prompt (leaving the public vision-tool default of 2000 unchanged) to fix #10809's latency/context bloat. #10852 is the earliest open PR. Cross-linking for the maintainer to pick.

[tonydwb]

Code Review Summary

Verdict: Comment (prior automated review noted)

This PR has a prior automated COMMENT review. No new issues found.

Looks Good

• Caps gateway vision preprocessing output — appropriate bounds check
• No security concerns

[teknium1]

Thanks for narrowing the change to gateway auto-preprocessing and preserving the public vision_analyze schema.

Problems

• gateway/run.py:15045 passes max_tokens=500, but this does not cap the affected common path today. vision_analyze_tool calls async_call_llm; agent/auxiliary_client.py:7120-7124 forwards the value into _build_call_kwargs, and agent/auxiliary_client.py:6222-6254 deliberately omits max_tokens for ordinary OpenAI-compatible/custom providers. The issue's reported llama-server custom-provider path therefore still receives no 500-token wire cap.
• The new test in tests/tools/test_vision_tools.py mocks async_call_llm, so it verifies only that the wrapper receives 500, not that the provider request carries it. Existing tests/agent/test_auxiliary_client.py:278-331 covers the intentional omission behavior.

Suggested changes

• Preserve the concise prompt, then add a narrowly scoped, provider-compatible forced-cap path through agent/auxiliary_client.py rather than relying on the current general auxiliary argument plumbing.
• Test the underlying async client's request kwargs for the target custom/OpenAI-compatible route.

Automated hermes-sweeper review.

[teknium1]

vision_analyze_tool receives this value, but async_call_llm currently drops max_tokens for ordinary OpenAI-compatible/custom routes in agent/auxiliary_client.py:_build_call_kwargs (the llama-server-style route from #10809). Please carry this through a deliberately compatible capped-call path and test the underlying client request, not only the async_call_llm mock.