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 (when experimental MCP is enabled) use that configured route.
There are three practical routes:
| Route | What it means | Public Alpha status | | --- | --- | --- | | Managed cloud | NeuralScio-managed model route | Not active during Public Alpha; future availability and timing are not published | | 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 |
Provider and model choices
> Provider model identifiers and BYOK defaults change independently of this guide and are maintained in the desktop model catalog. This page intentionally does not publish a static model-ID or price list: use only the choices exposed by the installed build, and confirm access and charges with the provider. A catalog entry alone does not prove account access, endpoint availability, or runtime support. NeuralScio-managed cloud AI is not active during Public Alpha.
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:
- managed cloud AI is not active during Public Alpha; no launch timing is published here
- 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
- when experimental MCP is included and configured, an external client can call available tools; it does not expose a user-facing "switch provider" tool, so 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.
When retrieval indexing is enabled, PDF import can start local indexing. If your build exposes Off (disable RAG) in AI Model Settings, that option controls retrieval indexing; it does not disable a separately started AI action. Check the visible status after import and before using any AI feature.
Tool-backed workflows
The AI layer is also tied to MCP and tool schemas. Experimental MCP clients can reach configured research tools when the current build and settings enable them.
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:
- the managed cloud implementation uses an allowlisted model layer; managed cloud AI is not active during Public Alpha
- 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
Related Docs
- Read MCP & Headless for agent and automation workflows.
- Read Offline Mode for the local-first boundary.
- Read Pricing for Public Alpha access and future cloud plan details.