Skip to content

[Feature]: per-model capability declarations — text-only, context tier, and video processing mode #3377

Description

@lidge-jun

Area

Provider adapters

What are you trying to accomplish?

Declare, per model, what a provider can actually do — context tier, vision or text-only, video processing mode — instead of relying on OpenCodex's inferred defaults that silently mismatch the upstream.

This consolidates three requests that each name one missing capability axis. Each is closed individually and absorbed here:

What prevents this today?

Each axis is missing at the same layer — the provider/model row has nowhere to say it.

Text-only is not expressible. src/cli/provider.ts parses through --default-model but has no text-only flag, and src/cli/provider-runtime.ts offers no equivalent on edit. A text-only model that receives an image fails at the upstream instead of being rejected or downgraded locally.

Video processing mode is dropped. src/chat/inbound.ts preserves only the video URL, src/responses/schema.ts has no processing field, and src/adapters/google.ts converts non-data video URLs into text markers. Gemini's agentic video mode cannot be requested at all.

Context tier is not selectable. src/providers/github-copilot-transport.ts enriches headers and base URL only; there is no context-tier option on provider edit, so a Copilot model cannot be pinned to its long-context tier and OpenCodex cannot apply its own cap against that tier.

What should OpenCodex do?

Give the provider/model configuration a capability block that these three cases populate, so adding a capability axis later does not require another bespoke flag:

  1. Accept a text-only declaration at provider add and provider edit, and reject or explicitly downgrade image content for such models before dispatch rather than after.
  2. Carry a video processing mode from ingress through the schema to the Google adapter, so processing: "agentic" reaches the upstream unmodified.
  3. Accept a context tier per model, apply the OpenCodex cap against the selected tier, and send whatever header or field the provider requires.

Example usage or interface

ocx provider add mine --default-model my-model --text-only
ocx provider edit copilot --model gpt-x --context-tier long
{
  "providers": {
    "google": {
      "models": {
        "gemini-x": { "video": { "processing": "agentic" } }
      }
    }
  }
}

Alternatives or workarounds

Users currently avoid affected models, or accept upstream errors that surface as opaque proxy failures because OpenCodex had no way to know the model's real capability.

Additional context

Absorbs #3268, #3271, #3281. Credit for the original analysis belongs to @turin-dev, @GoldenLoaf24h, and @Simon-Opopeee.

PR #3282 by @Simon-Opopeee (GitHub Copilot context tier) is open and addresses item 3; it is not superseded by this issue.

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestproviderProvider adapters, OpenAI-compat presets, upstream API quirks

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions