#1933·eigent

[Feature Request] Add aimlapi.com as a first-class LLM provider

Author: hugoaimlapiCreated Sep 14, 2026Updated Sep 14, 2026
Labelsenhancement

Motivation

Hi! I'm Hugo from aimlapi.com — an AI aggregator that gives access to 1000+ models in one API, trusted by 400k+ users.

We'd love to be available as a verified provider option inside Eigent — so we went ahead and did all the technical work on our side.

To build our partnership, we offer a 50/50 revenue share on all traffic from this integration. (P.S.: tracking starts as soon as this release goes live, so no earnings will be lost during setup)

My contacts: [email protected] (email / Slack), Telegram: @hug0the

The integration is already built and tested in our fork: https://github.com/aimlapi/eigent-aimlapi A PR-ready branch is prepared on top of current main (15 files, +618/-8, of which 428 lines are tests) — we can open the PR as soon as you say go.

Problem: reaching aimlapi.com today means using the generic "OpenAI Compatible" entry — the user has to know and type the base URL by hand, there is no logo or label, and the model dropdown is empty, so every model id has to be typed from memory. Requests also carry no application identity, unlike the OpenRouter entry.

Solution

Register aimlapi as its own BYOK provider on the existing OpenAI-compatible path — the same shape as the Ant Ling and Nebius Token Factory entries, so it costs a registry entry rather than a new client:

  • src/lib/llm.ts: one INIT_PROVODERS entry — label aimlapi.com, host https://api.aimlapi.com/v1, models endpoint /models?include=all, site https://aimlapi.com; plus the logo, the dark-mode fill list and the i18n source-usage allowlist.
  • backend/app/model/model_platform.py: aimlapi -> openai-compatible-model in PLATFORM_ALIAS_MAPPING, so the backend routes it like every other OpenAI-compatible provider.
  • src/lib/providerModels.ts: two generic additions to the shared listing parser so the dropdown is usable — support for the modalities object (the shape aimlapi.com publishes instead of OpenRouter's architecture, and only under include=all), and de-duplication of ids, since the listing repeats an id once per endpoint surface. Rows that name an endpoint surface other than openai/chat-completions are dropped, because a model served only from the Responses API answers 404 Model not found on /chat/completions. Both changes are keyed on fields the other providers' listings do not publish, so their output is unchanged.
  • Attribution: HTTP-Referer, X-Title, X-AIMLAPI-Partner-ID, X-AIMLAPI-Source on requests bound for api.aimlapi.com, merged into the default_headers init param the model client already declares (the Codex subscription runtime uses the same path). The headers are keyed on the request host, not on the configured provider id, so pointing the aimlapi entry at another endpoint — or another provider at a proxy — never leaks them to a third party, and a user's own header wins on a clash.

Raw listing is 785 rows; after the filters the picker shows 352 chat-capable ids in 51 groups (measured against the live listing on 2026-09-03).

Alternatives

No response

Additional context

  • Tests: 6 test files, 428 lines — provider entry, parser behaviour (modalities, de-duplication, endpoint-surface filter, legacy shapes unchanged), host-scoped attribution on both the Python and TypeScript sides, and the backend alias mapping.
  • No new dependency, no change to the agent loop or to any other provider's behaviour; the provider is inert until a key is entered.
  • Happy to adjust naming, placement or scope to whatever you prefer before we open the PR.