Home / Local AI
The local AI layer
Text, image, speech and vision models running on the user's own device, inside a C# application, with the native dependency problem already solved. It sits beside the engine, not inside the renderer — and it is the last thing on this site for a reason.
Where this sits, and why it is last
If you came here to evaluate a renderer, you can stop reading now and lose nothing. The engine does not depend on any of this. The web build does not contain any of it. Nothing in Features or Getting started requires a model file, a GPU runtime or a purchase.
The foundational inference libraries — SeasonONNX,
SeasonGGML, SeasonTTS,
SeasonVision and SeasonAudio
— are MIT, like the engine. SeasonAI, the layer that
turns them into task-oriented panels, is the commercial part, and
it is not in this repository. What you can read here is the seam:
Apps/Engine/Panels/SeasonAI/ holds the open-source
AIButton, AIPanel and
AINotice that the closed layer plugs into.
That arrangement is deliberate and stated up front because the alternative — an engine page that quietly pivots into a paid feature — reads as an advertisement wearing an open-source badge. If the split bothers you, the engine without it is complete and permissively licensed, and that is not a consolation prize.
What the contribution actually is
Not another inference backend. Not a better model. The claim is narrower and more boring: making dependency-heavy local models practical inside a shipping desktop application. One API over both ONNX Runtime and GGML, native runtimes whose versions are known to agree with each other, and CUDA / cuDNN binaries packaged into the build instead of an install guide handed to the user.
TextTranslateImage VideoMusicTTS STTVision
Eight modalities, one application, no Python environment. That is the whole pitch. Models and runtimes → covers which formats and execution providers are behind each one.
Image generation, running locally inside Apps/Engine
The honest gap
Eight generation capabilities ship. None of their output can currently be bound to anything in the scene. Results are displayed inside the AI panels and stop there. There is no path from a generated image to a material texture, no generated-asset folder with a stable layout, and no way to send a selected object's texture back into image-to-image as a reference.
Which means that today, functionally, this is a local generation utility that happens to be bolted to a renderer. Closing that gap is the highest-return item on the AI roadmap, and it is also the only defensible answer to the obvious question below.
"Why not just use ComfyUI, which is free?"
It is a fair question and it deserves a real answer rather than a feature table. For generating an image, ComfyUI is free, excellent, and has a larger node ecosystem than this will ever have. So do A1111, Forge, Fooocus, LM Studio, Ollama and Jan in their respective lanes. Every headline capability here has a free, actively developed alternative.
The difference is the audience and the location. This is aimed at a developer who wants generation to happen inside their own C# project — reachable from an API, surfaced through UI panels they can configure, in source they can modify. Not a separate application to alt-tab into and copy files out of.
| If you want to… | Use |
|---|---|
| Generate the best possible image, with full control over the graph | ComfyUI. Genuinely. |
| Chat with a local model | LM Studio or Ollama |
| Call local inference from C# without shipping a Python environment | The MIT libraries below the AI layer |
| Ship an application where generation is a feature your users see | This, once the asset path in the roadmap exists |
The eventual argument — the one that no standalone tool can answer — is that ComfyUI cannot select an object in your scene. That argument is not available yet, because the asset path described above does not exist. It is listed as a plan, not as a feature.
How it reaches the application
The bridge is small enough to describe in a paragraph. The reference application hosts
Season.AI.Panels.AIButton, which opens
Season.AI.Panels.AIPanel. That panel owns a
Texts entry per modality — text, translate, image,
video, music, stt, tts, vision — and swaps a
currentPanel underneath. When a capability is not unlocked,
AINotice takes over and presents the tiers.
Apps/Engine/Engine.csproj
<Compile Remove="Panels\SeasonAI\**" /> // excluded from the open build
<ProjectReference Include="..\..\..\SeasonAI\SeasonAI.csproj" />
The Compile Remove is how one source tree serves both builds:
the panel sources are present and readable, but the open build compiles them out of the
application and takes them from the commercial project instead. The consequence is spelled
out on the reference application page — that
unconditional project reference is why Apps/Engine does not
build from a clean clone.
Tiers, as the shipped code describes them
AINotice is open source, so the tier structure is not a
marketing claim — you can read the three entries it constructs:
| Tier | As described in AINotice.cs | Status |
|---|---|---|
| Base Models | "Limited backend support" — free | In the free build |
| All Models | "CUDA support" — premium | Store add-on, not yet published |
| Source Code | "Current & future updates" — premium | Not yet available |
The free tier is base models on CPU and DirectML. What a purchase adds is the larger model set plus CUDA, which is a speed and quality upgrade rather than a new capability — and CUDA only helps NVIDIA hardware. Saying so here rather than in the small print is the only sane way to sell it.
No prices are quoted on this site yet, because neither add-on has been submitted and announcing a number before that is how you end up publicly cutting it. There will be no subscription: inference runs on the user's own electricity, so there is nothing recurring to charge for. The base application stays free.
Where to go next
Models and runtimes
ONNX Runtime and GGML side by side, how CPU, DirectML and CUDA are selected, and what the packaged native dependencies actually weigh.
Where it is going
Generated output into the scene, cloud models with your own key, runtime C# compilation, and why 3D generation is further away than it looks.
Back to the engine
The part of this project that is MIT, complete, and does not need any of the above to be useful.