Skip to content

feat(ai): expand provider capabilities#500

Merged
Xoshbin merged 2 commits into
Xoshbin:mainfrom
AllDaGearNoIdea:feat/ai-provider-capabilities
Jul 14, 2026
Merged

feat(ai): expand provider capabilities#500
Xoshbin merged 2 commits into
Xoshbin:mainfrom
AllDaGearNoIdea:feat/ai-provider-capabilities

Conversation

@AllDaGearNoIdea

Copy link
Copy Markdown
Contributor

I finally got around to testing AI Agents.

The first thing I thought to do was ask what the next world cup matches were, and that revealed the openai one was using an older api endpoint, and didn't have web search capabilities.

Once I got that working, I had a play with different model response times, and realised there was no "effort" setting.

I've expanded the provider plugin capabilities:

  • OpenAI and Custom providers can use either Responses (default) or Chat Completions (old default). Existing configurations will use the old default unless changed.
  • OpenAI hosted web search can be enabled for OpenAI and compatible Custom endpoints. It works alongside function/MCP tools, shows a Searching… status, and gets a longer request timeout.
  • Reasoning effort is now an additional option for models. Naming abstracted into "Effort", but the API request format adapted to OpenAI, Anthropic, Gemini, OpenRouter, Ollama, and Custom endpoints. OpenAI and OpenRouter narrow the available levels by model.
  • The Responses streaming adapter handles text, hosted-search activity, function calls, errors, and the encrypted reasoning context required across tool-loop turns.
  • Provider validation now follows each plugin's actual requirements, keeping API keys optional for unsecured Custom endpoints while still requiring their base URL.

Additional:

  • I added agent system prompts to prime for scenarios (current date, web search if possible), hints about display size, and avoidances of tables being split visually.
  • Deleting a thread didn't remove it until navigated away from, that's fixed.
    markdown table words being
  • Diagnostics show the actual failure messages.
  • Vendored notification fix now uses the generic NSPort type.

Test:

  • Add a new OpenAI or Custom provider and confirm Responses is selected by default.
  • Switch between Responses and Chat Completions and confirm existing configurations retain Chat Completions.
  • Enable hosted web search and confirm "Searching…" appears when in progress.
  • Change models and confirm unsupported reasoning levels are cleared.
  • Confirm normal chat, function tools, and hosted search can be used together.

Tests came back green.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces comprehensive support for reasoning models and hosted web search across several AI providers (OpenAI, Anthropic, Google, Ollama, OpenRouter, and Custom). It implements the OpenAI Responses API format, adds a provider-neutral reasoning effort selector in the settings UI, and updates the agent loop to handle streaming status (e.g., "searching") and provider-specific reasoning context. Critical feedback was provided regarding invalid API parameters for Anthropic (output_config instead of thinking) and Gemini (thinkingLevel instead of thinkingBudget), missing support for actual OpenAI reasoning models (o1 and o3-mini) in the model family mapping, and a potential race condition/redundant fetch issue in the AgentChatView.svelte reactive effect.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

Comment thread asyar-launcher/src/services/ai/providers/anthropic.ts Outdated
Comment thread asyar-launcher/src/services/ai/providers/anthropic.ts Outdated
Comment thread asyar-launcher/src/services/ai/providers/openai.ts
Comment thread asyar-launcher/src/services/ai/providers/google.ts Outdated
Comment thread asyar-launcher/src/services/ai/providers/google.ts Outdated
Comment thread asyar-launcher/src/built-in-features/agents/AgentChatView.svelte Outdated
@dose-dot-dev

Copy link
Copy Markdown
Contributor

i was having issues using the AI features on windows via Ollama + gemma4. looking forward to testing again once this is merged!

@AllDaGearNoIdea

Copy link
Copy Markdown
Contributor Author

@dose-dot-dev thanks, would really appreciate some extra eyes on this, see if this works with your setup on windows for sure.

@AllDaGearNoIdea

Copy link
Copy Markdown
Contributor Author

@Xoshbin looking at this made me question the interface.

I think Raycast's Beta has a couple of things correct:
Screenshot 2026-07-13 at 21 35 58

Putting text entry at the bottom and having most of the window for content makes more sense.

I will make some design proposals.

@Xoshbin

Xoshbin commented Jul 13, 2026

Copy link
Copy Markdown
Owner

@Xoshbin looking at this made me question the interface.

I think Raycast's Beta has a couple of things correct: Screenshot 2026-07-13 at 21 35 58

Putting text entry at the bottom and having most of the window for content makes more sense.

I will make some design proposals.

Hey @AllDaGearNoIdea Thank your for the pr, first.
I'm aware of this change they made in beta since the first days of their release, Even thought I know you have a better eye than me regarding designs and ui. Since the first time I saw this, I don't see anything convincing me to move that path, the very first issue of this bottom text input that I don't like is the eye change, your main text input in the launcher is at the top most of the time but suddenly in the ai thread it changes to the bottom that makes your eye look for it. that is how I think about. but as you know I'm open for discussions, if you think it's convenient I'd love to hear your thoughts. Help convince me!.

Edit: I like the idea of giving the whole view to the conversation, but we need to push the archived or old threads somewhere else.

@Xoshbin Xoshbin merged commit 50b5b29 into Xoshbin:main Jul 14, 2026
1 check passed
Xoshbin pushed a commit that referenced this pull request Jul 14, 2026
ShellExecTool spawns an executable directly (Command::new(command).args),
with no implicit shell. The tests drove it with POSIX commands — `echo`,
`sh`, `ls` — which on Windows are cmd builtins with no .exe (`echo`, `ls`)
or absent entirely (`sh`), so the spawn failed and six tests errored once
#499 made the suite runnable on Windows.

Route the shell-dependent cases through the host shell (`cmd /C` on
Windows, `sh -c` elsewhere) via a SHELL constant, with per-platform
spellings where the syntax differs (`1>&2` vs `>&2`, `dir /B` vs `ls`).
The args-omitted case uses `hostname` — a real no-arg executable present
on all three platforms — so it still exercises the "args absent → runs"
path without a shell. No product change; ShellExecTool's direct-exec
contract is unchanged.

Clears the last of the 38 Windows failures surfaced by #499 (see #498).
Independent of #500, which only touches the frontend agents UI, not this
Rust tool.


Claude-Session: https://claude.ai/code/session_01MGJAx66y29o33szDvVYTBH

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants