The invoice for an AI feature never matches the invoice for its prototype.

At prototype stage you call an API and the bill is small enough that nobody opens it. Then the thing ships, real documents start arriving, and the same feature costs more per month than the server it runs on. A second vendor for embeddings, a third for OCR because the first mangles Greek, an object store for the documents, and a data-processing agreement for each. That is where small teams end up, and it is not a technical problem. It is a bill with several line items and nobody able to say which one is the product.

Inferyes replaces the vendor list with one endpoint on machines I control.

The API

/v1/chat/completions, /embeddings, /rerank, /images/generations, /forecast, plus the document operations: /extract, /summarize, /title, /synopsis, /tags, /translate, /sentiment, /pii, /quality, /moderate, and classifications for document type and business party. Runs are named and cancellable (/runs, /jobs/:id), and usage is readable as a number or as a stream (/usage, /usage/stream) so a partner’s dashboard and my own can read the same ledger.

What is underneath

• Presets are the unit of work: task kind, pinned model, prompt or JSON schema, options, and the timeout policy for worker-backed kinds. Preset trees chain them into a DAG where one step’s output feeds the next, so extract-classify-summarise-route is one run rather than glue code.
• Backends are registered OpenAI-compatible servers with their declared capabilities and a monitor that notices when one stops answering.
• A worker fleet of capability-scoped workers, with fleet tokens, leases and a queue. A worker declares what it can do and holds a credential that cannot reach the customer API. The contract is documented well enough that adding a worker is a weekend, not a negotiation.
• Two ledgers: one for model calls, one for extraction and worker jobs, behind one report.
• Workspaces isolate presets, tokens, runs and usage per client, with API keys encrypted at rest through Vault.

What it works against

The assumption that a serious AI feature needs a frontier model on someone else’s hardware. Most of the work I see is extraction, classification, translation, summarising and forecasting. A local model of a few billion parameters does those at a cost that does not scale with success, and does them without a document leaving the building.

It also works against my own worst instinct, which is accepting a subscription because configuring it is faster than replacing it. Twelve months later that subscription is a dependency nobody remembers choosing.

What it costs

Own hardware, own power, own model upgrades, own pager. A small model is not a frontier model, and when a customer genuinely needs the biggest one, the honest answer is to buy the API for that specific job. The gateway makes that a per-preset decision instead of an architectural one.

Proprietary, not sold as a package. Deployments are mine or a client’s, by invitation. The service page describes what a client gets; this page describes what is running underneath.