list_series

pro.aicut/aicut · Verify this server

Lists aicut's AI Video Story series (niches): episodic short-video formats with an authored identity - e.g. fruit dramas, transformation stories - that generate a whole multi-scene episode from one idea. BROWSING IS `browse_series`' JOB, NOT THIS TOOL'S - AND THAT IS THE FIRST THING TO GET RIGHT HERE. When the USER is looking at the catalogue or deciding which series to use ('what series do you have', 'show me the options', 'what can you make'), call `browse_series` FIRST and let the card answer: the catalogue is VISUAL, every tile carries that series' own preview still and its demo clip, and a series is chosen BY EYE - the taglines all sound plausible and the art does not. Answering such a question out of this tool's text is the wrong shape even when the text is correct. THIS TOOL IS THE DATA READ behind that choice - prices, the duration ladder, the fields a quote or a create has to be validated against - and the fallback where the client cannot render cards at all. Come here with `series_id` once a series is settled. TWO CALLS. WITHOUT `series_id` you get the COMPACT CATALOG - every series' `id`, `kind`, `name`, `tagline`, `preview_url` + `preview_video_url` (the series' own art - see PRESENTING), `rank` + `badge` (the picker's own ranking), `frames_first` (whether the staged story create can serve it TODAY), `cast` (`required` / `writer_owned`), `defaults.video_model`, and `episode_tokens` (`seconds` + a `min`-`max` token range for one episode at that default length). `episode_tokens` COVERS THE START FRAMES AND THE SCENE VIDEOS ONLY - the cast portraits and the final render are extra, so it is the pitch figure for what the episode itself costs and is always an understatement of the all-in. `cast`, `defaults` and `episode_tokens` are each NULL on a series the catalog cannot fully describe - say nothing about its cost and fetch its full entry instead of guessing a number. That is a SHORTLIST, and it is all it is: it deliberately carries no duration ladder, no per-model prices and no create arguments, because the full catalog is half a megabyte and does not fit in a tool result. WITH `series_id` you get that ONE series IN FULL, and you MUST make this call before you quote a price or create anything. It adds `scene_count` (min/max/default), the idea-input descriptor with `has_idea_presets`, the `duration` block, the complete `defaults` (video / start-frame / portrait models AND the `language` the series is written in) and the whole `pricing` block described next. Never quote money off the compact list: `episode_tokens` is an orientation figure for a one-line pitch, not a quote. PASS `video_model` WITH IT. A full entry ships the priced duration ladder for EVERY video model the series offers - around ninety rungs - and you need exactly one: the model you are going to create on. `video_model` returns only that model's block, which is the difference between a large result and a small one on the call this tool makes mandatory. Pass the series' `defaults.video_model` unless the user named a model; omit it only when you genuinely mean to compare models. A model the series does not publish is refused with the ones it does, so an id you guessed never silently returns an empty ladder. TWO BLOCKS ARE INFORMATIONAL - READ THEM, DO NOT TRY TO SEND THEM. `duration` (`fixed_only`, `default_mode`, `default_scene_seconds`, `auto_range`) describes the writer's own per-scene sizing; there is no matching argument on `generate_story_video`, which takes `duration_seconds` off the ladder and nothing else. And `scene_count` (min/max/default) is internal bookkeeping in the same way - see NEVER ASK FOR A SCENE COUNT below. Neither is an input you are failing to set. PRICING, AND THE ONE BLOCK YOU MUST READ - IT ARRIVES ONLY ON THE `series_id` CALL: `pricing.video_models[].durations` is the episode-length PICKER - each option is a real length in `seconds` with the `scene_count` it derives, `frames_tokens` (charged at create), `videos_tokens` (charged at fire) and `total_tokens`. `durations.default_seconds` is the rung to assume. There is also `pricing.start_frame_models` (per-frame rates for the optional advanced pick), `pricing.frame_regen_tokens` (what ONE redraw costs) and `pricing.render_tokens_per_minute` (what the FINAL render costs per rendered minute - a platform rate, the same one `render_story_video` charges at). THE RENDER RATE IS HOW AN EPISODE'S TOTAL GETS A FOURTH LINE: `render_story_video` cannot quote its own price until the scene videos are done, so before then this rate is the only published source - state it as a rate or as a rough figure with a tilde, never as the price. ANY OF THESE BLOCKS CAN BE NULL on a series the catalog cannot fully describe - `durations`, `defaults`, `frame_regen_tokens`, even `pricing` itself. A null is not a zero and never a guess: fall back to `estimate_only` on the tool that would spend, and if `durations` is null this series cannot be sized from here at all (say so and point at the aicut web app). Every figure here is the webapp's own quote for that rung; the authoritative episode quote is still the create tool's `estimate_only`. QUOTE A RUNG HONESTLY - TWO FLAGS, AND THEY ARE NOT THE SAME QUESTION. (1) `videos_estimated` = is the video figure one the writer is HELD to. When it is true the episode writer picks its own scene count and lengths whatever this rung orders, so mark `videos_tokens` with a tilde ('~7.5 T') even when `exact` is true - a rung is routinely both, and today every rung that pins a per-scene length is. (2) `frames_estimated` = the same question for the frames row: true when the rung orders only a total length, so `frames_tokens` is what the expected scene count costs rather than the charge - tilde it ('~2 T'). THE TOTAL takes a tilde whenever EITHER `videos_estimated` or `frames_estimated` is true, because the total is the two rows added. These are the webapp sign-off's own verdicts, so a rung quoted this way reads exactly as its button does. `exact` IS A SEPARATE FLAG AND IT IS TRUE ON EVERY RUNG THAT SHIPS: the price is one number, not a range. If one ever ships with `exact: false`, do not read the price off the rung - call `estimate_only` and quote that. AND ONE FLAG IS NOT ABOUT MONEY AT ALL: `scene_count_estimated` true means `scene_count` is what THIS RUNG DERIVES and not what the episode will contain - the writer picks its own count, which is exactly why the frames figure is loose. Never state such a count as a fact. NEVER ASK FOR A SCENE COUNT. Scenes are a mechanism unit and no tool here takes one: the sizing question is LENGTH in seconds, and the create takes `duration_seconds` off the ladder above. NEVER STATE A SCENE COUNT AS FACT. A rung's `scene_count` is what THAT RUNG DERIVES, not what the episode will contain: the writer sizes the episode itself and routinely lands a scene or two either side - on a rung whose `frames_estimated` is true it is not held to the count at all. So do not say 'at 20s that's 3 scenes'. If the user asks how many scenes they get, answer with the hedge attached - 'the writer decides; this length usually comes out around 3' - and never let a count you stated become a number the user thinks they bought. The count is not a sizing input, not a quote, and not a promise. AND DO NOT VOLUNTEER IT AT ALL: `scene_count` is internal bookkeeping that rides these responses so the machinery can be reasoned about, not a fact the product tells anyone - the webapp never shows a user a scene count and never asks for one, so neither do you. Answer it only if the user asks, with the hedge above, and never open a sizing question with it. DEFAULTS RULE: use each series' `defaults` (the `series_id` call) unless the USER names a model. Do not interview the user about options they did not ask about - the defaults are what the series is tuned for. ONE CARVE-OUT (and it is parity, not an exception): the two models that DRAW THE PICTURES - the start-frame model and the cast portrait model - are visible pickers in the webapp, so name each once, in the line where you are already asking something, with the default and its price already chosen. Name it; do not wait on it. `defaults.language` is the language the series is WRITTEN IN (some are German formats): use it, and only raise language at all if the user asks for a different one. When `defaults` is null the series names none - omit the model arguments and let the create resolve them. PRESENTING, WHERE THERE IS NO CARD - on a client that renders one you should not be here, you should have called `browse_series`. The compact list ARRIVES SORTED in the aicut picker's own order, ranked by real usage, so the first few entries ARE the shortlist. (`rank` is each series' position in the webapp's full picker, so the numbers can start above 0 and skip: some series are not served here at all.) When the user asks broadly (what formats exist, what should I make), present a SHORTLIST of 3-5: the TOP MATCHES by that published rank among the ones that fit their ask, name + one-line pitch + `episode_tokens` as a rough cost ('~10 T for 30s') each, plus a count of the rest. `badge` is worth one word when it is there. DO NOT PASTE `preview_url` OR `preview_video_url` INTO THE CHAT. Written as a markdown image a preview renders as a grey placeholder the reader has to click, and a preview clip written as a link is a trip to a browser tab - which is the exact reading experience `browse_series` exists to replace, and shipping it as a fallback taught the card's own catalogue to look broken. Describe the series in words here and offer the card: an 'I can show you these' followed by `browse_series`. NEVER dump the whole catalog into chat, and never fan out `series_id` calls across the shortlist - fetch the one series the user picks. WHEN: the user is BROWSING or deciding which series to use - `browse_series` first, not this tool. Call this one with NO arguments only where the client cannot render the card, or when what is wanted is catalogue DATA rather than a look at the catalogue; call it with `series_id` as soon as one series is settled, before you price or create anything. THE STAGED FLOW this catalog feeds: pick a series, then INVENT episode ideas yourself and settle one with the user in chat - offer 3 of your own in one line each and sharpen from their reaction; `list_series_ideas` is the series' own preset cards and is for when the user asks for THOSE, not the default opening move. The idea is one short paragraph and the engine writes the scenes, never you. Then the staged tools take it from there: `generate_cast` (the FREE roster draft) and `generate_cast_portraits` (the PAID faces) on a series whose `cast.required` is true, then `generate_story_video` (the start frames generate and the run PARKS for review), `regenerate_story_frame` for frames the user dislikes and `set_scene_kept` to cut one, `fire_story_video` (the scene videos), then `render_story_video` (the final file). BREVITY: lead with the ONE decision you need from the user, and keep at most one short paragraph before the question. Never re-explain the staged flow (cast -> frames -> fire -> render) once it has been explained in this conversation - after that, name only the next step. When suggesting episode ideas, offer at most 3, one line each. OUTPUT: this returns JSON for you to read. When you report back to the user, give them the media URL plus a one-line summary. Do not paste the raw JSON, job ids, or internal field names into the conversation.