Home › Roadmap
SeasonStudio today is eight generators sharing a window. The direction of travel is a studio that remembers what you did, helps you say what you want, and can carry out a whole piece of work rather than one step of it.
Four horizons, ordered by confidence rather than by date. Horizon 0 is in your hands now. Horizon 1 is what we are building. Horizon 2 is where we intend to go. Horizon 3 is honest speculation. Nothing here carries a delivery date, because a roadmap with dates is a marketing document.
The ground the rest of this page stands on. Eight modalities, two local inference stacks, two content safety gates, and no account anywhere.
Text, translation, image, video, music, transcription, speech and vision, sharing one layout, one results panel and one set of habits.
llama.cpp, stable-diffusion.cpp, GGML and ONNX Runtime, with CUDA, DirectML, Vulkan, Metal and CoreML where the hardware offers them.
A run names the single file it is missing. No pre-provisioning, no model zoo you did not ask for.
One codebase, built on the same SeasonEngine foundation as its sister application, shipping through both desktop stores.
Making a good afternoon repeatable.
The gap we hear about most is not a missing modality — it is that a lucky result is hard to get back to. This horizon is about memory, guidance and the small editing moves that currently send you to another application.
Every run saved locally with its model, prompt, seed and settings, so a result can be reopened, adjusted and re-run weeks later. Today the studio shows you only what the current run needs; the intent is a history you can walk back through, entirely on your own disk. This is the single most requested thing, and the first thing we are building.
One place to see what is on your shelf, how much space it takes, which panel it belongs to and what its licence permits — instead of reasoning about a folder of large files.
Describe what you want in ordinary sentences and let the local language model turn it into a prompt shaped for the model you actually chose. The Text panel can already do this by hand; the point is to make it part of the panel you are standing in.
Crop, straighten, adjust levels, trim a clip, fade an edge. Not a photo editor and not a sequencer — just enough that a finished result does not need a round trip through another application before you can use it.
Save a configuration you like as a named preset, and run a prompt across several seeds or several sizes in one go, so exploring costs one decision instead of ten.
One sentence, a whole piece of work.
Today you drive eight tools. In this horizon the studio can drive them for you: you describe the outcome, and a local agent plans the steps, moves material between panels, and comes back with something whole for you to judge.
"Make me a thirty-second opener for a storybook video: three illustrations in one style, a narrated line over each, and an ambient bed underneath." The agent decomposes that, picks models, runs the panels in order, and presents the result with every step visible and re-runnable. Running on your machine, on your shelf, with nothing dispatched anywhere.
A transcript straight into Text, a caption from Vision straight into Image, a finished still straight into Video, a script straight into speech. Today that is copy and paste; it should be one action.
Characters, palettes, reference images, voices and recurring style notes, kept per project and reusable across every panel — so a series looks like a series without you re-typing its identity each time.
Mesh from a prompt or from a reference image, exported in formats the rest of your pipeline already reads. This is the point where the sister engine becomes more than a shared foundation: SeasonEngine renders glTF natively, so a generated asset has somewhere to go the moment it exists.
Panels in order, with consistent characters and a shared palette, so image generation can serve narrative work rather than single frames.
A design suite, if the field keeps moving.
Everything below depends on models that either do not exist yet or do not yet fit on a desktop. We list it because it is the direction we are steering, not because it is promised.
Rigging and motion for a generated mesh: a skeleton inferred automatically, weights fitted, and a clip driven from a description or a reference. Together with 3D generation this is the longest-standing item on our own list, and the one that would most change what the studio is for.
Some work needs a model that will never fit on a laptop. If we add the ability to send a single run to a hosted API, it will be opt-in per run, off by default, clearly marked while it is happening, and never a requirement for anything the app does today. Local first is not a phase we are passing through — it is the product.
The codebase already targets mobile; the constraint is that phone-class hardware suits some of these panels and not others. A mobile release would start from the tools that genuinely work there rather than pretending the whole studio fits.
Cleaner hand-offs to the tools designers already use, and a way to add your own step to a workflow. Shape to be determined by what people are actually doing with the app.
Generated assets — textures, meshes, animations, audio — dropping into a SeasonEngine project without a conversion step. Two applications, one foundation, and the sister relationship finally doing some work.
A roadmap is more useful when it also says what will not happen. These are decisions, not omissions.
The studio should get better at understanding you, not better at collecting you. — the line we check new features against