本文へ移動
cccskills
無料GitHub で公開

odyssey-interactive-video

Plan and scope production work with Odyssey's real-time interactive video world models (odyssey.ml — Odyssey-1/Odyssey-2/Starchild-1/Agora-1). Use when a request involves generating video that a user steers live with keyboard, text, speech, or controller input (streamed frames that respond in the moment), or when someone must decide between Odyssey-style interactive generation and offline clip generators (Sora/Veo/Kling) or downloadable 3D / game engines. Covers what is verified versus announced, current access routes, latency and coherence limits, feasible-now versus speculative use cases, pricing/access terms, and content/rights considerations. This is a fast-moving research-stage product; the skill teaches honest scoping, not a promise of production reliability.

インストール方法を見る

含まれるファイル(2)

  • SKILL.md22.0 KB
  • EVAL.md12.0 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Odyssey interactive video (world models)

What this skill is for

Odyssey builds world models: systems that generate video one frame at a time in real time, conditioned on the history of frames plus whatever input a user is streaming right now. The output is not a finished clip you download — it is an interactive stream the user drives. This skill helps an agent scope, plan, and honestly advise on projects that use (or consider using) Odyssey's models.

Use it when a request looks like:

  • "Can we build an explorable AI world / playable dream the user walks through?"
  • "Real-time interactive video that reacts to typed prompts or a controller."
  • "Should we use Odyssey or Sora/Veo for this?" (interactive vs. offline decision).
  • "Prototype an interactive environment / experiential installation / live demo."

Do not route here for: offline text-to-video clips you render once and download (that is Sora/Veo/Kling/Runway territory), exportable 3D assets or meshes (that is a 3D-asset or game-engine pipeline), or captioning/editing existing footage. Odyssey produces no downloadable clip and no exportable geometry by default — if the deliverable is a file to hand off, interactive video is usually the wrong tool. See "Production decision" below.

Maturity flag, read first. Odyssey's own CTO Jeff Hawke describes the field as "the GPT-2 era of world models" and "a phase of mass exploration, not mass commercialization" [Secondary, The Data Exchange, verified 2026-07-10]. Treat every capability here as research-grade. Prototypes, demos, art, and experiments are feasible today; SLA-bound production pipelines generally are not. Say this plainly to any user with a production deadline.

Evidence labels used below

  • [Documented] — stated in Odyssey's own model pages / technical reports.
  • [First-party claim] — Odyssey's own performance/capability assertion (marketing or blog), not independently verified.
  • [Secondary] — reputable press or analyst reporting.
  • [Heuristic] — production judgment from the nature of the technology, not a cited fact.

All volatile facts (model names, latency, access, pricing) are dated verified 2026-07-10 unless noted. Re-verify before relying on them — this product changes on a scale of weeks.

What "interactive video" means operationally

A traditional video model (Sora, Veo, Kling) is bidirectional: it plans a whole clip with knowledge of its own future frames, so it takes seconds-to-minutes to produce a few seconds of fixed video. You cannot change it mid-generation.

Odyssey's models are causal and autoregressive: each new frame is predicted only from past frames and past/incoming user actions, then streamed immediately [Documented, odyssey.ml/introducing-odyssey-2]. Consequences an agent must internalize:

  1. The user is in the loop continuously. Input (keypress, mouse, typed text, speech, controller) is fed in mid-stream and changes what comes next. Odyssey-1 explicitly likens this to "reacting to what happens"; Odyssey-2 likens prompting during playback to "conversing with a language model" [Documented].
  2. Latency is per-frame, not per-clip. Odyssey-1: a new frame roughly every 40 ms (up to ~30 fps) [Documented, 2025-05-28]. Odyssey-2: ~50 ms/frame, ~20 fps [Documented]. Starchild-1: synchronized audio+video up to 24 fps [Documented, 2026].
  3. Every frame is generated, not composited. Odyssey states "every frame is absolutely generated by a diffusion model we've trained" — no game engine, no pre-authored 3D assets, no meshes [Documented/Secondary, TechCrunch 2025-05-28].
  4. Coherence is bounded and drifts. Streams stay plausible for a bounded window, then degrade. See "Capability limits."

Current model lineup (verified 2026-07-10)

Odyssey (odyssey.ml) is a world-model research lab; founders Oliver Cameron (CEO) and Jeff Hawke (CTO) come from autonomous driving, and Pixar co-founder Ed Catmull sits on the board [Secondary, TechCrunch]. The public model family, oldest to newest:

ModelFirst publicWhat it isInteractive inputFrame rate / latencyAccess route
Odyssey-12025-05-28First "playable world model"; action-conditioned next-frame predictor. Narrow-distribution, deliberately traded generality for autoregressive stability. Described by Odyssey as "a glitchy dream — raw, unstable."keyboard / touch / joystick~40 ms/frame, up to 30 fps, 5+ min coherence claimedSuperseded (research preview)
Odyssey-2 (API tier: Odyssey-2 Pro)2025-10-27 blog"General-purpose world model that dreams AI video instantly you can interact with." Steered by natural-language prompts during playback.typed natural-language prompts (+ actions)~50 ms/frame, ~20 fpsWeb: experience.odyssey.ml · API: developer.odyssey.ml (emerging)
Starchild-12026-05-17First multimodal world model — synchronized audio + video, generated autoregressively; environments, dialogue, ambient sound evolve from streaming input.streaming text, speech, or actionup to 24 fps, synced A/VPreview + technical report at odyssey.ml (starchild.odyssey.ml/starchild-1.pdf)
Agora-12026Multi-agent world model: up to 4 players in one shared simulated environment (a GoldenEye-style deathmatch demo), each player's viewpoint rendered live. Decouples world-state simulation from per-view rendering.multiple players' actionsreal-time per-viewPlayable at agora.odyssey.ml
PROWL-12026Reinforcement-learning framework for exploring game environments (research paper, arXiv 2605.18803). Research artifact, not an interactive product.n/an/aarXiv paper

[All rows Documented from odyssey.ml model pages / homepage, verified 2026-07-10.]

Naming heuristic for agents: "Odyssey" alone in 2026 usually means Odyssey-2 (the live general-purpose experience). If a user says "the interactive video thing from Odyssey," default to Odyssey-2 and confirm. Starchild-1 is the one to name when sound matters; Agora-1 when multiplayer/shared state matters.

Access routes today — verify carefully, do not assume an API

This is the area most likely to be misstated. As of 2026-07-10:

  • Web experiences are the reliably public route. experience.odyssey.ml (Odyssey-2) and agora.odyssey.ml (Agora-1) are publicly playable in a browser [Documented, odyssey.ml homepage]. This is the safest thing to point a user to today and the right way to evaluate the model before committing.
  • An API exists but is early/emerging. There is developer-facing documentation at documentation.api.odyssey.ml and a dashboard at developer.odyssey.ml/dashboard describing an Odyssey-2 Pro API with three surfaces: interactive streams (real-time), viewable/broadcast streams, and a Simulate endpoint for offline/batch scripted generation [Documented, API docs, verified 2026-07-10]. Authentication is via an API key (keep server-side; browsers connect with short-lived credentials). It references session/concurrency limits and stream-duration limits (a "credit lease expired" error), a Discord, an API License Agreement, and support@odyssey.ml.
    • Caveat an agent must surface: Odyssey's own homepage did not prominently advertise the API on 2026-07-10, and the Odyssey-2 launch blog originally said the API was "coming soon." So treat API availability as real but nascent — confirm current status, quotas, and terms directly at developer.odyssey.ml before promising an integration. Do not assume stable endpoints, versioned SDKs, or uptime guarantees.
  • Starchild-1 and PROWL-1 are, as of this date, research/preview + technical report — a report and preview, not a documented general API tier. Do not promise programmatic Starchild-1 access without checking.

[Heuristic] What to tell a user about access: "You can try it yourself right now in a browser at experience.odyssey.ml. Programmatic/API access via Odyssey-2 Pro is available but early — I'd verify current quotas and terms at developer.odyssey.ml before we design an integration around it."

Capability limits (the honest section)

Every one of these is load-bearing for scoping. [Documented/First-party unless tagged.]

  • Visual fidelity is unstable. Independent and Odyssey descriptions alike report blurred, distorted, dreamlike output; fine detail and text-in-scene are unreliable [Secondary, TechCrunch/eWeek; First-party "glitchy dream"].
  • Coherence is time-bounded and drifts. Odyssey claims "5 minutes or more" of coherent stream for Odyssey-1; Hawke's later framing is more conservative — "one to two minutes" before degradation, up from an earlier "15 to 30 seconds" [First-party / Secondary]. [Heuristic] Plan around ~1–2 minutes of reliable coherence, not 5+, for anything you show a client.
  • World persistence is weak. Because state lives in the model's rolling context rather than a stored scene graph, geometry and layout can shift when you look away and back; objects are not guaranteed to persist. Starchild-1's report explicitly notes "scene and acoustic identity still drift over long horizons" [Documented]. There is no reliable "save this world and return to the exact same place" primitive.
  • Resolution / frame rate are modest. ~20–30 fps; resolution is not headlined by Odyssey and is well below film-finishing quality [Documented for fps; resolution not published — do not quote a number].
  • No exportable asset. You get streamed frames (and, for Starchild-1, audio), not a mesh, not a texture, not a downloadable MP4 clip by default. The Simulate endpoint produces recordings, but the artifact is generated video, not editable 3D [Documented].
  • Per-user GPU cost and infra. Runs on GPU clusters (H100s historically; AWS/Trainium going forward). Odyssey's own 2025 figure was $1–$2 per user-hour of compute, expected to fall [First-party, 2025-05-28]. Every concurrent viewer consumes a live GPU session — this does not scale like serving a cached video file.
  • No quantitative benchmarks for the interactive style yet. Starchild-1's report says standardized benchmarks for this interaction mode "don't yet exist" [Documented]. You cannot cite an FVD/quality number to a stakeholder.

Production decision: interactive video vs. the alternatives

Choose the tool by what the deliverable actually is. [Heuristic framework.]

Pick Odyssey interactive video when:

  • The core experience is live, open-ended user steering — the user's real-time input must change the video, and no fixed script would do.
  • You are building a demo, prototype, art piece, research probe, or experiential/live installation, and dreamlike/unstable aesthetics are acceptable or even desired.
  • Novelty and "the user drove this themselves" is the point (marketing activation, conference booth, playable teaser).

Pick an offline video generator (Sora / Veo / Kling / Runway) instead when:

  • You need a finished, downloadable clip with controlled composition, fixed length, and repeatable output.
  • Visual fidelity, brand-safe detail, legible text, or client-approvable frames matter.
  • Distribution is one-to-many (a file served to thousands) — offline clips scale cheaply; interactive streams do not.

Pick a game engine / downloadable 3D (Unreal, Unity, Gaussian splats, NeRF-to-mesh) instead when:

  • You need persistent, deterministic worlds, exact collision, exportable assets, or the same environment every session.
  • You must ship an asset that runs on the client without a live GPU backend per user.
  • Long sessions (hours) or guaranteed geometry are required.

[Heuristic] One-line litmus test: Does the user need to steer the pixels live, and can you tolerate a dreamlike, non-persistent, GPU-per-viewer stream? Yes → Odyssey. Any "no" → probably an offline or engine pipeline.

Feasible now vs. speculative

Feasible today (research-grade, expectations set):

  • Interactive prototypes and concept demos — "walk through this vibe" explorable moodboards.
  • Experiential marketing / live activations where the novelty of real-time AI worlds is the draw and a staffed, time-boxed session hides drift.
  • Interactive storytelling / "playable dream" art that leans into the surreal, unstable aesthetic rather than fighting it.
  • Rapid ideation — quickly feeling out an environment or mood before committing to a real 3D/production build.
  • Odyssey's own cited proof points: hackathon-style interactive weather apps, game scaffolding [Secondary, Hawke].

Speculative / not reliable yet (do not promise):

  • Shippable AAA-style games or engine replacements.
  • Brand-safe, pixel-controlled advertising deliverables requiring legible logos/text and approvable frames.
  • Persistent multiplayer worlds with durable state (Agora-1 is an early multi-agent demo, not a live-service platform).
  • Long-form (hours) coherent experiences.
  • Anything needing an exportable asset, SLA, or guaranteed reproduction of the same world.

Pricing and access terms

  • No published consumer price tiers as of 2026-07-10. Pricing signal is usage-based and tied to live GPU consumption; there is a credit/lease model referenced in the API docs ("credit lease expired") [Documented].
  • Historical compute reference: $1–$2 per user-hour (Odyssey's own 2025 figure, expected to decline) [First-party]. Treat this as an order-of-magnitude cost driver, not a current quote.
  • Web experiences are free to try in-browser [Documented].
  • [Heuristic] Always get a current quote from developer.odyssey.ml before budgeting — and budget per concurrent-user-hour, because that is the real cost shape.
  • Company context (affects longevity risk, not per-project pricing): Odyssey raised a $310M Series B on 2026-06-17 (~$1.45B post-money) led by Natural Capital with Amazon, GV, AMD Ventures, IQT, EQT; AWS is the preferred cloud with Trainium chips [Secondary, multiple outlets]. Well-funded, but still pre-commercialization by its own account.

Content, rights, consent, privacy

  • Training data provenance. Odyssey trains partly on its own real-world capture from a proprietary ~25 lb 360° backpack rig (6 cameras, 2 lidar, IMU, ~3.5K, depth metadata), plus other data [Secondary, TechCrunch]. This first-party capture reduces some third-party-scraping concerns but does not eliminate IP questions.
  • Output IP is unsettled. Press coverage flags open questions about who owns procedurally generated worlds and whether output resembling known IP could infringe [Secondary]. [Heuristic] Do not assume commercial-use rights, ownership, or indemnity for generated streams — read Odyssey's current API License Agreement / ToS and get commercial terms in writing before client delivery.
  • Consent/likeness. If a user streams speech into Starchild-1 or the world depicts real, recognizable people/places, apply normal consent and likeness diligence — real-time generation does not exempt a project from these.
  • Privacy of streamed input. Interactive sessions send user keystrokes/speech/actions to Odyssey's servers. For any project handling personal or sensitive input, confirm data-handling/retention terms before deploying.
  • Provenance/labeling. Output is synthetic; label AI-generated experiences per platform and jurisdiction rules.

How an agent should plan an Odyssey project

  1. Confirm the deliverable is genuinely interactive. If the user actually wants a file to download, redirect to an offline generator or 3D pipeline before going further.
  2. Set maturity expectations up front — GPT-2 era, dreamlike, ~1–2 min coherent, non-persistent, GPU-per-viewer. Put this in writing.
  3. Pick the model: Odyssey-2 (general, prompt-steered) → default; Starchild-1 → sound needed; Agora-1 → shared/multiplayer.
  4. Evaluate hands-on first at experience.odyssey.ml / agora.odyssey.ml before designing anything. Do not design around unseen capability.
  5. Verify access route and terms at developer.odyssey.ml (API status, quotas, session/duration limits, license) — dated, because it changes.
  6. Budget by concurrent user-hours, not by clip.
  7. Design for drift: short sessions, staffed/guided experiences, aesthetics that embrace instability, fallbacks if a stream degrades.
  8. Clear rights/consent/privacy before any commercial or public deployment.

Examples (labeled — these are illustrations, not required formulas)

Example A — Scoping request, agent gives an honest routing answer

Intent: A brand agency asks: "We want a 30-second interactive AI world at our booth where visitors type a mood and walk around it. Use Odyssey. Also we want the final clips for social." Good agent response (essential characteristics):

  • Splits the two asks. The booth experience is a strong fit for Odyssey-2 at experience.odyssey.ml or via the Odyssey-2 Pro API — real-time, prompt-steered, novelty is the point.
  • Flags that "final clips for social" is a different deliverable: Odyssey doesn't hand you a clean downloadable, output is dreamlike/unstable, and it won't be brand-pixel-controlled. Recommend either screen-recording the live session (accepting the aesthetic) or generating the social cut separately with an offline model (Veo/Sora/Kling).
  • Sets expectations: ~1–2 min coherent, non-persistent geometry, ~20 fps, GPU cost per concurrent visitor, staffed booth to manage sessions.
  • Notes access/terms verification and rights/consent before public use. Why structured this way: the failure mode here is silently promising a clean downloadable social asset from an interactive model. The value is separating "live steer" from "finished file."

Example B — Model selection under a constraint

Intent: "We want an interactive AI experience where a companion character talks back with real voice and ambient sound as the user speaks to it." Expected approach: Sound is central and input is speech, so route to Starchild-1 (synchronized audio+video, streaming speech/text/action input, "narrator/companionship" interaction regime) rather than Odyssey-2 (video-only). Warn that Starchild-1 is preview + technical report stage (verify programmatic access), that acoustic/scene identity drifts over long horizons, and that no interactive-quality benchmarks exist yet. Add consent/privacy handling for streamed speech. Why: picking Odyssey-2 here would silently drop the audio requirement.

Example C — Reality-check on a speculative ask

Intent: "Can we replace our Unity game backend with an Odyssey world model so we don't have to build levels?" Expected approach: No — not for a shippable game today. Explain: no persistent/deterministic world (geometry drifts, no durable state), no exportable assets, no exact collision, coherence bounded to ~minutes, and a live GPU session per player that doesn't scale like a client-side engine. Position Odyssey/Agora-1 as a research probe or prototype for what learned worlds might feel like, and cite Hawke's own "GPT-2 era, not mass commercialization" framing. Recommend a traditional engine for the shippable product. Why: the critical failure is validating an engine-replacement claim the technology cannot support yet.

Sources (verified 2026-07-10)

First-party:

  • Odyssey homepage & model index — https://odyssey.ml/ (models: Odyssey-2, Starchild-1, Agora-1, PROWL-1; web experiences).
  • "Introducing Odyssey-1: A Playable World Model" — https://odyssey.ml/introducing-odyssey-1 (2025-05-28; 40 ms/frame, ≤30 fps, 5+ min claim, $1–2/user-hour, H100 US/EU).
  • "Introducing Odyssey-2: A General-Purpose World Model" — https://odyssey.ml/introducing-odyssey-2 (blog byline 2025-10-27; ~50 ms/frame, ~20 fps, prompt-steered, API "coming soon").
  • "Starchild-1: The First Real-Time Multimodal World Model" — https://odyssey.ml/introducing-starchild-1 and technical report starchild.odyssey.ml/starchild-1.pdf (announced 2026-05-17; synced A/V ≤24 fps; long-horizon drift noted).
  • Odyssey API documentation — https://documentation.api.odyssey.ml/ and developer.odyssey.ml/dashboard (Odyssey-2 Pro; interactive streams / viewable-broadcast streams / Simulate; API key auth; session & duration limits).

Secondary (labeled as reporting):

Note: model names, latency, fps, access routes, and pricing are volatile; re-verify at odyssey.ml and developer.odyssey.ml before relying on any of them.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Production guidance for reusable layered 2D character rigs in browser-rendered and video media. Use for SVG hierarchies, pivots and constraints, FK/IK planning, pose and facial libraries, acting, cycles, deterministic handoff, crop variants, and rig QA; not for character concept continuity, 3D armatures, or motion-capture solving.

日本語の概要は準備中です。原文の説明を表示しています。

calesthio/generative-media-skills2022026年7月14日 更新

Use this skill to turn generated, captured, scanned, or modeled 3D output into production-ready standalone assets for DCC, real-time engine, web, or interchange delivery. It covers requirements, topology repair, scale and axes, UVs, PBR baking, LODs, static and skeletal readiness, rig handoff, optimization, glTF/USD/FBX delivery, validation, QA, and rights/provenance. Do not use it for provider-specific generation prompts, full scene/world building, mocap operation, or exact CAD/manufacturing work.

日本語の概要は準備中です。原文の説明を表示しています。

calesthio/generative-media-skills2022026年7月14日 更新

ace-step

無料

Use ACE-Step and ACE-Step 1.5 for local or hosted AI music generation, including text-to-music, lyrics-to-song, instrumental beds, covers, repainting, stem/track extraction, track completion, LoRA personalization, REST/Python/Gradio workflows, rights review, and music integration for video, ads, games, and social content.

日本語の概要は準備中です。原文の説明を表示しています。

calesthio/generative-media-skills2022026年7月14日 更新

Use Adobe Firefly Services to generate, edit, expand, fill, match, composite, and upscale still images through the current REST APIs. Apply when selecting Firefly Image 5 versus Image 3/4 or custom models, implementing authenticated asynchronous image workflows, using style or structure references, building product composites, handling provenance and enterprise rights, or diagnosing Firefly image jobs in production. Exclude Firefly video, audio, and unrelated Creative Cloud APIs.

日本語の概要は準備中です。原文の説明を表示しています。

calesthio/generative-media-skills2022026年7月14日 更新

Plan, prompt, call, edit, iterate, and productionize Alibaba Cloud Model Studio image generation with current Wan 2.7 Image, Qwen-Image 2.0, and Z-Image Turbo models. Use for Alibaba/DashScope text-to-image, multi-reference generation, instruction editing, character-consistent image sets, typography and layout work, regional authentication, model selection, API integration, cost/rate-limit planning, troubleshooting, safety, rights, privacy, and output QA.

日本語の概要は準備中です。原文の説明を表示しています。

calesthio/generative-media-skills2022026年7月14日 更新

Plan, implement, and review Alibaba Wan video generation using Alibaba Cloud Model Studio/DashScope hosted APIs or official Wan 2.1/2.2 open-weight checkpoints. Use for Wan text-to-video, image-to-video, first/last-frame or continuation, reference-to-video, video editing, speech-driven video, character animation, regional deployment, billing, licensing, and production safety.

日本語の概要は準備中です。原文の説明を表示しています。

calesthio/generative-media-skills2022026年7月14日 更新

calesthio のスキルをすべて見る

このスキルの問題を報告する