Onboard is designed for local AI. The model, prompts, code context, and answers can run inside the customer environment instead of relying on an external AI service.

No. Onboard is self-hosted, and source code does not need to be uploaded to SciTools or to a third-party cloud service.

Yes. Onboard is meant to be shared by the engineering team, so developers can work from the same project model rather than isolated local notes or one-off AI sessions.

Pricing is based on the number of projects covered. Every tier includes unlimited users and unlimited lines of code.

A project is the unit OnBoard organizes work around — typically a codebase or repository, even if it spans multiple binaries or libraries. If those binaries and libraries are built and maintained together as a single product, we treat them as one project.

That said, every team's setup is different, and we know "one product" isn't always a clean line. If you're not sure how your codebase should be counted, or you have a use case that doesn't fit neatly into this definition, our sales team can work with you directly to find a fair setup for your situation — just reach out and we'll figure it out together.

Onboard uses SciTools Understand analysis data, including relationships, references, dependencies, call paths, metrics, and project structure. It is not limited to searching raw source files.

Onboard isn't locked to a single AI provider. If you'd rather run models locally or route through your own provider, you can point Onboard at any OpenAI-compatible endpoint. That covers local runtimes like LM Studio (and similar tools such as Ollama or vLLM) as well as hosted aggregators like OpenRouter that give you access to many models through one API key. Just enter the base URL and API key/model name in Onboard's settings, and it'll use that endpoint instead of the built-in model. This is a good fit for teams that want to keep code analysis fully on their own infrastructure, or that already have model preferences and billing set up elsewhere.