Provider Registry
Genfeed Core stores reviewed model records behind one generation-facing surface. Text models are curated through OpenRouter, media models are discovered from verified Replicate owners, and Genfeed-managed models remain an explicitly assigned provider.
Registry Layers
| Layer | File | Role |
|---|---|---|
| Model records | packages/services/ai/models.service.ts | Returns reviewed model records already known to the app |
| Replicate watcher | apps/server/workers/src/crons/model-watcher/cron.model-watcher.service.ts | Creates inactive review drafts for models from verified Replicate owners |
| OpenRouter catalog | packages/agent/src/constants/agent-models.constant.ts | Defines the curated text-model choices exposed to the agent |
| BYOK access | apps/server/api/src/services/byok/* | Resolves organization provider keys before hosted/server fallback at execution time |
| Generation tools | packages/tools/src/registry/source/index.ts | Exposes stable agent-facing tools such as generate_image and generate_video |
How Discovery Works
The weekly watcher reads Replicate’s catalog, restricts results to verified owners, de-duplicates them by model key, and creates inactive records for operator review. It never activates a discovered model automatically.
OpenRouter choices are curated in code rather than mirroring the full upstream catalog. This keeps the user-facing text-model set deliberate and prevents unbounded provider dumps from filling the model table.
fal.ai remains a supported execution integration where a media path explicitly selects it, but Genfeed does not ingest the fal.ai catalog into the model table.
Provider Configuration
Provider discovery and provider execution are related but separate:
| Concern | Configuration | Used by |
|---|---|---|
| OpenRouter text execution | OPENROUTER_API_KEY | Curated agent and text-generation paths |
| Replicate discovery/runtime | REPLICATE_KEY | Replicate watcher and generation integrations |
| fal.ai runtime execution | FAL_API_KEY | Explicit fal.ai generation integrations |
| Organization BYOK execution | Organization BYOK settings | Runtime provider resolution in ByokProviderFactoryService |
| Managed Cloud execution | GENFEED_API_KEY | Explicit Cloud-backed managed inference paths |
Core does not require every provider key. At least one generation-capable provider must be configured for real generation, but docs and registry tests can run without live provider credentials.
Stable V1 Generation Surface
For v1, callers should treat these as the stable generation-facing surfaces:
- Core Loop Step 3 docs: Generation Service
- Agent tool metadata:
packages/tools/src/registry/source.ts - Agent tool registry/UI mapping:
packages/tools/src/registry/tool-registry.ts - Internal media APIs:
/v1/images,/v1/videos,/v1/musics,/v1/voices/generate - Skill execution path:
apps/server/api/src/services/skill-executor/* - Replicate discovery path:
apps/server/workers/src/crons/model-watcher/cron.model-watcher.service.ts
Lower-level provider APIs and experimental model sync jobs can change as long as this stable surface keeps accepting the documented tool inputs and returns normalized generated media records.
Verification
Provider registry behavior is covered by:
apps/server/workers/src/crons/model-watcher/cron.model-watcher.service.spec.tsapps/server/workers/src/services/model-discovery.service.spec.tsapps/server/api/src/services/byok/byok-provider-map.util.spec.ts
The repository CI runs these suites in their owning workspaces.