Repository navigation
docs: document promptCacheKey for custom openai-chat providers (#2541) - #2625
Conversation
Carries wssfk12138's docs onto dev with one factual correction and the privacy:scan fix the gate needs. The submitted prose said opencodex never generates the key. That is true of the adapter and false of the request path: Claude Messages translation derives a prompt_cache_key from metadata.user_id (claude/inbound.ts:523-531), or from a model/system/tools cohort when the client sends none (:532-552), because the OpenAI backends report cached_tokens:0 for every keyless turn. A reader debugging an unexpected key would have been sent the wrong way. Reworded to say what actually holds: the adapter forwards and never invents, but the key is not always the caller's. Also carries the providers-accounts.md example masking, because privacy:scan is red on dev and this PR cannot be verified green without it.
|
✅ Deterministic PR hygiene checks passed. |
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe documentation adds optional ChangesPrompt cache key documentation
OAuth example redaction
Estimated code review effort: 1 (Trivial) | ~5 minutes Suggested reviewers: ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 17c6f63daa
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| The adapter forwards the key it is given and never invents one. It can still receive a key the | ||
| caller did not send: Claude Messages translation derives one from `metadata.user_id`, or from a | ||
| model/system/tools cohort when the client sends no metadata, because the OpenAI backends report | ||
| `cached_tokens: 0` for every keyless turn. So "forwarded, not fabricated" describes this adapter, | ||
| not the whole request path. |
There was a problem hiding this comment.
Reconcile the Kimi key-generation guidance
For Claude Messages requests routed to either canonical Kimi preset, src/claude/inbound.ts derives a key and the promptCacheKey: true registry entries forward it, so the immediately preceding claim that Kimi receives only caller-supplied keys and that keyless requests remain keyless is false; the seven translated provider guides repeat that claim as well. Revise the Kimi paragraph and its translations to distinguish adapter behavior from the complete request path, rather than leaving this new qualification contradicting them.
AGENTS.md reference: docs-site/AGENTS.md:L8-L9
Useful? React with 👍 / 👎.
| caller did not send: Claude Messages translation derives one from `metadata.user_id`, or from a | ||
| model/system/tools cohort when the client sends no metadata, because the OpenAI backends report |
There was a problem hiding this comment.
State the system-prompt condition for cohort keys
For a valid Claude Messages request with neither metadata.user_id nor a system message, translation does not derive a cohort key: anthropicToResponsesTranslation gates this branch on systemParts.length > 0, and the no-metadata/no-system regression test expects prompt_cache_key to remain absent. Qualify this sentence with the system-prompt requirement so users do not expect every metadata-free request to receive a generated key.
AGENTS.md reference: docs-site/AGENTS.md:L7-L8
Useful? React with 👍 / 👎.
…-jun#2541) (lidge-jun#2625) * docs: document promptCacheKey for custom providers * docs: clarify prompt cache validation steps * docs: clarify prompt cache validation prerequisite * docs: document promptCacheKey for custom openai-chat providers (lidge-jun#2541) Carries wssfk12138's docs onto dev with one factual correction and the privacy:scan fix the gate needs. The submitted prose said opencodex never generates the key. That is true of the adapter and false of the request path: Claude Messages translation derives a prompt_cache_key from metadata.user_id (claude/inbound.ts:523-531), or from a model/system/tools cohort when the client sends none (:532-552), because the OpenAI backends report cached_tokens:0 for every keyless turn. A reader debugging an unexpected key would have been sent the wrong way. Reworded to say what actually holds: the adapter forwards and never invents, but the key is not always the caller's. Also carries the providers-accounts.md example masking, because privacy:scan is red on dev and this PR cannot be verified green without it. --------- Co-authored-by: wssfk12138 <79346097+wssfk12138@users.noreply.github.com>
…-jun#2541) (lidge-jun#2625) * docs: document promptCacheKey for custom providers * docs: clarify prompt cache validation steps * docs: clarify prompt cache validation prerequisite * docs: document promptCacheKey for custom openai-chat providers (lidge-jun#2541) Carries wssfk12138's docs onto dev with one factual correction and the privacy:scan fix the gate needs. The submitted prose said opencodex never generates the key. That is true of the adapter and false of the request path: Claude Messages translation derives a prompt_cache_key from metadata.user_id (claude/inbound.ts:523-531), or from a model/system/tools cohort when the client sends none (:532-552), because the OpenAI backends report cached_tokens:0 for every keyless turn. A reader debugging an unexpected key would have been sent the wrong way. Reworded to say what actually holds: the adapter forwards and never invents, but the key is not always the caller's. Also carries the providers-accounts.md example masking, because privacy:scan is red on dev and this PR cannot be verified green without it. --------- Co-authored-by: wssfk12138 <79346097+wssfk12138@users.noreply.github.com>
Summary
Carries #2541 by @wssfk12138 onto
devwith one factual correction, plus theprivacy:scanfix the gate needs.The correction
The submitted prose said opencodex never generates the key. That is true of the adapter and false of the request path. Claude Messages translation derives a
prompt_cache_keyfrommetadata.user_id(src/claude/inbound.ts:523-531), or from a model/system/tools cohort when the client sends no metadata (:532-552) — because the OpenAI backends reportcached_tokens: 0on every keyless turn, which is the whole reason that code exists.That matters for the reader this page is written for: someone who enables the option, sees a
prompt_cache_keythey never sent, and goes looking for a bug. The docs now say what actually holds — the adapter forwards the key it is given and never invents one, but the key is not always the caller's.Everything else in the PR checked out against the code: the config field, the opt-in default, the reload requirement, and the HTTP 400 hazard for strict gateways.
The privacy:scan fix
bun run privacy:scanis a CI gate and it is red ondev— the per-account quota example added in #2587 carries two real-looking addresses, one on a real domain. This PR could not be verified green without fixing it, so the masking is carried here: the local part was already elided, so the domain is elided the same way. Masking rather than swapping inexample.comkeeps it passing on its own terms instead of relying on a domain the regex happens not to match.Verification
Reviewed claim-by-claim against the implementing source; the reviewer also confirmed the seven translated locale guides retain deny-by-default wording and do not contradict the English source.
Checklist
devprivacy:scangreen${EXAMPLE_API_KEY}placeholderCloses #2541.
Summary by CodeRabbit
New Features
Documentation