feat(core): add EVREN LLM to /connect #62967

Primary sources

• EVREN model/API documentation
• EVREN Swagger UI
• EVREN OpenAPI 3.1 schema, reporting EVREN LLM API version 0.1.0
• Official public model/status data used by the portal

Connection and authentication

• Proposed OpenAI-compatible base URL: https://evren-llmapi.ssyz.org.tr/v1.
• Official documentation shows evren_llm_... keys and both Authorization: Bearer … and X-API-Key examples.
• An unauthenticated GET /v1/models returned 401, with error.code = "unauthorized".
• Credentialed reads using each header reached the terms gate and returned 403, with error.code = "terms_not_accepted".
• Credentialed GET /v1/terms/status and GET /v1/terms/text succeeded with Bearer authentication.
• The OpenAPI document does not declare securitySchemes; it is useful for payloads but insufficient by itself to establish authentication behavior.

Terms are a model-discovery prerequisite too

The observed 403 terms_not_accepted came from GET /v1/models, before any inference attempt. A discovery plugin that turns every failure into an empty model list would hide a required onboarding step.

The documented flow is:

1. GET /v1/terms/status → current version and acceptance state.
2. GET /v1/terms/text → version and Markdown content.
3. After explicit user review/consent, POST /v1/terms/accept with {"version": <reviewed-current-version>}.

No acceptance request was made during this research. An MVP can keep acceptance external, but must document the actual official path and preserve useful terms errors. In-app terms review/acceptance can be a separate design; never accept terms silently.

Models observed in the official public data

This is a dated public catalog, not proof that every API key can use every row. deepseek-v4-flash and mimo-v2.6-pro, mentioned in an earlier candidate list, were absent from this response. Do not hard-code that candidate list as current availability.

The public data also contains embedding, rerank, OCR, transcription, TTS, guard, and decision entries; those are outside this chat-provider request. Some chat entries advertise image input, so task === "vision_chat" alone is insufficient to determine vision support. Public portal and authenticated API capability field names also differ.

Authenticated model contract

OpenAPI's ModelListResponse contains data: ModelInfo[]. ModelInfo includes task, modalities, nullable context_length, nullable default_max_output_tokens, nullable capabilities, and nullable pricing.

• default_max_output_tokens is an omitted-request default, not a documented hard maximum. Resolve its relationship to OpenCode's required output limit before mapping it.
• ModelCapabilities describes tool calling, vision, thinking, reasoning effort, accepted effort values/aliases, and other accepted parameters. Unsupported parameters can be rejected with 400; avoid inferring support solely from model names.
• auto is a routing option. Its public capabilities are empty; do not copy a concrete model's tool/vision support or context window onto it without verification.
• Pricing uses EVREN credits (CR by default), whereas OpenCode model costs use USD per million tokens. Do not copy credit prices into USD fields or infer permanent free usage from dated examples.

Still unverified: successful authenticated model enumeration after acceptance, streaming inference, tool-call/result continuation, reasoning transport, image input, and actual account-specific availability. No inference request was made, and no end-to-end OpenCode compatibility is claimed yet.

1. Add catalog support first

Follow models.dev's provider contribution format. Proposed provider identity/configuration:

name = "EVREN LLM"
npm = "@ai-sdk/openai-compatible"
opencodeai = "@opencode/ai/providers/openai-compatible"
api = "https://evren-llmapi.ssyz.org.tr/v1"
env = ["EVREN_LLM_API_KEY"]
doc = "https://evren.ssyz.org.tr/llm/models"

These environment-variable and display-name choices are proposals, not server requirements. Add properly sourced model definitions and the logo required by models.dev. Verify gateway-specific capabilities, reasoning compatibility, limits, and pricing representation; do not inherit unsupported underlying-model features.

Confirm the published entry reaches OpenCode's catalog and bundled/release path. The current catalog loader uses models.opencode.ai and a bundled snapshot.

2. Decide whether EVREN needs additional OpenCode code

A catalog entry may be enough for /connect. Assess the concrete remaining gaps: account-filtered discovery, terms guidance, or request compatibility that cannot be described by catalog metadata.

If justified, add packages/core/src/plugin/provider/evren.ts and register it in packages/core/src/plugin/provider.ts. Extend the catalog registration rather than creating competing provider/integration definitions. Use provider/integration ID evren and the existing OpenAI-compatible package; explicitly associate the provider with its integration if creating it independently.

For dynamic discovery, follow Modal, ProviderRefresh, and SharedCache:

• Fetch GET /models relative to the /v1 base URL using the active connection.
• Decode unknown JSON at the HTTP boundary; normalize chat/vision_chat entries into chat models with explicit capabilities.
• Scope cached results to endpoint and active credential identity/fingerprint; preserve connection provenance so one account's model list cannot become another account's.
• Reuse background refresh, bounded requests, deduplication, and transient-error handling. Do not retry terms/auth failures as transient failures.
• Keep startup and server handlers nonblocking; use existing provider/model update events for client refresh. Do not add server-side waits for plugin activation.

No INTEGRATION_PRIORITY.evren = 6 change is required for discoverability: the picker already includes and alphabetically sorts unprioritized integrations. Adding priority also promotes it into “Popular”, which is a separate product decision.

3. Validate the selected design

• Read the relevant .opencode/skills testing instructions first. Exercise production registry/credential/model code with fixture-driven tests and local HTTP fixtures where needed.
• For a plugin implementation, add focused coverage such as packages/core/test/plugin/provider-evren.test.ts: registration before credentials, stored key and env access, task/capability mapping, null/missing metadata, credential switching, refresh, and terms/auth/transient discovery failures.
• Run focused tests and bun typecheck from packages/core; include TUI tests/typechecks if TUI behavior changes. Run root bun run check for the OpenCode change. A catalog-only contribution follows models.dev's validation workflow.
• After externally accepted terms, perform a credentialed smoke test: list allowed models, stream a small reply, complete a tool-call/result round trip, and test advertised reasoning/vision support before claiming it.
• Verify the real /connect → EVREN LLM → model picker flow using bun run dev:live from a development worktree.
• Keep a future PR based on/targeted at dev; obtain design approval before opening the implementation PR. If OpenCode code adds new behavior, apply the repository's feature-flag policy and document the flag. Include the required PR visual when applicable.

No Protocol/Server HttpApi changes are expected for catalog/provider registration. If the approved terms UX changes public contracts, regenerate the client with bun run generate from packages/client; do not edit generated files manually.