[BUG] v4.7.10: video_generate() default runway/gen3a_turbo invalid — fails before auth

[Dhivya-Bharathy]

[BUG] v4.7.10: praisonai.capabilities.video_generate() default runway/gen3a_turbo still invalid — fails before provider authentication

Metadata

Field	Value
Repository	https://github.com/MervinPraison/PraisonAI
Release tested	PraisonAI v4.7.10 (db166f427)
Package	praisonai (praisonai.capabilities.videos)
Related	VideoAgent, MCP praisonai.videos.generate, LiteLLM video backends
Labels	bug, sdk-contract, video, litellm, capabilities
Severity	High — documented default cannot run; contradicts praisonai models validate
Component	src/praisonai/praisonai/capabilities/videos.py
Discovered	2026-09-28 regression re-test on latest PyPI release (Windows, Python 3.13)
Prior releases	Same default observed on v4.7.9 — not fixed in v4.7.10
Duplicate search	gh search issues --repo MervinPraison/PraisonAI "runway/gen3a_turbo"

---

Executive summary

The capabilities-layer video_generate() function ships with default model="runway/gen3a_turbo". On PraisonAI v4.7.10 with current LiteLLM, that identifier does not resolve to any video provider. Calls fail immediately with:

litellm.BadRequestError: LLM Provider NOT provided ... You passed model=runway/gen3a_turbo

This occurs before Runway (or any provider) authentication — integrators cannot distinguish “bad API key” from “broken SDK default.”

Meanwhile:

• praisonai models validate runway/gen3a_turbo → ERROR, suggests runwayml/gen4_turbo
• VideoAgent(llm="runwayml/gen4_turbo") → reaches Runway backend (auth errors only with dummy keys)
• OpenAI video catalog uses sora-2 (validates successfully)

v4.7.10 did not update the capabilities default, MCP defaults, or docstrings to match LiteLLM’s runwayml/* namespace.

---

Expected vs actual

Caller	Expected	Actual v4.7.10
video_generate("prompt", api_key=...)	Provider auth / job started	BadRequestError — provider not provided
Default model in docstring	Validates via CLI	Rejected by models validate
Same id in VideoAgent docs	Single canonical Runway id	Docs say runwayml/gen4_turbo, capabilities say runway/gen3a_turbo
Release note for v4.7.10	Fix or deprecate broken default	Unchanged from v4.7.9

---

Root cause

src/praisonai/praisonai/capabilities/videos.py:

def video_generate(
    prompt: str,
    model: str = "runway/gen3a_turbo",
    duration: int = 5,
    aspect_ratio: str = "16:9",
    ...
) -> VideoResult:

LiteLLM video provider resolution expects prefixes such as:

• runwayml/gen4_turbo, runwayml/gen4.5, …
• openai/sora-2 (OpenAI video)
• gemini/veo-* (Google)

There is no runway/ provider alias in LiteLLM’s video config path — hence get_llm_provider() raises before HTTP.

---

Sequence diagram

sequenceDiagram
    participant App
    participant VG as video_generate()
    participant LLM as litellm.video_generation
    participant Prov as Provider resolver

    App->>VG: prompt only (default model)
    VG->>LLM: model=runway/gen3a_turbo
    LLM->>Prov: resolve provider
    Prov-->>LLM: BadRequestError (no provider)
    LLM-->>VG: exception
    VG-->>App: no VideoResult

Loading

---

Minimal reproduction

pip install "praisonai==4.7.10"

python -m praisonai --version
python -c "from praisonai.capabilities.videos import video_generate; video_generate('a red ball', api_key='sk-dummy', timeout=8)"
python -m praisonai models validate runway/gen3a_turbo
python -m praisonai models validate runwayml/gen4_turbo
python -m praisonai models validate openai/sora-2

---

Terminal evidence — v4.7.10 (2026-09-28)

$ python -m praisonai --version
PraisonAI version 4.7.10

$ python -c "from praisonai.capabilities.videos import video_generate; video_generate('a red ball', api_key='sk-dummy', timeout=8)"

Provider List: https://docs.litellm.ai/docs/providers

Traceback (most recent call last):
  ...
  File ".../praisonai/capabilities/videos.py", line 74, in video_generate
    response = litellm.video_generation(**call_kwargs)
  ...
litellm.exceptions.BadRequestError: litellm.BadRequestError: LLM Provider NOT provided. Pass in the LLM provider you are trying to call. You passed model=runway/gen3a_turbo
 Pass model as E.g. For 'Huggingface' inference endpoints pass in `completion(model='huggingface/starcoder',..)` Learn more: https://docs.litellm.ai/docs/providers

$ python -m praisonai models validate runway/gen3a_turbo
ERROR: ❌ 'runway/gen3a_turbo' is not a valid model
INFO: Did you mean one of these?
  • runwayml/gen4_turbo
  • runwayml/gen4_image_turbo
  • runwayml/gen4.5

$ python -m praisonai models validate runwayml/gen4_turbo
SUCCESS: ✅ 'runwayml/gen4_turbo' is a valid model
Capabilities: tool-calling

$ python -m praisonai models validate openai/sora-2
SUCCESS: ✅ 'sora-2' is a valid model
Capabilities: tool-calling

Note: Exit code and emoji output may vary by terminal encoding; the error text is stable.

---

Terminal evidence — contrast matrix (VideoAgent vs capabilities)

Probe with dummy keys — supported models should fail at authentication, not provider resolution.

# capabilities default (broken)
video_generate('probe', api_key='sk-dummy', timeout=8)
→ BadRequestError: LLM Provider NOT provided ... runway/gen3a_turbo

# explicit runwayml (provider resolved)
VideoAgent(llm='runwayml/gen4_turbo', api_key='sk-dummy').generate('probe')
→ APIConnectionError / key format error from Runway (expected)

# explicit OpenAI Sora family
VideoAgent(llm='openai/sora-2', api_key='sk-dummy').generate('probe')
→ AuthenticationError from OpenAI (expected)

This contrast is the smoking gun for SDK maintainers: only the capabilities default uses an unresolvable id.

---

Impact

Consumer	Risk
MCP server hosts	Tool defaults mirror capabilities — broken out of the box
Notebook / script authors	Omit model= → confusing LiteLLM error
CI pipelines	models validate fails default id while docs show it in signature
Technical writers	Docstring example runway/gen3a_turbo is invalid

---

Suggested fix

1. Change default to runwayml/gen4_turbo (align with VideoAgent) or openai/sora-2 if OpenAI-first positioning matches product docs.
2. Update docstrings, MCP adapter defaults (runway-gen3 → canonical id), and CLI --model help text in the same PR.
3. Add unit test: default model string passes ModelCatalogue.validate_model() and LiteLLM video backend probe (mocked).
4. Add release note under v4.7.11: breaking default change for anyone relying on the old string (unlikely in production since it never worked).

---

Acceptance criteria

• video_generate(prompt, api_key=...) without model= reaches provider layer (401/403 acceptable with dummy key)
• praisonai models validate <default> → SUCCESS
• MCP video tool default matches capabilities module
• Changelog documents default change

---

Workaround

Always pass explicit model:

from praisonai.capabilities.videos import video_generate

video_generate(
    "A sunset over the ocean",
    model="runwayml/gen4_turbo",  # or openai/sora-2
    api_key=os.environ["RUNWAYML_API_SECRET"],  # or OPENAI_API_KEY
)

---

Appendix — MCP default drift (static analysis)

MCP extended capabilities historically default to runway-gen3 — a third stale id class. Any fix must update all three surfaces:

Surface	Stale id (observed)	Target
capabilities.videos	runway/gen3a_turbo	runwayml/gen4_turbo or openai/sora-2
MCP videos tool	runway-gen3	same
CLI praisonai videos	sora	sora-2 or openai/sora-2 (see separate issue)

---

Appendix — LiteLLM catalogue probe (conceptual)

import litellm
# Pseudocode for maintainers:
# ProviderConfigManager.get_provider_video_config(model="runwayml/gen4_turbo") → RunwayMLVideoConfig
# ProviderConfigManager.get_provider_video_config(model="runway/gen3a_turbo") → None / error

---

Appendix — test gap

test_video_agent.py may pass 33/33 while never importing praisonai.capabilities.videos. Add:

def test_video_generate_default_model_validates():
    from praisonai.capabilities.videos import video_generate
    import inspect
    sig = inspect.signature(video_generate)
    default_model = sig.parameters["model"].default
    assert ModelCatalogue().is_valid_model(default_model)

---

Appendix — severity table

Factor	Rating
Frequency	High — default code path
Detectability	Medium — error message obscure
Data loss	None
Security	None
Trust / DX	High

---

Appendix — OpenAI catalog alignment

OpenAI’s public catalog lists Sora family video models for API consumers. PraisonAI validates sora-2 but capabilities default to Runway Gen3a turbo under wrong prefix — double misalignment (wrong vendor default + wrong prefix).

---

Appendix — release diff expectation

git diff v4.7.9..v4.7.10 -- src/praisonai/praisonai/capabilities/videos.py
# Expected today: no default change → bug persists

Maintainers should verify on each release until default id validates.

---

Appendix — consumer messaging (docs)

Document a Supported video models table:

Model id	Provider	Validated	Video backend
openai/sora-2	OpenAI	yes	yes
runwayml/gen4_turbo	Runway	yes	yes
runway/gen3a_turbo	—	no	no

---

Appendix — filing checklist

• Reproduce on Linux/macOS CI node (exclude Windows-only factors)
• Link https://github.com/MervinPraison/PraisonAI/releases/tag/v4.7.10
• Search existing issues for duplicate before opening

---

Appendix — extended BadRequestError (full message)

litellm.exceptions.BadRequestError: litellm.BadRequestError: LLM Provider NOT provided. Pass in the LLM provider you are trying to call. You passed model=runway/gen3a_turbo
 Pass model as E.g. For 'Huggingface' inference endpoints pass in `completion(model='huggingface/starcoder',..)` Learn more: https://docs.litellm.ai/docs/providers

---

Appendix — mermaid (three defaults problem)

flowchart TB
    subgraph surfaces [Public surfaces v4.7.10]
        CAP[capabilities video_generate]
        CLI[CLI praisonai videos]
        MCP[MCP videos.generate]
    end
    CAP --> D1[runway/gen3a_turbo invalid]
    CLI --> D2[sora invalid]
    MCP --> D3[runway-gen3 invalid]
    VAL[models validate] --> OK[runwayml/gen4_turbo, sora-2]
    D1 -.->|contradicts| VAL
    D2 -.->|contradicts| VAL

Loading

---

Appendix — post-fix verification

python -c "from praisonai.capabilities.videos import video_generate; video_generate('probe', api_key='sk-dummy', timeout=5)"
# Expect: auth error from Runway/OpenAI — NOT Provider NOT provided

---

Appendix — Runway prefix history (integrator note)

LiteLLM standardized Runway video provider string on runwayml/. Older examples used runway/ or hyphenated runway-gen3. PraisonAI still embeds the oldest form in capabilities defaults — tripping provider resolution before HTTP.

---

Appendix — OpenAI Sora path

Validators accept sora-2. Capabilities Python default does not use it — CLI issue covers sora shorthand. Python default uses Runway instead, splitting OpenAI-first vs Runway-first stories.

---

Appendix — mock-based unit test (sketch)

def test_video_generate_default_reaches_provider(monkeypatch):
    monkeypatch.setattr(
        "litellm.video_generation",
        lambda **kw: type("R", (), {"url": "u", "id": "1", "status": "ok"})(),
    )
    from praisonai.capabilities.videos import video_generate
    import inspect
    default = inspect.signature(video_generate).parameters["model"].default
    r = video_generate("p", model=default, api_key="k")
    assert r.status == "ok"

Test should fail on v4.7.10 until default changes.

---

Appendix — observability

Log structured fields on video failures: model, provider_resolved, exception_class. Today users only see LiteLLM generic provider message.

---

Appendix — docs site updates

Replace all occurrences of runway/gen3a_turbo in:

• Capabilities reference pages
• MCP tool schema defaults
• VideoAgent comparison tables

---

Appendix — release manager checklist

• Verify tag contains fix commit
• PyPI praisonai wheel includes updated videos.py
• Desktop bundle picks up same wheel version

---

Appendix — stack trace anchor (line numbers)

On v4.7.10, failure originates at video_generate → litellm.video_generation → get_llm_provider. Support teams can search logs for runway/gen3a_turbo to identify this bug vs customer misconfiguration.

---

Appendix — customer support macro

Your SDK is using the default video model runway/gen3a_turbo, which PraisonAI 4.7.10 cannot route. Upgrade to ≥4.7.11 (when fixed) or pass model="runwayml/gen4_turbo" / model="openai/sora-2" explicitly.

---

Appendix — PyPI install repro (isolated)

python -m venv .venv-pai4710
.venv-pai4710\Scripts\pip install praisonai==4.7.10
.venv-pai4710\Scripts\python -c "from praisonai.capabilities.videos import video_generate; video_generate('x', api_key='sk-dummy', timeout=5)"

Expect BadRequestError provider not provided on unfixed versions.

---

Appendix — GitHub issue title (copy-paste)

[BUG] video_generate() default runway/gen3a_turbo invalid on v4.7.10 — fails before auth

---

Appendix — labels

bug, sdk-contract, video, litellm, capabilities, regression

---

Appendix — owner routing

Team	Action
SDK	Change default + tests
MCP	Sync tool schema default
Docs	Remove invalid Runway id from examples
QA	Add release gate: default validates

---

End of issue document.

[praisonai-triage-agent]

👋 Thanks for opening this issue, @Dhivya-Bharathy!

A maintainer will review this shortly. In the meantime:

• Make sure you've included steps to reproduce (for bugs)
• Check existing issues for duplicates
• Review the documentation for related guides

Bug and enhancement reports are auto-triaged with Claude. Questions and other issues: a maintainer can comment @claude to trigger analysis.

Routing: Agent-callable tools → PraisonAI-Tools; lifecycle plugins (tracing/hooks/guardrails) → PraisonAI-Plugins. TypeScript/JavaScript SDK fixes land in src/praisonai-ts/ in this repo.

[praisonai-triage-agent]

Claude finished @Dhivya-Bharathy's task —— View job

---

Issue #5340 — Already Fixed on main ✅

I investigated all three surfaces flagged in this report. The bug described here has already been resolved on the current main branch (via the earlier fix for #5172). All video defaults now use the canonical, validatable openai/sora-2 identifier — the stale runway/gen3a_turbo / runway-gen3 / sora ids no longer exist anywhere in the codebase.

• Read AGENTS.md for architecture rules
• Read capabilities/videos.py — default is already openai/sora-2
• Check MCP and CLI video default surfaces
• Confirm no stale ids remain in repo
• Verify regression tests exist and pass

Evidence

1. Capabilities layer — src/praisonai/praisonai/capabilities/videos.py

def video_generate(prompt: str, model: str = "openai/sora-2", ...):   # line 23
async def avideo_generate(prompt: str, model: str = "openai/sora-2", ...):  # line 93

2. MCP tool — src/praisonai-mcp/.../adapters/extended_capabilities.py:38

@register_tool("praisonai.videos.generate")
def videos_generate(..., model: str = "openai/sora-2", ...):

3. CLI — src/praisonai-code/.../cli/features/capabilities.py:1010

parser.add_argument("--model", "-m", default="openai/sora-2", help="Model to use")

4. No stale identifiers remain — a repo-wide search for gen3a_turbo, runway-gen3, and runway/gen3 returns zero matches.

Regression tests already present and passing

src/praisonai/tests/unit/test_capabilities.py contains TestVideoDefaultModelParity, which locks all surfaces to VideoAgent.DEFAULT_MODEL == "openai/sora-2" — exactly the guard requested in this issue's "test gap" appendix:

$ python -m pytest tests/unit/test_capabilities.py::TestVideoDefaultModelParity -q
4 passed in 0.16s

The tests cover:

• test_canonical_default_is_sora2 — single source of truth
• test_video_generate_default_matches_canonical
• test_avideo_generate_default_matches_canonical
• test_sync_and_async_defaults_agree

Conclusion

This report was filed against PyPI v4.7.10, but the fix landed on main after that release. No code changes are needed — the acceptance criteria are already met and guarded by tests. The remaining action is simply to publish a new release (≥ v4.7.11) so PyPI consumers pick up the corrected wheel. No PR created since there is nothing to change.
• Branch: claude/issue-5340-20260928-0800