AI Studio

AI Studio has two modes, toggled at the bottom-left of the composer: Chat and Generate.

Chat: the agent operates your project#

The agent uses Mosael's MCP tools to see your project and propose changes: searching media, arranging the timeline, kicking off generation, even publishing.

• Confirmation cards: any action that would mutate project / external state pops a confirmation card and only lands after you approve.
• Choice cards: at a genuine fork — two or three routes all make sense and which one is right depends on what you want (which platform to publish to, which style) — it lays the options out for you to pick, single or multi select, with an "other" box and a skip. Skipping means it continues on its own judgement rather than asking again. A confirmation card can be set to "always allow in this session"; a choice card cannot — it is asking precisely because it does not know, and auto-answering would mean it made the answer up.
• Skills: preset skills (opencode-style) are available at the bottom-left of the composer.
• Attachments: images on the current message go straight to the selected model. Images and videos imported into the media library are analyzed by analyze_asset with the current session model, not a separate hidden vision model.
• The left column lists conversations; each is independent and can be renamed / deleted.

The editor, workflow canvas and boards reuse this same session pool in a compact assistant panel. Its top-left heading is the current conversation title; click it to search or switch sessions. Long titles ellipsize, and the control stays visually flat rather than adding a framed selector.

Under the hood it hosts an external coding-agent CLI (opencode-style), not a home-grown chat loop. Requires model providers to be configured.

The composer keeps only what you look at every turn#

The composer row carries just the things you touch on every message: the Chat / Generate toggle, attachments, the model, and send. Everything else lives behind the slider icon in session settings — the set-once-and-forget things:

• Thinking: off / low / medium / high. When on, the model's reasoning streams into a collapsible block you can expand, and it auto-collapses when done. "Off" only means we don't ask for it: models that reason regardless (k3, DeepSeek reasoner) still have their thinking shown.
• Video analysis mode:
  • Auto: an API-key model uses native whole-video input when its Adapter supports it; otherwise Mosael samples frames and includes any existing speech transcript. Subscription/OAuth models use sampled frames through the tool-free Gateway and need no service address.
  • Native video: forces whole-video input. The OAuth Gateway has no video block, so this fails with a clear suggestion to use Frames instead of silently changing model or mode.
  • Frames + transcript: always samples the timeline and sends existing transcript text to the current vision model alongside those frames.
• Context: a meter with "N% left", plus Compact context now.

What happens when the context fills up#

Once a conversation runs long, the app has the model summarize the earlier turns and keeps the recent ones, freeing room to continue. This is never silent — a record stays in the conversation saying how many messages moved out and roughly how many tokens were freed; expand it to read the summary itself.

• It triggers at 80% of the selected model's context window. Windows differ per model and are editable in model settings.
• You can compact on demand instead of waiting — it costs one model call, so it's an explicit button rather than something that fires on its own.
• The meter is anchored on real usage reported by the vendor (the last call's input + output); only messages newer than that are estimated.

Trajectory: what it did, and where the time went#

The conversation answers "what it said". The Trajectory tab answers a different question: what it did, and where the time went.

Three lanes (input / model / tools) compress the whole session into blocks, with two projections: sequence gives every record equal width (needs no timestamps, so it is always drawable), and duration lays them out by real elapsed time with the idle gaps squeezed out. Below is a step-by-step ledger; open a step to see its arguments, result and timing.

The trajectory also carries the half the conversation never shows:

• The system prompt, recorded only on the turns where it changed. It is not a constant — cross-session memory and the current task plan are interpolated into it, so it differs almost every turn, and when you are asking "why did it suddenly do that", this is the first place to look.
• Context injection as its own row. What goes to the model is "what you typed + this context", so the question you see in the trajectory is the one the model actually received.
• Per-turn token detail (input / output / cache reads) on the turn header. With no usage records it is blank rather than 0 — "not recorded" and "spent nothing" are different facts.

Subagents: handing off an investigation#

The agent can hand a self-contained piece of work to a subagent — read-only tools, its own context. Only the conclusion comes back. What that saves is context, not compute: a search that would have spent forty turns rummaging through files spends them somewhere else, and your main conversation receives the answer instead of the rummaging.

• Dispatch does not block. The agent gets a receipt immediately and keeps working; whether and when to wait is its own decision. Dispatch several in one message and they run concurrently.
• Nothing is lost. Reports it never waited for are delivered at wrap-up.
• Each subagent is a session you can open, with the same interface as the main conversation — from the right-hand panel or the header. You can watch it work, step by step, while it runs.

Agents in different sessions can also @-notify each other. An idle recipient starts immediately; a busy one queues the message and picks it up when it is free. Messages that arrive this way carry a "from another agent" badge, so a conversation never looks like it talked to itself.

Generate: text-to-image / text-to-video#

In Generate mode the left column is the generation model catalog, the middle is the results feed, and the composer takes your prompt:

Switch between chat and generate in one click — describe the shot in the bottom input, tune engine parameters on the right; results can be sent straight to the media library:

• Pick a model → write a prompt → send; the job queues and finished results land in the media library.
• Whether a model can run depends on its vendor's key being configured; with no usable model, a banner at the top links to settings.

The controls follow the model#

Not every model takes the same parameters: Wan wants a pixel pair like 832*480, Seedance wants a tier like 720p; some let you pick a duration, some have exactly one. So the right panel shows only what this model actually supports — switch models and the controls switch with it. Manually entered models that are not in the built-in capability catalog remain usable, but Open Studio does not guess their duration, resolution, or media-input rules from another model by the same vendor.

First frame, last frame, reference#

Image-to-video is more than "here's a picture":

	What it means
First frame	Start moving from this image
Last frame	Give it together with the first and the model animates from one to the other
Reference	Not a starting frame — a style or subject reference

Again, only models that support these get the controls. Each takes either an image from the media library or a pasted link.

Asking the agent works the same way: "use these two images as first and last frame for a 5-second clip" and it will check what the model supports before sending — passing a parameter the model does not accept is rejected outright rather than quietly producing something else.

Feishu (Lark) binding#

Settings → Feishu bot connects the agent to Feishu so you can chat from there.

Changes that need confirmation arrive as a card in that same Feishu chat — approve or reject without leaving Feishu.

Who may approve follows the account binding: whoever taps the button must already have their Feishu account bound to an Mosael account, and must still be a member of the workspace. Everyone in a group chat can see the card; seeing it is not permission to approve it.

Two developer-console settings are required for this (neither is settable via API, so one-click bot creation cannot do it for you): subscribe to card.action.trigger under Event Subscriptions, enable Interactive Card under App Features → Bot, then republish the app. Until then the bot falls back to a plain-text notice telling you which switches to flip.