System-1 AI: where Jev, Clef and Clairic fit in web applications

What the editor would see

Take an article about replacing an oil-fired heating system. It also explains which grants are available, so it belongs under both “Heating” and “Grants”. Solar panels appear only in a brief comparison. A keyword search cannot make that distinction.

We would give the model the article, the available topics and a description of what each topic covers. The questions are specific: is heating the main subject? Does the article explain grant options? The model returns an assessment for each topic. It does not invent categories or rewrite the article.

The editor sees these suggestions alongside the existing article in the CMS, then accepts or changes them. Once approved, the website uses the assignments for topic pages, search filters and related reading. The model has done a first pass through work that would otherwise need repeating for every article.

If the old categories are well maintained and map neatly to the new structure, a normal migration is enough. A model becomes useful when the new structure requires someone to judge the content. Whether it saves time depends on how much the editor still has to correct.

What makes System-1 models different

A conventional language model builds its answer token by token. A token might be a word, part of a word or another sequence of characters. The answer can be structured data as well as prose. A language model could handle the topic assignment in our example, too.

The System-1 models discussed here instead compute predefined decisions or fields in a model pass, without generating the answer as a sequence of text. In the CMS example, that means returning assessments for the specified topics directly, with no additional text output. This can reduce computation and response times, particularly when the same kind of task runs many times.

The name borrows from the distinction between fast and slow thinking. Here it describes a technical approach, not a human ability to think. Automated classification is hardly new. What these models offer is a way to describe questions and possible answers in ordinary language, without training a separate model for every new classification task. Typesafe introduced the approach with Jev.

Jev, Clef and Clairic compared

Jev and the Clef models classify and assess content. Clairic extracts specific details from documents. Choosing topics for an article means evaluating known categories. Reading a product data sheet means finding values we do not know in advance.

With Jev, it is worth separating established features from experimental ones. Typesafe enabled experimental image input in October, including for the existing 1.13 version. We would not yet plan around it as a standard feature for an application that needs to process documents as images.

The main difference between Clef and Clef-flash is size. Parameters are the values a model learns during training; having more of them does not make every result better. A smaller model, needing less computing power, may be enough for a straightforward classification. Whether it handles ambiguous requests equally well needs testing with the application's own data.

Clef-omni also accepts audio. That is useful when an assessment needs both the spoken content and the picture. Its output is still an assessment of predefined options, not a transcript or a freely written video description.

Clairic launched in preview on 19 October. For text extraction, it can return source locations to help people check a result against the original. It also has separate functions for estimates and predictions. An application needs to keep those clearly distinct from extracted facts. An estimated value must not look as though it appeared in the document. Cloudflare's introduction to Clairic covers these different tasks.

Getting product details out of supplier documents

Another possible use is a customer portal containing technical product information. Suppliers send data sheets as PDFs, each laid out differently. The portal has fixed fields for details such as model name, operating voltage and dimensions. Today, someone finds those details in the document and types them in.

An extraction model such as Clairic would look for the requested details. The portal would show the results next to the original, ready for someone to check and accept. If the document does not specify an operating voltage, that field must stay empty. A number from a different table is not a substitute.

This makes the difference between the two examples clearer. Jev or Clef assess which known categories apply. Clairic returns a specific value we have not supplied beforehand. An application could combine the tasks, first identifying the document type and then requesting the relevant fields. Where a supplier already provides well-structured data, a direct import is usually simpler.

Open weights and running a model yourself

With a provider's API, we send data to an external service and receive the result. The provider looks after the model infrastructure. For a limited first implementation, that avoids having to set up an environment of our own.

Open weights means the model's learned parameters are available. The licence determines whether and how they may be used, modified and redistributed. It does not tell us whether the training code and sufficient information about the training data are also available. Open weights and a fully open AI development process are different things. The Open Source Initiative explains the distinction.

The weights for Clef, Clef-flash and Clef-omni are available under Apache 2.0. That opens up the option of running them in a suitable cloud environment or the client's own data centre. A weights release has been announced for Clairic, but is not yet available at the time of writing.

Self-hosting may make sense when data must stay within a defined environment, or when there is a large volume of similar tasks. It requires suitable hardware, a supported runtime and someone to maintain it. Downloading a model does not provide updates, capacity planning or failure monitoring.

We make that decision with the client's IT team. Data handling, workload, cost and responsibility all have to fit. Much of the reasoning is familiar from choosing between cloud and on-premises hosting for web applications, with the additional question of suitable model hardware.

What we need to check before connecting a model

A useful test needs examples from the actual workflow, including incomplete and ambiguous inputs. We need to agree beforehand what counts as correct and what happens when something goes wrong. An editor can correct a misplaced topic before publication. An incorrect product value that goes unnoticed may later appear in quotes and orders.

We also check the model's confidence scores against those examples. A score of 95 per cent is a model output, not a demonstrated 95 per cent success rate in this workflow. Testing shows which cases can proceed automatically and which need someone to review them.

Calculations, permissions and binding business rules stay in the application code. The model suggests a category or a value. The application decides, under the agreed rules, whether an article gets published or a record changes.

Our invoice experiment with Clairic

For our invoice tool milchrechnung.at, we tested whether Clairic could transfer details from PDF invoices into a form. We used synthetic invoices with known correct values. Our prototype extracted the PDF text, then asked Clairic to find invoice numbers, dates, amounts and individual line items.

Header details such as invoice number and date were almost always identified correctly when present. Line items were another matter: our prototype could not reliably match descriptions, quantities and prices. In one case, it entered the 20 per cent VAT rate as a discount, although the invoice contained no discount. The number was in the document, but it meant something else.

That was not enough to import whole invoices automatically, so we did not add the prototype to the public application. Suggesting individual fields for review would be a more useful next step for us: the user sees the proposed value beside the invoice and decides whether to accept it.

Choosing a model for the application

For the CMS topic example, we would compare Jev with the relevant Clef variants. If the task involves picture and sound together, Clef-omni is worth testing. For extracting individual document fields, Clairic is a candidate if its preview status fits the intended use. A requirement to run on your own infrastructure narrows the choice further.

A provider demo shows what is possible. The decision needs results from your own data, the amount of correction required and the cost of the entire process. A cheap model call saves little if almost every record needs fixing by hand. Getting one part of the job reliably right can already save substantial work.

For us, this adds options for integrating AI into websites and business applications. Many applications do not need a chat interface. They need a useful classification, a value that can be checked against its source, and a straightforward way for someone to review the suggestion.