Does your business need an AI model that thinks in German?

With Kolibri-1, Aleph Alpha has released a model built for German texts that does its reasoning steps in German instead of English. iX tried it out and puts exactly the right question in its headline, namely whether thinking in German also helps with the answers. For you this is not a question about models, it is a question about two kinds of text that come up in your business every week. A cover letter for a quote and the reply to a complaint.

The test that takes half an hour

Pull five quotes and five complaints from the last quarter, together with the text your employee actually sent out. Let two or three models write the same draft, with the same information the person had back then.

Do not grade the style. Count how many drafts could go out after two minutes of correcting, and how many you would throw away and write again. That single number is worth more than any leaderboard. Watch four things while you do it. The technical terms of your trade, deadlines and figures carried over unchanged from the source, the form of address, and the legal terms. Whether a model keeps statutory warranty and guarantee apart is something you see in exactly those five complaints and nowhere else.

Where language counts and where it does not

With a quote letter you notice the difference quickly. A model raised on English texts likes to write a sales letter with three exclamation marks in spirit, where your customer expects two sober paragraphs. It uses the informal address where the formal one belongs, it translates trade terms back into generalities, and it phrases a firm commitment where a note about the offer being subject to change belongs.

When it reads a delivery note line out of a PDF, on the other hand, you notice little of the language. Numbers are numbers. So the question „German model or not" is not a matter of principle for your whole business, it is one you answer per task. It may well be that for your quote letters a model that argues in your language wins, and for filing documents another one that is mainly fast and cheap.

The complaint is the point where a human decides

A complaint is about goodwill, about liability, sometimes about a customer you have had for twelve years. No model knows the history, and none carries the risk if a goodwill gesture turns into an admission of liability in the draft.

That is why the draft ends up in the outbox as a draft and not as a sent mail. The machine takes over the wording, the release is done by the person who knows the customer, and it takes them two minutes instead of twenty. We build our systems exactly that way, because an automation without a named point of release becomes the owner's problem in the first dispute.

Open models have long been the normal case

Alongside the German models, something else has shifted. Through one widely used gateway that developers use to address many models at once, around 71 percent of requests now go to models with open weights. The reasoning in the report is sober and turns mostly on the price per request.

For you the number is less interesting than what follows from it. Open weights means the same model runs at several providers, and also on a machine you pay for. That makes the provider replaceable, and that is the point where sovereignty stops being a slogan. The last mile still leaves the house if the draft eventually goes out through someone else's mail provider.

Three paths, and the middle one usually gets forgotten

• Rent. You pay per request or per head at a provider. Up and running fast, no operations, ongoing costs, and every time the provider switches models your results change without you doing anything.
• Have it operated for you. An open model runs on a server that belongs to you or that you rent in Germany, and someone else takes care of updates, monitoring and restarts. The data and the system stay yours, the on-call duty does not become your problem. That is the category we work in.
• Run it yourself. The cheapest option on paper, the most expensive in reality if nobody in the house can get the box back up on a Saturday.

For the decision you need two numbers: tokens per run and runs per month. A two-page quote letter with product data comes to roughly a few thousand tokens of input and under a thousand of output. Multiply that by your monthly volume and put in your provider's current price. We have no average figure here that holds for your business, and anyone who gives you one has guessed it.

Hardware does not automatically get more expensive either. There are models where, out of 24 billion parameters, only about two are active per token, which cuts memory requirements and response time noticeably. Whether the quality is enough for your complaints is again something only your test folder will show you.

Where it gets stuck in daily operation

The enthusiasm for models with a reasoning step has a price that developers see in their bills. A model that first thinks for half a page uses a multiple of the tokens and takes noticeably longer. In a chat nobody minds. At 400 drafts a night it is the item that makes the invoice.

The second stumbling block is not flowing text, it is everything that is supposed to come back structured. If your process expects a clean data field with a customer number and a delivery date, the models part ways faster than they do in writing. And the third one we admit openly. How well a freshly released model holds up over months of continuous operation is something nobody knows after a few weeks, we included.

Hence the fallback. Keep a second model configured and write into the process who gets alerted when the first one does not answer. With open weights that switch is one line of configuration. That is the real gain, not the price per request.

What you can do next week

Set up the folder with the ten real cases. Let three models have a go, one of them German-speaking, one of them open. Count the drafts a person would send after two minutes of correcting. And only then decide where the thing should run.