Platform Service Configuration

Configure which AI providers and models power VeriPrompt's internal features like Guru, Architect, and MCP execution.

Overview

VeriPrompt uses AI internally for several platform services. As an admin, you control which provider and model each service uses -- giving you full control over cost, performance, and data residency.

Accessing Service Configuration

Navigate to Admin > System Tools > Service Config or go directly to /admin/service-config.

Permissions

Only Super Admins can access and modify service configuration.

Available Services

Service	Description	Default Provider	Default Model
Guru Chat	Main chat assistant for prompt engineering guidance	Anthropic	claude-3-5-haiku-20241022
Prompt Optimizer	One-click prompt optimization (Optimize button)	Anthropic	claude-3-5-haiku-20241022
Guru Explain	Contextual "Explain It" feature for prompts and MCP tools	Anthropic	claude-3-5-haiku-20241022
Guru Refine	Guided wizard refinement with follow-up questions	Anthropic	claude-3-5-haiku-20241022
Architect	Project Architect for requirement analysis and proposals	Anthropic	claude-sonnet-4-20250514
MCP Executor	MCP tool execution engine	Anthropic	claude-3-5-haiku-20241022

How to Configure a Service

Each service card shows the Effective provider/model badge -- this is what would actually be used at runtime.

Option 1: Use a Provider Group

1. Select a Provider Group from the dropdown (e.g., "Default LLMs", "US Providers")
2. The first member of the group will be used
3. Leave Provider set to "Auto" and Model empty

This is useful when you want the service to follow your routing groups.

Option 2: Set an Explicit Provider and Model

1. Set Provider Group to "None -- use explicit provider below"
2. Select a Provider from the dropdown:
   • Anthropic
   • OpenAI
   • Google
   • DeepSeek
   • Moonshot (Kimi)
3. Enter the Model ID (e.g., claude-3-5-haiku-20241022, gpt-4o-mini, kimi-k2-0711-preview)
4. Click Save

Option 3: Auto (Default)

Leave everything on default. The system uses the built-in defaults shown in the table above.

Provider Resolution Priority

When a service needs to make an AI call, the system resolves the provider in this order:

1. PlatformServiceConfig -- explicit settings you configure in Service Config
2. GuruConfig fallback -- only for Guru-related services (configured at /admin/guru-config)
3. Built-in defaults -- hardcoded sensible defaults
4. Final fallback -- Anthropic / claude-3-5-haiku-20241022

Capability-Based Service Configuration

Rather than pinning every service to a frozen provider/model string, you can configure each platform service by capability. The service then resolves a live, ordered list of provider/model candidates from your active provider catalog at request time -- so the configuration keeps working even as you add, update, or retire individual models.

Resolution methods (priority order)

For each service, the system applies the first method you have configured, in this order:

1. Provider selector -- a JSON filter evaluated against the live catalog (e.g. only cheap-tier models from specific providers). Most flexible; never references a specific model ID.
2. Quality tier -- one of cheap, fast, quality, or secure. Selects all live models carrying that tier.
3. Provider + model pin -- an explicit provider and model. This is validated against the live catalog: if that model no longer exists (e.g. it was retired or re-imported under a new ID), the pin is silently skipped rather than failing the call.
4. Provider group -- a named group. Dynamic groups resolve their own selector against the catalog; static groups use their members, with each member validated against the catalog (stale members are dropped).

If none of these is set on the service, resolution falls back to:

5. The designated platform-default provider group (see below), then
6. The service's capability-default tier (its built-in role intent), then
7. The full active provider pool, ordered with the preferred tier first.

This produces an ordered candidate list. The first candidate is preferred; the rest act as automatic cross-provider failover.

Capability-default tier per service

Every service ships with a sensible default tier reflecting its role, used whenever no explicit tier or selector is set:

Service	Default tier (role intent)
Guru Chat	cheap
Prompt Optimizer	cheap
Guru Explain	cheap
Guru Refine	cheap
MCP Executor	cheap
Chat Terminal	fast
Architect	quality

For example, the Architect defaults to the quality tier because it performs deeper requirement analysis, while the Prompt Optimizer and Guru default to cheap since they run frequently on short tasks.

Platform-default provider group

You can designate one provider group as the org-wide fallback pool for all services. This is stored as the system setting platform:default-provider-group. When a service has no selector, tier, pin, or group of its own, it draws from this default group before falling back to the global tier/pool. Set it once and every unconfigured service inherits the same pool.

Live effective provider/model (read-only)

In Admin → Chat Settings → Service Config, each service card shows the live effective provider/model -- the actual provider and model that would be used right now, resolved against the current catalog. This is read-only and recalculated on every load, so you can confirm exactly how your selector, tier, pin, or group resolves before relying on it. If you retire a model, refresh the page to see which model the service now resolves to.

Why capabilities, not frozen model IDs

Because services reference capabilities (a tier or a selector) rather than a hardcoded model ID:

• Updating or re-importing your providers automatically flows to every service -- no per-service edits needed.
• No service breaks when a model is retired. The retired pin is skipped and the next valid candidate is used.
• Cost and performance intent (e.g. "always use the cheapest qualifying model") survives catalog changes.

Example: configure the Prompt Optimizer with a selector

Suppose you want the Prompt Optimizer to always use a cheap model, but only from Anthropic or DeepSeek. In Admin → Chat Settings → Service Config, set the Prompt Optimizer's selector to:

{ "tiers": ["cheap"], "providers": ["anthropic", "deepseek"] }

What gets resolved:

• The system filters the live catalog to active models that are tagged cheap and belong to anthropic or deepseek.
• The matching models are ordered with the cheap tier first, healthiest-first (most recently tested), and de-duplicated.
• The live effective provider/model badge shows the top candidate -- for instance deepseek/deepseek-chat if that was tested most recently.
• The remaining matches stay available as automatic failover. If, say, the DeepSeek model is later retired from your catalog, the selector simply resolves to the next qualifying Anthropic model with no configuration change.

Selector clauses are combined with AND, and any empty or omitted clause passes everything. Supported clauses include providers, tiers, regions (ISO country codes), excludeModels, and privacyTiers.

Enable / Disable Services

Each service has a toggle to enable or disable it. Disabling a service will prevent it from being used across the platform.

Supported Providers

Provider	Key	Compatible Models
Anthropic	anthropic	claude-3-5-haiku, claude-3-5-sonnet, claude-sonnet-4, claude-opus-4
OpenAI	openai	gpt-4o, gpt-4o-mini, o1, o3-mini
Google	google	gemini-2.0-flash, gemini-2.5-pro
DeepSeek	deepseek	deepseek-chat, deepseek-reasoner
Moonshot (Kimi)	moonshot	kimi-k2-0711-preview, kimi-k2-thinking-turbo, kimi-k2.5

TIP

The provider must have valid API credentials configured in Admin > AI Agents > AI Providers before it can be used for internal services.

Legacy: Guru Config

The dedicated Guru Config page (/admin/guru-config) provides additional Guru-specific settings:

• Enable/disable the entire Guru platform
• Credit limits per user (max credits per user)
• Default provider/model specifically for Guru features

Settings in Service Config take priority over Guru Config for Guru-related services.

Example: Switch Guru to DeepSeek

1. Go to /admin/service-config
2. On the Guru Chat card, set Provider Group to "None"
3. Select DeepSeek as Provider
4. Enter deepseek-chat as Model
5. Click Save
6. Repeat for Prompt Optimizer, Guru Explain, and Guru Refine if desired

The "Effective" badge will update to show deepseek/deepseek-chat.

Example: Use Moonshot Kimi for Optimization

1. Ensure Moonshot API credentials are configured in AI Providers
2. Go to /admin/service-config
3. On the Prompt Optimizer card, select Moonshot (Kimi) as Provider
4. Enter kimi-k2-0711-preview as Model
5. Click Save