Skip to content

docs: show OpenAI-compatible gateway setup - #1022

Open
cerebrixos wants to merge 1 commit into
prism-php:mainfrom
cerebrixos:tuning-engines-openai-compatible-docs
Open

docs: show OpenAI-compatible gateway setup#1022
cerebrixos wants to merge 1 commit into
prism-php:mainfrom
cerebrixos:tuning-engines-openai-compatible-docs

Conversation

@cerebrixos

Copy link
Copy Markdown

Summary

  • add an OpenAI-compatible gateway example to the OpenAI provider page
  • show how to route Prism through Tuning Engines by changing the provider URL and API key
  • keep Prism application calls unchanged with ->using('openai', 'gpt-4o')

Why

We are a Rails and AI infrastructure team using Prism with Tuning Engines. Since Prism already supports configurable provider URLs, this gives Laravel/PHP teams a simple setup path for governed model access, policy checks, traces, audit logs, and usage/cost reporting without changing their Prism application logic. It would mean a lot to us if you are open to including it, and I am happy to revise the copy to fit the docs style.

Validation

  • git diff --check

@cerebrixos

Copy link
Copy Markdown
Author

Hello team @pocketarc . Please do consider this PR for merge. So much appreciate in advance :)

wishborn added a commit to Particle-Academy/prism that referenced this pull request Aug 12, 2026
Inspired by prism-php#1022 by @cerebrixos, rewritten rather than
absorbed.

The gap that PR identified is real: `url` appears in the config block but
nothing on the page says it can point somewhere other than OpenAI, so the
single most common deployment question — "can I put this behind vLLM / a
gateway / Azure" — is unanswered.

The upstream PR answers it with one vendor's product as the worked example,
including their hostname, their env var name, and a paragraph of their
positioning. Merging that would put a supplier advertisement in our
provider docs and date the page to that supplier. So this documents the
capability instead: a neutral placeholder URL, self-hosted runtimes and
gateways named as categories, and no vendor endorsed.

Also adds what a user actually gets wrong here and the upstream text omits:
"OpenAI-compatible" rarely covers the whole surface, so an unsupported
feature fails at the endpoint rather than in Prism; and model names drive
capability inference, so a llama model behind the OpenAI provider is not
treated as structured-output capable. Closes with a pointer to the dedicated
providers, which map their APIs' real quirks.
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.

1 participant