@askalf/dario 5.5.89 → 5.5.90

package/dist/codex-backend.d.ts

@@ -114,6 +114,27 @@ export declare function createResponsesTranslator(model: string): {
     /** Everything seen so far, as one non-streaming chat.completion body. */
     complete(): Record<string, unknown>;
 };
+/**
+ * Fields the ChatGPT Codex backend accepts on /responses.
+ *
+ * It is NOT the public Responses API: it rejects a whole class of sampling and
+ * metadata parameters outright, one 400 at a time —
+ *   400 {"detail":"Unsupported parameter: <name>"}
+ * Probed directly against a live subscription (2026-08-30); rejected were
+ * temperature, top_p, max_output_tokens, presence_penalty, frequency_penalty,
+ * seed, metadata, top_logprobs, truncation and service_tier.
+ *
+ * This is an ALLOWLIST rather than a list of the ten known-bad names on
+ * purpose. The backend is undocumented and clearly restrictive, so the failure
+ * we must not have is "we started sending a new field and every request 400s".
+ * Dropping an unknown field degrades one request; sending one breaks all of
+ * them. Both request builders stay correct for an API-key Responses endpoint —
+ * which does accept these — because the scrub happens HERE, at the transport
+ * that knows which backend it is talking to.
+ */
+export declare const CODEX_SUPPORTED_FIELDS: readonly string[];
+/** Drop every field this backend does not accept. Pure; exported for tests. */
+export declare function toCodexSupportedBody(body: Record<string, unknown>): Record<string, unknown>;
 export declare function buildCodexHeaders(creds: CodexAccountCredentials): Record<string, string>;
 /**
  * Serve a request from a stored Codex account, in either client wire shape.

package/dist/codex-backend.js

@@ -377,6 +377,37 @@ export function createResponsesTranslator(model) {
         },
     };
 }
+/**
+ * Fields the ChatGPT Codex backend accepts on /responses.
+ *
+ * It is NOT the public Responses API: it rejects a whole class of sampling and
+ * metadata parameters outright, one 400 at a time —
+ *   400 {"detail":"Unsupported parameter: <name>"}
+ * Probed directly against a live subscription (2026-08-30); rejected were
+ * temperature, top_p, max_output_tokens, presence_penalty, frequency_penalty,
+ * seed, metadata, top_logprobs, truncation and service_tier.
+ *
+ * This is an ALLOWLIST rather than a list of the ten known-bad names on
+ * purpose. The backend is undocumented and clearly restrictive, so the failure
+ * we must not have is "we started sending a new field and every request 400s".
+ * Dropping an unknown field degrades one request; sending one breaks all of
+ * them. Both request builders stay correct for an API-key Responses endpoint —
+ * which does accept these — because the scrub happens HERE, at the transport
+ * that knows which backend it is talking to.
+ */
+export const CODEX_SUPPORTED_FIELDS = [
+    'model', 'input', 'stream', 'store', 'instructions',
+    'tools', 'tool_choice', 'parallel_tool_calls', 'reasoning',
+];
+/** Drop every field this backend does not accept. Pure; exported for tests. */
+export function toCodexSupportedBody(body) {
+    const out = {};
+    for (const k of CODEX_SUPPORTED_FIELDS) {
+        if (body[k] !== undefined)
+            out[k] = body[k];
+    }
+    return out;
+}
 export function buildCodexHeaders(creds) {
     const headers = {
         'Content-Type': 'application/json',
@@ -434,17 +465,7 @@ export async function forwardToCodex(req, res, body, creds, corsOrigin, security
     const upstreamBody = isAnthropic
         ? { ...anthropicToResponsesRequest(parsed, model), stream: true }
         : chatCompletionsToResponses(parsed);
-    // The ChatGPT Codex backend REJECTS an output cap outright:
-    //   400 {"detail":"Unsupported parameter: max_output_tokens"}
-    // Both builders set it from the client's max_tokens / max_completion_tokens,
-    // so BOTH shapes 400 whenever a client asks for one. It stayed hidden because
-    // every smoke test so far happened to omit max_tokens; it then showed up as a
-    // 100% failure on the Anthropic path, where the Messages API REQUIRES
-    // max_tokens and so always produced it. Stripped here rather than in either
-    // translator because it is a property of THIS backend, not of either wire
-    // format — the same builders are correct against an API-key Responses
-    // endpoint, which does support the parameter.
-    delete upstreamBody.max_output_tokens;
+    const scrubbed = toCodexSupportedBody(upstreamBody);
     const target = `${CODEX_BACKEND_BASE_URL.replace(/\/$/, '')}/responses`;
     const abort = new AbortController();
     const timeout = setTimeout(() => abort.abort(), upstreamTimeoutMs);
@@ -454,7 +475,7 @@ export async function forwardToCodex(req, res, body, creds, corsOrigin, security
         const upstream = await fetchImpl(target, {
             method: 'POST',
             headers: buildCodexHeaders(creds),
-            body: JSON.stringify(upstreamBody),
+            body: JSON.stringify(scrubbed),
             signal: abort.signal,
         });
         if (!upstream.ok) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@askalf/dario",
-  "version": "5.5.89",
+  "version": "5.5.90",
   "description": "Use your Claude Pro/Max subscription in any tool — Cursor, Cline, Aider, the Agent SDK, your scripts — at subscription pricing, not per-token API bills. One local Anthropic + OpenAI-compatible endpoint.",
   "type": "module",
   "bin": {