modell.halowerk.com

Compares two submitted sample sets feature by feature and returns deterministic drift metrics. Continuous features are binned on the combined value range and receive PSI, Jensen-Shannon divergence and a Kolmogorov-Smirnov statistic; categorical features receive PSI and Jensen-Shannon divergence over exact category labels. The response names every feature, its sample counts, the metric values, the threshold used, and the reason a feature was flagged. It is a distribution check over your provided data only: it does not fetch production telemetry, store samples, retrain a model or claim business impact.

A comparison table of language models: input, output and cache prices per million tokens, context window, maximum output length, batch discount and a short note on what each is suited to. Filter by vendor, by a maximum price, by the context window you need, or by capability tag. Every row carries the date its prices were last checked, so a stale figure is visible rather than silently wrong. This is a curated table, not a live vendor query: prices are the publicly published list rates and negotiated or promotional rates are not represented. Availability, rate limits per account and regional restrictions are not covered — they depend on your contract, not on the model.

Scores every catalogue model against one task and returns a ranked shortlist. You state the task kind, optionally a per-call budget in USD, how much speed matters, the input size and any vendor restriction; the answer names a model, the estimated cost per call, and the sub-scores it was chosen on, so the ranking can be checked rather than trusted. Models that cannot hold the input are excluded and listed separately with the reason. Weights are yours to set and are echoed back. The routing table is a heuristic over published prices and capability tags, not a benchmark: it will not tell you which model is more accurate on your data, and for anything quality-critical it is a shortlist to evaluate, not a verdict.

Works out what a call would cost. Give either the text itself or a token count, plus the expected output length, and get input, output, cache-read and cache-write cost per model with the total. Token counts derived from text are estimates from character and word statistics, not a tokeniser, and typically land within about 15 percent — where an exact count matters, count with the vendor tokeniser. Prices come from a table with a stated date; a model whose price has moved since is reported with its table date, so an old figure is visible rather than silently wrong. Unknown model names are refused with the closest matches rather than guessed.

Plans the division of a long input for a given model. It reserves room for the system prompt, the expected answer and a safety margin, then works out how many chunks are needed and where to cut, preferring paragraph boundaries over line and sentence boundaries and never cutting inside a word. Optional overlap carries context across the seams. The result gives per-chunk token estimates, the character offsets of every cut, the boundary type actually used, and the total cost for processing all chunks on that model. If the text fits in one pass, it says so and stops. Token counts are estimates from character and word statistics, not a tokeniser: leave the default margin in place, or verify with the vendor counter where an overrun would be expensive.

Validates output against a JSON Schema and reports each violation with its JSON path, the rule it broke and a sentence saying what to change. Accepts either a parsed object or the raw string a model returned: a payload wrapped in a code fence or surrounded by prose is unwrapped, and the wrapping is reported separately from schema errors so you fix the right layer. Draft 2020-12 and draft-07 are both supported, along with the common string formats. Optionally the repairable problems are listed: missing fields that have a default, and unexpected extra fields. It validates structure, never truth — a document that satisfies the schema perfectly can still be factually wrong, and nothing here checks that.

Takes the steps of one agent run and returns a scored report. It counts identical tool calls (same tool, same arguments) as loops, finds the longest run of consecutive failures, marks calls whose result was empty or null as wasted, and attributes cost per step and per tool so the expensive part is visible. Cost is taken from your figures when supplied, otherwise computed from token counts against the model price table. A grade from A to F is derived from four measurable ratios — loops, errors, empty results and cost concentration — and every ratio is returned with the threshold it was judged against, so the grade can be recomputed or disagreed with. It judges shape and spend only: a run can be efficient and still produce the wrong answer, and nothing here checks the answer.

Reads an OpenAPI 3.x document and reports what would stop a machine consumer. Errors: missing openapi, info or paths; a path that declares no method; an internal $ref that resolves to nothing; a parameter without a name, location or schema; a request body without content. Warnings: an operation without operationId (client generators fall back to guessing), a response without a schema, a 2xx response missing entirely, no example anywhere on an operation, a path parameter that appears in the URL but is never declared. External $refs to other files are reported as unresolvable here rather than treated as errors, since only the document handed in is read. Swagger 2.0 is detected and rejected with a note rather than validated against the wrong rules.

Converts each OpenAPI operation into an MCP tool. Path, query and header parameters and the JSON request body are merged into one input schema, because MCP tools take exactly one; a name collision between a body field and a parameter is reported rather than silently overwritten. Internal $refs are expanded inline so each tool schema stands alone — an MCP client cannot resolve them. Tool names come from operationId, normalised to snake_case, or are derived from method and path when it is missing. Read-only operations are marked with readOnlyHint and write operations with destructiveHint. Only application/json bodies are converted: multipart, form and binary bodies are listed as skipped with the reason. The result is a starting point, not a finished server — it carries no auth handling and no request execution.

Two checks in one. First the arguments are validated against the tool input schema and every violation is reported with its path and a sentence saying what to change. Second, values that satisfy the schema but look wrong are flagged: an unset required field filled with a placeholder like "string" or "TODO", a number at a suspicious order of magnitude, an address that fails its checksum shape, a destructive flag set to true, an empty string where content was expected. Fields whose names suggest an irreversible effect — amounts, recipients, deletion and force flags — are held to the stricter standard. Warnings are heuristics and can be wrong in both directions: treat them as a prompt to look, not a verdict, and never as a substitute for the tool own checks.

Compares a producer output schema against a consumer input schema and reports whether the two can be chained. Every required field of the consumer is looked for in the producer: exact name matches first, then well-known synonyms (url/uri/link, id/key/ref, created_at/timestamp and so on), which are reported as renames needing a mapping rather than as clean matches. Types are checked for direction: integer into number is widening, number into integer loses precision, anything into string is a conversion, string into anything is a parse that can fail. Enum values are intersected, so a producer that can emit a value the consumer does not accept is flagged. The result is a field mapping you can implement directly, plus the list of gaps no mapping can close.

Use this when an agent has an older and a newer LLM catalog snapshot and needs a deterministic migration diff before changing routing or budgets. Rows are matched by vendor plus model, id or name. The result separates added, removed and changed models and reports field-level differences for input, output and cached-input price, context window and maximum output tokens. Both snapshots come from the caller: this endpoint does not fetch vendor data, infer missing values, judge whether a change is beneficial or store either catalog.