LLM Store

// PRODUCT WALKTHROUGH

Visual orientation backed by the product facts below.

Use the gallery as quick orientation, then inspect mechanics, actions, outputs, integrations, and boundaries.

LLM Store Overview slide — Overview **Central AI routing and governance for Unreal Engine projects**
Stable routes, governed providers, visible cost and health.

// THE PAIN

Before the plugin enters the chat.

Every feature hardcodes its own model — and nobody sees the bill.

PAIN

One Blueprint calls GPT-4 directly. Another hardcodes a local Ollama tag. A Python script still holds last quarter's API key. There is no shared map of what runs where or what it costs.

Swapping providers means touching feature code. Rotating secrets means hunting config fragments. When usage climbs, leads and finance learn about it from an invoice — not from the project.

What that feels like

Model IDs and API keys are duplicated across maps, scripts, and plugins.
Fallback and runtime mode decisions live in code, not in policy.
Nobody can answer 'what did we spend on AI this sprint?' from inside UE.

// WHAT YOU GET

After — in the editor, not in a slide deck.

Features ask for a task route. You decide provider, fallback, secret handling, and cost in one editor surface.

GAIN

LLM Store is the control room: register providers, define routes like docs.summarize, set runtime modes, and read cost before automation spreads through the team.

Routes like docs.summarize that survive provider churn.
Secrets and runtime modes kept out of feature code.
A readable cost trail before automation spreads through the team.

// HOW IT WORKS

The product architecture, inspected from the plugin surface.

These are the moving parts I would place on the page so buyers can understand what they are actually getting beyond the slide narrative.

01 / Providers

Local and remote runtimes register behind one store.

OpenAI, Ollama, LM Studio, vLLM, TGI, llama.cpp, Anthropic, Gemini, Azure OpenAI, Mistral, OpenRouter, and mock providers fit the same route model.

02 / Routes

Features request tasks, not hardcoded model IDs.

A feature can ask for an embedding, chat, summary, or agent task route while the store resolves model, runtime mode, policy, and fallback.

03 / Govern

Secrets, readiness, audit, and cost stay out of feature code.

The subsystem owns config, secret access, provider execution, readiness checks, cost reports, queue behavior, and add-on registries.

// FIT

Who actually reaches for this.

Projects that need one visible control point for local and remote AI providers instead of scattered credentials and hardcoded model choices.

An editor control point for local and remote models, including governance and optional agent-facing surfaces.

// SURFACE

Where it lives in Unreal.

Provider dashboard, model registry, task routes, runtime modes, policy checks, cost tracking, and optional agent access.

// CAPABILITY MAP

Feature groups with the value of each part made explicit.

Grouped from plugin modules, public APIs, automation hooks, and documented workflow surfaces.

Provider control room

The product value is centralization: teams stop scattering model strings and API keys through plugins.

Register local and cloud providers in one editor workflow.
Define task routes such as docs.summarize or iis.embedding.code.
Resolve runtime mode and provider fallback without changing feature code.
Inspect provider readiness before a workflow depends on it.

Governance and cost

AI use becomes an operational decision, not an invisible side effect.

Keep secret access behind a store-owned backend.
Track request cost and export cost reports.
Use audit trails to explain what provider handled which task.
Separate model policy from feature implementation.

Task execution surface

LLM Store is useful to other plugins because it speaks in task routes and typed execution paths.

Execute chat, completion, embedding, streaming, and queued tasks.
Support context-pack and agent-task oriented calls.
Expose add-on registries so bridges can stay small.
Export and import setup for repeatable project configuration.

// OPERATOR TOOLS

Concrete actions, expected result, and mutation boundary.

This is the part that keeps product marketing honest: buyers can see which buttons, APIs, or MCP tools matter and what they change.

// ACTION

Create provider

Why it matters: Registers the runtime a task route can use.
Operator result: Features can stop carrying provider-specific setup.
Change surface: Updates LLM Store config.

// ACTION

Define task route

Why it matters: Maps a project task to model, provider, policy, and fallback.
Operator result: Feature code asks for intent instead of model IDs.
Change surface: Updates route configuration.

// ACTION

Run readiness check

Why it matters: Validates provider and secret availability before use.
Operator result: Broken runtime setup is visible in the editor.
Change surface: Records readiness state and diagnostics.

// ACTION

Export cost report

Why it matters: Turns request history into a reviewable usage summary.
Operator result: Leads can discuss AI spend from project data.
Change surface: Writes report output.

// ACTION

Execute task route

Why it matters: Runs a feature request through the resolved provider, model, policy, and fallback chain.
Operator result: Feature code stays stable while provider choices can change centrally.
Change surface: Creates provider requests and request-history records.

// ACTION

Stream response

Why it matters: Lets editor features consume long model responses incrementally.
Operator result: Interactive tools can feel responsive while still using governed routes.
Change surface: Provider call plus streamed response state.

// ACTION

Import / export setup

Why it matters: Moves provider and route configuration between projects or machines.
Operator result: Teams can reproduce AI routing decisions without hand-copying settings.
Change surface: Reads or writes LLM Store setup artifacts.

// ACTION

Register add-on executor

Why it matters: Lets bridge plugins extend execution without bloating the core store.
Operator result: Thin integrations can join the route model cleanly.
Change surface: Updates runtime add-on registry state.

// TYPICAL FLOW

From inspection to use without losing the product boundary.

01

Add a provider and register models or local runtime options.

02

Create task routes that describe how each AI task should resolve.

03

Review policy, cost, secret handling, and optional agent access before use.

// PROOF AND BOUNDARIES

Signals that make the product specific, plus the limits worth saying out loud.

Each card turns implementation facts into buyer-facing proof without pretending the tool solves the wrong problem.

Providers Cloud, local, self-hosted, and mock providers

Routes Task routes with fallback and runtime mode

Security Central secret access instead of duplicated keys

Accounting Audit and cost reporting surfaces

Provider span OpenAI, Ollama, LM Studio, vLLM, TGI, llama.cpp, Anthropic, Gemini, Azure OpenAI, Mistral, OpenRouter

Execution modes Chat, completion, embeddings, streaming, queued jobs, context-pack and agent-task calls

Extensibility Add-on registries for small bridges instead of direct feature coupling

Outputs

What the plugin leaves behind when the workflow is doing useful work.

Route config
Readable task-to-provider decisions for the project.
Readiness diagnostics
Provider and secret checks before automation runs.
Cost exports
Usage evidence for technical and business review.
Request history
Audit material that shows which provider handled which task.
Portable setup
Import/export artifacts for repeating provider and route decisions.

Inspection basis

The concrete code, API, and tool surfaces used to shape this product page.

Subsystem
ULLMStoreSubsystem owns config, route resolution, provider execution, secret access, readiness, cost, and audit.
Provider adapters
The code surface covers cloud, local, self-hosted, OpenRouter-style, and mock providers.
Route model
Task routes decouple feature intent from model IDs, runtime mode, fallback, and provider-specific execution.
Bridge hooks
Add-on registries and embedding routes explain why IIS can delegate provider execution without taking direct ownership.

Integrations

Where the product connects without losing ownership of its own domain.

Internal Index Service
The bridge can route IIS embedding jobs through LLM Store governance.
Unreal Capability Mesh
Recent editor jobs and setup routes can be exposed through mesh manifests.
Provider add-ons
New execution backends can register without changing every feature plugin.
Unified MCP Server
Governed routes can be reached by local tools when providers expose compatible tool contracts.
Bridge plugins
Small runtime plugins can adapt requests into LLM Store routes without duplicating provider stacks.

Safety model

The boundaries that make the tool understandable before automation enters.

Secret locality
Credentials belong to the store rather than individual feature plugins.
Policy before execution
Routes make provider, model, fallback, and runtime choices inspectable.
Mock path
A mock provider supports dry workflow development without live spend.
Cost visibility
Request history and reports make spend visible before automation spreads.
Config portability
Import/export reduces undocumented local setup drift.

Not for

The cases where the product promise would be the wrong expectation.

Teams that want every plugin to manage its own provider keys.
Use cases where AI calls should be hidden from project governance.
Projects that need a hosted billing portal instead of in-project operational visibility.

// PRODUCT MEDIA

Tutorial and platform embeds stay attached to product context.

YouTube, Discord, LinkedIn, and Fab widgets are reserved for product presentation, explanation, support context, or tutorials. No third-party widget loads automatically.

Tutorial video

YouTube

Product walkthroughs, setup explanations, and tutorial material.

Embed source pending. No third-party widget is loaded here.

Open platform

Primary support context

Discord

Discord-first product support, quick questions, setup discussion, and community context.

Embed source pending. No third-party widget is loaded here.

Open platform

Professional context

LinkedIn

Company background, provider identity, project credibility, and listing context.

Embed source pending. No third-party widget is loaded here.

Open platform

Marketplace context

Fab

Product listing context, license details, purchase route, and marketplace availability.

Embed source pending. No third-party widget is loaded here.

Open platform

// INFORMATION

All essential product signals in one place.

Status Available on Fab

Category AI Plugins

Unreal Engine 5.4; current descriptor/build line UE 5.8

Source state LLMStore.uplugin VersionName 1.1.1 / Version 111

Primary surface Provider dashboard, model registry, task routes, runtime modes, policy checks, cost tracking, and optional agent access.

Marketplace Fab listing available

Direct sales None on this website

Support route Discord first; product context lives on this page

Listing context Fab for marketplace, LinkedIn for public provider identity

Fact surface 3 functions / 3 settings / 3 failure modes / 2 bridges

Boundary Central Unreal governance and execution layer for providers, models, routes, policies, costs, secrets, and optional agent adapters.

Primary workflow Configure providers, models, task routes, route policies, and secret backends, then execute stable TaskKind routes from feature plugins or tools.

// NOTES

Practical boundaries.

Listed on Fab as LLM Store 1.0.2 / Unreal plugin version 102.

License, checkout, and download are handled on Fab; GitHub holds the documentation and release notes.

Recent editor jobs can be listed through `llmstore.editor.jobs.list.v1` and `llmstore.editor.jobs.status.v1` when Unreal Capability Mesh is enabled.

Optional helper scripts are documented as local source customizations and are not required for the Fab-ready plugin.

// LEGAL / PRIVACY

Static information page.

Purchases, downloads, marketplace accounts, and platform-specific license details are handled outside this website. Product or tutorial widgets are loaded only after activation, where configured.

Provider details are listed in the legal notice. The current site template does not set first-party cookies and does not load analytics scripts.

Legal Notice Privacy Policy

// RESOURCES

Open the channel that matches the next question.

Fab listing

Listing, license, purchase, account, and download context are handled by Fab.

Open

GitHub documentation

Manuals, quickstarts, settings references, troubleshooting, technical notes, and release material live in GitHub.

Open

Discord support (primary)

Start quick questions, setup help, support context, and product-fit discussion on Discord.

Open

Plugin support email

Formal plugin support requests can be sent to the dedicated support mailbox.

Open

LinkedIn company context

Company background, public provider identity, and listing context are available on LinkedIn; support still starts on Discord.

Open

// RELATED

Visual orientation backed by the product facts below.

Before the plugin enters the chat.

After — in the editor, not in a slide deck.

The product architecture, inspected from the plugin surface.

Local and remote runtimes register behind one store.

Features request tasks, not hardcoded model IDs.

Secrets, readiness, audit, and cost stay out of feature code.

Who actually reaches for this.

Where it lives in Unreal.

Feature groups with the value of each part made explicit.

Provider control room

Governance and cost

Task execution surface

Concrete actions, expected result, and mutation boundary.

Create provider

Define task route

Run readiness check

Export cost report

Execute task route

Stream response

Import / export setup

Register add-on executor

From inspection to use without losing the product boundary.

Signals that make the product specific, plus the limits worth saying out loud.

Outputs

Inspection basis

Integrations

Safety model

Not for

Tutorial and platform embeds stay attached to product context.

YouTube

Discord

LinkedIn

Fab

All essential product signals in one place.

Practical boundaries.

Static information page.

Open the channel that matches the next question.

Fab listing

GitHub documentation

Discord support (primary)

Plugin support email

LinkedIn company context

Nearby tools in the catalogue.

Internal Index Service

Unified MCP Server

Tiny Tool Execution Runtime

Continue through the catalogue.