hanzoai 2.2.10 → 8.5.89

package/dist/api/benchmark-api.js

@@ -57,6 +57,54 @@ const BenchmarkApiAxiosParamCreator = function (configuration) {
                 options: localVarRequestOptions,
             };
         },
+        /**
+         * Lists the effective published claims: what the leaderboard will use for each (benchmark, model) after the seed, the import and any stored correction are layered. It answers the operator\'s question — what does this arena currently believe someone else reported, and did we ship that or fix it.  Effective values only. The history of a key lives in the append-only file and is not what this op is for; a list that returned every superseded row would make the common question the hard one.
+         * @summary Lists the effective published claims: what the leaderboard will use for each (benchmark, model) after the seed, the import and any stored correction are layered.
+         * @param {string} [benchmark] Benchmark filters to one benchmark id. Empty returns every benchmark.
+         * @param {string} [model] Model filters to one model. Empty returns every model.
+         * @param {string} [provider] Provider filters to one lab or leaderboard — the way to read what a single source claims across every model it covers.
+         * @param {string} [source] Source filters to one citation, which is the finest grain there is: a source is what makes two claims about one model independent rather than a restatement of each other.
+         * @param {string} [protocol] Protocol filters by HOW a claim was scored, so provider cards can be read apart from third parties running their own harness.
+         * @param {*} [options] Override http request option.
+         * @throws {RequiredError}
+         */
+        getBenchmarkClaims: async (benchmark, model, provider, source, protocol, options = {}) => {
+            const localVarPath = `/v1/benchmark/claims`;
+            // use dummy base URL string because the URL constructor only accepts absolute URLs.
+            const localVarUrlObj = new URL(localVarPath, common_1.DUMMY_BASE_URL);
+            let baseOptions;
+            if (configuration) {
+                baseOptions = configuration.baseOptions;
+            }
+            const localVarRequestOptions = { method: 'GET', ...baseOptions, ...options };
+            const localVarHeaderParameter = {};
+            const localVarQueryParameter = {};
+            // authentication bearer required
+            // http bearer authentication required
+            await (0, common_1.setBearerAuthToObject)(localVarHeaderParameter, configuration);
+            if (benchmark !== undefined) {
+                localVarQueryParameter['Benchmark'] = benchmark;
+            }
+            if (model !== undefined) {
+                localVarQueryParameter['Model'] = model;
+            }
+            if (provider !== undefined) {
+                localVarQueryParameter['Provider'] = provider;
+            }
+            if (source !== undefined) {
+                localVarQueryParameter['Source'] = source;
+            }
+            if (protocol !== undefined) {
+                localVarQueryParameter['Protocol'] = protocol;
+            }
+            (0, common_1.setSearchParams)(localVarUrlObj, localVarQueryParameter);
+            let headersFromBaseOptions = baseOptions && baseOptions.headers ? baseOptions.headers : {};
+            localVarRequestOptions.headers = { ...localVarHeaderParameter, ...headersFromBaseOptions, ...options.headers };
+            return {
+                url: (0, common_1.toPathString)(localVarUrlObj),
+                options: localVarRequestOptions,
+            };
+        },
         /**
          * Is the ONLY valid arm-vs-arm test: it pairs the two models on the items BOTH completed, and answers rescue and damage counts with an exact-McNemar p.  Pairing is what prevents the subset artifact — comparing one model\'s easy subset against another\'s full run — so n_common, not either arm\'s own coverage, is the number to read this by.  Both a and b are required. The benchmark defaults to gpqa_diamond.
          * @summary Is the ONLY valid arm-vs-arm test: it pairs the two models on the items BOTH completed, and answers rescue and damage counts with an exact-McNemar p.
@@ -101,6 +149,42 @@ const BenchmarkApiAxiosParamCreator = function (configuration) {
                 options: localVarRequestOptions,
             };
         },
+        /**
+         * Returns each model\'s measured score per run over time, oldest first, with the change between runs.  This is the counterweight to a leaderboard: the board shows the latest run because that is what \"how good is it\" means, and a single latest number cannot distinguish a model that has always been strong from one that just improved, or from one that regressed after a provider changed something. Both matter for routing, and only one of them is visible on a board.  Runs with no id — attempts recorded before runs existed — group under the empty run, which is honestly what they are: one undated measurement.
+         * @summary Returns each model\'s measured score per run over time, oldest first, with the change between runs.
+         * @param {string} [benchmark] Benchmark is the catalog id to read, defaulting to gpqa_diamond.
+         * @param {string} [model] Model filters to one model. Empty returns every model measured.
+         * @param {*} [options] Override http request option.
+         * @throws {RequiredError}
+         */
+        getBenchmarkHistory: async (benchmark, model, options = {}) => {
+            const localVarPath = `/v1/benchmark/history`;
+            // use dummy base URL string because the URL constructor only accepts absolute URLs.
+            const localVarUrlObj = new URL(localVarPath, common_1.DUMMY_BASE_URL);
+            let baseOptions;
+            if (configuration) {
+                baseOptions = configuration.baseOptions;
+            }
+            const localVarRequestOptions = { method: 'GET', ...baseOptions, ...options };
+            const localVarHeaderParameter = {};
+            const localVarQueryParameter = {};
+            // authentication bearer required
+            // http bearer authentication required
+            await (0, common_1.setBearerAuthToObject)(localVarHeaderParameter, configuration);
+            if (benchmark !== undefined) {
+                localVarQueryParameter['Benchmark'] = benchmark;
+            }
+            if (model !== undefined) {
+                localVarQueryParameter['Model'] = model;
+            }
+            (0, common_1.setSearchParams)(localVarUrlObj, localVarQueryParameter);
+            let headersFromBaseOptions = baseOptions && baseOptions.headers ? baseOptions.headers : {};
+            localVarRequestOptions.headers = { ...localVarHeaderParameter, ...headersFromBaseOptions, ...options.headers };
+            return {
+                url: (0, common_1.toPathString)(localVarUrlObj),
+                options: localVarRequestOptions,
+            };
+        },
         /**
          * Answers one row per model for the benchmark named — what our own harness measured, beside what the vendor claims, and the gap between them.  The gap is the point of the arena; provider-reported claims have run materially hot against one standardized harness.  The two planes are NEVER blended, and that is the rule to read the rows by: a model we have measured but no vendor has claimed for shows published null, a model with only a claim shows measured null, and gap exists only where both do.  n is coverage and is not decoration: two measured numbers taken over different item counts are not comparable, so read the row\'s n before reading its accuracy.
          * @summary Answers one row per model for the benchmark named — what our own harness measured, beside what the vendor claims, and the gap between them.
@@ -161,6 +245,39 @@ const BenchmarkApiAxiosParamCreator = function (configuration) {
                 options: localVarRequestOptions,
             };
         },
+        /**
+         * Records published claims: one to correct a number, many to import a leaderboard. Every row must carry a Source, because a claim without its citation is a number nobody can check — and an unattributed number in the published plane is indistinguishable from a measurement, which is the one confusion this whole surface is built to prevent.  Writes are append-only, so this never destroys the value it replaces. A vendor restating a score leaves both rows on disk, which is how the restating itself becomes visible.
+         * @summary Records published claims: one to correct a number, many to import a leaderboard.
+         * @param {PutClaimsIn} putClaimsIn
+         * @param {*} [options] Override http request option.
+         * @throws {RequiredError}
+         */
+        postBenchmarkClaims: async (putClaimsIn, options = {}) => {
+            // verify required parameter 'putClaimsIn' is not null or undefined
+            (0, common_1.assertParamExists)('postBenchmarkClaims', 'putClaimsIn', putClaimsIn);
+            const localVarPath = `/v1/benchmark/claims`;
+            // use dummy base URL string because the URL constructor only accepts absolute URLs.
+            const localVarUrlObj = new URL(localVarPath, common_1.DUMMY_BASE_URL);
+            let baseOptions;
+            if (configuration) {
+                baseOptions = configuration.baseOptions;
+            }
+            const localVarRequestOptions = { method: 'POST', ...baseOptions, ...options };
+            const localVarHeaderParameter = {};
+            const localVarQueryParameter = {};
+            // authentication bearer required
+            // http bearer authentication required
+            await (0, common_1.setBearerAuthToObject)(localVarHeaderParameter, configuration);
+            localVarHeaderParameter['Content-Type'] = 'application/json';
+            (0, common_1.setSearchParams)(localVarUrlObj, localVarQueryParameter);
+            let headersFromBaseOptions = baseOptions && baseOptions.headers ? baseOptions.headers : {};
+            localVarRequestOptions.headers = { ...localVarHeaderParameter, ...headersFromBaseOptions, ...options.headers };
+            localVarRequestOptions.data = (0, common_1.serializeDataIfNeeded)(putClaimsIn, localVarRequestOptions, configuration);
+            return {
+                url: (0, common_1.toPathString)(localVarUrlObj),
+                options: localVarRequestOptions,
+            };
+        },
         /**
          * Validates a router blend — its name, its arms, the rank they escalate through and the panel fan-out width — and answers 202 with the preset and the enso-<name> it would be served as.  It VALIDATES AND ECHOES: the definition is not persisted yet, so a preset accepted here is not one the model layer will resolve. Treat the response as a check on the blend, not a promise to serve it.  Defaults fill the shape rather than refusing it: an omitted rank becomes the arms in declared order and a panel below 1 becomes 1. The one real invariant is that rank may only name arms the blend declares — the same rule the model catalog enforces — and a rank naming anything else is a 422 listing exactly which entries were undeclared. A blend with no name or no arms is a 400.
          * @summary Validates a router blend — its name, its arms, the rank they escalate through and the panel fan-out width — and answers 202 with the preset and the enso-<name> it would be served as.
@@ -249,6 +366,23 @@ const BenchmarkApiFp = function (configuration) {
             const localVarOperationServerBasePath = base_1.operationServerMap['BenchmarkApi.getBenchmarkCatalog']?.[localVarOperationServerIndex]?.url;
             return (axios, basePath) => (0, common_1.createRequestFunction)(localVarAxiosArgs, axios_1.default, base_1.BASE_PATH, configuration)(axios, localVarOperationServerBasePath || basePath);
         },
+        /**
+         * Lists the effective published claims: what the leaderboard will use for each (benchmark, model) after the seed, the import and any stored correction are layered. It answers the operator\'s question — what does this arena currently believe someone else reported, and did we ship that or fix it.  Effective values only. The history of a key lives in the append-only file and is not what this op is for; a list that returned every superseded row would make the common question the hard one.
+         * @summary Lists the effective published claims: what the leaderboard will use for each (benchmark, model) after the seed, the import and any stored correction are layered.
+         * @param {string} [benchmark] Benchmark filters to one benchmark id. Empty returns every benchmark.
+         * @param {string} [model] Model filters to one model. Empty returns every model.
+         * @param {string} [provider] Provider filters to one lab or leaderboard — the way to read what a single source claims across every model it covers.
+         * @param {string} [source] Source filters to one citation, which is the finest grain there is: a source is what makes two claims about one model independent rather than a restatement of each other.
+         * @param {string} [protocol] Protocol filters by HOW a claim was scored, so provider cards can be read apart from third parties running their own harness.
+         * @param {*} [options] Override http request option.
+         * @throws {RequiredError}
+         */
+        async getBenchmarkClaims(benchmark, model, provider, source, protocol, options) {
+            const localVarAxiosArgs = await localVarAxiosParamCreator.getBenchmarkClaims(benchmark, model, provider, source, protocol, options);
+            const localVarOperationServerIndex = configuration?.serverIndex ?? 0;
+            const localVarOperationServerBasePath = base_1.operationServerMap['BenchmarkApi.getBenchmarkClaims']?.[localVarOperationServerIndex]?.url;
+            return (axios, basePath) => (0, common_1.createRequestFunction)(localVarAxiosArgs, axios_1.default, base_1.BASE_PATH, configuration)(axios, localVarOperationServerBasePath || basePath);
+        },
         /**
          * Is the ONLY valid arm-vs-arm test: it pairs the two models on the items BOTH completed, and answers rescue and damage counts with an exact-McNemar p.  Pairing is what prevents the subset artifact — comparing one model\'s easy subset against another\'s full run — so n_common, not either arm\'s own coverage, is the number to read this by.  Both a and b are required. The benchmark defaults to gpqa_diamond.
          * @summary Is the ONLY valid arm-vs-arm test: it pairs the two models on the items BOTH completed, and answers rescue and damage counts with an exact-McNemar p.
@@ -264,6 +398,20 @@ const BenchmarkApiFp = function (configuration) {
             const localVarOperationServerBasePath = base_1.operationServerMap['BenchmarkApi.getBenchmarkCompare']?.[localVarOperationServerIndex]?.url;
             return (axios, basePath) => (0, common_1.createRequestFunction)(localVarAxiosArgs, axios_1.default, base_1.BASE_PATH, configuration)(axios, localVarOperationServerBasePath || basePath);
         },
+        /**
+         * Returns each model\'s measured score per run over time, oldest first, with the change between runs.  This is the counterweight to a leaderboard: the board shows the latest run because that is what \"how good is it\" means, and a single latest number cannot distinguish a model that has always been strong from one that just improved, or from one that regressed after a provider changed something. Both matter for routing, and only one of them is visible on a board.  Runs with no id — attempts recorded before runs existed — group under the empty run, which is honestly what they are: one undated measurement.
+         * @summary Returns each model\'s measured score per run over time, oldest first, with the change between runs.
+         * @param {string} [benchmark] Benchmark is the catalog id to read, defaulting to gpqa_diamond.
+         * @param {string} [model] Model filters to one model. Empty returns every model measured.
+         * @param {*} [options] Override http request option.
+         * @throws {RequiredError}
+         */
+        async getBenchmarkHistory(benchmark, model, options) {
+            const localVarAxiosArgs = await localVarAxiosParamCreator.getBenchmarkHistory(benchmark, model, options);
+            const localVarOperationServerIndex = configuration?.serverIndex ?? 0;
+            const localVarOperationServerBasePath = base_1.operationServerMap['BenchmarkApi.getBenchmarkHistory']?.[localVarOperationServerIndex]?.url;
+            return (axios, basePath) => (0, common_1.createRequestFunction)(localVarAxiosArgs, axios_1.default, base_1.BASE_PATH, configuration)(axios, localVarOperationServerBasePath || basePath);
+        },
         /**
          * Answers one row per model for the benchmark named — what our own harness measured, beside what the vendor claims, and the gap between them.  The gap is the point of the arena; provider-reported claims have run materially hot against one standardized harness.  The two planes are NEVER blended, and that is the rule to read the rows by: a model we have measured but no vendor has claimed for shows published null, a model with only a claim shows measured null, and gap exists only where both do.  n is coverage and is not decoration: two measured numbers taken over different item counts are not comparable, so read the row\'s n before reading its accuracy.
          * @summary Answers one row per model for the benchmark named — what our own harness measured, beside what the vendor claims, and the gap between them.
@@ -289,6 +437,19 @@ const BenchmarkApiFp = function (configuration) {
             const localVarOperationServerBasePath = base_1.operationServerMap['BenchmarkApi.getBenchmarkPresets']?.[localVarOperationServerIndex]?.url;
             return (axios, basePath) => (0, common_1.createRequestFunction)(localVarAxiosArgs, axios_1.default, base_1.BASE_PATH, configuration)(axios, localVarOperationServerBasePath || basePath);
         },
+        /**
+         * Records published claims: one to correct a number, many to import a leaderboard. Every row must carry a Source, because a claim without its citation is a number nobody can check — and an unattributed number in the published plane is indistinguishable from a measurement, which is the one confusion this whole surface is built to prevent.  Writes are append-only, so this never destroys the value it replaces. A vendor restating a score leaves both rows on disk, which is how the restating itself becomes visible.
+         * @summary Records published claims: one to correct a number, many to import a leaderboard.
+         * @param {PutClaimsIn} putClaimsIn
+         * @param {*} [options] Override http request option.
+         * @throws {RequiredError}
+         */
+        async postBenchmarkClaims(putClaimsIn, options) {
+            const localVarAxiosArgs = await localVarAxiosParamCreator.postBenchmarkClaims(putClaimsIn, options);
+            const localVarOperationServerIndex = configuration?.serverIndex ?? 0;
+            const localVarOperationServerBasePath = base_1.operationServerMap['BenchmarkApi.postBenchmarkClaims']?.[localVarOperationServerIndex]?.url;
+            return (axios, basePath) => (0, common_1.createRequestFunction)(localVarAxiosArgs, axios_1.default, base_1.BASE_PATH, configuration)(axios, localVarOperationServerBasePath || basePath);
+        },
         /**
          * Validates a router blend — its name, its arms, the rank they escalate through and the panel fan-out width — and answers 202 with the preset and the enso-<name> it would be served as.  It VALIDATES AND ECHOES: the definition is not persisted yet, so a preset accepted here is not one the model layer will resolve. Treat the response as a check on the blend, not a promise to serve it.  Defaults fill the shape rather than refusing it: an omitted rank becomes the arms in declared order and a panel below 1 becomes 1. The one real invariant is that rank may only name arms the blend declares — the same rule the model catalog enforces — and a rank naming anything else is a 422 listing exactly which entries were undeclared. A blend with no name or no arms is a 400.
          * @summary Validates a router blend — its name, its arms, the rank they escalate through and the panel fan-out width — and answers 202 with the preset and the enso-<name> it would be served as.
@@ -334,6 +495,16 @@ const BenchmarkApiFactory = function (configuration, basePath, axios) {
         getBenchmarkCatalog(options) {
             return localVarFp.getBenchmarkCatalog(options).then((request) => request(axios, basePath));
         },
+        /**
+         * Lists the effective published claims: what the leaderboard will use for each (benchmark, model) after the seed, the import and any stored correction are layered. It answers the operator\'s question — what does this arena currently believe someone else reported, and did we ship that or fix it.  Effective values only. The history of a key lives in the append-only file and is not what this op is for; a list that returned every superseded row would make the common question the hard one.
+         * @summary Lists the effective published claims: what the leaderboard will use for each (benchmark, model) after the seed, the import and any stored correction are layered.
+         * @param {BenchmarkApiGetBenchmarkClaimsRequest} requestParameters Request parameters.
+         * @param {*} [options] Override http request option.
+         * @throws {RequiredError}
+         */
+        getBenchmarkClaims(requestParameters = {}, options) {
+            return localVarFp.getBenchmarkClaims(requestParameters.benchmark, requestParameters.model, requestParameters.provider, requestParameters.source, requestParameters.protocol, options).then((request) => request(axios, basePath));
+        },
         /**
          * Is the ONLY valid arm-vs-arm test: it pairs the two models on the items BOTH completed, and answers rescue and damage counts with an exact-McNemar p.  Pairing is what prevents the subset artifact — comparing one model\'s easy subset against another\'s full run — so n_common, not either arm\'s own coverage, is the number to read this by.  Both a and b are required. The benchmark defaults to gpqa_diamond.
          * @summary Is the ONLY valid arm-vs-arm test: it pairs the two models on the items BOTH completed, and answers rescue and damage counts with an exact-McNemar p.
@@ -344,6 +515,16 @@ const BenchmarkApiFactory = function (configuration, basePath, axios) {
         getBenchmarkCompare(requestParameters, options) {
             return localVarFp.getBenchmarkCompare(requestParameters.a, requestParameters.b, requestParameters.benchmark, options).then((request) => request(axios, basePath));
         },
+        /**
+         * Returns each model\'s measured score per run over time, oldest first, with the change between runs.  This is the counterweight to a leaderboard: the board shows the latest run because that is what \"how good is it\" means, and a single latest number cannot distinguish a model that has always been strong from one that just improved, or from one that regressed after a provider changed something. Both matter for routing, and only one of them is visible on a board.  Runs with no id — attempts recorded before runs existed — group under the empty run, which is honestly what they are: one undated measurement.
+         * @summary Returns each model\'s measured score per run over time, oldest first, with the change between runs.
+         * @param {BenchmarkApiGetBenchmarkHistoryRequest} requestParameters Request parameters.
+         * @param {*} [options] Override http request option.
+         * @throws {RequiredError}
+         */
+        getBenchmarkHistory(requestParameters = {}, options) {
+            return localVarFp.getBenchmarkHistory(requestParameters.benchmark, requestParameters.model, options).then((request) => request(axios, basePath));
+        },
         /**
          * Answers one row per model for the benchmark named — what our own harness measured, beside what the vendor claims, and the gap between them.  The gap is the point of the arena; provider-reported claims have run materially hot against one standardized harness.  The two planes are NEVER blended, and that is the rule to read the rows by: a model we have measured but no vendor has claimed for shows published null, a model with only a claim shows measured null, and gap exists only where both do.  n is coverage and is not decoration: two measured numbers taken over different item counts are not comparable, so read the row\'s n before reading its accuracy.
          * @summary Answers one row per model for the benchmark named — what our own harness measured, beside what the vendor claims, and the gap between them.
@@ -363,6 +544,16 @@ const BenchmarkApiFactory = function (configuration, basePath, axios) {
         getBenchmarkPresets(options) {
             return localVarFp.getBenchmarkPresets(options).then((request) => request(axios, basePath));
         },
+        /**
+         * Records published claims: one to correct a number, many to import a leaderboard. Every row must carry a Source, because a claim without its citation is a number nobody can check — and an unattributed number in the published plane is indistinguishable from a measurement, which is the one confusion this whole surface is built to prevent.  Writes are append-only, so this never destroys the value it replaces. A vendor restating a score leaves both rows on disk, which is how the restating itself becomes visible.
+         * @summary Records published claims: one to correct a number, many to import a leaderboard.
+         * @param {BenchmarkApiPostBenchmarkClaimsRequest} requestParameters Request parameters.
+         * @param {*} [options] Override http request option.
+         * @throws {RequiredError}
+         */
+        postBenchmarkClaims(requestParameters, options) {
+            return localVarFp.postBenchmarkClaims(requestParameters.putClaimsIn, options).then((request) => request(axios, basePath));
+        },
         /**
          * Validates a router blend — its name, its arms, the rank they escalate through and the panel fan-out width — and answers 202 with the preset and the enso-<name> it would be served as.  It VALIDATES AND ECHOES: the definition is not persisted yet, so a preset accepted here is not one the model layer will resolve. Treat the response as a check on the blend, not a promise to serve it.  Defaults fill the shape rather than refusing it: an omitted rank becomes the arms in declared order and a panel below 1 becomes 1. The one real invariant is that rank may only name arms the blend declares — the same rule the model catalog enforces — and a rank naming anything else is a 422 listing exactly which entries were undeclared. A blend with no name or no arms is a 400.
          * @summary Validates a router blend — its name, its arms, the rank they escalate through and the panel fan-out width — and answers 202 with the preset and the enso-<name> it would be served as.
@@ -403,6 +594,17 @@ class BenchmarkApi extends base_1.BaseAPI {
     getBenchmarkCatalog(options) {
         return (0, exports.BenchmarkApiFp)(this.configuration).getBenchmarkCatalog(options).then((request) => request(this.axios, this.basePath));
     }
+    /**
+     * Lists the effective published claims: what the leaderboard will use for each (benchmark, model) after the seed, the import and any stored correction are layered. It answers the operator\'s question — what does this arena currently believe someone else reported, and did we ship that or fix it.  Effective values only. The history of a key lives in the append-only file and is not what this op is for; a list that returned every superseded row would make the common question the hard one.
+     * @summary Lists the effective published claims: what the leaderboard will use for each (benchmark, model) after the seed, the import and any stored correction are layered.
+     * @param {BenchmarkApiGetBenchmarkClaimsRequest} requestParameters Request parameters.
+     * @param {*} [options] Override http request option.
+     * @throws {RequiredError}
+     * @memberof BenchmarkApi
+     */
+    getBenchmarkClaims(requestParameters = {}, options) {
+        return (0, exports.BenchmarkApiFp)(this.configuration).getBenchmarkClaims(requestParameters.benchmark, requestParameters.model, requestParameters.provider, requestParameters.source, requestParameters.protocol, options).then((request) => request(this.axios, this.basePath));
+    }
     /**
      * Is the ONLY valid arm-vs-arm test: it pairs the two models on the items BOTH completed, and answers rescue and damage counts with an exact-McNemar p.  Pairing is what prevents the subset artifact — comparing one model\'s easy subset against another\'s full run — so n_common, not either arm\'s own coverage, is the number to read this by.  Both a and b are required. The benchmark defaults to gpqa_diamond.
      * @summary Is the ONLY valid arm-vs-arm test: it pairs the two models on the items BOTH completed, and answers rescue and damage counts with an exact-McNemar p.
@@ -414,6 +616,17 @@ class BenchmarkApi extends base_1.BaseAPI {
     getBenchmarkCompare(requestParameters, options) {
         return (0, exports.BenchmarkApiFp)(this.configuration).getBenchmarkCompare(requestParameters.a, requestParameters.b, requestParameters.benchmark, options).then((request) => request(this.axios, this.basePath));
     }
+    /**
+     * Returns each model\'s measured score per run over time, oldest first, with the change between runs.  This is the counterweight to a leaderboard: the board shows the latest run because that is what \"how good is it\" means, and a single latest number cannot distinguish a model that has always been strong from one that just improved, or from one that regressed after a provider changed something. Both matter for routing, and only one of them is visible on a board.  Runs with no id — attempts recorded before runs existed — group under the empty run, which is honestly what they are: one undated measurement.
+     * @summary Returns each model\'s measured score per run over time, oldest first, with the change between runs.
+     * @param {BenchmarkApiGetBenchmarkHistoryRequest} requestParameters Request parameters.
+     * @param {*} [options] Override http request option.
+     * @throws {RequiredError}
+     * @memberof BenchmarkApi
+     */
+    getBenchmarkHistory(requestParameters = {}, options) {
+        return (0, exports.BenchmarkApiFp)(this.configuration).getBenchmarkHistory(requestParameters.benchmark, requestParameters.model, options).then((request) => request(this.axios, this.basePath));
+    }
     /**
      * Answers one row per model for the benchmark named — what our own harness measured, beside what the vendor claims, and the gap between them.  The gap is the point of the arena; provider-reported claims have run materially hot against one standardized harness.  The two planes are NEVER blended, and that is the rule to read the rows by: a model we have measured but no vendor has claimed for shows published null, a model with only a claim shows measured null, and gap exists only where both do.  n is coverage and is not decoration: two measured numbers taken over different item counts are not comparable, so read the row\'s n before reading its accuracy.
      * @summary Answers one row per model for the benchmark named — what our own harness measured, beside what the vendor claims, and the gap between them.
@@ -435,6 +648,17 @@ class BenchmarkApi extends base_1.BaseAPI {
     getBenchmarkPresets(options) {
         return (0, exports.BenchmarkApiFp)(this.configuration).getBenchmarkPresets(options).then((request) => request(this.axios, this.basePath));
     }
+    /**
+     * Records published claims: one to correct a number, many to import a leaderboard. Every row must carry a Source, because a claim without its citation is a number nobody can check — and an unattributed number in the published plane is indistinguishable from a measurement, which is the one confusion this whole surface is built to prevent.  Writes are append-only, so this never destroys the value it replaces. A vendor restating a score leaves both rows on disk, which is how the restating itself becomes visible.
+     * @summary Records published claims: one to correct a number, many to import a leaderboard.
+     * @param {BenchmarkApiPostBenchmarkClaimsRequest} requestParameters Request parameters.
+     * @param {*} [options] Override http request option.
+     * @throws {RequiredError}
+     * @memberof BenchmarkApi
+     */
+    postBenchmarkClaims(requestParameters, options) {
+        return (0, exports.BenchmarkApiFp)(this.configuration).postBenchmarkClaims(requestParameters.putClaimsIn, options).then((request) => request(this.axios, this.basePath));
+    }
     /**
      * Validates a router blend — its name, its arms, the rank they escalate through and the panel fan-out width — and answers 202 with the preset and the enso-<name> it would be served as.  It VALIDATES AND ECHOES: the definition is not persisted yet, so a preset accepted here is not one the model layer will resolve. Treat the response as a check on the blend, not a promise to serve it.  Defaults fill the shape rather than refusing it: an omitted rank becomes the arms in declared order and a panel below 1 becomes 1. The one real invariant is that rank may only name arms the blend declares — the same rule the model catalog enforces — and a rank naming anything else is a 422 listing exactly which entries were undeclared. A blend with no name or no arms is a 400.
      * @summary Validates a router blend — its name, its arms, the rank they escalate through and the panel fan-out width — and answers 202 with the preset and the enso-<name> it would be served as.

package/dist/api/billing-api.d.ts

@@ -97,6 +97,13 @@ export declare const BillingApiAxiosParamCreator: (configuration?: Configuration
      * @throws {RequiredError}
      */
     getBillingCreditBalance: (options?: RawAxiosRequestConfig) => Promise<RequestArgs>;
+    /**
+     * Returns the same balance /v1/billing/credit-balance reports, split by the tag each grant carries, so a reader can tell trial credit from bought credit and show the earliest expiry within each group. A console needs the split to say what will lapse and when; the single number cannot.  The subject is pinned to the caller before the handler runs, exactly as in the sibling reads, so the userId parameter can never name another tenant. A subject with no grants is an empty breakdown and a zero total, which is an answer and not an error.
+     * @summary What is left of your credit, grouped by where it came from
+     * @param {*} [options] Override http request option.
+     * @throws {RequiredError}
+     */
+    getBillingCreditBalanceBreakdown: (options?: RawAxiosRequestConfig) => Promise<RequestArgs>;
     /**
      * Returns the caller org\'s credit grants — each with its original amount, what remains and when it expires — so a customer can see what was given and what is left before metered spend draws it down. It is a READ of the caller\'s own subject, pinned before the handler runs, so a grant belonging to another tenant is simply absent. Granting credit is not this route and never has been: minting lands on the mint-gated POST /v1/billing/credit, which no browser can reach. Reading an empty balance is an empty array, not an error.
      * @summary List the credit grants on your org\'s balance
@@ -204,6 +211,13 @@ export declare const BillingApiAxiosParamCreator: (configuration?: Configuration
      * @throws {RequiredError}
      */
     getBillingUsageAccounts: (options?: RawAxiosRequestConfig) => Promise<RequestArgs>;
+    /**
+     * Answers the one read the account page renders: the subject\'s resolved plan, the plan\'s included monthly allotment beside what was actually granted this period, consumption capped at that grant, the overage past it, and the spendable wallet (balance minus holds) — all for the current UTC month, every figure derived from the same transactions the gateway\'s balance gate reads, so this read can never disagree with the gate that admits the next call. It rides the same pinned chain as the sibling reads: the user parameter is overwritten with the validated caller\'s own billing subject before the handler runs, so it can never name another tenant; user is required, which only a service-to-service caller can omit and be refused 400 for, and plan is optional — omitted, it is resolved from the subject\'s subscription. The rule to get right is that the two sides are DIFFERENT MONEY: the included figures are usage the subscription grants and the wallet is prepaid credit the customer bought, so a reader who sums them invents a balance nobody holds — and before the period\'s first allotment grant runs, monthlyCents shows the plan\'s entitlement while grantedCents is zero, which is the figure consumption actually draws down.
+     * @summary What plan you are on and how much of it is left, beside the wallet
+     * @param {*} [options] Override http request option.
+     * @throws {RequiredError}
+     */
+    getBillingUsageRollup: (options?: RawAxiosRequestConfig) => Promise<RequestArgs>;
     /**
      * Answers the receiving bank details for the brand this deployment serves — the account the funds actually land in, hydrated per brand rather than hard-coded — together with the payment reference to put on the transfer.  THE REFERENCE IS THE POINT. It carries your own billing key, and it is how an arriving wire is attributed to your account; a transfer sent without it arrives as an unidentified receipt. That is why this read is gated at all: an unpinned caller would be handed an unattributable reference.  Reading it credits nothing and reserves nothing. A wire is settled by an operator when the bank shows the funds, so the balance moves on receipt, not on this call.
      * @summary Where to wire funds, and the reference that credits them to you
@@ -419,6 +433,13 @@ export declare const BillingApiFp: (configuration?: Configuration) => {
      * @throws {RequiredError}
      */
     getBillingCreditBalance(options?: RawAxiosRequestConfig): Promise<(axios?: AxiosInstance, basePath?: string) => AxiosPromise<void>>;
+    /**
+     * Returns the same balance /v1/billing/credit-balance reports, split by the tag each grant carries, so a reader can tell trial credit from bought credit and show the earliest expiry within each group. A console needs the split to say what will lapse and when; the single number cannot.  The subject is pinned to the caller before the handler runs, exactly as in the sibling reads, so the userId parameter can never name another tenant. A subject with no grants is an empty breakdown and a zero total, which is an answer and not an error.
+     * @summary What is left of your credit, grouped by where it came from
+     * @param {*} [options] Override http request option.
+     * @throws {RequiredError}
+     */
+    getBillingCreditBalanceBreakdown(options?: RawAxiosRequestConfig): Promise<(axios?: AxiosInstance, basePath?: string) => AxiosPromise<void>>;
     /**
      * Returns the caller org\'s credit grants — each with its original amount, what remains and when it expires — so a customer can see what was given and what is left before metered spend draws it down. It is a READ of the caller\'s own subject, pinned before the handler runs, so a grant belonging to another tenant is simply absent. Granting credit is not this route and never has been: minting lands on the mint-gated POST /v1/billing/credit, which no browser can reach. Reading an empty balance is an empty array, not an error.
      * @summary List the credit grants on your org\'s balance
@@ -526,6 +547,13 @@ export declare const BillingApiFp: (configuration?: Configuration) => {
      * @throws {RequiredError}
      */
     getBillingUsageAccounts(options?: RawAxiosRequestConfig): Promise<(axios?: AxiosInstance, basePath?: string) => AxiosPromise<Accounts>>;
+    /**
+     * Answers the one read the account page renders: the subject\'s resolved plan, the plan\'s included monthly allotment beside what was actually granted this period, consumption capped at that grant, the overage past it, and the spendable wallet (balance minus holds) — all for the current UTC month, every figure derived from the same transactions the gateway\'s balance gate reads, so this read can never disagree with the gate that admits the next call. It rides the same pinned chain as the sibling reads: the user parameter is overwritten with the validated caller\'s own billing subject before the handler runs, so it can never name another tenant; user is required, which only a service-to-service caller can omit and be refused 400 for, and plan is optional — omitted, it is resolved from the subject\'s subscription. The rule to get right is that the two sides are DIFFERENT MONEY: the included figures are usage the subscription grants and the wallet is prepaid credit the customer bought, so a reader who sums them invents a balance nobody holds — and before the period\'s first allotment grant runs, monthlyCents shows the plan\'s entitlement while grantedCents is zero, which is the figure consumption actually draws down.
+     * @summary What plan you are on and how much of it is left, beside the wallet
+     * @param {*} [options] Override http request option.
+     * @throws {RequiredError}
+     */
+    getBillingUsageRollup(options?: RawAxiosRequestConfig): Promise<(axios?: AxiosInstance, basePath?: string) => AxiosPromise<void>>;
     /**
      * Answers the receiving bank details for the brand this deployment serves — the account the funds actually land in, hydrated per brand rather than hard-coded — together with the payment reference to put on the transfer.  THE REFERENCE IS THE POINT. It carries your own billing key, and it is how an arriving wire is attributed to your account; a transfer sent without it arrives as an unidentified receipt. That is why this read is gated at all: an unpinned caller would be handed an unattributable reference.  Reading it credits nothing and reserves nothing. A wire is settled by an operator when the bank shows the funds, so the balance moves on receipt, not on this call.
      * @summary Where to wire funds, and the reference that credits them to you
@@ -741,6 +769,13 @@ export declare const BillingApiFactory: (configuration?: Configuration, basePath
      * @throws {RequiredError}
      */
     getBillingCreditBalance(options?: RawAxiosRequestConfig): AxiosPromise<void>;
+    /**
+     * Returns the same balance /v1/billing/credit-balance reports, split by the tag each grant carries, so a reader can tell trial credit from bought credit and show the earliest expiry within each group. A console needs the split to say what will lapse and when; the single number cannot.  The subject is pinned to the caller before the handler runs, exactly as in the sibling reads, so the userId parameter can never name another tenant. A subject with no grants is an empty breakdown and a zero total, which is an answer and not an error.
+     * @summary What is left of your credit, grouped by where it came from
+     * @param {*} [options] Override http request option.
+     * @throws {RequiredError}
+     */
+    getBillingCreditBalanceBreakdown(options?: RawAxiosRequestConfig): AxiosPromise<void>;
     /**
      * Returns the caller org\'s credit grants — each with its original amount, what remains and when it expires — so a customer can see what was given and what is left before metered spend draws it down. It is a READ of the caller\'s own subject, pinned before the handler runs, so a grant belonging to another tenant is simply absent. Granting credit is not this route and never has been: minting lands on the mint-gated POST /v1/billing/credit, which no browser can reach. Reading an empty balance is an empty array, not an error.
      * @summary List the credit grants on your org\'s balance
@@ -848,6 +883,13 @@ export declare const BillingApiFactory: (configuration?: Configuration, basePath
      * @throws {RequiredError}
      */
     getBillingUsageAccounts(options?: RawAxiosRequestConfig): AxiosPromise<Accounts>;
+    /**
+     * Answers the one read the account page renders: the subject\'s resolved plan, the plan\'s included monthly allotment beside what was actually granted this period, consumption capped at that grant, the overage past it, and the spendable wallet (balance minus holds) — all for the current UTC month, every figure derived from the same transactions the gateway\'s balance gate reads, so this read can never disagree with the gate that admits the next call. It rides the same pinned chain as the sibling reads: the user parameter is overwritten with the validated caller\'s own billing subject before the handler runs, so it can never name another tenant; user is required, which only a service-to-service caller can omit and be refused 400 for, and plan is optional — omitted, it is resolved from the subject\'s subscription. The rule to get right is that the two sides are DIFFERENT MONEY: the included figures are usage the subscription grants and the wallet is prepaid credit the customer bought, so a reader who sums them invents a balance nobody holds — and before the period\'s first allotment grant runs, monthlyCents shows the plan\'s entitlement while grantedCents is zero, which is the figure consumption actually draws down.
+     * @summary What plan you are on and how much of it is left, beside the wallet
+     * @param {*} [options] Override http request option.
+     * @throws {RequiredError}
+     */
+    getBillingUsageRollup(options?: RawAxiosRequestConfig): AxiosPromise<void>;
     /**
      * Answers the receiving bank details for the brand this deployment serves — the account the funds actually land in, hydrated per brand rather than hard-coded — together with the payment reference to put on the transfer.  THE REFERENCE IS THE POINT. It carries your own billing key, and it is how an arriving wire is attributed to your account; a transfer sent without it arrives as an unidentified receipt. That is why this read is gated at all: an unpinned caller would be handed an unattributable reference.  Reading it credits nothing and reserves nothing. A wire is settled by an operator when the bank shows the funds, so the balance moves on receipt, not on this call.
      * @summary Where to wire funds, and the reference that credits them to you
@@ -1270,6 +1312,14 @@ export declare class BillingApi extends BaseAPI {
      * @memberof BillingApi
      */
     getBillingCreditBalance(options?: RawAxiosRequestConfig): Promise<globalAxios.AxiosResponse<void, any, {}>>;
+    /**
+     * Returns the same balance /v1/billing/credit-balance reports, split by the tag each grant carries, so a reader can tell trial credit from bought credit and show the earliest expiry within each group. A console needs the split to say what will lapse and when; the single number cannot.  The subject is pinned to the caller before the handler runs, exactly as in the sibling reads, so the userId parameter can never name another tenant. A subject with no grants is an empty breakdown and a zero total, which is an answer and not an error.
+     * @summary What is left of your credit, grouped by where it came from
+     * @param {*} [options] Override http request option.
+     * @throws {RequiredError}
+     * @memberof BillingApi
+     */
+    getBillingCreditBalanceBreakdown(options?: RawAxiosRequestConfig): Promise<globalAxios.AxiosResponse<void, any, {}>>;
     /**
      * Returns the caller org\'s credit grants — each with its original amount, what remains and when it expires — so a customer can see what was given and what is left before metered spend draws it down. It is a READ of the caller\'s own subject, pinned before the handler runs, so a grant belonging to another tenant is simply absent. Granting credit is not this route and never has been: minting lands on the mint-gated POST /v1/billing/credit, which no browser can reach. Reading an empty balance is an empty array, not an error.
      * @summary List the credit grants on your org\'s balance
@@ -1392,6 +1442,14 @@ export declare class BillingApi extends BaseAPI {
      * @memberof BillingApi
      */
     getBillingUsageAccounts(options?: RawAxiosRequestConfig): Promise<globalAxios.AxiosResponse<Accounts, any, {}>>;
+    /**
+     * Answers the one read the account page renders: the subject\'s resolved plan, the plan\'s included monthly allotment beside what was actually granted this period, consumption capped at that grant, the overage past it, and the spendable wallet (balance minus holds) — all for the current UTC month, every figure derived from the same transactions the gateway\'s balance gate reads, so this read can never disagree with the gate that admits the next call. It rides the same pinned chain as the sibling reads: the user parameter is overwritten with the validated caller\'s own billing subject before the handler runs, so it can never name another tenant; user is required, which only a service-to-service caller can omit and be refused 400 for, and plan is optional — omitted, it is resolved from the subject\'s subscription. The rule to get right is that the two sides are DIFFERENT MONEY: the included figures are usage the subscription grants and the wallet is prepaid credit the customer bought, so a reader who sums them invents a balance nobody holds — and before the period\'s first allotment grant runs, monthlyCents shows the plan\'s entitlement while grantedCents is zero, which is the figure consumption actually draws down.
+     * @summary What plan you are on and how much of it is left, beside the wallet
+     * @param {*} [options] Override http request option.
+     * @throws {RequiredError}
+     * @memberof BillingApi
+     */
+    getBillingUsageRollup(options?: RawAxiosRequestConfig): Promise<globalAxios.AxiosResponse<void, any, {}>>;
     /**
      * Answers the receiving bank details for the brand this deployment serves — the account the funds actually land in, hydrated per brand rather than hard-coded — together with the payment reference to put on the transfer.  THE REFERENCE IS THE POINT. It carries your own billing key, and it is how an arriving wire is attributed to your account; a transfer sent without it arrives as an unidentified receipt. That is why this read is gated at all: an unpinned caller would be handed an unattributable reference.  Reading it credits nothing and reserves nothing. A wire is settled by an operator when the bank shows the funds, so the balance moves on receipt, not on this call.
      * @summary Where to wire funds, and the reference that credits them to you