Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Feature]: opt-in per-provider alias template for newly discovered models

Open
  • Is something wrong?
#7,705 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
typescript
Domain
cli

Research direction

Explore the alias resolution and collision-check code in the OpenCodex CLI, plus the model discovery path handling liveModels. Review the ocx alias command to add template set/show subcommands. Done means discovered models get templated aliases marked source:template without overwriting user aliases.

Written by the indexing model from the issue text.

Description

catalog enhancement
Area

Catalog / models

What are you trying to accomplish?

Give every newly discovered model a predictable short alias automatically, following a per-provider template, so model names stay consistent across clients without manual ocx alias set calls each time a provider adds a model.

Example: provider alias CC, template {providerAlias}-{modelBasename} → command-code/reflection/beam:free becomes CC-beam-free.

What prevents this today?

ocx alias supports list, set, rm and defaults (built-in aliases). There is no way to say "alias every model of this provider with this pattern". Providers with live discovery (liveModels: true) add models at any time, and each new model appears without an alias until someone notices and runs ocx alias set.

What should OpenCodex do?

An opt-in, per-provider alias template applied to discovered models that do not already have an alias:

  • explicit user aliases always win and are never overwritten;
  • colliding or invalid generated names are skipped and reported, never silently renamed;
  • generated aliases are marked with a distinct source (for example source: "template"), so they can be listed, reviewed and removed separately from user aliases;
  • nothing changes for providers without a template.
Example usage or interface
ocx alias template set command-code "{providerAlias}-{modelBasename}"
ocx alias template show command-code
ocx alias list --json   # generated rows carry "source": "template"

The exact placeholders and the behaviour for :free / / characters in model ids are open; today I normalize : to - and take the last path segment.

Alternatives or workarounds

An external job that polls /v1/models, finds rows without alias_of, and runs ocx alias set for each. On my host it applied new aliases 5 times in 7 days (340 runs). It works, but it is exactly the kind of logic that belongs next to alias resolution and collision checks inside OpenCodex.

Additional context

Related to #7703 on alias-aware client exports: together they would let a user standardize names once and have every client receive them. Feature proposal only; I would not start a PR without agreement on the interface.

Checks
  • I searched existing issues and documentation.
  • This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
  • I removed secrets and personal data.
Dominant language
TypeScript
Stars
16.9k
Forks
1.3k
Avg merge
9h 39m
Merged PRs (30d)
633

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lidge-jun/opencodex

All issues in lidge-jun/opencodex

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.