Expanded API and Model Support

AGENTS.md

@@ -12,6 +12,8 @@ Keep this `AGENTS.md` up to date whenever development workflows, architecture, s
 
 Cusco implements exact checkpoint continuation, shared logical branches, tier accounting, transactional mappings, mapped execution, bounded live generation, multi-model residency, resumable execution sessions, and priority-aware deficit round-robin scheduling with monotonic promotion. The public API provides OpenAI-compatible inference under `/openai/v1/*` and a Cusco control plane under `/cusco/v1/*`, including bounded Ollama-compatible model management under `/cusco/v1/api/*`. It also includes strict compatibility controls, native wire streaming, bounded text-plus-image admission, immutable Hub resolution, metadata-driven execution profiles, a SQLite model catalog, versioned daemon configuration, production Compose packaging, request-tied deterministic `window_tail` context compaction with atomic successor publication and OpenAI replay metadata, durable stored Responses continuation, and a negotiated transactional `cusco.context_update.v1` fold operation. Model identity, configuration, aliases, lifecycle operation records, and stored OpenAI Responses resources survive restart in the v1 profile; logical Cusco contexts and native execution state are disposable.
 
+The native executor derives each loaded model's required ordinary-KV, sliding-window, and recurrent state components at runtime. Cusco does not maintain a family allowlist for execution-state geometry; Gemma 4 and Qwen 3.5 MoE retain exact checkpoint-continuation and mapped-execution proof coverage, while metadata-derived Qwen 3.5/3.6 MoE chat-template rendering supports OpenAI text generation. The canonical acceptance fixture remains Gemma.
+
 The repository currently contains:
 
 - `crates/context-store`: Rust logical contexts, structurally shared token sequences, and evaluated-prefix mappings;
@@ -31,11 +33,11 @@ The server dynamically admits and reuses multiple model epochs within configured
 ## Build and dependency conventions
 
 - Docker Compose is the primary development, test, proof, and production interface. `compose.test.yaml` owns development and verification services; every test or proof command must select it explicitly with `docker compose -f compose.test.yaml`. `compose.yaml` is reserved for the production-oriented `server` service, which runs the release binary with persistent bind mounts under the ignored `data/` tree. Keep CPU-only and GPU execution supported by the same image; CPU-only checks should omit GPU passthrough rather than use a separate build.
-- Test Compose services mount project-scoped `cargo-registry`, `cargo-git`, and `cargo-target` named volumes so repeated runs reuse downloaded crates and compiled artifacts. Preserve these mounts on new Rust-running test services; do not remove the volumes during routine cleanup. Production state must use the `data/models`, `data/state`, and `data/spill` bind mounts rather than named or anonymous volumes.
+- Test Compose services mount project-scoped `cargo-registry`, `cargo-git`, and `cargo-target` named volumes so repeated runs reuse downloaded crates and compiled artifacts. Preserve these mounts on new Rust-running test services; do not remove the volumes during routine cleanup. Test and production services share the ignored `data/models` artifact cache by default so real-model verification does not duplicate downloads; `CUSCO_MODEL_DIR` may override that host path. Production state must use the `data/models`, `data/db`, and `data/spill` bind mounts rather than named or anonymous volumes.
 - Local builds must support CUDA architectures `sm_61` and `sm_70`. Use `CUSCO_CUDA_ARCHITECTURES="61;70"` for normal local builds.
 - Reserve the broad, full CUDA architecture build for production releases. Do not spend local development time compiling every supported CUDA target unless release validation specifically requires it.
 - `llama.cpp-version.txt` is the sole source of truth for the llama.cpp version. It contains a release tag only. Build and fetch tooling must read it; never duplicate the tag or record the corresponding commit hash.
-- Keep llama.cpp changes behind the versioned C ABI in `native/include/cusco_executor.h` (currently ABI version 14). Rust should not depend directly on unstable llama.cpp internals.
+- Keep llama.cpp changes behind the versioned C ABI in `native/include/cusco_executor.h` (currently ABI version 17). Rust should not depend directly on unstable llama.cpp internals.
 - Model files and generated proof results are local artifacts and must not be committed.
 - Files matched by `.gitignore` are intentionally local artifacts. Never force-add, stage, or commit them; if an ignored artifact contains durable project guidance, move that guidance into an appropriate tracked document instead.
 - `config.example.yaml` is the exhaustive, documented operator configuration template. Keep it synchronized with every supported configuration field and update its comments and sensible deployment defaults whenever the schema or behavior changes; `config.yaml` is the ignored operator-local copy mounted by production Compose. Verification services and harnesses must use the tracked `config/test.yaml`, whose test-specific limits and feature choices must not leak into the operator example.
@@ -57,7 +59,7 @@ Select the proof GPU with `CUSCO_GPU_DEVICE_ID`; do not assume a particular host
  - The focused API smoke, executor, mapped-execution, representation-measurement, and scheduler proofs remain diagnostics when changing those subsystems; they do not replace the canonical acceptance gates.
 - Python tests of `/openai/v1/*` behavior must use the pinned official `openai` Python client for models, completions, chat completions, Responses, and streaming. Direct HTTP remains appropriate for Cusco control-plane routes and the generated OpenAPI document.
 - Changes to `/openai/v1/*` behavior must run the pinned `oai-lens` SDK-conformance gate. Bootstrap it explicitly with `tools/fetch-oai-lens.sh`, then run `docker compose -f compose.test.yaml run --rm oai-lens` against the separately running candidate. Probe failures are advisory until their contracts graduate into blocking acceptance coverage; bootstrap, build, execution, report parsing, and artifact-preservation failures are blocking. Review `results/oai-lens-gate.json` against `config/oai-lens-expectations.json`. Never use a neighboring checkout or modify the ignored `.tools/oai-lens/` source.
-- Real-model tests and proofs use the single canonical artifact `hf://unsloth/gemma-4-E2B-it-GGUF/gemma-4-E2B-it-Q3_K_M.gguf`. Pass that URI directly to proof and smoke interfaces; the model registry resolves its immutable revision, validates or populates the persistent cache under `${CUSCO_MODEL_DIR:-./models}/cache`, and supplies the resolved local path only at the executor boundary. Tests must not inspect the cache layout, copy, hard-link, symlink, or independently redownload the artifact. This Gemma model supports vision and tool use, so their real-model acceptance coverage should use the same artifact. Executor-boundary changes require the real model proof, not only deterministic model-free tests, and must write machine-readable evidence under `results/`.
+- Real-model tests and proofs use the single canonical artifact `hf://unsloth/gemma-4-E2B-it-GGUF/gemma-4-E2B-it-Q3_K_M.gguf`. Pass that URI directly to proof and smoke interfaces; the model registry resolves its immutable revision, validates or populates the persistent cache under `${CUSCO_MODEL_DIR:-./data/models}`, and supplies the resolved local path only at the executor boundary. Tests must not inspect the cache layout, copy, hard-link, symlink, or independently redownload the artifact. This Gemma model supports vision and tool use, so their real-model acceptance coverage should use the same artifact. Executor-boundary changes require the real model proof, not only deterministic model-free tests, and must write machine-readable evidence under `results/`.
 - Mapped-executor changes require `docker compose -f compose.test.yaml run --rm mapped-proof`; it writes staged-versus-mapped evidence to `results/mapped-proof.json`. Representation changes additionally require `docker compose -f compose.test.yaml run --rm representation-proof`; it replays `config/representation-workload.json` and writes exact-continuation, publication-scaling, copy, state-movement, and graph-telemetry evidence to `results/representation-proof.json`.
 - Verify failure behavior transactionally: cancellation, preparation failure, transfer failure, validation failure, and commit failure must leave the prior binding usable.
 - For behavioral work, exercise the changed path end to end. A successful compile alone is not sufficient.

Cargo.toml

@@ -20,7 +20,8 @@ thiserror = "2.0.17"
 futures-util = "0.3.31"
 http-body-util = "0.1.4"
 parking_lot = "0.12.5"
-ureq = "3.1.4"
+ureq = { version = "=3.0.12", default-features = false, features = ["rustls", "gzip"] }
+url = "2.5.7"
 
 tokio = { version = "1.49.0", features = ["macros", "net", "rt-multi-thread", "signal", "sync"] }
 tower = "0.5.2"

README.md

@@ -14,20 +14,33 @@ details and optimized kernels.
 - Persistent logical contexts with branching and evaluated-prefix reuse.
 - Device, host, and storage residency accounting with mapped llama sequence
   activation and local spill support.
+- Runtime-derived execution profiles whose required ordinary-KV, sliding-window,
+  and recurrent state components come from the loaded native executor rather
+  than a model-family allowlist.
 - Dynamic model registration, immutable revisions, aliases, loading, reloading,
   retirement, and removal.
 - Priority-aware request scheduling with bounded admission, cancellation,
   deadlines, output backpressure, and diagnostic records.
 - OpenAI-compatible completions, chat completions, and durable Responses APIs,
   including stored-resource retrieval, deletion, and `previous_response_id`
   continuation.
+  Chat Completions supports the current `max_completion_tokens` total-generation
+  limit and the deprecated `max_tokens` field for legacy clients; if both are
+  supplied, their values must match.
+  Chat Completions and Responses accept OpenAI service-tier requests but
+  currently normalize every supported tier to the neutral `default` tier
+  without changing scheduler priority. Responses report the actual tier as
+  `default`; tier-aware HTTP admission may map this field to queue policy later.
 - An Ollama-compatible model-management profile for discovery, inspection,
   pulling, aliases, deletion, and residency reporting.
 - Cusco-native context, compaction, lifecycle, status, OpenAPI, capability
   discovery, and transactional context-update endpoints.
 - Buffered and streaming generation, deterministic sampling controls, stop
   handling, request-shape validation, typed function-call/result continuation,
   and `tool_choice` controls for `auto`, `none`, `required`, and named functions.
+  Responses can also execute an operator-enabled, policy-bounded `web_search`
+  tool through a configured SearXNG-compatible provider; it is disabled by
+  default and returns standard search-call items and URL citations.
 - Deterministic `window_tail` context compaction with transactional successor
   publication and replay metadata.
 - Versioned YAML configuration, bearer authentication, transport diagnostics,
@@ -233,6 +246,9 @@ second inference API.
   workload scheduler serializes native quanta across the process.
 - Image inputs are validated and bounded, but inference rejects them because
   the executor does not yet expose a compatible vision-projector path.
+- Hosted web search currently supports a SearXNG-compatible JSON backend only.
+  Shell/container execution, page retrieval, file search, code interpretation,
+  vector stores, and other server-executed tools are not available.
 - Embeddings are not available until the executor exposes embedding output.
 - Physical tier accounting does not yet correspond to independently movable
   native KV and recurrent-state blocks.