Repository navigation
feat(compression): add Responses tool-output engine - #8010
diegosouzapw merged 7 commits into
Conversation
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8d7972779d
ℹ️ 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".
8d79727 to
5483477
Compare
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
5483477 to
5fd242d
Compare
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
5fd242d to
53b52dc
Compare
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
53b52dc to
6b7ccc2
Compare
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
1 similar comment
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Reviewed alongside #8008/#8009. The engine logic itself is solid — ran the new |
bd9b32c to
184e689
Compare
|
Thanks for the review. I addressed both requested items.
The updated branch is pushed to |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 184e6891bb
ℹ️ 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".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f51c2b6eb7
ℹ️ 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".
| value: "codex-responses", | ||
| labelKey: "compressionModeCodexResponses", | ||
| descKey: "compressionModeCodexResponsesDesc", | ||
| icon: "data_object", | ||
| }, |
There was a problem hiding this comment.
When an operator has saved the engine panel, enginesExplicit makes the persisted engines map authoritative and ignores defaultMode during plan resolution. This newly added Advanced settings choice only changes defaultMode (while the save request retains the existing engine map), so selecting it reports success but continues running the previously enabled engine or no engine at all. Update the codex-responses toggle map as part of this selection, or remove this choice from the legacy mode selector.
Useful? React with 👍 / 👎.
…odex-responses-compression
The codex-responses compression engine already imports the shared countTextTokens/resolveTokenizerEncoding from tiktokenCounter.ts (no duplicate encoder) and CompressionSettingsTab.tsx already threads the new mode through the existing useTranslations()/labelKey pattern - both pre-existing on this branch tip after rebasing onto release/v3.8.49. What was missing after the rebase: the new compressionModeCodexResponses / compressionModeCodexResponsesDesc keys existed only in en.json. Filled en-fallback into all 42 locales via scripts/i18n/fill-missing-from-en.mjs and added real pt-BR/vi translations. Also rebaselined the three files whose own growth (new codex-responses mode wiring) crossed the frozen file-size caps: open-sse/mcp-server/schemas/tools.ts, open-sse/services/ compression/strategySelector.ts, and src/lib/db/compression.ts. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
…odex-responses-compression
fb6ea29
into
cheaper-inference:release/v3.8.49
#8010 registered the codex-responses engine in the compression catalog (engineCatalog.ts, stackPriority 12 between rtk's 10 and headroom's 15) but never added it to adaptiveCompression/ladder.ts's AGGRESSIVENESS and REDUCTION_FACTOR maps. Those maps' own header documents that they must cover every real catalog/registry engine, not just the 7 in DEFAULT_LADDER, so an operator adding codex-responses via ladderOverride silently fell back to aggressivenessOf() === 0 (same as "off") and expectedReductionFactor() === 0.9 (the generic default), breaking floor-mode escalation ranking for any ladder that includes it. Add "codex-responses" to both maps between rtk and ionizer, matching its stackPriority (12) sitting between rtk's (10) and ionizer's (13): - AGGRESSIVENESS: 22 (between rtk's 20 and ionizer's 25) - REDUCTION_FACTOR: 0.84 (between rtk's 0.85 and ionizer's 0.83), reflecting its "lossless-first, bounded diagnostic" guidance in engineCatalog.ts Validation: tests/unit/ladder-engine-maps-6533.test.ts red -> green (2 of 3 tests were failing on the missing engine; all 3 pass after the fix). Sanity-checked neighbors compression-exclusions.test.ts and compression/adaptive-resolve-plan.test.ts still pass. Refs #8010
…e#8010) * Add Responses tool-output compression engine * fix: enable Codex Responses stacked steps * fix(compression): share Codex tokenizer and rebase UI * fix(compression): sync MCP engine selection * fix(compression): i18n parity for codex-responses mode + rebaseline The codex-responses compression engine already imports the shared countTextTokens/resolveTokenizerEncoding from tiktokenCounter.ts (no duplicate encoder) and CompressionSettingsTab.tsx already threads the new mode through the existing useTranslations()/labelKey pattern - both pre-existing on this branch tip after rebasing onto release/v3.8.49. What was missing after the rebase: the new compressionModeCodexResponses / compressionModeCodexResponsesDesc keys existed only in en.json. Filled en-fallback into all 42 locales via scripts/i18n/fill-missing-from-en.mjs and added real pt-BR/vi translations. Also rebaselined the three files whose own growth (new codex-responses mode wiring) crossed the frozen file-size caps: open-sse/mcp-server/schemas/tools.ts, open-sse/services/ compression/strategySelector.ts, and src/lib/db/compression.ts. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> --------- Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com> Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
…er-inference#8381) cheaper-inference#8010 registered the codex-responses engine in the compression catalog (engineCatalog.ts, stackPriority 12 between rtk's 10 and headroom's 15) but never added it to adaptiveCompression/ladder.ts's AGGRESSIVENESS and REDUCTION_FACTOR maps. Those maps' own header documents that they must cover every real catalog/registry engine, not just the 7 in DEFAULT_LADDER, so an operator adding codex-responses via ladderOverride silently fell back to aggressivenessOf() === 0 (same as "off") and expectedReductionFactor() === 0.9 (the generic default), breaking floor-mode escalation ranking for any ladder that includes it. Add "codex-responses" to both maps between rtk and ionizer, matching its stackPriority (12) sitting between rtk's (10) and ionizer's (13): - AGGRESSIVENESS: 22 (between rtk's 20 and ionizer's 25) - REDUCTION_FACTOR: 0.84 (between rtk's 0.85 and ionizer's 0.83), reflecting its "lossless-first, bounded diagnostic" guidance in engineCatalog.ts Validation: tests/unit/ladder-engine-maps-6533.test.ts red -> green (2 of 3 tests were failing on the missing engine; all 3 pass after the fix). Sanity-checked neighbors compression-exclusions.test.ts and compression/adaptive-resolve-plan.test.ts still pass. Refs cheaper-inference#8010
…e#8010) * Add Responses tool-output compression engine * fix: enable Codex Responses stacked steps * fix(compression): share Codex tokenizer and rebase UI * fix(compression): sync MCP engine selection * fix(compression): i18n parity for codex-responses mode + rebaseline The codex-responses compression engine already imports the shared countTextTokens/resolveTokenizerEncoding from tiktokenCounter.ts (no duplicate encoder) and CompressionSettingsTab.tsx already threads the new mode through the existing useTranslations()/labelKey pattern - both pre-existing on this branch tip after rebasing onto release/v3.8.49. What was missing after the rebase: the new compressionModeCodexResponses / compressionModeCodexResponsesDesc keys existed only in en.json. Filled en-fallback into all 42 locales via scripts/i18n/fill-missing-from-en.mjs and added real pt-BR/vi translations. Also rebaselined the three files whose own growth (new codex-responses mode wiring) crossed the frozen file-size caps: open-sse/mcp-server/schemas/tools.ts, open-sse/services/ compression/strategySelector.ts, and src/lib/db/compression.ts. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> --------- Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com> Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
…er-inference#8381) cheaper-inference#8010 registered the codex-responses engine in the compression catalog (engineCatalog.ts, stackPriority 12 between rtk's 10 and headroom's 15) but never added it to adaptiveCompression/ladder.ts's AGGRESSIVENESS and REDUCTION_FACTOR maps. Those maps' own header documents that they must cover every real catalog/registry engine, not just the 7 in DEFAULT_LADDER, so an operator adding codex-responses via ladderOverride silently fell back to aggressivenessOf() === 0 (same as "off") and expectedReductionFactor() === 0.9 (the generic default), breaking floor-mode escalation ranking for any ladder that includes it. Add "codex-responses" to both maps between rtk and ionizer, matching its stackPriority (12) sitting between rtk's (10) and ionizer's (13): - AGGRESSIVENESS: 22 (between rtk's 20 and ionizer's 25) - REDUCTION_FACTOR: 0.84 (between rtk's 0.85 and ionizer's 0.83), reflecting its "lossless-first, bounded diagnostic" guidance in engineCatalog.ts Validation: tests/unit/ladder-engine-maps-6533.test.ts red -> green (2 of 3 tests were failing on the missing engine; all 3 pass after the fix). Sanity-checked neighbors compression-exclusions.test.ts and compression/adaptive-resolve-plan.test.ts still pass. Refs cheaper-inference#8010
Summary
Validation
npm run lintnpm run test:unitnpm run test:coverage>= 60%for statements, lines, functions, and branchesnpm run typecheck:coreTests Added Or Updated
Coverage Notes
Reviewer Notes