AI Features

Understand local, BYOK, and managed cloud AI boundaries during Public Alpha.

NeuralScio uses language models inside a research workflow, not as a detached generic chat tab. The important implementation detail is context: the desktop app can combine active article state, saved-library material, retrieval components, and tool-backed actions in the same workspace.

During Public Alpha, managed cloud AI is paused. You can use local models or BYOK (your own API keys / local endpoints) where supported. BYOK is an access mode, not a managed cloud trial.

AI Backends

NeuralScio separates the AI model route from the research tools that use it. You can choose the route in the desktop AI settings, and the assistant, agents, Writer help, RAG actions, and MCP-triggered research runs use that configured route.

There are three practical routes:

| Route | What it means | Public Alpha status | | --- | --- | --- | | Managed cloud | When enabled after Public Alpha billing, NeuralScio-managed cloud models will use account credits | Not active during Public Alpha | | Your API keys | You bring a provider key and NeuralScio calls that provider through your configured account | Optional technical setup if supported | | Local | Ollama or the native GGUF / llama.cpp worker runs on your machine | Available where configured |

Cloud providers

| Provider | Status | Notes | | --- | --- | --- | | OpenAI | Implemented | BYOK path; managed-cloud route is planned | | Anthropic Claude | Implemented | BYOK path; managed-cloud route is planned | | Google Gemini | Implemented | BYOK path; managed-cloud route is planned | | DeepSeek V4 Flash / V4 Pro | Implemented | OpenAI-compatible BYOK path; managed-cloud route is planned | | Kimi 2.6 | Implemented | BYOK path; managed-cloud route is planned | | GLM 5.1 | Implemented | BYOK path; managed-cloud route is planned | | Qwen 3.6 Max Preview | Implemented | BYOK path; managed-cloud route is planned | | MiniMax 2.7 | Implemented | BYOK path; managed-cloud route is planned |

Local providers

| Path | Status | Notes | | --- | --- | --- | | Ollama | Implemented | Local model path for desktop workflows | | Native GGUF / llama.cpp worker | Implemented | Separate worker process with backend selection |

Model Choice With Agents And MCP

Agents and MCP do not create a separate AI account. They reuse the model route selected in Settings -> AI.

That means:

  • when managed cloud routes are enabled after Public Alpha billing, a managed DeepSeek selection can use NeuralScio account credits
  • if you select your own API route, the same research tools run through your configured key
  • if you select Ollama or the native worker, the run stays on the local model path where the selected tools also support local execution
  • an external MCP client can call NeuralScio tools, but the current public MCP surface does not expose a user-facing "switch provider" tool; change the model in Settings -> AI before the run

What The AI Research Assistant Does

Article-level help

  • summarize the active article
  • answer follow-up questions in context
  • keep responses tied to the paper you are reading or the library you have saved

Retrieval-backed assistance

The desktop stack includes embeddings, vector indexing, and keyword retrieval. NeuralScio can ground answers in your saved material instead of acting like a blank chat box.

Tool-backed workflows

The AI layer is also tied to MCP and tool schemas. That matters for agent workflows because the same research stack can be reached from the UI or from MCP clients.

Agent orchestration and verification scaffolding

The desktop codebase includes agent definitions, agent sessions, an orchestrator, autonomous run records, candidate-action evaluation, a decision ledger, proof obligations, portfolio review, and formalization-planning tools. These are best described as assisted research automation and verification workflow support.

The important boundary is that structured logs and verifier states are not the same as model reasoning. NeuralScio can record what was tried, which action was chosen, what evidence was attached, and which obligations remain. Model-generated hypotheses and summaries still need human review before they are used as scientific conclusions.

Voice Support

Voice support exists, but it should be framed as a supporting layer.

| Backend | Status | Notes | | --- | --- | --- | | OpenAI Realtime | Implemented | Cloud voice path | | Gemini Live | Implemented | Cloud voice path | | Grok Voice | Implemented | Cloud voice path | | Local voice path | Implemented | Speech-to-text plus text-to-speech components |

Use voice when it helps with accessibility or hands-busy moments. It works best as a supporting input and playback layer inside the wider research workflow.

Local vs Cloud Boundary

Can stay local

  • Ollama-based analysis
  • native GGUF / llama.cpp worker flows
  • saved-library context used by local models
  • local agent sessions when they use local models and local data
  • explicit saved-library and document context chosen inside the workflow

Requires network access

  • provider search across external scholarly sources
  • managed cloud AI
  • account-linked billing and entitlements
  • remote MCP transports or external tools that call network services

Safety And Control Layer

The implemented AI stack includes concrete controls:

  • managed cloud requests use an allowlisted model layer
  • article and web content are treated as untrusted input in prompt composition
  • trusted-host allowlists and response blocklists reduce risky links and unsafe content patterns
  • provider policies can narrow which content is eligible for AI processing
  • autonomous/tool-heavy runs can record candidate evaluation, decision, and outcome artifacts
  • remote MCP exposure can require token, TLS, and CORS configuration

1. Read MCP & Headless for agent and automation workflows. 2. Read Offline Mode for the local-first boundary. 3. Read Pricing for Public Alpha access and future cloud plan details.