AI Providers

Every Assistant (internally an Agent) in RondoFlow runs on a provider — the backend that actually executes its prompts. You choose a provider and a model per Assistant, so a single Workspace (internally a Canvas) can mix a local Claude Code Assistant, a fast OpenAI Assistant, and a web-searching Perplexity Assistant in the same workflow.

RondoFlow ships with three Assistant providers and one transform node:

• Claude Code (default) — spawns (starts) the Claude Code CLI as a child process and streams its structured events.
• OpenAI — talks to the OpenAI Responses API directly.
• Perplexity — talks to the Sonar API (OpenAI-compatible chat completions).
• Sakana AI node — calls Sakana AI chat completions inside a workflow step.

The provider id is stored on each Assistant. An unset or unknown provider falls back to claude-code, so existing Assistants keep their original behavior.

How a provider is chosen

You pick an Assistant provider by which palette card (Card = Node) you drag onto the Workspace — there is one card per Assistant provider:

The Assistant provider is fixed at creation time. The Assistant editor (the drawer that opens when you click a Card) derives the provider from the existing Assistant and shows it read-only — you can change the model and tool toggles there, but not the provider itself. To switch providers, create a new Assistant from the matching palette card.

Two values on each Assistant drive execution:

• provider — one of claude-code, openai, or perplexity.
• providerConfig — a small JSON object (model id + tool toggles) that applies only to API providers. Claude Code does not use it.

export type AgentProviderId = 'claude-code' | 'openai' | 'perplexity'
export const DEFAULT_AGENT_PROVIDER: AgentProviderId = 'claude-code'

When you drag an API-provider card or edit one of these Assistants, RondoFlow fills in a default providerConfig for that provider (see Per-Assistant configuration below).

Credentials

Where the credential comes from depends on the provider.

For Claude Code, the setup-token (CLAUDE_CODE_OAUTH_TOKEN, from claude setup-token) wins when both are set, and only the winning credential is forwarded to the CLI.

For the API providers, the runner resolves the key from the forwarded environment at run time (the per-run env first, then process.env). If the key is missing, the Assistant fails fast with a clear message rather than starting a request:

OPENAI_API_KEY is not configured. Add it in Settings → Credentials (OpenAI access).
PERPLEXITY_API_KEY is not configured. Add it in Settings → Credentials (Perplexity access).

Comparison

Per-Assistant configuration

API providers share a single config shape, stored in the Assistant’s providerConfig JSON column:

export interface ProviderConfig {
  readonly model: string          // chat model id (ignored when deepResearch is on)
  readonly webSearch: boolean
  readonly deepResearch: boolean
  readonly deepResearchModel?: string // optional explicit deep-research override
}

• model — the model id sent to the provider. Claude Code ignores this; it uses the CLI’s model selection.
• webSearch — adds the web-search tool (OpenAI only). Ignored by providers whose model always searches, such as Perplexity Sonar.
• deepResearch — auto-switches the request to the provider’s dedicated deep-research model. For OpenAI it also forces web search on. Deep-research runs are agentic and slow, so the runner uses a wide 30-minute client timeout (vs. 10 minutes for regular chat).

Models

The model catalogs are curated lists shown in the Assistant editor; the stored value is the raw model id, so the lists can grow without code changes elsewhere.

OpenAI (default gpt-5-mini):

Deep-research models (selected automatically when deepResearch is on; default o4-mini-deep-research-2025-06-26): o4-mini-deep-research-2025-06-26 (fast) and o3-deep-research-2025-06-26 (thorough).

Perplexity (default sonar):

When deepResearch is on, Perplexity uses sonar-deep-research. Sonar’s base URL is https://api.perplexity.ai.

Sakana AI node (default sakana-chat):

The Sakana AI node uses these as quick presets in the node drawer and still allows any custom model id.

A cross-engine verification pattern

Because the provider is per-Assistant, a common pattern is cross-checking one engine’s output with another: have a Claude Code Assistant do the main work, then route its result to an OpenAI or Perplexity Assistant that reviews or fact-checks it. RondoFlow ships ready-made Workspace presets for exactly this:

• OpenAI Cross-Check — an OpenAI Assistant on gpt-4.1 with web search on.
• Perplexity Cross-Check — a Perplexity Assistant on sonar-pro (Sonar always searches).

Drop one of these in alongside your Claude Code Assistant to get a second opinion from a different model family on the same task.

The shared runner abstraction

The chain executor and process manager don’t care how an Assistant runs — only that its runner exposes a common event contract: text, tool_use, tool_result, usage, completion, and error, plus spawn / sendMessage / kill and the pid / isRunning liveness signals the watchdog reads.

A single factory picks the runner from the provider id:

export function createAgentRunner(provider: AgentProviderId | undefined): AgentRunner {
  switch (provider) {
    case 'openai':
      return new OpenAIRunner()
    case 'perplexity':
      return new PerplexityRunner()
    case 'claude-code':
    default:
      return new ClaudeCodeSpawner()
  }
}

• Claude Code uses ClaudeCodeSpawner, which already satisfies the runner surface by spawning the CLI.
• OpenAI and Perplexity both extend StreamingApiRunner, a base class that owns the shared lifecycle: resolve the API key from the forwarded env, stream one request, map the provider’s stream onto the event contract, estimate token cost, and abort cleanly on kill(). Each subclass implements only runStream (the provider-specific HTTP call and event mapping) and declares its key env var.

Because every runner emits the same events, web search shows up the same way in the UI for all providers — for example, the Perplexity runner emits a synthetic web_search tool_use / tool_result pair so a Sonar search renders like any other search. Token usage events also carry a coarse cost estimate computed from a per-model rate table (the APIs don’t return a dollar figure).

Provider pages

Related