AI

The AI node runs a model inside your workflow. It sits between the data you pull and the action you take: read a Jupiter quote and decide whether to swap, judge how close a Kamino position is to liquidation, score trending tokens before a Phoenix limit order. It can also do the plain work, classifying results, writing messages, turning messy text into JSON, or generating an image for another node.

There is no separate OpenAI node anymore. Every provider runs through this one AI node:

• Log in with ChatGPT to use your ChatGPT account.
• Log in with Grok to use your Grok account.
• Use OpenRouter and pick any model ID, such as openai/gpt-5-mini.
• Use Venice AI for private inference through Venice models.

For normal text output, downstream nodes read the reply as {aiResponse.data}. For image output, downstream nodes read {aiResponse.imageUrl}.

Providers

Pick whichever fits your workflow. You can add credentials for more than one provider and switch per-node.

Quick start

1. Add one AI credential:
   • Log in with ChatGPT from the AI node or Connections.
   • Log in with Grok from the AI node or Connections.
   • Add an OpenRouter key under Credentials.
   • Add a Venice AI key under Credentials.
2. Drop an AI node onto the canvas. In the config dialog, pick your credential.
3. Choose a model from the live dropdown (or type any model ID).
4. Write a prompt, e.g. Given this quote, is the slippage acceptable? Answer yes or no: {json jupiterResponse.data}.
5. Wire the next node to read {aiResponse.data}.

That's the whole loop. Everything below is detail for when you need it.

Prerequisites

• One AI credential:
  • ChatGPT: log in with ChatGPT from the AI node or Connections. No API key is needed, but the session can expire and require reconnecting.
  • Grok: log in with Grok from the AI node or Connections. No API key is needed, but the session can expire and require reconnecting. See Grok Integration.
  • OpenRouter: openrouter.ai/keys
  • Venice AI: venice.ai/settings/api. Add any USD balance to your Venice account first; Venice keys stay inactive on a $0 balance and will fail at runtime. See the Venice AI setup walkthrough for the exact steps.
• Add API keys as credentials in Credentials.

Operations

Input modes

Configuration

Select a credential first to load the live model list. The list is fetched directly from the active provider, so it reflects what your key, ChatGPT account, or Grok account can use.

Switching credentials across providers clears the saved model. OpenRouter IDs (e.g. openai/gpt-5-mini), Venice IDs (e.g. llama-3.2-3b), ChatGPT IDs, and Grok IDs (e.g. grok-4.5) use different formats, so the node prompts you to pick again rather than send a mismatched pair to the provider.

The user prompt is hard-capped at 200,000 characters. Anything longer is truncated with a marker ([Prompt truncated by Solaris to stay within model context limits]) before the call goes out.

Model IDs by provider

You can type a custom ID in either case. The runtime forwards it unchanged to the active provider, so typos fail at the wire with the provider's own error message (e.g. "model not found").

Advanced parameters

These are OpenAI-compatible parameters. Provider and model support can vary, so if a model rejects one of these settings, remove the setting or pick a different model.

On Grok, frequencyPenalty, presencePenalty, and stop are dropped before the call: xAI rejects all three on reasoning models, and every model it ships reasons. temperature, topP, and seed work normally.

Reasoning

Some models support extended reasoning. When enabled, the model may return additional reasoning metadata alongside the reply.

Reasoning is model-dependent. Models that don't support reasoning can reject the call. Venice's reasoning-capable models surface their thinking as reasoning_content and are normalized into the same reasoning output field as OpenRouter.

ChatGPT always reasons. Every model on a ChatGPT credential reasons on every call, so there is nothing to switch on. The node hides the Reasoning toggle for ChatGPT credentials and shows the effort picker on its own; only the depth is yours to choose. Leaving the effort unset does not disable reasoning, it runs the model at medium. minimal is raised to the shallowest depth ChatGPT offers, since ChatGPT models have no lighter setting. Each model also caps its own depth, so an effort above a model's ceiling is lowered to that ceiling rather than rejected.

Grok always reasons too. grok-4.5, xAI's only current model, reasons on every call and cannot be switched off; the Reasoning toggle only decides whether you set the depth or let the model use its default (high). It accepts low, medium, and high, so xhigh and max are lowered to high and minimal is raised to low rather than being rejected. See Grok Integration.

JSON Request mode

When inputMode is json, the body must be an object with an OpenAI-compatible messages[] array. This is the only request shape the runtime forwards to AI providers.

Static JSON is checked in the editor before the workflow runs. If the JSON contains template expressions, the final shape is checked after those templates render at runtime. Legacy provider formats such as Gemini contents[] or Anthropic top-level system are rejected when the rendered request is parsed.

{
  "messages": [
    { "role": "system", "content": "You are a concise assistant." },
    { "role": "user", "content": "Summarize: {json birdeyeResponse.data}" }
  ]
}

role must be one of system, user, assistant, developer. content is a non-empty string, or an OpenAI-format content-parts array ([{ "type": "text", "text": "..." }, { "type": "image_url", "image_url": { "url": "..." } }]) for multimodal models.

The body may also set:

All other fields in the body are ignored. Advanced parameters (topP, frequencyPenalty, etc.) and responseFormat come from node settings, not the JSON body. Set them in the editor's Advanced parameters panel or Response format toggle.

Template expressions inside requestJson are resolved before the body is parsed as JSON, so a path like {json codeResponse.data} interpolates a JSON value at that position. Undefined paths fail loudly with AI JSON input uses undefined variables: <path> instead of producing invalid JSON or empty substitutions.

Response format

The responseFormat setting controls how the model's reply lands in the output envelope. It must agree with what your prompt asks for. Instructing the model to respond in JSON without flipping this toggle leaves .data as a string that downstream nodes can't traverse with field paths.

Some models don't support structured outputs and will fail when json_object is set. Pick a model that does, or fall back to text and parse downstream.

Image generation

Some OpenRouter models generate images rather than (or alongside) text. When you select an image-capable model, an Output toggle appears in the config dialog:

• Image (the default once you pick an image model): the node sends the image request, hosts the returned image, and emits a fetchable URL as {aiResponse.imageUrl}.
• Text: forces an ordinary text reply even on a text-and-image model, so .data behaves exactly like a normal chat completion.

Image-only models skip the toggle and always produce an image. Capability is detected from the model's reported modalities in the live catalog; for a free-typed model ID with no catalog entry, the node falls back to the *-image naming convention.

Hosted URL lifetime

The node uploads the generated bytes to Solaris storage and returns a temporary signed URL (about an hour); the underlying file is reaped within a day. This is sized for immediate, in-run consumption, so wire {aiResponse.imageUrl} straight into the node that uses it. Don't park an image URL behind a long Delay or a multi-hour pause and expect it to still resolve. The raw image bytes are never written into the run journal, only the hosted URL.

Using the image downstream

imageUrl is the field other nodes point at:

• Pump.fun createToken with imageUrl: {aiResponse.imageUrl} launches a token with a generated logo.
• Telegram sendPhoto with photoUrl: {aiResponse.imageUrl} posts the image to a chat.

If your image bytes come from somewhere else, raw base64 from a different image API behind an HTTP node, the Storage Host File → URL operation turns them into the same kind of URL.

Output

In text mode (default):

{
  "success": true,
  "data": "The current price of SOL is approximately $150.",
  "model": "openai/gpt-5-mini",
  "usage": { "promptTokens": 42, "completionTokens": 18 }
}

In json_object mode:

{
  "success": true,
  "data": { "price": 150, "asset": "SOL", "confidence": "high" },
  "model": "llama-3.3-70b",
  "usage": { "prompt_tokens": 42, "completion_tokens": 18 }
}

In image mode (see Image generation):

{
  "success": true,
  "imageUrl": "https://.../generated.png",
  "imageUrls": ["https://.../generated.png"],
  "model": "google/gemini-2.5-flash-image",
  "usage": { "promptTokens": 12, "completionTokens": 0 }
}

Image mode has no .data. imageUrl is the first (primary) hosted image; imageUrls lists all of them when a model returns more than one. Any text the model returned alongside the image lands in text.

The model field reflects the provider's canonical ID. OpenRouter IDs are slashed, such as openai/gpt-5-mini; Venice, ChatGPT, and Grok IDs are bare. The usage shape mirrors whatever the provider returns. Depending on the provider, token counts may appear as snake_case or camelCase, so inspect the run output before wiring usage fields into downstream nodes.

Reasoning models may add a reasoning field when reasoning is enabled.

Reference patterns:

• {aiResponse.data} is the model's reply as a string. In text mode this is the raw model output. In json_object mode .data is an object, so without the json prefix the template substitutes [object Object] (string coercion). Use {json aiResponse.data} instead when .data is an object.
• {aiResponse.data.field} is a scalar field (string / number / boolean) from a json_object reply, dropped in unquoted. The right shape for prompts and most string fields in HTTP query strings.
• {json aiResponse.data.field} is the same field JSON-encoded (strings get quotes, objects/arrays get JSON syntax). Use this when interpolating into JSON HTTP bodies, or when the field itself is an object or array.
• {json aiResponse} is the full response envelope, useful for HTTP bodies or debugging.
• {aiResponse.imageUrl} (image mode only) is the hosted URL of the generated image, the field to drop into a Pump.fun imageUrl or Telegram photoUrl.

Template variables

The system prompt, prompt, and JSON-input fields all support template expressions like {json codeResponse.data.field}. Two things to know:

• Use the variable picker (the { } button next to any text field). It walks upstream nodes and suggests valid paths, including nested field paths once the workflow has run once. Before the first run, it falls back to a static schema for known node types so you still get useful suggestions.
• Undefined paths fail loudly. If a path doesn't resolve (typo, wrong nesting, upstream node didn't emit that field), the node fails before calling the model. Checked across all three template fields (systemPrompt, prompt, requestJson) so a single failure surfaces every offending path at once. The error message mentions the offending path: Prompt template uses undefined variables: <path> in prompt mode (covers system prompt + prompt), AI JSON input uses undefined variables: <path> in JSON Request mode (covers system prompt + JSON body). This is the most common cause of "I don't see any data" replies; fix the path instead of debugging the model. A path that resolves to null (e.g. balanceResponse.mint on a SOL balance) is treated as a present value, not a missing one.

When to pick which provider

• Default to OpenRouter if you need access to a specific commercial model (GPT, Claude, Gemini) or want the broadest catalog.
• Use ChatGPT if you want the lowest-friction setup and already have a ChatGPT account. See ChatGPT Integration.
• Use Grok if you already have a Grok account and want xAI's Grok 4.5. See Grok Integration.
• Pick Venice when you need private inference, want to run uncensored or open-source models, or already use Venice for the rest of your stack.

You can use multiple providers in the same workflow. Each AI node carries its own credential, so one node can call an OpenAI model through OpenRouter while the next routes to Llama through Venice.

Common use cases

Solaris AI Flow exposes more than 200 onchain operations, over 100 of them DeFi actions across Jupiter, Raydium, Orca, Meteora, Kamino, Phoenix, Sanctum, DFlow, and Pump.fun. The AI node is how a workflow decides which of them to run.

• Gate a trade. Read a Jupiter quote and a Pyth price, judge the spread and slippage, then let a Condition node route to a swap or to nothing.
• Watch leverage. Feed getUserObligations and getLeverageMetrics from Kamino to the model and alert before a position nears liquidation.
• Rank new tokens. Score GMGN or Pump.fun trending lists against your criteria, then place a Phoenix limit order on the survivors.
• Parse and route. Turn unstructured data into structured JSON with the json_object response format so downstream nodes can branch on real fields.
• Explain what happened. Summarize a fill or a wallet's activity into a Telegram or Discord message a human can act on.
• Choose your provider per prompt. Route sensitive prompts through Venice for private inference and public ones through OpenRouter for breadth.

A model's judgment is not a safety guarantee. Trade nodes support dry-run mode; keep a new workflow simulating until you have watched it decide correctly on real data.

Next steps

• Node reference — every swap, order, and lending action an AI node can gate
• Jupiter connects AI to on-chain swaps
• Configuring Nodes explains template expressions for dynamic prompts