Skip to content

docs: document Standard Compute OpenAI-compatible gateway setup - #3383

Merged
Yeachan-Heo merged 2 commits into
ultraworkers:mainfrom
henrikdukefoss:docs/standard-compute-gateway
Nov 9, 2026
Merged

Yeachan-Heo merged 2 commits into
ultraworkers:mainfrom
henrikdukefoss:docs/standard-compute-gateway

Conversation

@henrikdukefoss

Copy link
Copy Markdown
Contributor

Summary

  • Adds a Standard Compute section to docs/local-openai-compatible-providers.md, after the UberLLM section. Docs only.
  • Covers the base URL and key, the routed StandardCompute model (each request goes to the cheapest enabled model that can handle it, with automatic fallback), the local/ hatch for the bare routed name and for vendor-prefixed pinned ids, and the public model list.
  • Disclosure: I work on Standard Compute.

Anti-slop triage

  • Classification: docs-only
  • Evidence: follows the existing LLMTR (docs: document LLMTR OpenAI-compatible gateway setup #3373) and UberLLM sections. local/ handling checked against is_local_openai_model_syntax in rust/crates/rusty-claude-cli/src/main.rs. curl https://api.stdcmpt.com/v1/models returns the catalog without a key, including StandardCompute and deepseek/deepseek-v4-flash.
  • Non-destructive review result: merge candidate

Verification

  • Targeted tests/docs checks ran, or the gap is explicitly recorded. (No Rust code changed, so cargo test was not run; I did not run the repo's scripts locally.)
  • git diff --check passes.
  • No live secrets, tokens, private logs, or unrelated generated churn are included.

Resolution gate

  • If this PR resolves an issue, the issue number and fix evidence are linked. (n/a, no issue)
  • If this PR should not merge, the rejection/defer rationale is evidence-backed and does not rely on vibes. (n/a)
  • I did not merge/close remote PRs or issues from an automation lane without owner approval.

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

@Yeachan-Heo Yeachan-Heo left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The smart-routing claim needs a source/wording correction. It says each request uses “the cheapest enabled model that can handle it, with automatic fallback.” Standard Compute’s routing docs describe selecting an enabled model according to the account’s quality preference (stronger models for harder tasks, cheaper ones for simpler tasks). Their pinning docs document provider failover within the same model and explicitly say the gateway does not switch to a different model; I couldn't verify automatic fallback for the smart-routing alias. Please align the sentence with the documented routing behavior or cite a current source for that guarantee.

The base URL, unauthenticated model catalog, listed model IDs, and local/ transport/model-prefix behavior check out.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@henrikdukefoss

Copy link
Copy Markdown
Contributor Author

Thanks, good catch. Fixed in 56ae758: the sentence now matches the routing docs (the router picks from the account's enabled models by quality preference) and the automatic fallback claim is removed. Nothing else changed.

@Yeachan-Heo Yeachan-Heo left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Standard Compute setup is accurate. The smart-routing description matches the vendor documentation, and the live unauthenticated model catalog confirms the documented gateway and model IDs. Claw's local/ prefix selects OpenAI-compatible transport and is removed before the model is sent. No changes requested.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

@Yeachan-Heo
Yeachan-Heo merged commit f51a33a into ultraworkers:main Nov 9, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants