LLM Settings

qRaptor calls a language model in a lot of places that aren’t your agent: writing SQL in the Data Assistant, generating an app in Vibe Coding, summarising a document, transcribing speech. Each of those is a use case, and each has a model behind it.

LLM Settings is where you see what those are and change them.

The LLM Settings tab showing use cases grouped by category with their current models

What you’ll see

Use cases are grouped into six collapsible categories:

Category	Covers
Data & Query	SQL generation, schema generation, data management
Code Generation	Vibe Code, code completion, code review, theme
Agent Operations	Agent reasoning, planning, tool selection, memory decisions
Document & Content	Document analysis, summarisation, content generation
Core	Chat, embedding, and the fallback default
Voice	Speech-to-text, text-to-speech, realtime voice

Each row shows the use case, a one-line description, the model currently behind it, and a switch.

ℹ️

Every use case starts on a system default chosen for your plan. You don’t have to set anything here — this screen exists for when you want something different.

Overriding a use case

Expand the row

Click Override on the use case you want to change.

Choose a source

System Configuration — a different model provided by qRaptor. Managed for you, billed in credits, subject to your plan’s limits.
Project Configuration (BYOK) — one of your own configurations. Billed to your provider account, no platform usage limits, and you own the relationship.

Pick the configuration

The list is filtered to configurations that fit the use case — language models for reasoning and generation, embedding models for embedding, speech services for voice.

An expanded use case row showing the override source selector and configuration picker

Save

The row now carries a badge showing where its model comes from: System Override or Project Config.

💡

Overrides are per use case, not all-or-nothing. Pointing Vibe Code at your own Claude account while everything else stays on platform defaults is a normal setup.

Bring your own key

Using Project Configuration (BYOK) changes who pays and who holds the limits:

	Platform model	Your own configuration
Billed	Credits from your subscription	Your provider account
Usage limits	Your plan’s	Your provider’s
Model choice	What your plan includes	Anything your account can reach
Managed by	qRaptor	You

Reasons to bring your own: a model the platform doesn’t offer, a specific region for data residency, a fine-tune, an existing committed spend agreement, or simply wanting provider-side visibility of your usage.

To use one, create it first under Configurations — it will then appear in the picker here.

Disabling a use case

The switch on each row turns a use case off entirely. Nothing calls a model for it. Use this to make sure a platform feature never runs — a project that must not use code generation can switch those off rather than relying on nobody clicking the button.

Reverting

A use case you’ve overridden gets a revert button. It removes your override and restores the system default, after a confirmation.

ℹ️

Reverting removes the override, not the configuration. Your BYOK configuration stays where it is and can be used elsewhere.

When changes take effect

Immediately. Publish an override and the next call for that use case uses the new model — there’s nothing to redeploy and no delay to wait out.

Voice use cases

Voice works the same way, with one difference worth knowing: the picker filters to speech services rather than language models, so you’ll see your Deepgram, ElevenLabs, Azure Speech or OpenAI voice configurations rather than your chat models.

Create voice configurations under Configurations → Voice — see Add a configuration.

Common issues

“No project configs available” — you have no configuration of a kind that fits this use case. Create one first; the picker only offers matching kinds.
A model you expected isn’t in the System Configuration list — the list is filtered by what suits the use case, and by what your plan includes.
A use case you were told about isn’t listed — some legacy use cases are resolved internally but no longer offered for configuration. If a feature is behaving unexpectedly, check the use case that actually drives it.
You can’t change anything — this needs Developer Developer or above.

Configurations overview — creating the configurations this screen points at.