Nyckel

Executive Summary

Nyckel is a managed prediction service for applications that repeatedly need a classification. A function accepts text, an image, or structured data and returns a label with confidence. The service combines hosting, model selection, annotation, and retraining, so developers work with an endpoint and a labeled dataset rather than operating a training stack.^[1]

Its distinguishing workflow is the feedback loop: send an input, decide what to do with the prediction, learn the correct answer, and feed that answer back. It fits the AI decision APIs comparison because software consumes its predictions directly. This profile focuses on Nyckel's classification path and does not treat all of its detection and search functions as equivalent decision models.

---

What the product exposes

A marketplace-listing function, for example, might combine a title, price, condition, and photograph. The structured-data guide allows adding fields after creation; field IDs remain useful when names change. For ranking, each candidate requires an invocation, so scoring a large candidate set multiplies API use. A nearest-neighbor search function is a different fit when the question is similarity rather than an observable outcome.^[6]

---

Architecture and customization

A new function can answer from a zero-shot baseline before receiving labeled examples. Nyckel then evaluates candidate models and trains a function-specific model as annotations accumulate. During retraining, the active model continues serving traffic until a replacement is validated and promoted. Model family selection and hyperparameters are managed by Nyckel.^[5]

This is operationally convenient, but a stable endpoint does not imply frozen predictions. The model behind it can change as the dataset changes. The platform overview says previous versions are retained in the console and the endpoint routes to the current selected model.^[1] This review did not establish a public API contract for pinning a production model version or exporting weights for independent serving.

Input and output modalities are fixed when a function is created. A text classifier cannot later become an image classifier under the same function identity.^[4] That makes the schema and label taxonomy part of the application design: settle what each label means, how overlapping cases are resolved, and who can change the definitions.

For quality estimates, Nyckel documents cross-validation: each annotated sample is predicted by a model that did not train on it, then a final serving model is trained on all annotated data. The training guide also currently lists 512 tokens of text context for its Text and Tabular models. Long-document users should verify the selected path's input handling and test whether important information survives preprocessing.^[7]

---

Worked example: route a support ticket and learn from a correction

This is an illustrative API workflow, not a live test. Assume a Text → Classification function with labels Billing, Bug, and Other. The quickstart creates functions and labels through REST, using a client-credentials token obtained from /connect/token; those tokens last one hour.^[4]

1. Invoke with an application identifier

Store the function ID and token securely in the server environment. Use an identifier that can reconnect the prediction to the eventual resolution:

curl --request POST \
  "https://www.nyckel.com/v1/functions/$NYCKEL_FN/invoke?externalId=ticket-42&capture=false" \
  --header "Authorization: Bearer $NYCKEL_TOKEN" \
  --header 'Content-Type: application/json' \
  --data '{"data":"I cannot open my invoices after the latest update."}'

The invoke reference documents externalId, optional label distributions through labelCount, and capture control.^[8] A hypothetical response might be:

{
  "labelName": "Bug",
  "labelId": "example-bug-label",
  "confidence": 0.82,
  "externalId": "ticket-42"
}

The example disables automatic capture deliberately. It still sends the input for inference; later feedback can explicitly create a training sample. Capture is not an audit log or a promise that every response already has a stored sample.^[9]

2. Separate prediction from action

A high-confidence result can enter an automatic routing path, an intermediate result a review queue, and a low-confidence result a manual intake path. Nyckel documents this three-zone pattern, but the thresholds depend on the cost of mistakes and available reviewers.^[10]

For this hypothetical ticket, the application might hold 0.82 for review rather than moving it immediately. Neither 0.82 nor a chosen 0.95 cutoff establishes business acceptability without validation. Low confidence means the classifier is uncertain; it does not mean the customer request should be discarded.

3. Feed back the resolved label

Suppose a reviewer determines that the request belongs with Billing. Submit the original input and its known label using the same external ID:

curl --request POST \
  "https://www.nyckel.com/v1/functions/$NYCKEL_FN/samples" \
  --header "Authorization: Bearer $NYCKEL_TOKEN" \
  --header 'Content-Type: application/json' \
  --data '{
    "data":"I cannot open my invoices after the latest update.",
    "externalId":"ticket-42",
    "annotation":{"labelName":"Billing"}
  }'

The current quickstart describes a 409 Conflict when the content or external ID already identifies a sample; update the existing annotation in that case. The canonical v1 specification defines that operation as PUT /functions/{functionId}/samples/{sampleId}/annotation.^[4][11]

There is documentation drift worth catching before copying an integration: the separate feedback guide assumes an invoke returns sampleId and shows a POST annotation update. The current quickstart and OpenAPI contract instead support the explicit sample-creation workflow above; the FunctionOutput schema contains externalId, not sampleId.^[12][11]

---

Confidence, calibration, and abstention

Nyckel describes its 0–1 confidence as a calibrated probability: predictions around 0.90 should be correct approximately 90% of the time over many comparable cases.^[13] This is a vendor description, not an independent calibration result established by this review.

Calibration measures the relationship between predicted confidence and observed correctness. Research by Guo and colleagues demonstrates why neural-network confidence needs separate evaluation rather than being assumed reliable from classification performance alone.^[14] A valid response schema also says nothing about whether a label is correct.

A useful evaluation for the ticket example would retain an untouched set of resolved tickets, compare results by label and confidence band, and measure the error rate among automatically routed cases. Track both false routing and the fraction deferred to people. Include unusual inputs and repeat the evaluation after model or traffic changes. This is evaluation guidance, not a claim that Nyckel supplies a universal threshold or a guaranteed error bound.

Abstention belongs in the application policy: hold an uncertain result, request additional context, or use a fallback. The threshold guide recommends revisiting cutoffs as the model and input distribution change.^[10] A named Other label can help define the task, but it does not prove recognition of every out-of-distribution input.

---

Production and data handling

Capture and review: invoke capture is enabled by default but selective. It samples uncertain predictions, underrepresented classes, and some random traffic, with caps and deduplication. capture=false excludes a request from this review mechanism. Keep a separate log when every decision must be auditable; an unannotated capture and a labeled training sample are different states.^[9]

Serving and load: the integration guide describes synchronous invocation or an application-owned queue and worker. Its sub-200-millisecond text-latency description is a vendor expectation, not a measured tail-latency guarantee. Store prediction identifiers, labels, confidence, and timestamps; handle 429 and server errors with bounded retries.^[15] The API reference lists 25 requests per second and 25 concurrent requests, with higher limits negotiable under Enterprise.^[16]

Where data goes: the model guide distinguishes generalist-model zero-shot inference from an active private model served on Nyckel infrastructure. It says inputs to that trained serving path are not forwarded to a third-party model provider.^[5] The service terms separately allow third-party AI APIs during evaluation of training methods, while restricting customer training data to that customer's use.^[2] These statements cover different stages; “private inference” should not be expanded into a claim that no third party can ever process the data.

Deployment: the public offering is a hosted service. Enterprise pricing lists dedicated infrastructure and regional deployments, but this review did not verify a downloadable server, portable model weights, a self-hosting contract, or specific residency regions.^[17] Likewise, capture opt-out alone does not establish zero retention across service logs, processors, or backups. Obtain the relevant retention and deployment terms for the intended workload.

---

Pricing and commercial terms

Published USD monthly terms, checked September 16, 2026:^[17]

Starter adds custom training and private inference. Business adds workflow features such as human review queues, prediction auditing/export, and larger retention. The API guides describe capabilities broadly; confirm the required plan rather than assuming every documented workflow is included in Free.^[17]

An invoke is a prediction call; retained samples are a separate billing dimension. Human labeling, application logging, queue infrastructure, and error remediation also belong in the cost estimate. Compare cost per acceptable automated decision, including review, rather than per API response alone.

Nyckel's terms define a commercial cloud-service subscription rather than a license to a self-operated model stack.^[2] The plan table is a dated public-price snapshot, not a negotiated enterprise quote.

---

Published experience and evidence limits

In a February 2023 vendor-published customer account, Gardyn AI lead Sunil Rawal described using Nyckel to classify plant images. The decision-relevant detail is the operating design: high-confidence flags could reach customers, while botanists reviewed lower-confidence cases and fed corrections back. Gardyn's account supports that workflow's practical use, but it is a selected customer story rather than an independent comparison of today's models.^[18]

The September 16 research searched public developer discussion and reviews as well as primary documentation. It did not establish a current, independently reproducible benchmark for Nyckel's calibration, latency under load, or cost per correct classification. Those remain trial criteria rather than assumed strengths.

---

Alternatives and the buying decision

These alternatives illustrate different operating choices, not a ranked or exhaustive market map:

Nyckel is attractive when a stable set of labels, an observable eventual answer, and ongoing feedback are central to the product. A managed classifier has less value when the answer can be expressed as a simple deterministic rule, or when nobody can supply reliable corrections. Teams requiring control of architecture and release promotion should evaluate that requirement explicitly against Nyckel's automatic model-management approach.

Where Tembo fits

Disclosure: I am Tembo's CEO and co-founder.

Tembo provides the adjacent execution layer: coding agents working in cloud environments with repository context and team visibility.^[22] Its documented schedules, integration events, and webhooks can start agent work.^[23]

An application could classify incoming tickets with Nyckel, route uncertain cases to people, and dispatch an approved engineering task to Tembo. That is a proposed custom workflow, not a documented native Nyckel integration. Nyckel supplies the prediction; the application owns routing and authorization; Tembo supplies agent execution. The extra platform makes sense when the result needs substantial follow-up work, while an ordinary queue or rules engine may be sufficient for simple label assignment.

---

Evaluation priorities

Best fit: teams with recurring classification work, domain experts or observed outcomes to provide labels, and a preference for managed training and hosting.

Poor fit: buyers needing independently operated model weights, fixed model releases without further verification, or a confidence number that can stand in for application-specific quality measurement.

A useful trial closes the entire loop: representative inputs, explicit labels, measured routing errors, staffed review, corrected samples, and a second evaluation after retraining. Nyckel removes much of the model-operating work; the application still needs a defensible definition of a correct decision.

---

Research by Ry Walker Research • methodology