feat(providers): add Eden AI provider

[MVS-source]

🎯 Description

Adds Eden AI (https://www.edenai.co) as a native provider. Eden AI is an OpenAI-compatible aggregator that exposes 100+ models from many providers (OpenAI, Anthropic, Google, Mistral, DeepSeek, X.AI, …) through a single EU-hosted endpoint and one API key.

EdenAIProvider mirrors the existing OpenAI-compatible providers (closest analog: OpenRouterProvider). Because Eden AI returns the actual per-request cost in each response, the provider uses that value for accurate accounting and falls back to a local pricing table when it's absent. Follows the "Adding a New Provider" checklist in CONTRIBUTING.

🔄 Type of Change

• 🚀 New provider integration
• ✅ Test additions/improvements
• 📝 Documentation update

🧪 Testing

Test cases added

• Unit tests (tests/test_edenai.py, 11 tests: init, completion, system prompt, API-cost vs local-pricing fallback, 401, 429, cost estimation)
• Manual testing (live end-to-end against the Eden AI API)

How to test

import asyncio
from cascadeflow.providers import EdenAIProvider  # uses EDENAI_API_KEY env var

async def main():
    p = EdenAIProvider()
    r = await p.complete(prompt="Hello!", model="anthropic/claude-sonnet-4-5")
    print(r.provider, r.model, r.cost, r.content)
    await p.close()

asyncio.run(main())

Verified locally: pytest tests/test_edenai.py → 11 passed; existing provider tests (groq/openai/ollama) → 49 passed, 1 skipped (no regressions); black/ruff clean. Live run: complete, stream, and fetch_available_models (763 models) all working; cost read from the API response.

📝 Notes

• Model naming uses Eden AI's provider/model format (e.g. mistral/codestral-latest).
• API key read from EDENAI_API_KEY only — never hardcoded or logged.
• Base URL defaults to https://api.edenai.run/v3 (EU-only endpoint available at https://api.eu.edenai.run/v3).

[saschabuehrle]

Thanks for the provider contribution. I rebased the patch conceptually onto current main after #180 and the isolated tests, Ruff, and Black pass, but this is not merge-ready through cascadeflow’s actual configuration path.

Required before merge:

1. Register edenai in ModelConfig.validate_provider. Today ModelConfig(name="x", provider="edenai", cost=0) raises a validation error, so a CascadeAgent cannot configure this provider.
2. Add an edenai entry to PROVIDER_CAPABILITIES with the implemented streaming/tool/cost behavior.
3. Add an integration-level regression test that constructs ModelConfig with provider="edenai" and resolves the provider from PROVIDER_REGISTRY; direct-provider unit tests did not catch this blocker.

Official Eden AI V3 docs confirm the /v3/chat/completions endpoint, provider/model names, and top-level cost tracking, so those core API assumptions look reasonable. Please update against current main and re-request review.

[MVS-source]

Thanks for the detailed review. All three blockers are addressed, rebased onto current main after #180.

1. edenai is now registered in ModelConfig.validate_provider, so ModelConfig(name="x", provider="edenai", cost=0) validates and a CascadeAgent can configure the provider.
2. Added an edenai entry to PROVIDER_CAPABILITIES reflecting what is actually implemented: streaming and tool calling supported, supports_logprobs: False with max_top_logprobs: 0 (support varies per underlying model, consistent with EdenAIProvider._check_logprobs_support), and has_cost_tracking: True, since Eden AI returns the real per-request cost in the response body so accounting is exact rather than estimated.
3. Added tests/test_edenai_integration.py, which covers the configuration path rather than the provider in isolation: ModelConfig validation (including case-insensitivity), PROVIDER_REGISTRY resolution, CascadeAgent wiring for a multi-model setup, custom base_url propagation for the EU gateway, and a guard that keeps the capability matrix in sync with the implementation.

One thing worth flagging: the first two blockers are coupled by your own test. test_model_config_provider_allows_all_provider_capability_keys from #180 iterates over PROVIDER_CAPABILITIES, so it fails if a provider is listed there but missing from the validator allow-list. The existing suite therefore now guards this regression as well.

Verification on my side: full suite green with the CI marker filter (1251 passed, 41 skipped), plus black --check on 25.11.0, ruff check on 0.15.0 and mypy --ignore-missing-imports all clean.

Ready for another look whenever you have time.