akm-cli 0.9.15-beta.2 → 0.9.15-beta.4

package/docs/migration/release-notes/0.9.15.md

@@ -8,6 +8,20 @@ now, retry shortly." If a script or scheduler wrapper special-cases exit 2 to
 detect a held lease, switch it to exit 75, or read the JSON envelope's `code`
 field instead.
 
+A concurrent `akm index` now also exits 75 instead of exit 78 or exit 70. A
+2026-09-10 field report found a second `akm index` (no `--skip-if-locked`)
+colliding on the short internal barrier that registers the opt-in rebuild
+lock could fail with `{"code":"INVALID_CONFIG_FILE"}` at exit 78 — a
+config-error exit that told a supervisor to stop retrying ordinary
+contention between two legitimate runs. That barrier now retries briefly
+before giving up, and a busy barrier is reclassified as `TransientError`
+code `MAINTENANCE_BARRIER_BUSY` (exit 75) instead. Contention on index.db
+itself was already reclassified from a raw `database is locked` error (exit
+70) to `TransientError` code `INDEX_DB_CONTENDED` (exit 75). Either way, the
+fix for a scheduled or opportunistic index run is the same:
+`akm index --skip-if-locked` steps aside (exit 0) instead of contending at
+all.
+
 The six shipped scheduled `improve` task templates now run with
 `--require-engines`, which aborts (exit 78) before any index work when a
 process's engine or credential cannot be resolved in the task's own
@@ -17,6 +31,23 @@ already-materialized task files are not rewritten. To get the same protection
 on an existing scheduled task, add `--require-engines` to its `run:` command
 yourself, then run `akm task sync`.
 
+`--require-engines` now also runs a bounded reachability probe against each
+distinct engine endpoint (the same probe `akm health` already uses), not
+only a config/credential check. A field re-test found the flag let a run
+through to a fully dead endpoint, which then sat silent for minutes making
+no progress and no exit — the flag's exit-78 abort now catches that case up
+front, naming the unreachable engine and endpoint, before any index work.
+If a scheduled `--require-engines` run starts failing at exit 78 after
+upgrading, check that the engine's endpoint actually answers — this is the
+flag doing its documented job on a condition it previously missed, not a
+new failure mode. Separately, `--timeout-ms` and an engine's own configured
+timeout already aborted an in-flight request correctly, and SIGTERM/SIGINT
+already ended a run within its documented grace period — both confirmed,
+not changed, by this investigation. A live run now also prints one
+default-level line if it waits more than a few seconds on its first engine
+response, so a slow-but-alive run and a dead one are never indistinguishable
+from silence alone.
+
 `akm health --no-probe` now also skips the `cli-version` update check (a GitHub
 release lookup), alongside the engine-reachability checks it already skipped.
 An air-gapped or offline host's existing `--no-probe` habit now suppresses both
@@ -38,6 +69,17 @@ scheduled or opportunistic run step aside instead of contending with a rebuild
 already in progress; the shipped `index-refresh` scheduled task already passes
 it.
 
+`embedding.maxTokens`'s default (the per-request token budget) is now 6000,
+down from 8000: a field report on an 8192-token llama.cpp embedder showed the
+4-chars-per-token estimator undercounts dense technical text by 7-55%, so the
+old default regularly overshot the endpoint's real context window. If you
+already set `embedding.maxTokens` explicitly, this default change does not
+affect you — your configured value is unchanged. `akm index` also now
+recovers automatically within a run: on the first request rejected for
+exceeding the endpoint's context window, it lowers its effective budget for
+the rest of that run (reported with one line) rather than continuing to hit
+the same wall on every following batch.
+
 `embedding.concurrency` (positive integer, 1-16) overrides the number of
 embedding requests kept in flight at once, which otherwise defaults to 1 for
 a loopback endpoint and 2 for a remote one. Set it only for an endpoint that
@@ -103,6 +145,40 @@ instead of ever failing a whole batch over one oversized document.
   set `contextLength` specifically to control request batching (not your
   Ollama server's context window), set `embedding.maxTokens` instead.
 
+**Which token knob fixed the original 8k-context overflow.** A 0.9.15-beta
+field report described documents estimated under the request budget that
+still tokenized to 8.5k-12.4k real tokens against an 8192-token endpoint,
+because the 4-chars-per-token estimator undercounts dense technical text.
+`maxInputTokens`, `maxTokens`, and `contextLength` are easy to confuse, and
+only one of them makes that overflow structurally unreachable:
+
+- `embedding.maxInputTokens` (default `512`) is the per-DOCUMENT cap. It
+  truncates a document's embedded text to its head before the document is
+  ever counted toward a request, so no single document can contribute more
+  than 512 estimated tokens. This is the fix: it makes the original
+  single-document overflow structurally unreachable, independent of the
+  other two knobs.
+- `embedding.maxTokens` (default `6000`) is the per-REQUEST budget — how
+  many already-capped documents fit in one HTTP request — plus a same-run
+  adaptive shrink on the first context-size rejection. It reduces how often
+  a request lands near an endpoint's real limit, but a request-level budget
+  alone cannot stop one oversized document from overflowing a request.
+- `embedding.contextLength` sets Ollama's `num_ctx` only. It no longer feeds
+  the request token budget the way it used to (the two fields used to share
+  this one value), and it has no effect at all against a non-Ollama
+  endpoint.
+
+The field's exact 0.9.15-beta config — `contextLength: 8192` and
+`maxTokens: 8000` — produces no 400s on 0.9.15. `maxTokens` now defaults
+lower anyway (6000), but that is not why the overflow stopped: every
+document is truncated to `maxInputTokens` (512 tokens) before it is counted
+toward any request, so the 8.5k-12.4k-token documents that used to overflow
+an 8192-token endpoint can no longer reach the request budget in the first
+place. Set `embedding.maxInputTokens` higher only if you need documents
+longer than ~2000 characters embedded in full — for a corpus with such
+documents, size `embedding.maxTokens` to still fit the worst case, or the
+overflow risk returns.
+
 `akm index --full` and an index-generation bump no longer re-embed
 unchanged content: vectors about to be discarded are salvaged and handed
 back to unchanged entries at the start of the next embedding pass instead
@@ -131,3 +207,10 @@ effective config and another config file or bundle-relative file. `akm config
 unset` now refuses to unset a key whose value comes only from an
 `extends`-inherited base, naming the source, since there would be nothing local
 to remove.
+
+The scheduler runs the binary path `akm task sync` recorded at sync time, not
+whichever akm your shell now resolves to. After upgrading akm through a
+different installer than the one active at your last `task sync` (e.g.
+npm-global to a standalone download), run `akm task sync` again so the
+schedule points at the new binary; `akm health --probe` now warns via a new
+`scheduler-binary` advisory when the two diverge.

package/docs/reference/cli.md

@@ -117,7 +117,7 @@ Every command exits with one of the following codes:
 | 2 | Usage / bad input | `UsageError` |
 | 4 | Health warning (`akm health` only) | — |
 | 70 | Internal / unclassified error | unexpected throw |
-| 75 | Transient — retry shortly (sysexits `EX_TEMPFAIL`); another akm process holds a lock or is writing `state.db` right now, not a bad command line | `TransientError` |
+| 75 | Transient — retry shortly (sysexits `EX_TEMPFAIL`); another akm process holds a lock or is writing `state.db` or `index.db` right now, not a bad command line | `TransientError` |
 | 78 | Configuration error | `ConfigError` |
 
 Failures classified by akm emit a JSON error envelope on **stderr** before
@@ -279,7 +279,19 @@ opt-in, PID-liveness-only rebuild lock and releases it on exit — this is
 advisory, never the blocking lock #872 removed (see
 [Locks](https://github.com/itlackey/akm/blob/main/docs/architecture/internals/indexing.md#locks)). A human-typed
 `akm index` with no flag is never gated by it: if another run already holds
-the lock, it warns and proceeds anyway, contending with the existing run.
+the lock, it warns and proceeds anyway, contending with the existing run. If
+that contention makes index.db genuinely busy (SQLite `database is locked`)
+long enough to exhaust the driver's retry window, the run now fails with
+exit 75 (`TransientError`, code `INDEX_DB_CONTENDED`) instead of the raw
+driver error at exit 70 — the same retry-shortly contract as
+`STATE_DB_CONTENDED`, so a scheduler can branch on it instead of alerting.
+The rebuild lock itself is registered through a brief internal barrier
+(`getMaintenanceBarrierPath()`) shared with every other akm lock/lease; two
+`akm index` runs launched close enough together to collide on that
+registration step retry briefly and then, if it is still busy, also exit 75
+(code `MAINTENANCE_BARRIER_BUSY`) rather than the config-error exit 78 a
+2026-09-10 field report found — a busy registration barrier is ordinary
+contention between two legitimate runs, never a broken config file.
 `--skip-if-locked` changes that only for the invocation that passes it: if
 the lock is already held by a live process, it skips gracefully (exit 0,
 `{ ok: true, skipped: { reason: "lock-held", pid, launcherPid, startedAt } }`
@@ -358,15 +370,17 @@ akm health --report --window-compare 7d --format html
 | `--window-compare` | Compare the current window against the prior window of the same duration (e.g. `24h`, `7d`). With `--report`, overrides the default trend window. |
 | `--group-by` | Group rows by `run` (one row per `improve_runs` entry). Omit for the default summary. |
 | `--windows` | Explicit comparison window(s) as `name=...,since=ISO,until=ISO` (repeatable, up to 4). Mutually exclusive with `--window-compare`. |
-| `--no-probe` | Skip the `default-llm-engine` / `configured-engines` reachability probes and the `cli-version` update check (for an offline or air-gapped host). |
+| `--no-probe` | Skip the `default-llm-engine` / `configured-engines` reachability probes, the `cli-version` update check, and the `scheduler-binary` version check (for an offline or air-gapped host). |
 
 The command reads `state.db`, verifies that the required tables exist, performs a
 write-read probe against the events stream, inspects `task_history`, checks the
 default agent engine, and summarizes recent `improve_*` events. Unless
 `--no-probe` is given, it also sends a bounded (3s timeout) reachability probe
 to the `default-llm-engine` and every `configured-engines` LLM connection (and
-an SDK engine's LLM fallback), one probe per distinct endpoint, and checks the
-installed akm-cli version against the latest GitHub release (`cli-version`).
+an SDK engine's LLM fallback), one probe per distinct endpoint, checks the
+installed akm-cli version against the latest GitHub release (`cli-version`),
+and runs the scheduler's recorded akm binary with `--version` to check it
+against the running CLI (`scheduler-binary`).
 
 Primary result fields:
 
@@ -1239,6 +1253,14 @@ Shipping akm inside your own product (a Docker image, a plugin's own
 `node_modules`)? See [Bundling akm](../integration/bundling-akm.md) for the
 full boot contract, JSON shapes, and exit codes.
 
+`akm upgrade` replaces the binary in place for its own install method, but a
+scheduler binding recorded by an earlier `akm task sync` under a *different*
+install method is not repointed automatically — the scheduler runs the
+binary path recorded at sync time, not whichever akm `upgrade` just
+installed. Run `akm task sync` after switching installers so scheduled runs
+pick up the new binary; see [`task sync`](#task) and `akm health`'s
+`scheduler-binary` advisory.
+
 ### clone
 
 Copy an asset from any source into a managed writable bundle or an unmanaged
@@ -2321,6 +2343,7 @@ akm improve --require-engines          # for scheduled runs: abort (exit 78) ins
 akm improve --no-sync                  # skip the end-of-run git commit entirely (default: on for git-backed bundles)
 akm improve --sync --no-push           # commit only, skip the push after it
 akm improve --plan --strategy thorough # preview thorough's resolved engine/model routing; nothing is dispatched
+akm improve lessons/my-lesson --show-prompt --format text # print the composed reflect prompt for one asset, unwrapped; no lock/index/engine call
 akm improve report                     # LLM usage/routing report for the most recent real run
 akm improve report --run <id>          # ...for one specific improve_runs id
 akm improve report --since 7d          # ...aggregated over every real run started in the last 7 days
@@ -2340,7 +2363,8 @@ akm improve report --since 7d          # ...aggregated over every real run start
 | `--strategy <name>` | Override the active improve strategy (a built-in or entry under `improve.strategies`) |
 | `--json-to-stdout` | Also emit the full persisted JSON result on stdout for a live run. Without this flag, stdout stays empty. Dry-runs always emit their result and are never persisted. |
 | `--skip-if-locked` | If another improve run already holds the lock, skip gracefully (exit 0) instead of failing with "already running" (exit 78). Use for high-frequency scheduled runs so they don't pile up failures while a longer run is in progress. |
-| `--require-engines` | Abort (exit 78, before any indexing, lock, or log side effect) if the active strategy would enable a process whose engine or credential cannot be resolved in this process's environment. Without this flag, improve degrades gracefully: it skips the affected processes and reports them in the result's `skippedProcesses`. Recommended alongside `--skip-if-locked` for scheduled runs, since the operator's own shell can pass config validation while a scheduler's stripped-down environment (see #953) cannot. |
+| `--require-engines` | Abort (exit 78, before any indexing, lock, or log side effect) if the active strategy would enable a process whose engine or credential cannot be resolved in this process's environment, OR whose endpoint fails a bounded reachability probe — the same probe `akm health`'s `default-llm-engine`/`configured-engines` checks run, once per distinct endpoint. Without this flag, improve degrades gracefully: it skips the affected processes and reports them in the result's `skippedProcesses`. Recommended alongside `--skip-if-locked` for scheduled runs, since the operator's own shell can pass config validation while a scheduler's stripped-down environment (see #953) cannot. |
+| `--show-prompt` | Print the composed reflect prompt (#952) for one asset and exit — before any lock, index write, or engine dispatch. Requires a fully-qualified asset ref as the scope (`akm improve lessons/my-lesson --show-prompt`); rejected with a type or whole-bundle scope. The default output format is JSON, which carries the prompt as a `prompt` field (escaped into one line) alongside the resolved `engine`/`engineKind`; pass `--format text` to print the prompt itself, unwrapped and readable by eye. |
 | `--sync` / `--no-sync` | Commit (and optionally push) the git-backed primary bundle when the run finishes. Default: on for git-backed bundles (per profile config). |
 | `--push` / `--no-push` | Push after the end-of-run sync commit when writable with a remote configured. `--no-push` commits only, skipping the push. Default: per profile config (`true`). `sync.push` stays outside the autonomy gate — this is a per-run opt-out, not a default change. |
 
@@ -2396,6 +2420,18 @@ on an unavailable credential either — even a strategy left with every process
 disabled this way still returns its plan, with the affected processes in
 `skippedProcesses`.
 
+`--timeout-ms` is a run-wide wall-clock budget: when it expires, the run
+cooperatively aborts any in-flight engine request (the same `AbortSignal`
+every LLM call already honors) instead of waiting out the engine's own,
+much longer, per-call timeout — the run then finishes and reports normally
+rather than hanging past its budget. SIGTERM/SIGINT/SIGHUP end a live run
+the same way, within a short bounded grace period, and the process exits
+with a stable per-signal code (`143`/`130`/`129`) rather than needing a
+`kill -9`. If a live run has waited more than a few seconds without any
+engine response at all, one default-level line ("Still waiting for the
+first engine response...") is printed so a scheduled run's log is never
+silently empty while an engine is slow or dead.
+
 For dry runs, `plannedRefs` is the effective post-limit work set, not every
 ref in the requested scope. The `plan` object preserves both views: raw scope
 size and per-gate removals, configured and effective caps, final ranked refs
@@ -2437,6 +2473,17 @@ no model or per-process notices. Neither `--dry-run` nor `--plan` probes
 engine reachability over the network — pair with `akm health --probe` (or the
 default probe-on behavior) to check whether a named engine actually answers.
 
+`--show-prompt` (#952) is the cheapest way to exercise reflect alone: it
+builds the exact prompt reflect would send for one asset — the same source
+resolution, runner selection, feedback/schema-hint/related-lesson/rejected-
+proposal gathering `akm improve`'s live reflect step uses — and prints it
+without acquiring a dispatch lease, so it never calls an engine. Add
+`--format text` (the default JSON/yaml envelope escapes the prompt into one
+line, which defeats a by-eye read) to confirm by eye that recent feedback is
+framed as an unverified report to investigate (never a fact to insert
+verbatim) and that the response contract tells the model never to emit the
+truncation marker or any content from outside the shown asset.
+
 When reinforced facts need promotion, `knowledge` is the higher-authority
 destination than `memory`. The deterministic search ranking also prefers
 `knowledge` over `memory` hits, including inferred `.derived` memories, when
@@ -2872,6 +2919,13 @@ task template (both the core set and the improve-schedule set) and asks once
 before changing task files or scheduler state; non-interactive setup changes
 neither.
 
+Because the scheduler runs the exact binary path recorded at the last `task
+sync`, upgrading akm through a different installer than the one active at
+that sync (npm-global to a standalone download, or vice versa) leaves
+scheduled runs invoking the old, now-stale binary — `task sync` re-resolves
+the current path and repoints them. `akm health --probe`'s `scheduler-binary`
+advisory warns when the two diverge, naming both versions.
+
 Setup reconfiguration preserves existing scheduler runtime bindings. Changing
 the AKM storage path or installed runtime path therefore requires an explicit
 `akm task sync --rebind`; setup does not silently migrate those entries.

package/docs/reference/configuration.md

@@ -396,8 +396,8 @@ unless a remote `embedding` config is provided.
 `akm improve`'s memory-inference/consolidate passes when they call an
 embedding model: `provider`, `endpoint`, `model`, `apiKey` (symbolic
 reference, same rules as engine `apiKey`), `dimension`, `localModel`,
-`maxInputTokens`, `maxTokens`, `batchSize`, `chunkSize`, `contextLength`,
-`timeoutMs`, `concurrency`, and `ollamaOptions.num_ctx`.
+`maxInputTokens`, `maxTokens`, `batchSize`, `contextLength`, `timeoutMs`,
+`concurrency`, and `ollamaOptions.num_ctx`.
 
 The knobs that bound request/document size and rate, all optional (defaults
 apply when unset), for a remote endpoint (`src/llm/embedders/remote.ts`):
@@ -405,12 +405,46 @@ apply when unset), for a remote endpoint (`src/llm/embedders/remote.ts`):
 | Key | Default | Bounds |
 | --- | --- | --- |
 | `embedding.maxInputTokens` | `512` | Per-DOCUMENT cap, applied before batching (#956). A document's embedded text is truncated to its head (unicode-safe) at this many estimated tokens instead of ever being skipped for size alone — a document is skipped only when its truncated head is empty. |
-| `embedding.maxTokens` | `8000` (`DEFAULT_TOKEN_BUDGET`) | Per-REQUEST token budget: how many (already-capped) documents' estimated tokens fit in one HTTP request. With the 512-token default document cap, a request carries about 16 documents by default. |
+| `embedding.maxTokens` | `6000` (`DEFAULT_TOKEN_BUDGET`) | Per-REQUEST token budget: how many (already-capped) documents' estimated tokens fit in one HTTP request. With the 512-token default document cap, a request carries about 11 documents by default. Lowered from 8000 to 6000 (#954): the 4-chars-per-token estimator undercounts dense technical text by 7-55%, so 8000 regularly overshot an 8192-token endpoint's real context window. |
 | `embedding.batchSize` | `100` | Per-REQUEST document-COUNT safety cap, independent of the token budget — guards against many tiny documents packing an oversized request. |
 | `embedding.contextLength` | unset | Ollama's `num_ctx` ONLY, forwarded verbatim as `options.num_ctx` on the native `/api/embed` request. Does **not** feed the request token budget above (#956) — the two used to share this one field, so setting it for the server's context window silently changed request batching too. |
 | `embedding.timeoutMs` | `120000` (120s) | Per-request wall timeout — see below. |
 | `embedding.concurrency` | `1` loopback / `2` remote | In-flight request window — see below. |
 
+**Which knob fixed the field's 8k-context overflow, worked examples.** A
+0.9.15-beta field report described documents estimated under the request
+budget that still tokenized to 8.5k-12.4k real tokens against an
+8192-token endpoint, because the 4-chars-per-token estimator undercounts
+dense technical text. Three knobs changed shape between beta and this
+release; only one of them makes that overflow structurally unreachable:
+
+- `embedding.maxInputTokens: 512` — per-DOCUMENT cap, applied before
+  batching. Example: a 6,000-character API reference page is truncated to
+  its first ~2,000 characters (512 estimated tokens) before it is ever
+  counted toward a request. This is the fix for the original overflow: no
+  single document can contribute more than 512 estimated tokens to a
+  request, no matter how `maxTokens` or `contextLength` are set.
+- `embedding.maxTokens: 6000` — per-REQUEST budget: how many already-capped
+  documents' estimated tokens fit in one HTTP request. Example: with the
+  default 512-token document cap, a request packs about 11 documents before
+  this budget is reached and the request is sent; if the run's first
+  request is still rejected for exceeding the endpoint's real context
+  window, akm shrinks this budget to three quarters of its value (floored
+  at twice `maxInputTokens`) for every later request in the same run. A
+  request-level budget alone cannot stop one oversized document from
+  overflowing a request — only the per-document cap above does that.
+- `embedding.contextLength: 8192` — Ollama's `num_ctx` only, forwarded
+  verbatim on a native `/api/embed` request. It has no effect on request or
+  document sizing, and no effect at all against a non-Ollama endpoint — see
+  below for why that used not to be true.
+
+A field config of `contextLength: 8192` + `maxTokens: 8000` (the exact
+0.9.15-beta values from the original report) produces no 400s on 0.9.15:
+`maxInputTokens` (512, new this release) caps every document before it is
+counted, so the original 8.5k-12.4k-token documents that overflowed the
+8192-token endpoint can never reach the request budget in the first place —
+independent of whatever `maxTokens` or `contextLength` are set to.
+
 `embedding.timeoutMs` (positive integer, default `120000` — 120s) is the
 budget for a request at the FULL token budget (`embedding.maxTokens`); a
 local model server on a large, token-budget-bounded batch legitimately takes
@@ -421,6 +455,18 @@ dead endpoint is still detected in seconds on the common case of small
 documents. Set `embedding.timeoutMs` lower to fail fast against a
 known-fast endpoint, or higher for a slow local server on large batches.
 
+`embedding.maxTokens` (or its default) is also a run-scoped adaptive
+starting point, not a hard ceiling (#954): on the FIRST rejection of an
+`akm index` run for exceeding the endpoint's context window, akm shrinks
+the request budget to three quarters of its current value — floored at
+twice `embedding.maxInputTokens` — for every request not yet sent, and
+prints one line naming the new value. This never changes the rejected
+request's own split-and-retry (below), never shrinks a second time in the
+same run, and never grows the budget back up. Users who set
+`embedding.maxTokens` explicitly are unaffected by the LOWERED DEFAULT
+above but still benefit from this same-run recovery if their own value
+turns out to be too high for the endpoint.
+
 A request TIMEOUT (not a rejection for exceeding the context window) never
 drops its batch immediately: field confirmation showed that once akm
 abandons a timed-out request, the endpoint (e.g. llama-server) keeps
@@ -447,10 +493,10 @@ serves parallel requests — a local server started with a multi-slot flag
 single-slot model server, which the default already protects from
 reload-thrash. Request SIZE remains the first throughput lever regardless:
 `embedding.batchSize` (a document-count cap, default 100) together with
-`embedding.maxTokens` (an estimated token budget per request, default 8000
+`embedding.maxTokens` (an estimated token budget per request, default 6000
 — NOT `embedding.contextLength`, see the table above) control how many
 documents land in one request — with the default 512-token
-`embedding.maxInputTokens` document cap, that is about 16-32 documents,
+`embedding.maxInputTokens` document cap, that is about 11 documents,
 taking about the same wall time as a single one against a healthy endpoint.
 
 ## Search tuning
@@ -737,3 +783,7 @@ network filesystem for the data directory and falls back to `DELETE`.
 configuration using `engines`, `defaults.engine`, `defaults.llmEngine`, and
 `improve.strategies`; AKM deliberately does not infer or rename ambiguous
 profile identities.
+
+`embedding.chunkSize` was never read by anything under `src/` (#954), so a
+config that still sets it is simply ignored — it still loads, unvalidated
+and without warning.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "akm-cli",
-  "version": "0.9.15-beta.2",
+  "version": "0.9.15-beta.4",
   "type": "module",
   "description": "akm (Agent Knowledge Manager) — a portable, local-first capability library for AI agents. Discover, load, share, and improve reusable skills, scripts, workflows, and knowledge across any shell-capable coding agent, including Claude Code, OpenCode, and Cursor.",
   "keywords": [

package/schemas/akm-config.json

@@ -223,10 +223,6 @@
           "type": "integer",
           "exclusiveMinimum": 0
         },
-        "chunkSize": {
-          "type": "integer",
-          "exclusiveMinimum": 0
-        },
         "contextLength": {
           "type": "integer",
           "exclusiveMinimum": 0
@@ -1927,10 +1923,6 @@
               "type": "integer",
               "exclusiveMinimum": 0
             },
-            "chunkSize": {
-              "type": "integer",
-              "exclusiveMinimum": 0
-            },
             "contextLength": {
               "type": "integer",
               "exclusiveMinimum": 0
@@ -3509,10 +3501,6 @@
           "type": "integer",
           "exclusiveMinimum": 0
         },
-        "chunkSize": {
-          "type": "integer",
-          "exclusiveMinimum": 0
-        },
         "contextLength": {
           "type": "integer",
           "exclusiveMinimum": 0