NEWVectors or files. Pick a path.Start →

    Changelog

    Release Notes

    New capabilities and performance improvements across the Mixpeek platform. Every entry links to relevant documentation and examples.

    October 2026

    DocsFeature

    Self-hosted MVS: shard storage settings documented, and filesystem storage in private beta

    The bring-your-own object storage page listed the variables the API, coordinator and Ray workers read, and left out the ones the MVS shard reads. A self-hosted deployment that followed it started a shard with no store. The page now has a Shard settings section: mvs.objectStore for the Helm chart, or MVS_STORE_BACKEND (s3 or gcs) with the MVS_S3_* or MVS_GCS_BUCKET variables, pointed at the same bucket as the rest of the deployment. MVS can also keep its data on a POSIX filesystem such as local NVMe, NFS or Lustre. That backend is in private beta, and you turn it on for a deployment by contacting us.

    APIFeature

    Batch retriever execution takes up to 16 queries per request

    POST /v1/retrievers/{retriever_id}/execute/batch runs one retriever over a list of queries in a single round trip. The list now holds at most 16 queries. A request with 17 or more is refused with 422, and error.details.limits.max_queries says 16, so a client can split the set without parsing the message. The limit had been 50, and no customer request in the previous 30 days sent more than 16.

    EngineFeature

    Failed batches name each cause, and their failed objects read FAILED

    When every job in a batch failed, the batch error read "All N jobs failed. First error: ...", which looked like one cause even when there were several. It now adds a count of the distinct error types, for example "(4 distinct causes: ...)". A batch whose rows all failed also left each object reading COMPLETED with no error. Those objects now read FAILED with the error type and message, the same as objects that fail in a partly successful batch.

    APIFeature

    A queued batch says how many batches are running and when it retries

    A batch waiting for capacity showed "N of N concurrent batches are running" with N taken from the limit, even when fewer were running. The queue reason now counts the batches actually holding a slot. When the engine turns a batch away for capacity, the reason keeps the engine's own explanation and adds when the batch will be retried, or that it starts when another batch finishes.

    APIPerformance

    Batches waiting in the queue start as soon as an earlier multi-tier batch ends

    A batch with more than one extraction tier holds a slot from its first tier to its last. When the last tier had nothing to extract, such as a clip with no speech, or a later tier failed early, the finished batch kept its slot and the batches queued behind it waited until something else freed one. In one run that wait was more than 25 minutes. Both paths now give the slot back and start the next queued batch.

    Batching
    Vector StorePerformance

    Filtered reads and bucket object listings are faster on shared MVS

    A filter that matches a field at several paths at once, which the managed attribute filter does, made each count and scroll collect every point on the shard before narrowing. On the shared store that meant 14.1 million ids per call and scroll times around 5.4 seconds. Those groups now resolve from the index entries alone. Separately, listing a bucket's objects newest first now reads the order straight from the date index: on a 222,765-object bucket a 500-object page at offset 3,000 went from 0.31 to 0.19 seconds, and the first page from 0.08 to 0.045 seconds.

    StudioFeature

    New Studio accounts run a live search before choosing a plan

    The first signup step now opens with a search that runs as the page loads and shows four live results from a public demo, with a switch between a film-scene collection and an art collection, suggested queries and a free-text box. After paying, a new account lands on the dashboard rather than on billing settings.

    StudioPricing
    APIFeature

    Default system alerts notify once per cooldown, and the stalled-ingest alert names its bucket

    A default alert whose condition stayed true sent a new email and in-app notification on every check. It now notifies once, then waits for the alert's cooldown or re-notify interval, or 24 hours when neither is set, before notifying again. Every check is still recorded in the alert's history. The "no new objects" alert now carries the bucket it measured, so the notification says which bucket stopped receiving objects.

    Alerts
    PlatformFeature

    Account setup that fails partway is retried automatically

    Each new account gets a default namespace, collection and retriever. If a step failed during an outage, the account stayed half set up until someone fixed it by hand. A scheduled job now retries setup every 15 minutes for accounts more than an hour old, up to five times, and records the last error on the account.

    EnginePerformance

    Image extraction on CPU batch workers runs about 50 times faster

    A large image batch on CPU workers had been embedding about 185 images an hour. The model ran in bfloat16 on processors with no hardware support for it, so each image took about 20 seconds, and only one of the batch's worker CPUs was ever put to work. CPU batches now embed in fp32 and start one model copy per worker CPU from the beginning. In our test at the same worker shape, 3,414 images took 20 minutes, about 10,250 an hour, where the previous code managed about 180 an hour. GPU batches are unchanged.

    EngineFeature

    Failed audio fingerprint and Vertex embedding objects say why they failed

    When the audio fingerprint extractor could not read a file, the batch failed with a message saying it returned 0 rows, followed by a list of possible causes. Each object now carries a named error: an unsupported format, a video with no audio track, or a decode failure with FFmpeg's last lines of output. A video with no audio track is not retried. When a Vertex multimodal embedding fails, the object's error now carries the provider's message, where it had read "None/empty". A finished batch also takes its extracted and failed counts from its per-object record, so a row that failed extraction is counted as failed.

    APIFeature

    A retriever that times out with nothing to return answers 503, and you can retry it

    When a required stage hit its time limit before any results existed, the retriever answered 200 with an empty result marked degraded, which reads the same as a search that matched nothing. In our test of 30 executions over a million documents, 5 came back that way. It now answers a retryable 503 whose error names the stage and its time limit. A stage that times out after earlier stages returned results still answers 200 with those results, flagged degraded, and optional stages set to on_error skip behave as before. The attribute_filter stage also fails when the vector store does not answer its scroll; it had returned the documents fetched before the error, usually none.

    APIFeature

    Retriever stages read from the API can be posted back without unknown-key warnings

    A retriever stage read from a GET, a clone or a pinned revision in a resource.executed event carries a parameters field, which the API fills in as a copy of config.parameters. Posting that stage back flagged parameters as an undeclared key, and retriever execution flagged settings, including settings.limit, which the API translates itself. Both now count as declared, so they get no warning today and no 422 after November 2. A misspelled key next to them is still reported.

    Vector StorePerformance

    Searches on compressed indexes find more of the true nearest neighbors

    Once a namespace is large enough for product-quantization compression, each partition ranked its candidates by approximate scores and cut the list before exact scoring, so true neighbors could drop out. A compressed partition that keeps its full-precision vectors, which is the default, now rescores a wider window of candidates from those vectors. In our test on 420,000 vectors of 768 dimensions, recall@10 rose from 0.840 to 0.927 at the default probe count and from 0.904 to 1.000 with every partition searched. 95th-percentile search time moved from between 2.9 and 3.8 ms to between 3.0 and 4.6 ms.

    Vector StorePerformance

    Vector store searches stop waiting on re-inserts and background index work

    Re-inserting a point that already exists took the shard's write lock, so searches queued behind it. Re-inserts now stage without the lock: under a test load of 120,000 single-point re-inserts, the 95th-percentile time a search spent waiting on the lock fell from 213 ms to 1 ms. Index splits and compression training run on their own lower-priority threads, so a search's probes go first. The vector store also sends each response at once. A single search had taken about 50 ms at the client against 7.5 ms at the shard, while the last packet of each response waited for the client's delayed acknowledgment.

    StudioFeature

    Billing & Usage in Studio shows where your credits went

    The Billing & Usage page in Studio has a cost breakdown card. It splits the month's usage by kind (extraction, retrievers, vector store reads and writes, uploads, inference and storage) and by extractor, retriever and namespace, and shows storage GB-months by class. When the daily rollup has not yet reached the latest days, the card says how much of the month's total it covers. The card reads the same breakdown the API returns from GET /v1/organizations/billing/usage/breakdown.

    APIFeature

    From November 2, request bodies with undeclared keys return a 422 that names the accepted keys

    Until November 2, 2026, a JSON request body carrying a key the endpoint does not declare is accepted, and the response names the stray keys in the X-Mixpeek-Unknown-Keys header and in a warnings entry. From November 2 the same request returns 422 with the accepted keys listed, so a misspelled key such as limt gets an error that lists the right ones. The official SDKs already send only declared keys. Aliases the API accepts count as declared, including page_size on document lists and collections on batch create.

    APIPerformance

    attribute_filter pushes more filters down to the vector store

    The attribute_filter retriever stage now sends starts_with, ends_with and text matches to the store as prefix, suffix and text matches, along with a top-level OR of simple conditions, and case_insensitive filters no longer fall back to scanning in the API. A filter on a bare field name now goes only to the payload index you declared for it. In our 60,000-document test, a keyword equality filter had taken 1,117 ms at p95 as a stage against 96 ms through documents/list; the extra time came from also querying two unindexed copies of the field. Document lists also accept an optional partition so parallel workers can each read their own slice with their own cursor.

    APIPerformance

    Less CPU spent on each API request

    Error tracing had used about 12% of the API's busy CPU, mostly by opening a span for each middleware and reading every request body ahead of time; it now does neither. Route matching skips routers that cannot match the path and caches its route lookup, which cut resolving a bucket or object path from about 598 to 210 microseconds in our test. Log redaction skips lines that cannot hold a credential, about twice as fast per line, and the rate limiter reads its counter in one round trip.

    API reference

    Run the latest on your own files

    Everything above is live. Point Mixpeek at the storage you already have and search your video, images, audio, and documents through one API. Build starts at $25/mo for up to 1M vectors.