Provider Access & Dependencies

Start with a healthy provider setup

Many DreamCreator capabilities depend on a working model provider. Chat, research, subtitle translation, and automation all assume that at least one provider is configured correctly.

A complete provider setup usually means:

• API key or equivalent credential
• correct endpoint
• available model list
• enabled models
• clear knowledge of which models support tools

If those layers are incomplete, many features may appear present while still being unusable in practice.

External tools determine whether media and execution workflows can land

DreamCreator does not hide every capability inside the app binary. Important workflows depend on external tools such as:

• yt-dlp for download and source resolution
• FFmpeg for transcoding, muxing, and subtitle burn-in
• bun for parts of the runtime and tool execution
• playwright for web automation

That means “the app opens” is not the same as “the workflow is ready.” Operational readiness depends on installed dependencies, valid paths, and healthy versions.

Skill and tool dependencies are part of the environment too

If you enable skills, external tool search, or deeper execution flows, those are also part of dependency management. When a capability disappears, it is often better to check the runtime environment first rather than only the screen where the failure appears.

What local-first means in practice

In DreamCreator, local-first is not only branding. It means:

• provider settings and tool state stay on the machine
• downloads, subtitle assets, and workspace files live in your own file structure
• failures can be debugged through local tasks, files, logs, and configuration

That is one reason the product fits ongoing work better than one-off web utilities.