[heydryft]

Per the maintainer's note on #504, this no longer adds a dedicated provider. It now only adds a short docs section (docs/llm.md, "OpenAI-compatible gateways") showing how to use Runcrate, an AI cloud with an OpenAI-compatible API, through the existing OPENAI_BASE_URL and OPENAI_API_KEY settings:

export OPENAI_BASE_URL=https://api.runcrate.ai/v1
export OPENAI_API_KEY=<Runcrate API key>
summarize https://example.com --model openai/meta-llama/Llama-3.3-70B-Instruct-Turbo

No source, config schema, env var or stored-data changes, so there is nothing to migrate.

How it was checked:

• oxfmt --check docs/llm.md, pnpm run typecheck, and the provider tests (provider-registry.contract, model-spec, cli.llm.providers, daemon.models): 70 passed.
• GET https://api.runcrate.ai/v1/models (public, no key) lists meta-llama/Llama-3.3-70B-Instruct-Turbo.
• The documented path was run against a local mock OpenAI-compatible server (no real key): the CLI sent POST /v1/chat/completions with the model id passed through as meta-llama/Llama-3.3-70B-Instruct-Turbo.
• Not done: a live chat completion against Runcrate, since that needs an API key.

Disclosure: I work on Runcrate.

This PR was prepared with AI assistance (omp with Claude): the docs, this description and the commands above were written and run with it.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: needs real behavior proof before merge.

What this changes

This PR adds Runcrate-specific model names, credentials, endpoint settings, model discovery, status output, documentation, and tests.

Example: Select meta-llama/Llama-3.3-70B-Instruct-Turbo on Runcrate.

• Before: Use OPENAI_BASE_URL=https://api.runcrate.ai/v1, OPENAI_API_KEY, and --model openai/meta-llama/Llama-3.3-70B-Instruct-Turbo.
• After: Use RUNCRATE_API_KEY and --model runcrate/meta-llama/Llama-3.3-70B-Instruct-Turbo.

Review scores

Measure	Result	What it means
Overall readiness	🧂 unranked krab (1/6)	The implementation follows established wiring, but duplicates an owner-rejected provider surface and lacks observable execution proof.
Proof confidence	🧂 unranked krab (1/6)	Real behavior proof is necessary before merge. See Before merge.
Patch quality	🦪 silver shellfish (2/6)	1 actionable review finding remain.

Product

Kind: Feature · Worth it: No · Fix scope: Complete
User problem: Runcrate users want a named provider with independent credentials and automatic model discovery.
Reason: The owner explicitly declined dedicated OpenAI-compatible gateway providers in #504 (comment); this PR establishes no limitation in the supported custom-endpoint path that requires an exception.

Merge readiness

⛔ Blocked before merge - 5 items remain

Keep open under the repository’s no-auto-close policy, but do not merge the dedicated provider: an explicit owner decision directs OpenAI-compatible gateways through the existing custom-endpoint support.

Priority: P3
Reviewed head: efd770c39c0ebcdd39c5cd35539e4c90a1ed5621

Before merge

• Add real behavior proof - The changed Runcrate execution path is exercised through mocked completion and discovery clients only; the reported live model-list lookup does not prove authenticated generation. If retained, attach redacted terminal output or logs showing streaming and non-streaming CLI summaries and daemon model discovery, removing keys, IPs, and non-public endpoints. After adding proof, update the PR body, then request a new review with @clawsweeper re-review. The PR author or someone with repository write access can request it.
• Use the existing custom-endpoint path for Runcrate (P1) - For the advertised Runcrate model, current main already accepts OPENAI_BASE_URL=https://api.runcrate.ai/v1, OPENAI_API_KEY, and --model openai/meta-llama/Llama-3.3-70B-Instruct-Turbo; daemon discovery also uses that endpoint. Adding this registry entry creates another model namespace, credential set, and configuration surface for the same gateway access without demonstrating a missing capability. The owner explicitly rejected this approach in feat: add Cheaper Inference provider #504 (comment). Replace the native-provider wiring with a documented configuration example.
• Product: not worth merging - The owner explicitly declined dedicated OpenAI-compatible gateway providers in feat: add Cheaper Inference provider #504 (comment); this PR establishes no limitation in the supported custom-endpoint path that requires an exception.
• Add data-model compatibility proof - The review found that existing stored data may not work after upgrade. Show that existing data still loads and works with this change.
• Explain or restore the original intent of Dedicated gateway product surface - feat: add Cheaper Inference provider #504 (comment): The owner directed individual OpenAI-compatible gateways to the existing endpoint override instead of adding dedicated providers.

Findings

• [P1] Use the existing custom-endpoint path for Runcrate — src/llm/provider-registry.ts:80-87

Provenance

• Dedicated gateway product surface changes intended behavior without addressing why it exists (feat: add Cheaper Inference provider #504 (comment): The owner directed individual OpenAI-compatible gateways to the existing endpoint override instead of adding dedicated providers.)

Tests

• Missing end-to-end proof: If the native integration is retained, supply authenticated CLI streaming and non-streaming summaries, daemon discovery output, and fresh-install plus v0.26.0 upgrade evidence with existing settings intact; no base-failing/head-passing runtime regression demonstration is supplied.

Agent review details

How this fits together

The CLI and companion daemon resolve model names, credentials, and endpoints through shared provider configuration, then send extracted content to an inference API and return summaries or discovered model choices.

flowchart TD
  A[CLI or companion daemon] --> B[Model and configuration resolution]
  C[Credentials and endpoint] --> B
  B --> D[Shared OpenAI compatible transport]
  D --> E[Runcrate API]
  E --> F[Summary or model list]

Loading

Technical review

Best possible solution:

Document a Runcrate example using the existing OpenAI endpoint configuration and model namespace.

Do we have a high-confidence way to reproduce the issue?

This is a provider feature, not a reported runtime bug; source inspection confirms that main lacks the Runcrate namespace but already supports custom endpoints and model discovery.

Is this the best way to solve the issue?

The dedicated integration follows existing implementation patterns, but the owner’s subsequent gateway policy makes a configuration example the appropriate solution.

Full review comments:

• [P1] Use the existing custom-endpoint path for Runcrate — src/llm/provider-registry.ts:80-87
  For the advertised Runcrate model, current main already accepts OPENAI_BASE_URL=https://api.runcrate.ai/v1, OPENAI_API_KEY, and --model openai/meta-llama/Llama-3.3-70B-Instruct-Turbo; daemon discovery also uses that endpoint. Adding this registry entry creates another model namespace, credential set, and configuration surface for the same gateway access without demonstrating a missing capability. The owner explicitly rejected this approach in feat: add Cheaper Inference provider #504 (comment). Replace the native-provider wiring with a documented configuration example.
  Confidence: 0.99

Overall correctness: patch is incorrect
Overall confidence: 0.97

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against aaccb7c9c30e.

Provenance checked

• Provider metadata and compatible execution keeps the original intent (589c6c2: Centralize provider metadata, defaults, and capabilities while retaining the existing runtime and configuration owners.)

Testing

Proof path: in-process harness.

Security

None.

Evidence

What I checked:

• Explicit owner direction: In feat: add Cheaper Inference provider #504 (comment), steipete explicitly declined dedicated providers for individual OpenAI-compatible gateways and directed users to OPENAI_BASE_URL or openai.baseUrl with OPENAI_API_KEY.
• Existing endpoint configuration: Current main documents custom OpenAI-compatible endpoints; its client resolver selects Chat Completions by default for custom hosts while preserving explicit transport settings. (docs/config.md:475, aaccb7c9c30e)
• Existing model discovery: Current main already discovers models from custom OpenAI-compatible endpoints using the configured OpenAI key and returns openai-prefixed model choices. (src/daemon/models.ts:317, aaccb7c9c30e)
• Pinned introduced change: The introduced diff adds a Runcrate registry entry and threads its independent credentials and endpoint through existing execution owners; no separate transport is needed. (src/llm/provider-registry.ts:80, efd770c39c0e)
• Supplied validation boundary: The complete PR body explicitly reports no authenticated chat completion; the added CLI test mocks completeSimple, and the discovery test mocks fetch. Discussion contains only bot status comments and no additional behavior artifacts. (tests/cli.llm.providers.test.ts:170, efd770c39c0e)
• Provider architecture provenance: refactor(providers): centralize metadata and config parsing #410 centralized provider metadata while preserving explicit configuration boundaries; feat: add native MiniMax provider support (+ reasoning-tag stripping) #250 established the MiniMax integration used as this PR’s precedent. (src/llm/provider-registry.ts:60, aaccb7c9c30e)

Likely related people:

• Peter Steinberger: Raw commit 589c6c2 adds src/llm/provider-registry.ts:60 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: 589c6c2876f0; files: src/llm/provider-registry.ts)
• Neerav Makwana: Raw commit 3c24df0 adds src/llm/providers/models.ts:91 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: medium; commits: 3c24df0e9de8; files: src/llm/providers/models.ts)

Preflight source

Source unknown. Source comparison at the observed PR snapshot only. Completion is self-reported; body, policy, tests, execution, and report bytes are not verified.

Labels

Label changes:

• add P3: This adds provider-specific ergonomics for gateway access already supported through existing configuration.
• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦪 silver shellfish.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask.

Label justifications:

• P3: This adds provider-specific ergonomics for gateway access already supported through existing configuration.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦪 silver shellfish.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask.

Rating scale

6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior.

Workflow

ClawSweeper edits this one comment on every review. Comment @clawsweeper re-review for a fresh review only. Repair and merge execution lanes are retired.

Reviewed November 9, 2026, 2:04 AM ET / 07:04 UTC.

[heydryft]

I dropped the dedicated provider (commit 3f49865 reverts efd770c), since #504 says gateways should go through OPENAI_BASE_URL. The PR is now only a docs example in docs/llm.md, so there are no source, config or stored-data changes to migrate.

What I ran on the new head (Node 26, pnpm 11.27.0):

$ pnpm exec oxfmt --check docs/llm.md
All matched files use the correct format.
$ pnpm run typecheck        # core, root and extension: no errors
$ pnpm exec vitest run tests/provider-registry.contract.test.ts tests/model-spec.test.ts tests/cli.llm.providers.test.ts tests/daemon.models.test.ts
 Test Files  4 passed (4)
      Tests  70 passed (70)

The documented path against a local mock OpenAI-compatible server on 127.0.0.1 (dummy key, --no-cache):

$ OPENAI_BASE_URL=http://127.0.0.1:18765/v1 OPENAI_API_KEY=dummy-local \
  summarize article.txt --model openai/meta-llama/Llama-3.3-70B-Instruct-Turbo --plain --length short --stream on
A short mock summary.
via model openai/meta-llama/Llama-3.3-70B-Instruct-Turbo
0.3s · meta-llama/Llama-3.3-70B-Instruct-Turbo · ↑10 ↓5 Δ15

mock server log:
POST /v1/chat/completions auth=present model=meta-llama/Llama-3.3-70B-Instruct-Turbo stream=true

--stream off printed the same summary and the same request. GET https://api.runcrate.ai/v1/models needs no key and lists meta-llama/Llama-3.3-70B-Instruct-Turbo. I have not run a live chat completion against Runcrate, since that needs an API key. The PR title and description are updated.