Feature request: support Anthropic-protocol (/messages) vision providers (e.g. OpenCode Go qwen3.7-plus)

[EliteOtaku]

Problem

dsh-vision-toolkit (and upstream vision_client.py) hard-requires an OpenAI-compatible endpoint: it POSTs {baseUrl}/chat/completions with image_url content blocks. But some subscriptions expose their best vision models only on the Anthropic protocol:

• OpenCode Go ($10/mo) serves Qwen3.7 Plus / Qwen3.7 Max / Qwen3.8 Max / MiniMax M3·M2.7·M2.5 exclusively at https://opencode.ai/zen/go/v1/messages (Anthropic Messages format), while the cheaper vision models on /chat/completions (glm-5.1 etc.) are ~3.5× more expensive per token.
• Concretely: qwen3.7-plus ≈ 21,600 requests/month within Go's included quota vs ~4,300 for glm-5.1. That's a big deal for vision-heavy workflows (UI restoration, chart/screenshot analysis) running on text-only DeepSeek agents — exactly this project's target use case.

Verified facts (2026-08-14, live calls against OpenCode Go)

• POST /v1/messages with Authorization: Bearer <key> → 401; with x-api-key: <key> (+ anthropic-version: 2023-06-01) → 200.
• qwen3.7-plus accepts image blocks (source: {type: base64, media_type, data}) and returns content that may include type: "thinking" blocks in addition to text blocks.
• Sending thinking: {type: "disabled"} in the body is accepted and cuts latency/cost.

Proposal

Add an optional provider.protocol (openai | anthropic) setting, in both dsh-vision-toolkit's config schema and upstream vision_client.py:

• anthropic mode: POST {baseUrl}/messages with x-api-key + anthropic-version headers; map text → {type:text}, image_url (data URL or http) → {type:image, source:{type:base64,...}}; system role → top-level system; optional thinking:{type:disabled}; parse response by joining text blocks only (ignore thinking), map usage tokens.
• Keep openai as default so nothing breaks.

Current workaround (working today)

A ~150-line local protocol-translation gateway (OpenAI /chat/completions ⇄ Go /messages) running at 127.0.0.1, pointed to by provider.baseUrl. Text + real-image calls against qwen3.7-plus both verified (200). Reference implementation: https://gist.github.com/EliteOtaku/4e55d17ca4a70052243ea3ad9064440b

Native support would let users drop the extra long-running gateway process entirely — one less moving part. Happy to send a PR if this is in scope.

[Mooling0602]

Important finding (upstream diagnosis: Anionex/agent-vision-toolkit#19): qwen3.7-plus does work through the OpenAI-format POST https://opencode.ai/zen/go/v1/chat/completions (including image_url image blocks). The earlier conclusion that "OpenCode Go's Qwen3.7 Plus is served exclusively on /messages" may stem from the same phenomenon — Cloudflare blocks requests based on the User-Agent: vision_client.py uses urllib's default UA (Python-urllib/3.x), which gets HTTP 403 error code: 1010; the same request returns 200 with a browser/curl UA.

Verified locally (dsh-vision-toolkit v0.1.2):

• curl -A "Python-urllib/3.14" → 403/1010; default curl UA → 200; Python urllib + Chrome UA → 200.
• After patching the vendored vision_client.py (explicit Chrome UA header) and regenerating UPSTREAM_MANIFEST.json, vision_glance/vision_ground (qwen3.7-plus, OpenAI format) work end-to-end.

So the short-term fix for this bundle is a UA patch + manifest regeneration (no local gateway needed); provider.protocol Anthropic support remains a valuable feature (for other providers) and is worth keeping on the table.