AI Routing & Assistant
How Data Explorer chooses AI lanes, lets you configure models per role, and keeps clear boundaries between chat, SQL/MQL generation, vision, live search, and execution guardrails.
Using the AI Assistant day to day
Open the AI panel and pick a model
Press Ctrl+J to open the AI panel. Pick a model from the dropdown (or leave Auto), then choose a routing mode: Auto for balance, Fast / Cheap for light prompts, Best Quality for important work, or Gemini Only for maximum consistency.
Ask questions with schema context
Type a natural-language question in the composer at the bottom — the AI already knows the tables and columns of the active connection. Example: 'write a query counting orders per month this year'. Schema context is selected automatically per prompt.
Run suggested SQL straight in the editor
When the AI returns SQL, press the run button on the code block to insert it into the editor and execute immediately (risky queries still require confirmation). Or copy manually to edit before running.
Attach images/PDFs and ask follow-ups
Press the paperclip to attach an error screenshot, a diagram, or a PDF — the AI analyzes the content. After each answer, keep asking follow-ups in the same conversation; the AI retains the context of previous turns.
Check which provider/model actually answered
Every response shows the actual provider and model that handled it (e.g. 'Gemini 3.6 Flash') plus cited sources when live search was used — so you never mistake the lane while routing is active.
Context-driven routing
AI does not run through one hard-coded model. Short prompts, longer tasks, image input, and current-information requests can travel through different lanes when the routing mode and capability filters allow it.
Role-based configuration
Each role such as AI Assistant, Explain, AI SQL, AI NoSQL, and Autocomplete can inherit the main assistant model or use its own dedicated model to optimize for cost, speed, or quality.
Guardrails remain final
AI can generate statements, explain queries, or suggest next steps, but the editor, connection policy, and backend guardrails still make the final decision before real execution.
Configure AI by role
AI Assistant
The model used by the main chat panel, general assistance, and conversational AI flows. When you change this role, the visible assistant model outside the settings surface updates immediately.
Explain
A dedicated model for the query explanation dialog. This role is useful when you want explanations to be more detailed, more stable, or cheaper than the general assistant.
AI SQL
A model specialized for SQL generation, fixing, optimization, or index suggestions. You can bias this role toward heavier reasoning or faster iteration depending on your day-to-day queries.
AI NoSQL
A model for MongoDB/NoSQL generation, pipeline explanation, and JSON-oriented workflows. Keeping this role separate avoids forcing a SQL-centric model into document-style tasks.
Autocomplete
A dedicated model for ghost text and inline completions inside the editor. Splitting this role out is useful when you want typing suggestions to stay fast, short, and cheaper than chat or explain.
`Explain`, `AI SQL`, `AI NoSQL`, and `Autocomplete` can inherit the Assistant model. This keeps one central model when you want simplicity, while still allowing each role to be split out later.
Custom OpenAI-compatible providers
Load models from the provider
When the Base URL and API key are valid, the `Load models` button requests the provider model catalog so you can choose from a searchable dropdown. If the endpoint does not return a catalog, you can still type the model manually.
Stored locally per machine/user
Custom providers and role preferences are stored locally on the current client. They do not replace `server/.env`, and they do not automatically become shared global lanes for the whole system.
# Core fields in Configure AI
Provider name: My Provider
Base URL: https://your-provider.example.com/v1
API key: sk-...
Default model: custom-model-name
Routing modes in the AI panel
Auto
The default mode for most tasks. The app starts from the auto chain and then filters it by capabilities such as vision or live search when the prompt genuinely needs them.
Fast / Cheap
Leans toward cheaper and faster lanes, but does not override an explicit provider if you already locked a concrete model.
Best Quality
Best for long prompts, deeper query rewrites, detailed explanations, or requests that need stronger reasoning.
Gemini Only
Locks the workflow to the selected Gemini lane to reduce cross-provider variance and keep behavior more predictable.
Provider lanes currently exposed in the app
Gemini
The higher-quality lane for longer reasoning, image input, and tasks that need stronger reliability.
OpenRouter
A flexible multi-model lane used for broader fallback and, with some models, vision or live-search paths.
Groq
A low-latency lane optimized for short chat and fast iteration rather than vision or live search.
Cerebras
A lower-cost lane for tasks that do not need images or live web search.
Beeknoee
An explicit-model lane in the catalog when you want to target a Beeknoee model directly instead of relying on default fallback.
Important implementation note: `Beeknoee` is not injected into the default auto chain on its own right now. It participates when you explicitly select that provider or when the code is expanded later.
What explicit model selection really changes
# Higher-quality Gemini lane
gemini-3.5-flash
# Explicit Beeknoee provider
beeknoee:qwen-3-235b-a22b-instruct-2507
Vision and live search: the current boundaries
Vision-capable lanes
In the current repo, Gemini is the strongest default vision lane. OpenRouter can also act as a vision path when the chosen model genuinely supports images.
Live-search lanes
Live search is not the same as a model sounding web-aware. In the current wiring, live search is reserved for Gemini and OpenRouter.
Action cards, suggestion cards, and execution safety
Insert into editor
This option only inserts the query or payload into the current editor. It is not execution yet.
Run still goes through the app layer
When you choose to run, the query still passes through the query service, connection policy, and engine guardrails. AI cannot bypass those layers.
If you want the AI docs to stay grounded in reality, always separate three questions: which model is selected, which provider actually executes the request, and which capability is truly wired into this repo instead of merely advertised externally.
Ready to explore data?
Join the community on GitHub to contribute to the smartest local database IDE.
Launch App