eric/scriptorium
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 6 Wiki Activity

Implement support for OpenRouter sticky routing via a session_id variable

Browse Source
This commit is contained in:
Eric Rakestraw
2026-07-02 20:08:44 -05:00
parent 4d4bb7a121
commit 63fb8fc132
19 changed files with 363 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
docs/roadmap/cache.md
View File

@@ -129,7 +129,6 @@ These are intentionally out of scope for the initial feature:
- Image, tool, or non-text content blocks.
- Provider-specific automatic prompt caching toggles.
- Top-level OpenRouter `cache_control`.
- Top-level OpenRouter `session_id`.
- General-purpose serialization of `extra_params`.
- Provider-specific validation profiles for cache-control limits.

4
docs/roadmap/implementation.md
View File

@@ -4,7 +4,7 @@
This plan implements the feature defined in `docs/roadmap/cache.md`.
The implementation target is message-level Anthropic/OpenRouter-style cache control for rendered prompt messages, plus cache usage observability. Do not implement deferred roadmap items such as `content_blocks`, top-level `cache_control`, `session_id`, or general `extra_params` serialization.
The implementation target is message-level Anthropic/OpenRouter-style cache control for rendered prompt messages, plus cache usage observability. Do not implement deferred roadmap items such as `content_blocks`, top-level `cache_control`, or general `extra_params` serialization.
Follow the policy documents under `docs/policy/` while implementing:
@@ -182,7 +182,7 @@ Request serialization decisions:
- Keep string content for messages without cache control.
- Use content blocks only when `RenderedMessage.CacheControl` is non-nil.
- Do not introduce `content_blocks` prompt syntax.
- Do not serialize top-level `cache_control`, top-level `session_id`, or `extra_params`.
- Do not serialize top-level `cache_control` or `extra_params`.
- Split request and response wire message structs. The current `openAIChatMessage` is used in both request and response paths; changing request content to `any` should not make response decoding less strict than necessary.
Use request wire types equivalent to: