MVS is the AI routing layer for the entire MelTuc platform. Every blueprint that needs an LLM sends its request to MVS, which dispatches to the active provider — OpenRouter, Ollama, DeepSeek, or MiniMax — with automatic fallback. One API. Every model. Zero provider lock-in.
The dashboard shows the active routing configuration alongside real-time request activity. Today's request count and total token consumption appear at the top. The recent requests table shows the last ten dispatches with app ID, provider name, success status, latency, and timestamp. A top-apps strip highlights which blueprints are making the most calls today.
The providers page shows every registered provider and all their associated models. Each provider and model can be individually enabled or disabled with a toggle. Model identifiers are the exact strings passed to the provider's API. Context window sizes are shown for planning prompt budgets.
The settings page is where you set the active provider and model, configure an optional fallback for when the primary fails, and set default temperature and max token limits. The token section lets you generate per-app bearer tokens for external integrations. Each token is identified by app ID and can be individually enabled or disabled without regenerating.
The test interface lets you fire a live request through the full dispatch pipeline without writing any code. Enter a system prompt and user message, optionally override the provider, and submit. The response displays with timing, token usage, and the full normalised output. Every test run is saved to the history view for later reference.
MVS ships with adapters for four providers. The dispatch layer normalises all responses to the same output schema regardless of which adapter handled the call. Switching the active provider requires no code changes in any calling blueprint.
MVS is the single integration point for all AI across the MelTuc platform — every blueprint that needs an LLM routes through here.
One dispatch call works with OpenRouter, Ollama, DeepSeek, or MiniMax. Switch the active provider in settings — zero code changes required in any calling blueprint.
Configure a primary and fallback provider. When the primary fails or times out, MVS retries against the fallback transparently — callers never see the error.
Today's request count, token consumption, success rate, and avg latency updated on every page load. The recent requests table shows the last ten dispatches with full metadata.
Generate bearer tokens scoped to individual blueprints. Each token can be individually enabled or disabled without regenerating. External integrations authenticate via header.
Fire real requests through the full dispatch pipeline from the browser — no code, no curl. System prompt, user message, optional provider override. Response, timing, and token usage all returned.
Free models discovered and validated by FMR are synced directly into MVS with a single admin action — provisioned, skipped, and error counts reported for complete visibility.
Platform code routes through MVS with a single call_llm(prompt, via_mvs=True) — no token, no router import. The internal dispatch endpoint accepts a flat body and falls back to a direct provider call if MVS is ever unreachable.
Every successful call is logged to both the MVS ledger and the platform-wide AI operations log — source app, model, token counts, and cost — feeding ecosystem-wide usage and spend reporting.
Route all platform AI traffic through a single, configurable dispatch layer with automatic fallback. No provider lock-in. No code changes when switching models.
Open Model VaultRequires a MelTuc account. Create one free.