After the end of Phase 5, only adaptation 1 of 9 from spec §6 was
applied (Screenshot button iff vision, render_files_and_media:3030).
The pattern is established; the remaining 8 are mechanical
applications of the same pattern at their respective render sites.
The follow-up track applies the wrapping at:
- tools toggle (tool_calling)
- cache panel (caching)
- stream progress (streaming)
- fetch models button (model_discovery)
- token budget max (context_window)
- cost panel (3 cost_tracking states: estimate / 'Free (local)' / '-')
The _get_active_capabilities() helper (t5.1) is already in place.
As of end of Phase 4, only _send_minimax has a working tool-call loop.
Phase 3 (Grok, Llama) and Phase 2 (Qwen) entry points are single-shot;
they call send_openai_compatible once and return without executing
tool_calls. If the user notices 'tool execution doesn't work for
Qwen/Grok/Llama' after Phase 5 ships, the fix is to lift the tool
loop into a shared run_with_tool_loop() helper that wraps
send_openai_compatible. The 4 existing vendors (_send_anthropic /
_send_gemini / _send_gemini_cli / _send_deepseek) already have the
same inline duplication, so the lift would also help those.
This is a follow-up track, not in scope for qwen_llama_grok_integration_20260606.
Grok's own recommendation (consulted 2026-06-11):
'xAI (Grok) | xAI official OpenAI-compatible (https://api.x.ai/v1) |
Fully compatible and clean. Supports Grok-2 + Grok-2-Vision. No
meaningful unique native surface lost by using the compatible
endpoint.'
This REVERSES the earlier 'xAI native' correction. The OpenAI-
compatible approach for Grok is the canonical full-featured path;
the implementation in Phase 3 (OpenAI SDK with base_url=https://api.x.ai/v1
+ send_openai_compatible helper) is correct as-is.
Updates to the spec:
1. §3.1.1: replaced the 'use xAI native' decision with the confirmed
per-vendor table. Qwen=Native, Grok=OpenAI-Compatible (per Grok's
own confirmation), MiniMax=OpenAI-Compatible, DeepSeek=OpenAI-
Compatible, Ollama=OpenAI-Compatible-in-v1 (native in v2),
Meta Llama API=Native (new 4th backend, follow-up), Gemini=Native
(follow-up), Anthropic=Native (follow-up). Also added Grok's
recommended v2 matrix field expansion: audio, video, grounding,
computer_use, local, reasoning/extended_thinking, web_search,
x_search, code_execution, file_search, mcp_support, structured_output.
2. §4.3: reverted from 'Grok via xAI (Native REST API)' back to
'Grok via xAI (OpenAI-Compatible) - confirmed 2026-06-11'. The
implementation does NOT need a native refactor; the OpenAI SDK
at https://api.x.ai/v1 is the canonical approach. Removed the
earlier 'caching: true' entry from the registry (since the
OpenAI-compat shim doesn't expose prompt_cache_key) and the
'no persistent client' state struct (back to the OpenAI SDK
pattern).
3. §13.1.B: renamed from 'Native Vendor APIs' to 'Llama Native APIs
(Ollama native + Meta Llama API)' and removed the Grok native
refactor item (Grok says OpenAI-compat is fine). Kept the Ollama
native + Meta Llama API items + matrix expansion. Clarified that
Grok tests do NOT need rewriting; only Llama tests get 2 more
(native Ollama, Meta Llama API).
Net effect: the Phase 3 work that just shipped (Grok+Llama Green
using OpenAI-compat shim) is CORRECT as-is. The implementation
matches Grok's actual recommendation. No code rollback needed.
Three additions to the spec, per the user's architectural correction
in this session:
1. NEW section 3.1.1: 'Architectural principle: Use the best API per
vendor' — explains why the OpenAI-compatible shim loses vendor-
specific features (xAI: prompt_cache_key, reasoning_effort, server-
side tools, cost_in_usd_ticks; Ollama: think param, images array,
thinking field, structured outputs) and states the principle:
'use each vendor's native SDK or REST API when one exists, falling
back to OpenAI-compatible only when no native option exists.'
Also notes that the capability matrix IS the aggregate tracker;
future native features go into the matrix, and the GUI filters
based on it (no per-vendor UI branches).
2. UPDATED section 4.3 (Grok): 'Grok via xAI (Native REST API)' — was
'OpenAI-Compatible'. Now specifies two native endpoints
(/v1/chat/completions and /v1/responses), the native features that
matter, the updated capability registry (caching=true for Grok
via prompt_cache_key), and a 'Phase 3 placeholder behavior' note
that this track's Phase 3 ships the OpenAI-compatible Grok as a
placeholder. The native refactor is deferred to follow-up B.
3. UPDATED section 13.1: added follow-up track B 'Native Vendor APIs
(post-OpenAI-compatible-placeholder)' which documents:
- Grok → xAI native REST
- Llama (Ollama) → native /api/chat
- Llama (Meta Llama API) → new 4th backend (deferred pending
verification of Meta's API spec; llama.developer.meta.com/docs/overview
returned 400 on fetch this session)
- Capability matrix expansion (web_search, x_search, code_execution,
file_search, mcp_support, reasoning_effort, structured_output)
- Test rewrites (mock requests.post instead of chat.completions.create)
This is a docs-only commit; no code changes. The Phase 3 Green work
continues with the OpenAI-compatible approach as planned in the
existing Red tests (t3.3 Grok + t3.14 Llama), and the follow-up track
B handles the native refactor when prioritized.
4 surgical additions to the spec, no task changes:
1. Result return type: Added a coordination note in §3.1 (Data-
Oriented Design) explaining that the shared send_openai_compatible
helper should return Result[NormalizedResponse, ErrorInfo] from
day 1, not NormalizedResponse + ProviderError raise. This is so
the downstream data_oriented_error_handling_20260606 track is
a small mechanical pass over new code, not a second migration.
References nagent_review Pitfall #4 (provider history divergence)
and the ErrorKind.PROVIDER_HISTORY_DIVERGED_FROM_UI use case.
2. Declarative read, not behavioral dispatch: Added clarification
to §6 (UX Adaptation) that the capability matrix is a *read* of
declarative data, not a new dispatch layer. Per nagent_review
Pitfall #1 (opaque function calling in the Application is the
correct choice; nagent-style protocol is for Meta-Tooling),
UI elements are visible/enabled/disabled/hidden but the
*behavior* they invoke is unchanged. Three concrete examples
added: screenshot button, cost panel, cache panel.
3. PROVIDERS source of truth: Added a NOTE in §3.2 (Module Layout)
that src/models.py:79-86 PROVIDERS is the existing single
source of truth for the (vendor, model) enumeration. The
capability registry reads from this constant rather than
introducing a parallel list. Cross-references
docs/guide_models.md.
4. Docs touchpoint: Expanded Phase 6 (Docs + Archive) in §9 to
note that docs/guide_ai_client.md needs the new providers +
the shared helper documented, and that
docs/guide_context_aggregation.md (added 2026-06-08) is the
reference for the aggregate.py pipeline that all new providers
use.
5. See Also cross-references: Added 3 new entries to §13.2:
- docs/guide_context_aggregation.md (the new pipeline guide)
- conductor/tracks/nagent_review_20260608/report.md (§1, §5, §15)
- conductor/tracks/nagent_review_20260608/nagent_takeaways_20260608.md
(§1, §2, §9)
No plan.md changes. Plan tasks are task-level and will flow from
the spec changes when the track is re-planned.
The capability matrix v1 has no 'audio' field (audio_input is deferred to v2).
Qwen-Audio's vision flag was incorrectly marked true. Changed to false and
clarified that v1 uses Qwen-Audio as text-only; audio attachment UI is
hidden via the absent audio capability check.
ed
conductor-tier2