Feat/edenai provider

[YacineMK]

Summary

Adds Eden AI sync mechanism (provider scaffold, logo, sync module).

Eden AI is an EU-based AI aggregation platform that exposes 100+ models from many providers behind a single OpenAI-compatible API (https://api.edenai.run/v3, Authorization: Bearer,
provider/model format), with unified billing/usage tracking and EU data residency options. This adds the edenai provider using @ai-sdk/openai-compatible (no new dependency), matching
the pattern of existing aggregator entries like openrouter / kilo.

Changes

• providers/edenai/provider.toml — provider entry
• providers/edenai/logo.svg — monochrome logo (currentColor via SVG mask)
• packages/core/src/sync/providers/edenai.ts — sync module modeled on openrouter.ts / llmgateway.ts
• packages/core/src/sync/index.ts — registered in providers + aggregators group

Design notes

The sync treats Eden's /v3/models as authoritative only for cost, context, and modality data. Capability, open_weights, and reasoning-control fields default to safe values (false,
[]) when Eden's API doesn't provide them, following the llmgateway pattern. Existing hand-authored fields are preserved via context.existing().

Only text-output models are synced; specialty Eden endpoints (OCR, TTS, embeddings, sentiment) live on other Eden APIs and are out of scope.

Catalog

The generated catalog is ~800 files, which exceeds GitHub's 300-file PR-diff limit and would block the pr-reviewer workflow. Following the pattern from kilo #2997 and hyper #3352,
the catalog will land in a follow-up PR from an automation/sync-models-edenai branch that bypasses the reviewer by design.

To generate locally after merge:
bun models:sync edenai

Sources

• Eden AI catalog: https://api.edenai.run/v3/models
• Eden AI docs: https://www.edenai.co/docs

Verification

• bun models:sync edenai --dry-run → 796 planned, 0 errors
• bun validate → passes
• packages/sdk tests → 23/23 pass

[github-actions]

Action items

• [high] [violation] packages/core/src/sync/providers/edenai.ts:245 - Check: open_weights is model-intrinsic and must inherit via base_model when metadata exists; provider sync must not invent overrides. Why: Final code sets open_weights = existing?.open_weights ?? false and always passes it into factorBaseModel. For new factored models that becomes false, which overrides bases with open_weights = true (e.g. models/minimax/MiniMax-M2.1.toml). Patch 5 already produced that bad override (open_weights = false on minimax/MiniMax-M2.1). Hourly Eden sync will republish incorrect catalog data. Action: For factored entries omit open_weights (use undefined so metadata inherits), matching deepinfra/hyper. Only set open_weights on full inline models, and prefer existing?.open_weights there rather than a blanket false.
• [medium] [possible mistake] packages/core/src/sync/providers/edenai.ts:366 - Check: PR design and AGENTS.md: Eden is authoritative for cost/context/modalities; capability fields should not blindly override models/ facts. Why: Factored path still injects Eden-derived reasoning, tool_call, structured_output, and attachment into factorBaseModel. Peers such as llmgateway pass only gateway-authoritative fields for new factored models. Noisy Eden flags can permanently override curated capabilities on first sync. Action: For resolvedBase !== undefined, limit overrides to cost, served limit.context, modalities (if treated as authoritative), dates, and reasoning_options when needed; leave other capabilities unset so they inherit.
• [medium] [violation] packages/core/src/sync/providers/edenai.ts:1 - Check: New complex sync translators need focused regression coverage when they can corrupt catalog data. Why: buildEdenAIModel has no tests in packages/core/test/sync.test.ts, while similar aggregators (hyper, llmgateway) do. The open_weights/base_model bug would have been caught by a factored open-weight case. Action: Add unit tests for factored open-weight inheritance, missing output-limit handling, and full-inline fallbacks.
• [low] [possible mistake] .github/workflows/sync-models.yml:73 - Check: New sync providers that need credentials must wire secrets into the hourly workflow (sync.md). Why: Fetch uses EDENAI_API_KEY when set, but the workflow never exports it. Final PR ships zero model TOMLs and relies on automation; if /v3/models requires auth in CI, Eden stays empty after merge. Action: Confirm unauthenticated catalog access in CI; if a key is required, add EDENAI_API_KEY to the sync job env (and repo secrets). Update the PR body to match the deferred-catalog approach.

[github-actions]

Action items

• [high] [violation] packages/core/src/sync/providers/edenai.ts:340 - Check: Provider-agnostic capabilities must not be clobbered with false defaults when factoring via base_model (see DeepInfra/LLM Gateway sync patterns and AGENTS.md merge rules). Why: reasoning, tool_call, and structured_output are set with === true (missing API flags become false), and open_weights defaults to false for new models. Those values are always passed into factorBaseModel(), so when Eden omits a capability the sync writes explicit false overrides that replace inherited metadata (e.g. open-weight or tool-capable bases). The PR itself notes Eden is not authoritative for capabilities, but the code still treats absences as negatives. Action: Only emit capability fields when Eden explicitly reports them (or when overriding a curated existing value). For resolved base_model entries, prefer the DeepInfra/LLM Gateway approach: override cost/limit/modalities (and provider-specific reasoning_options) and leave tool_call / reasoning / structured_output / open_weights unset so they inherit from models/.
• [high] [violation] packages/core/src/sync/providers/edenai.ts:237 - Check: New provider models must use base_model when a matching models/<provider>/<model>.toml exists. Why: candidateBaseModels() only maps owned_by via DIRECT_METADATA_PROVIDER or bare/exact IDs. Gateway routes such as amazon/anthropic.claude-opus-4-6-v1 never resolve to anthropic/claude-opus-4-6 (Bedrock-style provider.model IDs, -v1:0, region suffixes). The initial sync catalog in this PR already produced full inline amazon/anthropic entries without base_model while models/anthropic/… exists—the same result automation will recreate after merge. Action: Extend resolution for gateway IDs (parse anthropic.* / meta.* / openai.* style names, strip Bedrock/region suffixes, reuse resolveCanonicalBaseModel / stronger aliases) so underlying canonical metadata is factored; add focused tests covering at least one amazon/anthropic and one direct anthropic/openai path.

[github-actions]

Action items

• [medium] [possible mistake] packages/core/src/sync/providers/edenai.ts:296 - Check: Factored base_model entries must keep attachment consistent with any modality overrides (or leave both unset so curated models/ metadata inherits). Why: The factored path always writes Eden modalities but never sets attachment, while the comment claims DeepInfra/LLM Gateway behavior—those peers leave modalities unset for new factored models. After merge, base attachment can disagree with Eden modalities (e.g. attachment = true with text-only input), so the automated catalog will ship inconsistent capability data. Action: Either omit modalities on the factored path so base metadata inherits, or set attachment from the same Eden input modalities whenever modalities are overridden.
• [medium] [possible mistake] packages/core/src/sync/providers/edenai.ts:1 - Check: New sync modules with non-trivial ID resolution and factored/inline splits need focused regression coverage. Why: normalizeGatewayName, Bedrock candidate factoring, and the factored vs inline field split already required multiple fixup commits (output limits, open_weights, capability clobbering). Without unit tests, the deferred automation catalog is likely to reintroduce the same class of bugs. Action: Add focused buildEdenAIModel tests covering Bedrock-style IDs resolving to base_model, factored field selection (no fabricated limit.output / capability clobber), and attachment/modality consistency.

[github-actions]

Action items

• [high] [violation] providers/edenai/logo.svg:1 - Check: New providers must ship a logo with no hardcoded colors; use currentColor for fills/strokes so it adapts when inlined. Why: The logo still hardcodes fill="white" / fill="black" inside a <mask>. Site rendering rewrites every non-currentColor fill to currentColor (packages/web/src/render.tsx providerLogoSvg), which collapses the mask cutouts into a solid rect and breaks the mark in the UI. Action: Replace the mask/cutout approach with a monochrome path (or equivalent) that uses only currentColor / none—no white/black fills—so the logo survives inlining and matches AGENTS.md.

[github-actions]

No actionable findings.

[YacineMK]

Friendly ping @rekram1-node CI is green (796 models planned, 0 errors on dry-run, all 23 SDK tests pass) This follows the same catalog-deferred pattern as #2997 (kilo) and #3352 (hyper) Happy to answer any questions

[MVS-source]

@rekram1-node could you take a look when you get a chance? This adds Eden AI as a sync provider (mirrors the OpenRouter/LLM Gateway pattern) and is needed to unblock Eden AI showing up as a provider in Kilo Code. Happy to help test or answer questions about the API responses.