The question of how large such a model may be has no single answer in megabytes. It has two budgets that work differently, and one item that is almost always underestimated.

Why a 3D model loads differently from a video

A product video is rendered once and then only played back. A 3D model in the browser, by contrast, is redrawn by the visitor's graphics card on every movement, from triangles for the surface and textures, meaning images for colour and material. That is why a customer can rotate the enclosure or choose a different panel, and that is why their device decides whether this runs smoothly.

A configurator sits between two extremes. A video fixes every frame in advance, a CAD program leaves every dimension open, and a configurator fixes the rules within which the customer chooses freely.

For the question of size this means: the customer's device carries the load. The limit is therefore set by the weakest device your audience uses to open the model.

Two budgets that have to be calculated separately

The first budget is transfer. Geometry, textures and the program code for rendering have to travel over the network, and together with the bandwidth their sum decides how long the customer waits. Compression methods make the data smaller for transport.

The second budget is GPU memory. To draw, the device holds geometry and textures in a form the graphics card can work with directly, and that form is often much larger than the transferred file. If memory is insufficient, rendering stutters or the page aborts.

The two budgets behave differently. A well-compressed file can load quickly and still overwhelm a phone's GPU memory, and a file that fits into memory can still take too long to load.

Why textures usually tip the balance

The size of a texture grows with the square of its edge length. A texture of 2,048 by 2,048 pixels has four times as many pixels as one of 1,024, and each material often carries several, for example for colour, surface structure and roughness. Eight materials with three textures each already make 24 images.

Then there is the difference between file and memory. JPG and PNG are compressed for transfer, but the graphics card cannot draw with these formats, so they are fully unpacked first. In addition, the device usually keeps reduced copies of every texture for distant views, which increases the requirement by about a third.

Textures in the KTX 2.0 format take a different route. They are converted on load into a format the graphics card can keep compressed even afterwards, and according to the Khronos Group this lowers GPU memory. An extension lets them be embedded directly in glTF files, the common delivery format for 3D on the web.

It is like files in an office: in the binder they take little space, spread out on the desk a great deal. A JPG texture lies spread out on the graphics card, while a texture in a GPU format stays in the binder.

Work out the load budget of the enclosure

The calculator separates both budgets and checks them against three assumed device classes. The preset is the enclosure as it might come out of a rendering program: 900,000 triangles, eight materials with three textures each at 2,048 pixels, JPG textures and compressed geometry. All values are examples, including the assumptions about bandwidth and GPU memory for the device classes.

Watch the smartphone row. Then switch the texture format from JPG to KTX2, and after that lower the texture resolution to 1,024.

In the default setting the model transfers about 25 megabytes, of which about 21 megabytes are textures, and occupies 537 megabytes of GPU memory. With KTX2, GPU memory in the calculation drops to 89 megabytes, but the phone still takes too long to load. Only at 1,024 pixels does the load time fall to about 7.5 seconds, and the verdict changes to "runs with compromises".

What the calculation reveals about the example

In this example geometry is the smaller item as long as it is compressed. Double the triangles to 1.8 million and transfer grows by only about three megabytes. Switch compression off and geometry becomes the largest item at about 25 megabytes, and even the laptop takes too long to load.

Texture resolution is the strongest lever. At 4,096 pixels the textures quadruple, and in the calculation even the office desktop fails on load time. Which resolution a material needs depends on how close the customer can get: a wire-mesh panel that never appears nearer than one metre from the camera needs no texture for a magnifying glass.

The calculation is deliberately simple. It knows no draw calls, no shadows and no progressive loading, and its factors for compression and memory are assumptions. It shows proportions and does not predict how a particular model runs on a particular device.

How a configurator is built inside

The load budget concerns only one of six stages a model passes through on its way from engineering to the customer. Most projects stall less at the graphics than at the rules.

Model. The geometry needs named parts such as post, door and panel, dimensions in millimetres and a fixed origin. If the model comes out of a rendering program as a single mesh without named parts, the software cannot tell where the door ends, and every variant becomes manual work.

Rules. This is where it is defined which options exist, which exclude each other and which limit dimensions apply. These rules often live in the heads of a few people, or the price list and the configurator keep separate option lists that drift apart.

Variants. The current state belongs in a place a link can carry, such as the page address. If it lives only in the browser's memory, the back button wipes the selection, and nobody can pass their configuration on.

Pricing and bill of materials. Quantities should come from the same geometry as the picture; otherwise a separately maintained bill of materials drifts at some point. Price tiers do not belong in the browser, because anyone can read them there.

Rendering. Material, light, camera, labelling and loading order decide the load budget. That includes deciding when not to draw, because an endlessly rotating model drains batteries.

Output. At the end is what the customer sends: an enquiry with the complete state, a bill of materials or a file for manufacturing. If the enquiry arrives without the configuration, the sales office rebuilds by hand what the customer had already set.

How a parametric definition can run as a service behind such a configurator is described in From Grasshopper model to web configurator. Two calculators that derive quantities and files from one rule are the façade rationaliser and the nesting calculator.

What should be settled before export

Most size problems arise at export, and most can be avoided with a few decisions beforehand. Sorted by effect, there are six.

1. Define the weakest device class in your audience and calculate both budgets for it.
2. Choose texture resolution per material by the shortest viewing distance.
3. Share and repeat textures across materials instead of painting every surface individually.
4. Consider a GPU-ready texture format when GPU memory is tight.
5. Compress geometry for delivery and remove details that are invisible from viewing distance, such as threads, screws and internal parts.
6. Derive the browser version automatically from engineering instead of rebuilding it by hand.

The last point decides maintenance. According to the Khronos Group, glTF is a format for the efficient transmission and loading of 3D scenes, which makes it a delivery format and not a working format. If the browser version is regenerated with every engineering change, it stays current, while a hand-built model drifts apart with the first change.

When a picture is the better choice

If a product comes in only a few versions, good photographs are cheaper to produce and maintain than any 3D model. Whether a parametric model pays off depends on the number of variants and how often they change, as set out in When a parametric model pays off.

If your audience mainly uses older phones or slow connections, a pre-rendered image or a short video is more robust. And if there is no clean engineering model, a configurator shows unchecked dimensions that someone might order by.

Whether a customer should also see the model in their own space is a separate question. When a dimensional check is enough and when AR helps is covered in Does it fit the room?, and the service itself is described on the page 3D configurators.

The obvious plan is a rebuild and a switch-over on a fixed date. The other plan moves the modules one at a time, lets old and new run side by side for a while and only switches the legacy system off once nothing uses it any more. Which plan holds depends less on the technology than on the dependencies between the modules, and those can be written down and worked through in advance.

Why a cut-over date puts so much on one day

With a switch-over on a cut-over date, everything happens at once: the data is transferred, every interface points to the new system, every user works in new screens from Monday. Each of these steps can succeed on its own and still fail in combination, and the fault only shows once the first real order runs through.

A cut-over date is like moving a workshop over one weekend. If one machine jams on Monday, the whole hall stands still, because the old layout has already been taken down. On top of that, a switch-over is hard to reverse once the first records exist in the new system: whoever switches back has to bring that data back into the legacy system.

This does not mean a cut-over date is always wrong. It means that the risk of a cut-over date grows with the number of modules that have to work together on that day. A step-by-step replacement keeps exactly that number small.

A router in front of the legacy system

Martin Fowler describes the approach under the name Strangler Fig, after a fig that grows up a host tree until it replaces it. New functions are built separately from the legacy system, both run side by side during the transition, and behaviour gradually moves from the old system to the new one. Fowler stresses that breaking the system down into pieces that can be replaced one at a time is the actual core of the approach.

Technically, this needs a place where it can be decided which system handles a request. That can be an interface in front of the system which the portal, warehouse and accounting already talk to, or a database view behind which the tables are moved. This router is transitional architecture: it costs effort although it disappears again at the end, and it is still the reason why each individual move stays small.

If there is no such place, because users and external systems write straight into the legacy database, the replacement starts by building one. This first step brings nothing new for the business, but it shows who actually uses the legacy system.

Which module moves first

Not every module can move at any time. Invoices need orders, orders need customers, and dunning needs invoices. A hard dependency of this kind means: a module can only run in the new system once its prerequisite already runs there, or it moves in the same stage as that prerequisite.

This gives a simple rule. Peripheral modules that no other module relies on move first, in the example shipping and quotes. An early move at a place with little traffic shows whether router, data synchronisation and operations work before a module the revenue depends on is due.

Modules that need each other, or whose prerequisite has to wait a long time itself, are harder. They lead to coupled moves, in which two modules change over in the same stage. A coupled stage is a small cut-over date inside the step-by-step replacement, and it deserves the most thorough preparation.

Working through the stage plan yourself

The calculator applies these rules. It takes a list of business modules, assigns an adjustable share of hard dependencies and plans stages from them in which at most the set number of modules move. Switch between cut-over date and step by step, and watch in which stage the invoices module changes over and whether that stage is outlined with a dashed line as a risk.

With the example values of the default setting, ten modules, two modules per stage and three hard dependencies, the plan has five stages. Invoices only move in stage 4, coupled to orders, which in turn wait for customers. Calculated as a cut-over date, all ten modules change over in one stage, and all three dependencies become coupled moves. With only one module per stage the risk disappears completely, but the plan grows to ten stages.

The numbers are stages, not weeks. How long a stage takes depends on the module, the data and the parallel run. What the calculator reliably shows is the structure: which modules wait, where couplings arise and which lever resolves them.

A parallel run means comparing

While a module moves, old and new run in parallel for one stage. That only adds safety if both results are compared. The router sends the same request to both systems, the legacy system stays authoritative for now, and every difference ends up in a log that someone reads.

Before switching over, it should be written down when the parallel run ends: for example once no unexplained difference has occurred over an agreed period and every known special case has run through at least once. Without such a criterion, the parallel run stays in place out of caution, and the team maintains two systems for longer than planned.

Differences are not always faults in the new system. Often the comparison reveals a rule that was never documented in the legacy system, such as a rounding step or a discount that only applies to one customer group. Findings like these belong in the description of the new module before the old one is switched off.

Who owns the data during the replacement

The most delicate question in a step-by-step replacement concerns the data. As long as a module exists in both systems, every data object needs exactly one leading system: customer master data is changed either in the old or in the new system, never in both. The other system receives a copy, and the direction of that copy only changes when the module moves.

In practice, this means creating a mapping table for identifiers early, because the new system assigns its own numbers, and deciding how often and in which direction data is synchronised. Letting both ends write at the same time creates conflicts that are hard to resolve later.

When a function is needed earlier than its module can move

In the example, the customer portal is supposed to hand over orders early, but the orders module can only move in stage 4. The stage plan alone does not answer this. An interim solution at the router can accept orders from the portal, check them and write them into the legacy system through the existing path until the new module is ready.

Such an interim solution is deliberately transitional code. It should be built so that it can later be placed in front of the new module or removed, and it belongs in the plan with a date for its review. Otherwise the interim solution turns into another legacy system.

When a cut-over date is the better choice after all

A step-by-step replacement costs a router, a parallel run and data synchronisation. These costs are not worth it in every case. A small system with few users and no integrations can often be switched over more cleanly on one well-prepared day.

1. The system is small: if all modules can be tested in one day, breaking it down brings little.
2. There is no place for a router: an application whose data can only be reached through its own user interface is hard to redirect section by section.
3. The data model cannot be split: if almost every table is written by almost every module, every stage becomes a coupled move.
4. The parallel run costs more than the risk: if a one-day outage is bearable, the preparation can be leaner.

Even then, part of the method remains useful. The list of modules and their dependencies shows what has to work together on the cut-over date, and therefore what should be tested together beforehand.

Where you can start

The first steps follow the same logic as the stage plan, and they can be started in-house. First comes a list of business modules with their users, data flows and hard dependencies, counted rather than estimated. Then every connection to other systems is described like a contract: format, direction, behaviour on failure and responsibility.

With this list, a peripheral module can be chosen as the first candidate, and it shows whether router, comparison and operations hold. Which documents a new module needs before another team runs it is covered in the guide Vom Proof of Concept in den Regelbetrieb (German). What needs to be settled for running an application in-house is described in Eine Anwendung im eigenen Haus betreiben, and how to spot shortcuts in the code that make every further move more expensive in Technische Schulden erkennen.

If a service provider is to accompany the replacement, the guide Prototyp weiterentwickeln lassen helps with the selection. An overview of software development at iiterate is on the page Softwareentwicklung.

That number is a sum. It is made up of five items that differ in size, react differently and can be reduced by different means.

Why a single time measurement explains little

A total time answers the question of whether an assistant is too slow. It does not answer why, and therefore not which measure helps. A new graphics card speeds up only one of the items, a faster search another, and both investments can miss the actual cause.

A latency budget, as known from planning real-time systems, is more useful. You set a target response time and distribute it across the items an answer passes through. If the sum exceeds the target, the budget shows at once which item is too large.

For the machine builder in the example, such a budget would have shortened the discussion. Instead of arguing about graphics cards, the team would have seen which item exceeds the target time and whether a setting can reduce it. This breakdown can be worked through with example values.

The five items of an answer

An assistant that answers from your own documents works through the same chain for every question. How that chain is built in detail is described in the knowledge article Retrieval-Augmented Generation. For response time, five parts of it count.

Document retrieval. The search finds text sections in the index that match the question. Its duration depends on the size of the collection, the search method and how permissions are filtered.

Reranking. A second model re-orders the candidates found before the best ones go to the language model. Its duration grows with the number of candidates it has to score.

Model answer. The language model reads the instruction, the question and the sections, then writes the answer. Reading the context takes time before the first word appears, and writing takes time for every word after that.

Check step. A check compares claims with their evidence and verifies permissions and format. It makes answers more reliable and adds an item of its own in return.

Network. Request and response travel back and forth between browser, application, search and model. If the model sits with an external provider, further hops are added; if it runs in your own network, they are shorter.

Why the model answer is usually the largest item

A language model does not write whole sentences at once. It generates tokens, that is, word fragments, one after another, and each new token builds on all the previous ones. Writing time is therefore roughly the number of tokens times the time per token.

Time per token is not a fixed property of a model. It depends on model size, hardware and quantisation, and on how many requests are sharing the compute at that moment. Two simultaneous requests on the same graphics card both slow down, and with an external provider the value can fluctuate with the provider's load.

The number of tokens, on the other hand, is up to you. An instruction that asks for detailed introductions, restatements of the question and closing summaries quickly doubles the answer length without making the answer any better.

The first word and the finished answer are two different times

Many interfaces show the answer while it is being written. For users, what matters most then is when the first word appears, less when the last one is in place. Before the first word, retrieval, reranking, network and context reading all run; only then does visible writing begin.

A check step changes this calculation. If it checks the finished answer before it is displayed, the interface can show nothing in advance, and the perceived wait equals the full sum. If it checks continuously or only selected claims, progressive display remains possible, but a claim that is already visible may have to be withdrawn afterwards.

Which variant fits is a business decision. For information on which someone releases a machine, waiting for the checked answer is the lesser evil.

Work through a latency budget yourself

The demonstration adds the five items into a sum and draws it to scale against a target response time. The presets are example values for an assistant with a two-second target, where the sum lands just below it. The values are not measurements; they only make the proportions tangible.

Set the time per token from 9 to 14 milliseconds, as if two requests were sharing one graphics card. Then shorten the answer length from 180 to 110 tokens and watch the target line.

At 14 milliseconds per token the bar overshoots the target by 880 milliseconds. With 110 tokens the sum is 1,900 milliseconds and back under the target, without any change to hardware or model.

What the calculation shows and what it leaves out

The model answer dominates the sum in almost every setting. Dropping reranking and the check step entirely saves 190 milliseconds together in the preset, while 70 fewer tokens at 9 milliseconds per token save 630 milliseconds. Shorter answers are therefore often the first and cheapest fix.

The calculation has three gaps that matter in operation. It uses one fixed value per item, although real timings vary and users notice slow answers more than the average. It knows no queue, which forms when more questions arrive than can be processed at the same time. And it does not separate reading from writing, although long sections passed to the model mainly delay the first word.

A reliable statement therefore needs measurements on your own system. Useful are timestamps at every hand-over and an evaluation that shows the slowest requests alongside the mean, for instance via the 95th percentile.

How the operating mode shifts the items

Where the language model runs changes two items above all. With an external provider, network hops and the provider's load are added; in your own network the hops are shorter, but all users share your own compute. A graphics card that is fast enough for one specialist team can become noticeably slower when a whole department asks questions at the same time.

The operating modes themselves, meaning a cloud interface, hosting in the EU and running in-house, differ in far more than response time. A comparison is on the page AI development, and the trade-off from the perspective of data and cost is in On-premise vs. cloud LLM. What hardware is realistic for running it yourself is described in Local LLM in the enterprise, and which open models can be run locally in the knowledge article Local language models.

For the machine builder this means: before a bigger graphics card is bought, a measurement with simultaneous questions shows whether the time per token rises under load. If it rises, more compute helps. If it stays stable, the cause lies in another item, and the new card would not solve the problem.

In what order to speed up a slow answer

The order follows the ratio of effect to effort. The first steps change configuration and instruction; only the last ones cost money.

1. Set timestamps per item and evaluate the slowest requests separately.
2. Limit answer length: ask for a short form in the instruction and remove restatements of the question and closing formulas.
3. Pass fewer and shorter sections if the test questions show that the correct passages still arrive.
4. Check the number of candidates for reranking, because it often grows unnoticed with the collection.
5. Place the check step so that nothing is checked twice, for example permissions before the search instead of after the answer.
6. Cache frequent questions with stable answers, provided their sources rarely change.
7. Only then decide on a smaller model, different hardware or a different operating mode.

Each of these changes can affect answer quality. That is why the same test set runs after every step, as described in Why AI features fail in practice.

When response time is secondary

Not every AI application keeps a person waiting. Extraction from documents, overnight evaluations or summaries for a report run in the background, and there throughput per hour matters more than seconds per request.

Conversely, there are applications for which a two-second budget is too generous, such as voice dialogues in which a pause feels like a fault. There the calculation shifts towards short answers, smaller models and a check that does not wait for the finished answer. The use case decides which target time is appropriate, and the budget makes visible what that target costs.

That sentence gives nobody anything to work with, because it names no location. An AI feature consists of several stages, and almost every fault arises at exactly one of them. The pump example is invented; the route to the cause carries over.

Why "the AI" is not a cause of failure

From the outside, two things are visible in an AI feature: the question and the answer. Everything in between looks like a closed box, so complaints land on the language model, because it is the only component whose name everyone knows. The obvious reaction is a different model, a longer instruction or a more expensive plan.

In a built system the box is a chain. Documents are collected, split, indexed and searched for every question; only then does a model write, and ideally a further stage checks the result before it is output. Break the technician's complaint down along this chain and a different picture appears: the manual was in the index, but the correct section only came sixth in the result list, and only the first four were passed to the model.

In this case the repair lies in retrieval. Nobody would need to change anything in the language model, and switching models would at best have covered up the fault.

The seven stages of an AI feature and their typical faults

The breakdown that follows is built for troubleshooting. How the processing works technically, from splitting through embeddings to reranking the hits, is explained in the knowledge article Retrieval-Augmented Generation. For troubleshooting, all that counts at each stage is what goes wrong there and how you notice it.

1. Intake. Documents, tickets and records are collected, together with their version and read permissions. Typical faults are an incomplete collection, outdated versions and scans without a text layer. You notice it when answers cite a superseded version or certain sets of files never show up.

2. Preparation. Texts are split into sections that can be found individually. If splitting tears a table apart or separates a heading from its content, retrieval finds fragments without context. The symptom is an answer that gives a number without its unit or condition.

3. Index. The sections are stored in searchable form, as a keyword index, a vector index or both. Faults arise when changed documents are not re-indexed or permissions are lost on import. The assistant then cites documents that have been deleted or that the person asking may not open.

4. Retrieval. For each question the system looks for matching sections and passes a limited number to the model. If the correct passage sits too far down, or the question uses different words from the document, it never arrives. The symptom is a generic, half-right answer although the knowledge is in the collection.

5. Model. The language model writes an answer from the question, the instruction and the sections passed on. It can weight sections wrongly, drop conditions or fill gaps with plausible general knowledge. You recognise this case when the correct passage was demonstrably passed on and the answer still deviates.

6. Check. A check stage compares claims with their evidence, verifies format and permissions and, when in doubt, holds an answer back. If it is missing or set too leniently, unsupported claims get through. If it is too strict, users conspicuously often receive no answer at all.

7. Output. The answer reaches a target system, such as an interface, a ticket or a record. Footnotes get lost there, numbers are reformatted or fields truncated. The symptom is an answer that was correct in the log and arrives wrong for the user.

Why retrieval is so often the cause

For every question, a language model reads only what is in its context window: the instruction, the question and the sections passed on. It is like a colleague who is handed four pages from a binder: he can write well, but only about those four pages. How many sections are passed on is a setting, and every setting cuts the result list off somewhere.

On top of that comes a vocabulary problem. The technician writes "leak rate", the manual speaks of "leakage", and a pure keyword search sees two different terms. Vector search and hybrid methods soften this, yet with technical terms, type designations and compound words the gap remains a frequent reason for misses. Which methods exist and how they can be combined is described in the knowledge article Semantic search in the enterprise.

Both effects are quiet. The answer reads fluently because the model makes something fitting out of the sections it received, and nobody sees the result list in which the correct passage sits just below the cut-off.

Try the retrieval from stage 4 yourself

The demonstration works with thirteen invented sections from a maintenance manual, a standard extract, a data sheet and maintenance logs. The technician's question is preset, and scoring uses a simple keyword search that weights rarer words more heavily. Watch the highlighted row with manual section 4.5 Leakage and the indicator of whether it reaches the model.

Set the context window to six sections and check whether the manual section arrives. Then switch back to four sections and turn on the synonym list.

Even at six sections, section 4.5 Leakage does not arrive: a few short maintenance-log entries and the standard extract crowd it out, because they repeat the same query words in far less text. Only the synonym list changes that. It reads "leak" as "leaks" and "leakage" too, and the section jumps straight to rank 1, from rank 7 of 13.

What the demonstration shows and where it stops

The two corrections come at different prices. More sections in the context window make every request longer and give the model more material to weight wrongly. A synonym list acts precisely but has to be maintained by someone who knows both the language of the documents and the language of the people asking.

Also try the question "When is the pump leaking?" Without the synonym list the correct section already lands at rank 2, and with it at rank 1, with the standard extract's definition of tightness directly behind it at rank 2. That is a good result, because the two passages together make up the complete answer.

The demonstration has deliberately tight limits. It calculates without embeddings, without reranking and without a language model, and its collection is small enough for every row to be traced. The ranks are results of the demonstration, not measurements from a system, yet the pattern behind them holds in large collections too: a correct answer requires the correct passage to arrive.

A test set makes faults countable

Individual complaints show that something goes wrong, but not how often. For that you need a fixed collection of real questions, each noted in advance with the source passage a correct answer would have to cite. A few dozen such everyday questions are enough for a first baseline.

The test set separates two questions that a complaint mixes together. The first is whether the correct passage arrived in the context window; if not, the fault lies in stages 1 to 4. The second is whether the answer was written correctly and with evidence from the passage that arrived; if not, it lies in the model, the instruction or the check.

After every change to splitting, index, retrieval, model or instruction, the same test set runs again. That makes visible whether a change helped or made something worse elsewhere. How answers can be tied to sources and assessed, including human spot checks, is covered in the knowledge article Checking AI answers. Why this evaluation is an ongoing cost item and not a project phase is set out in What a RAG system really costs to run.

In what order to narrow down a complaint

For a single complaint a fixed order pays off, because each step rules out whole stages. Starting with the model means checking first the place where the fault is least often visible.

1. Record the question and the expected source passage. Without the passage a correct answer would have to cite, no fault can be demonstrated.
2. Check whether the passage is in the index, in its valid version and with the right permissions. If it is missing, the cause lies in stages 1 to 3.
3. Look at the rank of the passage in the result list. If it sits beyond the context window cut-off, the cause lies in stage 4.
4. If the passage was passed on, compare instruction and answer. If the answer still deviates, the cause lies in stage 5.
5. Finally check the check stage and the output, that is, whether a supported answer was held back, shortened or reformatted.

This requires a retrieval log that records, for every answer, what was found, what was passed on and what was used. Without that log only guessing remains, and troubleshooting ends up at the model again.

When an AI feature is not the right solution

Not every question from operations needs seven stages. If a question can be phrased as a fixed query, such as a date or a master data value, a database is more precise and cheaper than any language model.

Two further cases fail before the technology does. If three versions of the same manual are in circulation, the first step is deciding which one applies. And without a person who adds new versions and withdraws old ones, the answers go stale without anyone noticing.

If a single error triggers payments, safety risks or downtime, a person belongs at the decision. Whether pump P-40 starts up again is the technician's call, and the assistant gives him the source passage for it. How well your own collection is prepared for such a system can be assessed with the RAG readiness check, and the building blocks an implementation involves are described on the page AI development.

The question sounds like a case for augmented reality. Often, though, a calculation is enough, because the enclosure and the room exist as dimensions anyway. Where that calculation stops, how detailed a 3D model has to be for a spatial view and when AR really helps can be clearly separated.

Why the question about the room is really two questions

Anyone asking whether an enclosure fits into the hall usually means two things. The first question is whether it can be set up with enough distance to walls and ceiling for maintenance and operation to remain possible. The second is whether the machine that is to stand inside it will get through the hall door.

Both questions have their own bottlenecks. An enclosure can stand comfortably in the room while the machine fails at the door width, and the other way round. A room check that answers only one of the two questions therefore creates false confidence.

Ideally the enclosure dimensions come from a configurator in which the customer sets width, depth, height and doors. How such a configurator derives drawing, bill of materials and weight from the same rule is shown on the page 3D configurators.

What a room check has to calculate

For placement, the enclosure needs its own footprint plus a maintenance clearance on every side. In front of the enclosure's doors a swing area is added that can be larger than the maintenance clearance, and in height there has to be room up to the ceiling. The clearance a particular machine needs is stated in its documentation; the calculation only takes it as an input.

The swing area is easily forgotten in sketches. An enclosure that just fits into the room with maintenance clearance can still be unusable if its door cannot open fully. The calculation therefore applies the larger of the two values in front of every door.

For bringing it in, the machine's cross-section is what counts. Upright, its narrower base side has to fit through the door width and its height through the door height. If the machine may be tilted, further orientations are added, and the calculation takes the most favourable one.

Both checks produce four statements a customer understands: whether the enclosure fits, whether the machine gets in, how much free floor area remains and where the tightest clearance is. A first answer rarely needs more.

Check the enclosure yourself

The demonstration calculates both checks for an enclosure of four by three metres and 2,200 millimetres high with one door. The preset is a hall of 6,500 by 4,600 millimetres with 800 millimetres of maintenance clearance, all example values. In this setting 200 millimetres of depth are missing, and the top view marks the affected walls.

Lower the maintenance clearance to 600 millimetres, or take one metre of depth off the enclosure. Then set the door width to 1,500 millimetres and allow tilting.

With 600 millimetres of maintenance clearance the enclosure fits, and almost six square metres remain free. At a door width of 1,500 millimetres the machine does not get in upright; tilted, the calculation reports "yes" with 0 millimetres of clearance.

What the check shows and what it leaves unsaid

The result with 0 millimetres of clearance is arithmetically correct and practically worthless. No machine can be moved through an opening without play, and forklifts, transport rollers or lifting gear need extra space. A useful check therefore works with a minimum clearance that the manufacturer sets from experience.

Placement is simplified too. The calculation centres the enclosure, knows no columns, cable trays, crane runways or floor drains, and does not ask about the load capacity of the floor. It also checks only the last door, although the transport route through corridors, ramps or a lift is often narrower.

As a first answer it still does the job. It replaces a follow-up question with a number and shows which piece of information is missing before anyone drives out to take measurements.

What a customer should provide

The quality of a room check depends on its inputs. Five pieces of information cover most cases, and many customers can supply them without a site visit.

1. Room dimensions: clear width, depth and height at the installation site, measured under the lowest point such as beams or pipes.
2. Door and gate dimensions: clear width and height of every opening along the transport route, including the first.
3. Obstacles: columns, cable trays, crane runways and floor drains with their approximate position.
4. Access: from which side the enclosure is operated and maintained.
5. Transport: whether the machine may be tilted and what it is moved with.

With this information the check can be calculated automatically and sent along as part of the enquiry. The sales office then sees not only the chosen enclosure but also whether it fits at the customer's site and gets in.

How detailed the model needs to be for a spatial view

If the customer is also to rotate the enclosure in 3D or later see it in their own space, every part needs a surface made of triangles. A model taken directly from engineering is almost always too detailed for this, because it carries details nobody sees from viewing distance.

The number of triangles can be estimated from the bill of materials: quantity per item times triangles per part, summed over all items. For the enclosure in the demonstration this gives about 800 triangles in a plain sales view, just under 7,000 in a version close to engineering with rounded profiles, and over 32,000 in a version close to manufacturing with connectors and foot plates.

The version close to manufacturing therefore has about 42 times as many triangles as the sales view, and for the question about the room it shows nothing extra. The purpose decides which level of detail is right: for dimensions and placement the plain version is enough, for explaining the joining technology the finer one is worth it. How the budgets of a model in the browser can be calculated is shown in How large can a 3D model in the browser be?.

The simplified version should not be made by hand. If it is derived automatically from the model with every engineering change, dimensions and quantities keep matching engineering. A rebuilt sales model, by contrast, shows an enclosure after the first change that no longer exists in that form.

When AR answers the question better than a calculation

A calculation needs dimensions, and some rooms are hard to put into dimensions. Irregular floor plans, scattered obstacles or a hall full of existing equipment cannot be described with five numbers. That is where an AR view can help, placing the model to scale in the real room through the camera of a phone or tablet.

The advantage is the view on site. The customer sees whether the enclosure ends in front of a column or touches a cable tray, and the conversation with the manufacturer starts from a shared picture. For this purpose the light model of the sales view is enough.

AR has limits of its own. Position tracking needs edges and patterns in the surroundings, and plain surfaces, glass or low light offer little of that, which is common in workshops. The application also has to run on the customers' devices, and camera access has to be granted first.

The order follows almost by itself. First come the rule and the dimensions, then the calculation, and AR where dimensions do not describe the room.

When a room check and 3D do not pay off

If there are only a few versions and hardly any customer asks about the room, a dimension drawing with minimum clearances is the cheaper answer. It can be printed, added to a quotation and needs no maintenance.

If the rule for clearances and variants exists only in one person's head, software comes too early. The first step is then to write down limits and dependencies so that configurator, bill of materials and check read the same source, as described in From Grasshopper model to web configurator.

And if the enquiry, room check included, ends up in an inbox because someone has to transfer it into the ERP system by hand, the effort merely moves elsewhere. Whether a parametric model pays off for your product can be estimated with the criteria in When a parametric model pays off.

If you can rule out these three cases, you are in a good starting position. It then pays to begin with the rule and the room check and to add the 3D model and AR view only once enquiries show that customers also want to see the room.

This article sets out the most important programmes as they stand in September 2026, describes the path to an application step by step and names the typical mistakes that can cost you the funding.

What kinds of funding exist

There are four kinds of funding, and they differ more in their logic than in their amount. A grant covers part of the eligible costs and is not repaid, but it requires an application before the project starts and a proof of use of funds (Verwendungsnachweis) at the end. A promotional loan runs through your own bank (Hausbank) and can include a grant component in higher tiers. The Forschungszulage is a tax-based incentive for research and development. Advisory services pay out no money but help you place a project.

An AI project is not eligible merely because of the keyword AI, but when it fits the purpose of a programme: research and development, digitalisation of processes and products, or external consulting. When researching, it helps to know that the Federal Ministry for Economic Affairs now operates as BMWE (formerly BMWK) and the research ministry as BMFTR.

Federal programmes at a glance

At federal level, five instruments are particularly relevant for AI projects in 2026, with very different status.

• ZIM (Zentrales Innovationsprogramm Mittelstand, the central innovation programme for SMEs). The BMWE funds research and development projects of SMEs, alone or with research institutions, as well as innovation networks and feasibility studies. Since 7 July 2026 a temporary application stop has applied: ZIM is currently not accepting new applications, reopening is targeted for early 2027 and depends on the 2027 budget. Applications already submitted will still be decided.
• KMU-innovativ. The BMFTR funds high-risk research and development projects in key technologies, including information and communication technologies. The procedure has two stages: first a project outline, then the application. The deadlines are 15 April and 15 October, the next being 15 October 2026 (as of September 2026). KMU-innovativ programme page.
• Forschungszulage (research allowance). Every company taxable in Germany can claim it, regardless of size and sector. First the BSFZ certifies that the work is research and development, then the allowance is claimed from the tax office after the end of the financial year, including for projects already carried out. For 2026 it was extended through the Investitionssofortprogramm (immediate investment programme). Forschungszulage certification body.
• ERP-Förderkredit Digitalisierung (511, 512). Through your own bank, KfW finances digitalisation in three tiers, from IT, software and cloud through process digitalisation, IT security and training to larger projects, explicitly including the use of AI on company data. The application must be submitted before the project starts, and the first tier requires a KfW Digitalisierungs-Check beforehand. KfW product page.
• Mittelstand-Digital Zentren. The BMWE funds free, vendor-neutral support on digitalisation, AI and IT security, with AI trainers in the centres. No money is paid out. The existing network is being phased out by the end of 2026, and from 1 January 2027 a new network follows with an additional focus on IT security, still free of charge for SMEs. Mittelstand-Digital.

For consortia of science and industry, the BMFTR guideline on AI flagship projects in value chains is also open, with a deadline for project outlines on 1 November 2026 (as of September 2026).

Funding at EU level

At EU level, four routes are open to AI projects: the European Digital Innovation Hubs, the EIC Accelerator, cascade funding and the Digital Europe Programme.

• European Digital Innovation Hubs (EDIH). Regional consortia offer free or subsidised services such as "test before invest", training and support in finding investment, with focus areas such as AI and cyber security. European Commission overview.
• EIC Accelerator. The European Innovation Council supports individual start-ups and SMEs with breakthrough innovations close to market, as a grant, an equity investment or both. Short proposals can be submitted at any time, and the next cut-off for full proposals is 4 November 2026 (as of September 2026). EIC Accelerator.
• Cascade funding. EU-funded project consortia pass part of their budget on to start-ups and SMEs through open calls, as lump sums, prizes or vouchers with simplified procedures, for example for small experiments and pilot projects. The calls stay open for at least two months on the EU Funding & Tenders Portal. Commission guidance (PDF).
• Digital Europe Programme. The Commission issues calls for AI, supercomputing, cyber security and digital skills. SMEs mostly benefit indirectly, for instance via the EDIHs. Programme page.

State programmes in Rhineland-Palatinate

In Rhineland-Palatinate, state funding is awarded by ISB, and four programmes are particularly relevant for AI projects.

• InnoTop. Technology-neutral funding for feasibility studies and research and development projects for new or improved products, processes and services, for SMEs and SmallMidCaps.
• Innovationsgutschein (FuE-Auftrag). An innovation voucher: a grant for SMEs that contract research and development of up to twelve months to a university or research institute.
• IBI-EFRE. A grant for investments with which commercial SMEs implement digitalisation in production and business models. Some sectors are excluded, a minimum investment volume applies, and the application is filed through the ISB portal before the project starts. Entry in the Förderdatenbank.
• Betriebsberatungsprogramm RLP. A grant towards external consulting, explicitly including digitalisation and artificial intelligence. Applications have been possible since 16 December 2025, and some topics require a recommendation from the chamber. The programme replaces the BITT technology consulting scheme, which ended in late 2025. ISB programme page.

The overview of innovation and digitalisation programmes is on isb.rlp.de. In the EU catalogue for Germany, no EDIH headquartered in Rhineland-Palatinate could be found (as of September 2026). Nearby options are EDIH Saarland, which also serves the Greater Region, and the Mittelstand-Digital Zentrum Kaiserslautern, which supports companies from Rhineland-Palatinate on AI readiness.

State programmes in North Rhine-Westphalia

In North Rhine-Westphalia, Mittelstand Innovativ & Digital (MID) is the central route for SMEs based in the state, and since 1 January 2026 NRW.BANK has been approving new projects.

• MID-Digitalisierung. A grant for developing market-oriented digital products with key technologies, explicitly including AI, machine learning and data mining. NRW.BANK product page.
• MID-Digitale Sicherheit. A grant for IT status analyses including penetration tests, staff training and basic IT protection measures. NRW funding portal.

Both programmes allocate application slots through a monthly lottery. Companies that are drawn have 28 days to apply, and being drawn is not yet a funding commitment. The 2026 call for MID-Digitale Prozesse, which funds external consulting, has already closed because the maximum number of applications was reached (as of September 2026). North Rhine-Westphalia also has three EDIHs: in Dortmund, in the Rhineland based in Aachen, and in South Westphalia.

Other federal states and expired programmes

For all other federal states, the federal Förderdatenbank (funding database) is the fastest way to suitable programmes. Every state has its own programmes, and the Förderdatenbank lists federal, state and EU funding, filterable by region, eligible applicants and type of funding. The page of the respective funding body remains authoritative, because calls open and close during the year.

Two federal programmes that people still often search for have expired: Digital Jetzt no longer accepts applications, and go-digital was ended in late 2024. The name ERP-Digitalisierungs- und Innovationskredit is also outdated, KfW's current product is the ERP-Förderkredit Digitalisierung.

Step by step to the application

With almost every programme, the path to the application follows the same ten steps, even though forms and portals differ.

1. Check your SME status. Under EU Recommendation 2003/361, an SME has fewer than 250 employees and stays within the thresholds for annual turnover or balance sheet total. Partner and linked enterprises may count. The Forschungszulage and the ERP-Förderkredit Digitalisierung are also open to larger companies. EU SME definition.
2. Use free orientation. A Mittelstand-Digital Zentrum, an EDIH or the federal funding advisory service can help you place the project before effort goes into an application.
3. Check the programme and its status. Is the programme open, is there a deadline, a lottery or an application stop?
4. Do not start before approval. An early start of the measure (vorzeitiger Maßnahmenbeginn), meaning a start before the grant decision has been received, is generally not permitted unless the guideline or a written consent allows it. This also applies to binding orders placed with service providers. With KfW, the application must be submitted before the project starts.
5. Add up de minimis aid. Where a programme grants de minimis aid, a ceiling of 300,000 euros per undertaking within three years applies. In the application you declare what you have already received in that period. Since 1 January 2026 a central register has been mandatory for this. Regulation (EU) 2023/2831.
6. Write the project outline. In two-stage procedures, the process starts with a short outline that must be understandable without follow-up questions and competes with other outlines. Projects are handled by Projektträger (project management agencies) such as DLR, PtJ or VDI/VDE-IT, which act on behalf of the ministry. Basics of project funding.
7. Submit the application. Federal research applications usually go through easy-Online, KfW loans through your own bank, state programmes through the ISB or NRW.BANK portals. Typical documents are a project description with work plan, a cost and financing plan, creditworthiness documents, the SME declaration, where applicable the de minimis declaration, and quotes from suppliers.
8. Secure your own contribution. Grants cover only part of the costs, and the company finances the rest itself.
9. Check cumulation. Funding can be combined, but only within the permitted aid intensities, and the same costs may never be funded twice. The usual approach is to split by cost item, for example free advice, a loan for the investment and the Forschungszulage for the development share.
10. Report and provide the proof of use. During the project you report to the Projektträger, and at the end comes the Verwendungsnachweis, consisting of a numerical statement and a technical final report. DLR Projektträger FAQ.

Typical mistakes

The typical mistakes are formal ones and can be avoided before you apply.

• Commissioning too early. Signing supply or consulting contracts bindingly before approval, or depending on the programme even before applying, can cost you eligibility.
• Overestimating SME status. The subsidiary of a larger group may not be an SME, even if it is small itself.
• Not checking the status. Programmes also close mid-year, as the ZIM application stop and the full MID-Digitale Prozesse call for 2026 show.
• Misreading the lottery. With MID, being drawn is not a commitment, and the deadline afterwards is short.
• Missing the programme's purpose. A consulting programme does not fund software licences, and a Mittelstand-Digital Zentrum pays out no money.
• Missing the deadline. With KMU-innovativ, a missed deadline means waiting half a year.
• Miscalculating de minimis. The three-year period is rolling and not tied to calendar years.
• Confusing names. EDIH Rheinland is based in Aachen and is not a point of contact for Rhineland-Palatinate. Older blog posts also mention programmes and product names that no longer exist.

Which programme fits which AI project

Which programme fits follows from the nature of the project: research, adoption or consulting.

An AI project is research-oriented if it carries technical risk, for instance a new method or a model for a question whose outcome is not known in advance. This is what the Forschungszulage, KMU-innovativ, InnoTop and the Innovationsgutschein are intended for, ZIM once it reopens, and the EIC Accelerator for breakthrough projects close to market.

It is about adoption when proven technology comes into your own operations, for example search across your own documents or the automation of a process. Suitable here are the ERP-Förderkredit Digitalisierung, IBI-EFRE in Rhineland-Palatinate and MID-Digitalisierung in North Rhine-Westphalia if a digital product results. Open cascade funding calls can support small pilot projects.

Consulting comes first when it is still open whether a use case will hold. The Mittelstand-Digital Zentren and the EDIHs are free, and external consulting in Rhineland-Palatinate is subsidised through the Betriebsberatungsprogramm. For IT security around an AI project, North Rhine-Westphalia offers MID-Digitale Sicherheit.

This article is general information, not legal or tax advice, and funding conditions change.

An AI project should be scoped before the funding question is asked, more on this under AI readiness.

What Slush is

Slush is a conference for start-ups and investors in Helsinki that began in 2008 as a gathering of 250 people. It is not-for-profit, owned by the Finnish Startup Foundation and organised by students and recent graduates together with a large team of volunteers.

The event takes place on 18 and 19 November 2026 at the Helsinki Expo and Convention Centre (Messukeskus), with a Day 0 programme on 17 November. According to the organiser, more than 12,000 people attend, around three quarters of them start-ups or investors. The focus is on curated European start-ups, international investors and tech media, and Slush explicitly names the DACH region as a core region. Programme and details are on the official Slush website.

What iiterate brings

iiterate brings to Helsinki the work we do every day: AI for environments in which data should not leave the company. We are an AI consultancy from Adenau in Rhineland-Palatinate and are travelling as part of the German delegation. Our focus areas:

• On-premise LLM. Language models that run on your own infrastructure.
• RAG and knowledge management. Retrieval systems that derive answers from a company's documents and cite the sources.
• AI with EU data residency. Architectures in which processing and storage remain within the European Union.
• Computational design. Parametric models and configurators in which rules generate the geometry.

In conversations we focus on concrete questions: which data a project touches, where processing may take place and which architecture follows from that.

Who should talk to us

Above all, investors, companies and founders who deal with AI and sensitive data should talk to us.

• Investors who assess AI projects in regulated or data-sensitive industries.
• Companies that want to use AI on confidential documents and need data residency in the EU or on their own premises to do so.
• Founders who work on AI with sensitive data and would like to talk about architecture, operations or collaboration.

A project that has not yet been fully thought through is no obstacle, but a good starting point for a conversation.

Arranging a meeting in Helsinki

The best way to arrange a meeting in Helsinki is in advance through our contact page. Briefly mention your topic and the days you will be on site. Conversations can be held in German or English.

The specification, without the marketing

Before discussing consequences, the plain table helps. All values come from Anthropic's model overview and pricing page, retrieved on 10 September 2026.

What Anthropic adds in its own model overview is notable: Claude Opus 5 is recommended as the default for most workloads, and Fable 5.1 is intended for cases where Opus 5 at a higher effort level falls short. That is an unusually clear act of self-limitation, and it is also the first filter for any architecture decision. Fable 5.1 is not a blanket upgrade but a tool for long, connected tasks.

The modality is narrow, and that matters in practice. Text and images go in, text comes out. No audio in, no audio out, no image or video generation. If you want to process a call recording, you need transcription in front of it. If you need spoken answers, you need speech synthesis behind it. If you want to generate graphics, you need a different model. This sounds trivial, but it moves system boundaries, cost and data protection questions to exactly the places where those additional components sit.

What a million tokens changes, and what it does not

The window is billed at standard per-token rates over its whole length; there is no long-context surcharge (Anthropic). That makes designs possible that previously failed not on the model but on the splitting: a complete set of contracts or tender documents in one pass rather than thirty fragments with a merge afterwards; a full agent trace including every tool output that is still analysable rather than truncated after twenty steps; a mid-sized repository over which a question is answered in one go rather than through a search that has to guess in advance which files matter. The gain lies less in intelligence than in the disappearance of a whole class of glue work, and in our projects that glue work was reliably the source of the hard-to-find errors.

The number is not a page count, though. Anthropic puts 1,000,000 tokens at roughly 555,000 English words on the current tokenizer, and notes in the same breath that this tokenizer produces roughly 30 percent more tokens for the same text than its predecessor (Anthropic). That figure refers to English text; no number for a German-language corpus can be derived from it, it has to be measured. Anyone planning capacity counts their own documents with the tokenizer of the model they actually use, and does not calculate in pages.

For the same reason, comparing window sizes across vendors says nothing. A token is a vendor-specific unit, and no published conversion maps two tokenizers onto the same quantity of text. A number on a spec sheet therefore tells you nothing about which model holds more of your text.

And the larger window does not make retrieval unnecessary. The reasoning is plain: everything in the window is paid for on every call and has to be processed on every call. A method that finds the twenty relevant paragraphs stays faster, cheaper and usually more precise than one that drops in ten thousand paragraphs and hopes for attention. The large window moves the threshold at which splitting becomes necessary a long way up. It does not replace the question of which information is needed for this particular answer.

The real engineering story is the cache read

The most interesting number in the specification is not an absolute value but a ratio. Fresh input costs USD 10 per million tokens, a cache hit USD 0.25. Writing to the cache costs USD 12.50 per million tokens at the five-minute tier and USD 20 at the one-hour tier. On Fable 5.1 and Mythos 5.1 the read price sits at 0.025 times the base price, against 0.1 times on every other Claude model, and according to Anthropic that is the only pricing change versus Fable 5 (Anthropic).

The factor of 40 between fresh input and a cache hit is what decides designs. In an agent loop the same system prompt, the same tool definitions and the same project context are read again at every single step. A task spanning two hundred tool calls reads the same preamble two hundred times. Whether that preamble is billed as fresh input each time or as a cache hit is not an accounting detail but the line between a design you can put into production and one you leave in the demo.

This is precisely why Anthropic's own phrasing, that typical workloads are around 25 percent cheaper and heavily agentic ones up to around 45 percent, is an estimate about cache hit rates rather than a price cut (Anthropic). The headline input and output prices are unchanged from Fable 5. A workload with poor cache locality sees almost none of that saving, and putting the 25 percent into a budget without the qualifier produces a hope rather than a budget.

What makes hit rates good or bad in practice is not a documented metric but engineering logic, and it can be named:

• A stable prefix. What gets reused is the unchanged beginning of the request. Everything constant belongs at the front, everything variable at the back. A timestamp, a session ID or a user name in the wrong place invalidates all the context that follows it.
• Deterministic assembly. Tool lists in random order, retrieval hits in shifting sort order, or objects with unstable key order produce a new prefix on every run. The cache then never sees the same thing twice.
• Lifetime against the rhythm of the task. Five minutes fits a tightly clocked agent loop. It does not fit a dialogue in which a person spends twenty minutes in a meeting between two questions. The one-hour tier costs more to write and only pays off once it actually rescues the hit.
• Enough repetition per prefix. Many short, mutually unrelated requests spread across many prefixes. Each pays for a write and rarely gets a read. That is the case where cache economics work against you, and then the Batch API at 50 percent off in both directions is often the better route.

One concrete pointer from the price list supports the same point: the computer use toolset adds roughly 4,500 input tokens per request, the browser use toolset roughly 6,600 (Anthropic). That is a constant block incurred again at every step, and therefore exactly the material that belongs in a stable prefix.

Agentic operation, tools and the question of the effort level

Fable 5.1 is built for long runs. Anthropic cites one unattended 38-hour run on a machine learning problem as evidence (Anthropic). That is a vendor statement about a single run rather than a distribution result, but it works as an order of magnitude for what the model was designed towards.

Thinking mode is adaptive and always on; the earlier manual mode with an explicit thinking budget is no longer accepted. Versus Fable 5 there are three breaking changes that touch every existing integration: forced tool use returns an error, earlier models cannot read this model's thinking blocks, and editing earlier turns invalidates the thinking blocks. Additions include per-message effort, turn-scoped system messages, readable progress updates between tool calls and the lower cache read price; several of these are marked as beta (Anthropic). For planning, that means a switch to this model is not a configuration change but a small rebuild followed by a test.

Effort levels call for care. The documentation names high as the default (Anthropic), and the announcement specifies that the default differs by surface: high in Claude Code, medium in Claude Cowork and on claude.ai (Anthropic). The full set of accepted values is not listed on the documentation pages we consulted, so we do not assert it.

The practical consequence is inconvenient but important: a benchmark number or a cost estimate without a stated effort level is not reproducible. Two teams measuring the same model through two different surfaces are measuring different configurations. Anyone who wants proposals, test results or internal comparisons to hold up notes the level alongside the number, in the same way one would not let a measurement pass without its unit.

A June 2026 knowledge cutoff is an architecture requirement

The knowledge and training data cutoff is June 2026 (Anthropic). Operationally this means nothing dramatic and quite a lot at the same time. Your price list from last week, yesterday's decision, the state of your order book this morning: none of it is in the model. It has to reach the context through retrieval, through a tool connection or through the prompt.

That is not a flaw in the model but a requirement on the architecture, and it is vendor independent. Any system meant to answer about current facts without a defined path along which those facts arrive is mis-specified, however good the model is. Two consequences have served us well. First, every fact-based answer needs a nameable source in the context rather than the model's memory. Second, every evaluation set needs a few questions whose correct answer changed after the cutoff: they test exactly the path that is most likely to break silently in production.

The Article 50 watermark is not an audit trail

Fable 5.1 and Mythos 5.1 carry an invisible text watermark from launch (Anthropic). Anthropic applies the marking worldwide and not only in the EU (Euronews). The background is the transparency obligation in Article 50 of the AI Act, which has applied since 2 August 2026 and requires machine-readable marking of synthetic content.

The decisive part is the caveat Anthropic itself adds. A detected watermark indicates that content may have been processed by Claude, is explicitly not fully conclusive, and does not on its own confirm the provenance of the content (Anthropic Help Center). On top of that, the detection interface is open only to a restricted group in a private preview (MacRumors).

For a company that wants to document its own use of AI, a sober design consequence follows, and this is a technical assessment rather than legal advice: the watermark is a signal inside the output that is not yours, that you generally cannot read yourself, and whose evidential weight the vendor itself limits. It is therefore not an audit trail. If it has to be traceable which model produced which output from which input at what time, and who released it, that record is created in your own logs. Technically this is unspectacular, because they are the same logs you keep anyway for debugging and cost control.

The constraint that decides architecture in Germany

In German projects, data handling decides whether a model can be used more often than capability does. Here the position is clearly documented and surprising to many. Anthropic classifies Fable 5.1 as a Covered Model. These models require 30-day data retention and are not available under zero data retention unless Anthropic expressly authorises it. An organisation running under zero data retention has to switch retention on deliberately for a specific workspace, otherwise requests are rejected with an error (Anthropic).

Two additions from the same source belong here, because the picture is skewed without them. Retained data, Anthropic states, is not used for model training without express permission. And even under zero data retention, flagged content may be retained for up to two years. Zero data retention also does not cover every route into the system, among them not the Batch API and the Files API.

Then there is the region question. On the first-party API there is no EU inference region. The inference geo parameter accepts exactly two values, global and us, and storage is US-only; a workspace's geo cannot be changed after creation (Anthropic). The workable route inside the EU runs through a partner cloud: Amazon Bedrock and Google Cloud offer regional endpoints with guaranteed data routing, at a 10 percent premium over the global endpoints, and set their own lifecycle dates (Anthropic).

This is a design input, not a verdict on the model. Three routes remain in practice, and the choice is made before the first prototype rather than after it. First: a regional endpoint at a partner cloud, with the premium and with the cloud provider as processor. Second: the first-party API with retention deliberately enabled, for data classes where that is defensible. Third: the data class in question never reaches this model at all, because another model or a local deployment takes over the part that sees the sensitive fields. The third route is examined too rarely, although in knowledge and document systems it is often the cleanest.

What changes, and what this model does not touch

Named honestly, a manageable but valuable set of task classes changes. Analyses across bodies of material that previously failed on the splitting become feasible in one pass. Agent runs that used to fall apart at the context boundary stay connected. And designs that have to re-read the same foundation very often become economical thanks to the cache read price, provided the assembly delivers the hit rate. Those are three real shifts, and they touch exactly the work that otherwise arrives in a consultancy as legwork.

Named just as honestly is what stays the same. The model's own capabilities are bounded too: penetration testing, exploit generation, binary-based scanning and biology research tasks are redirected to the Opus models, and fast mode is not available on Fable 5.1 (Anthropic, Anthropic).

More important, though, are the problems no model touches. Data quality remains your job: a larger window only reads contradictory master data more thoroughly. Process definition remains your job: an agent that does not know when a matter is settled merely reproduces the ambiguity that was already in the team. Access control remains your job: a model allowed to see everything is a data protection problem with a gift for language. Evaluation remains your job, because without a set of cases with known correct answers nobody can say whether a switch improved anything. And the cost of being wrong stays where it was: on a suggestion list an error is annoying, on an outgoing invoice it is expensive. That distinction decides the degree of automation, and it is a business question.

Our position on this is undramatic: Fable 5.1 moves the boundary of what a design can carry, and it moves it at a point that genuinely used to slow things down. It moves none of the questions that have to be answered before that. Which of those questions is still open in your next undertaking?

This piece reads the release the way a company deciding whether to build on it should read it: which specifications actually matter, what is real about the pricing structure and what is a modelled estimate, what breaks at the interface, and why the European route to this model runs through a partner cloud rather than through Anthropic itself.

What was actually released on 1 September

Anthropic released Claude Fable 5.1 on 1 September 2026, together with Claude Mythos 5.1. By Anthropic's own account the two are the same model with different safeguard levels: Fable 5.1 is generally available, Mythos 5.1 is invitation-only through trusted access programmes. Trade press confirms the date and availability on all platforms from launch day.

The model id is claude-fable-5-1, on Amazon Bedrock anthropic.claude-fable-5-1. It ships through the Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry and Claude Platform on AWS. Anthropic names Claude Code, Claude Enterprise and Claude Platform as surfaces, with different effort defaults: high in Claude Code, medium in Claude Cowork and on claude.ai. There is a retirement commitment: on Anthropic-operated platforms the model will not be switched off sooner than 1 September 2027, while Bedrock and Google Cloud set their own dates.

What Anthropic adds in the same documentation is worth noting. Fable 5.1 is described as being for demanding reasoning and long-horizon agentic work; as the default for most workloads Anthropic still explicitly recommends Claude Opus 5, with Fable 5.1 reserved for cases where Opus 5 at higher effort falls short. Anyone who has to justify the switch internally should know that sentence: the vendor itself does not recommend its new flagship across the board.

The specifications that carry a decision

The headline figures come from Anthropic's model documentation and matter more to an architecture decision than any leaderboard.

Two of these deserve more than a table row. First, the thinking mode: Fable 5.1 thinks adaptively and continuously, and the older manual mode with thinking.type: enabled and budget_tokens is no longer accepted. Anyone porting an existing integration has to touch that code.

Second, the context window. One million tokens correspond to roughly 555,000 English words according to Anthropic, measured on the current tokenizer introduced with Claude Opus 4.7. That same tokenizer produces roughly 30% more tokens for the same text than its predecessor. A context window figure is therefore not a capacity statement that can be compared casually across model generations, let alone across vendors. What matters for budgeting is how many tokens your own body of text actually produces, not the headline.

This piece deliberately keeps performance figures short, because they are the subject of a separate comparison. Only this much, and explicitly as vendor-reported numbers: Anthropic reports 52.6% for Fable 5.1 on Terminal-Bench-Science 0.1 against 24.7% for Fable 5, and 55.8% on Terminal-Bench 4.0 against 42.0%. The comparison column in Anthropic's own table is GPT-5.6 Sol. OpenAI's current flagship GPT-6 Astra shipped two days after this release and does not appear in Anthropic's figures at all.

The price: exactly one line changed

Anthropic's pricing documentation lists the following for Fable 5.1, in US dollars per million tokens.

Exactly one line is interesting. On Fable 5.1 and Mythos 5.1, cache reads are priced at 0.025x the input price, whereas every other Claude model uses a 0.1x multiplier. This is the sole pricing change versus Fable 5, whose cache read stood at 1.00 US dollars per million tokens. Input and output are unchanged. The full context window is billed at standard per-token rates; there is no long-context surcharge.

Anthropic puts the saving at approximately 25% versus Fable 5 for typical workloads, and up to approximately 45% for highly agentic work. That figure is important enough to read correctly: it is a modelled vendor estimate that comes entirely from the cache line, and it is not a price cut. If your requests rarely re-read the same context, you save nothing. If you run an agent loop that reads the same system prompt, the same codebase and the same tool definitions back a hundred times over, you save a great deal. The difference between those two cases is your cache hit rate, and only your own load profile knows it.

One more detail for the cost model: if inference is pinned to the United States via inference_geo: "us", a 1.1x multiplier applies to input, output, cache writes and cache reads.

Across the competitive field this cache line is the only real price difference at the frontier. OpenAI also lists 10 and 50 US dollars per million tokens for input and output on gpt-6-astra, but 1.00 US dollars for cached input. On cache reads Fable 5.1 therefore sits at a quarter of the price, which can be decisive in long agent loops. Everything else about that comparison, including which benchmark numbers are comparable at all, is covered in the separate piece.

What changes at the interface, and what breaks

As evidence of long-horizon autonomy Anthropic cites one unattended 38-hour run on a machine learning problem. Anyone planning to build on that should first read the list of API changes, because three of them break existing code.

Breaking changes versus Fable 5:

• Forced tool use returns an error.
• Earlier models cannot read Fable 5.1's thinking blocks.
• Editing earlier turns invalidates thinking blocks.

Additions:

• Per-message effort (beta).
• Turn-scoped system messages (beta).
• Readable progress updates between tool calls via display: "updates" (beta).
• The reduced cache read price.
• Content provenance marking.

Also relevant to agent architectures is the token overhead of the toolsets: computer_toolset_20260801 adds about 4,500 input tokens per request, browser_toolset_20260801 about 6,600. That is a base load incurred on every single request, and it belongs in every cost estimate. Fast mode, which exists as a research preview on Claude Opus 5 and Opus 4.8, is not available on Fable 5.1.

On the safety side, Anthropic reports that cybersecurity safeguards block 60% fewer false positives than before, and that biology safeguards fire 85% less often for benign requests related to elementary biology. At the same time whole classes of task remain excluded: penetration testing, exploit generation, binary-based scanning and biology research tasks are redirected to Opus models. Fable 5.1 can identify software vulnerabilities, while exploit generation stays restricted. New API accounts can also no longer manually edit prior context in multi-turn conversations; Anthropic states that this closes off a common, publicly documented distillation technique. For teams that rewrite conversation histories programmatically, that is a behavioural change with direct consequences for existing architectures.

Data residency: there is no EU region at Anthropic itself

This is where the engineering story parts company with the governance story. Anthropic's data residency documentation is unambiguous: the inference_geo parameter accepts exactly two values, global and us. Under current limitations it states in as many words that only those two are available. There is no EU inference region on Anthropic's first-party API.

The same holds for data at rest. A workspace geo is set when the workspace is created, cannot be changed afterwards, and the only available value is the US.

Two Anthropic sources appear to contradict each other here, and that deserves to be stated openly. The privacy help centre, last updated on 15 June 2026, says customer traffic may by default be routed to select countries in the US, Europe, Asia and Australia, and adds in the same text that data is stored in the US. The platform documentation, by contrast, knows only the two inference geos named above. The reconciliation lies in the distinction between routing and residency: global routing may transit Europe, but it is not a selectable guarantee that processing and storage take place in the EU. If you need such a guarantee, you will not find it here.

inference_geo itself is supported only from Claude 4.6 onwards; earlier models return a 400 error. It does not exist on Amazon Bedrock or Google Cloud, where the endpoint or inference profile determines the region. Microsoft Foundry instead offers a US Data Zone deployment type. The parameter is also unavailable through the OpenAI SDK compatibility endpoint.

The workable EU route therefore does not run through Anthropic but through a partner cloud. Bedrock and Google Cloud offer regional endpoints with guaranteed data routing, at a 10% premium over the global endpoints according to Anthropic's pricing documentation, and they set their own lifecycle dates. That also makes the widespread claim that Claude has EU data residency because it runs in Frankfurt half true and, in effect, misleading: Claude models can run in EU regions, but there the cloud provider is the data processor, not Anthropic. For the contractual construction that is precisely the difference.

Covered Model: 30 days of retention is a condition, not an option

The most inconvenient sentence in the whole documentation sits on Anthropic's page on API and data retention. It states of Claude Fable 5.1, Mythos 5.1, Fable 5 and Mythos 5 that these models require 30-day data retention and are not available under zero data retention unless expressly authorised by Anthropic. They are designated Covered Models.

In practice this means an organisation working under zero data retention today cannot simply switch Fable 5.1 on. It has to explicitly enable 30-day retention on a specific workspace, or the API answers with 400 invalid_request_error. That is not a configuration nicety but a decision that in many organisations has to pass data protection sign-off before the first line of integration code exists.

For completeness, Anthropic's commitments belong alongside it: retained data is, by its own statement, never used for model training without express permission, and conversation content is not retained by default outside the Covered Model exception.

Even organisations that already have zero data retention in place should know its boundaries, which are narrower than the name suggests.

• ZDR is enabled per organisation on request through sales and does not extend automatically to sibling organisations under the same account.
• It does not cover the Batch API, the Files API, code execution, Claude for Excel or the Claude Teams and Claude Enterprise product interfaces. Claude Code through Claude Enterprise with ZDR is the stated exception.
• CORS is unsupported for ZDR organisations.
• If a chat or session is flagged, Anthropic may retain inputs and outputs for up to two years, ZDR included.

The direction is therefore clear, and it runs against the pricing story. Fable 5.1 is cheaper in the agent loop than any other Claude model, and under strict EU data rules it is at the same time harder to adopt than the Claude models that are not on that list.

Article 50: a watermark from day one, with Anthropic's own caveat

According to Anthropic, Fable 5.1 and Mythos 5.1 carry an invisible text watermark from launch day. Article 50 of the EU AI Act, which requires machine-readable marking of synthetic content, has applied since 2 August 2026. Anthropic applies the mark worldwide and not only in the EU.

Anyone planning to build the watermark into a review process should know Anthropic's own caveat, and it is stated plainly in the help centre: a detected mark indicates that the content may have been processed by Claude, is "not fully conclusive", and does not on its own confirm the full provenance of the content. It is not proof in a legal sense, and the expectation of establishing authorship with it goes beyond what the vendor itself claims. That is a notable constellation: the marking is a genuine feature of the model, and its evidential weight is qualified by the same company that offers it.

Access is a further constraint. The detection API is in private preview and open only to eligible organisations; those named are regulators, law enforcement, media, fact-checkers, researchers, educational bodies and EU civil society. A company that wants to check incoming text for this mark itself currently cannot do so by that route.

The surrounding regulatory frame, as the publishing bodies describe it: enforcement for general-purpose AI models has likewise applied since 2 August 2026, with fines of up to 15 million euros or 3% of global annual turnover for non-compliant providers of such models, whether or not they signed the Code of Practice. The European Commission's Code of Practice binds signatories to a published transparency template, a systemic-risk assessment methodology and a copyright compliance framework, with documentation retained for at least ten years. These obligations fall on the model providers. What follows from them for your own organisation depends on your role in the supply chain and is a question for your legal advisers, not for a trade article.

What this means for a decision in Germany

Taken together the release produces an unusually clear picture, precisely because the two stories point in opposite directions. Technically, Fable 5.1 is the cheaper choice for long agent loops in which the same context is read over and over. In regulatory terms it is a model you cannot even start without 30-day retention.

Four questions should therefore be answered before integration begins.

1. What is your cache hit rate really? The entire saving hangs on that single metric. Measure it against a real load profile before you budget for 25%.
2. Can your data protection sign-off live with 30-day retention? If not, Fable 5.1 is not an option until Anthropic expressly authorises otherwise, and the question cannot be engineered around.
3. Which endpoint does inference run through? If processing in the EU is required, the route runs via Bedrock or Google Cloud, at a 10% premium over the global endpoints, with the cloud provider as data processor and with its own lifecycle dates.
4. Is Opus 5 enough? Anthropic itself recommends Opus 5 as the default, and Opus 5 is not on the list of Covered Models. Part of the governance question described here does not arise there in this form.

None of this is an argument against Anthropic. Fable 5.1 is a strong model, the cache change is a real improvement for agentic work, and the fact that the inconvenient facts are cleanly readable in Anthropic's own documentation speaks for the vendor rather than against it. It is an argument for reversing the order: first settle the conditions under which your data may be processed, then choose the model. What Fable 5.1 actually delivers in daily work is covered in a separate piece on capabilities in practice; how it stands against GPT-6 Astra, in another.

The table almost everyone is publishing is broken

The most common sentence in current coverage runs roughly like this: Anthropic's own benchmarks show Claude Fable 5.1 ahead of GPT-6 Astra. That sentence is false, and a calendar disproves it.

Anthropic published its benchmark table on 1 September 2026. The comparison column in it is labelled GPT-5.6 Sol. GPT-6 Astra went into limited preview on 3 September and into general availability on 4 September. Anthropic therefore did not merely fail to measure Astra, it could not have measured it: the model was not public at the time of publication.

Anyone reading the Terminal-Bench 4.0 row, where 55.8% for Fable 5.1 stands against 37.3%, and taking that 37.3% for Astra is comparing Anthropic's current model with the competitor's predecessor. That is not a rounding error, it is a different claim. And it is precisely the misreading now spreading fastest through aggregators and summaries.

The value of this piece therefore lies less in the numbers than in the sorting: which comparisons hold, which do not, and how to tell the difference.

What genuinely compares like for like

A small but clean core remains. Every row in the table below comes from the Anthropic model documentation, the Anthropic pricing page and the OpenAI developer documentation for gpt-6-astra, retrieved on 10 September 2026. These are each vendor's statements about its own product, in the same unit, with no measurement frame in between.

One caveat belongs on the cache write row: Anthropic sells two hold durations, five minutes and one hour, while OpenAI publishes no equivalent tier. The two USD 12.50 figures sit close together but not perfectly parallel.

The economically interesting row is the cache read. A factor of four in Anthropic's favour sounds like a minor line item, but in agentic work it is not: there the same context, repository, system instruction and tool descriptions, is read again and again across hundreds of steps. Anthropic itself puts the resulting saving at roughly 25% against Fable 5 for typical workloads and up to roughly 45% for highly agentic work. That figure is a vendor model calculation, not a price cut: the headline input and output prices are unchanged, and a workload with few cache hits saves close to nothing.

Two further items belong in any calculation. Anthropic's Batch API halves both directions, to USD 5 input and USD 25 output per MTok. And pinning inference to the United States on Anthropic's side applies, according to Anthropic's data residency documentation, a 1.1x multiplier across input, output, cache writes and cache reads.

Terminal-Bench 4.0: the one figure with a real cross-check

One benchmark row in this comparison deserves particular confidence, for a reason that is rarely explained.

On 1 September 2026 Anthropic reports Claude Fable 5.1 on Terminal-Bench 4.0 at 55.8%. In the results OpenAI reports for GPT-6 Astra, relayed by DataCamp on 3 September 2026 and explicitly labelled there as vendor-reported, Astra stands at 57.7% and Fable 5.1 is carried at an unchanged 55.8%.

Both vendors therefore arrive independently at the same number for the other camp's model. That is the strongest single check available anywhere in this comparison. A vendor has little incentive to rate a competitor too highly, and when two parties with opposing interests report the same figure, it suggests the figure survives the setup rather than being a house measurement.

Two limits remain nonetheless. First, neither publication states which harness, which scaffold and which effort level were used. Second, the gap of 1.9 percentage points is small enough that it could come from exactly those factors. The defensible reading is therefore: on Terminal-Bench 4.0 the two models sit close together according to both vendors, with a slight lead for Astra on OpenAI's measurement.

What does not compare, and why

The larger part of the published numbers does not belong in a shared table. This is not formalism, it is the difference between a basis for a decision and a wall of figures.

• OSWorld 2.0. Anthropic reports two figures for Fable 5.1, 77.9% with partial credit and 41.7% under strict scoring. On the OpenAI side there is a single figure for Astra of 72.6%, with no stated scoring mode. Setting 72.6 against 77.9 is as unfounded as setting it against 41.7. Until the scoring mode matches, there is no comparison here, only a selection.
• Context window. Anthropic states 1,000,000 tokens, OpenAI 1,050,000 with a maximum input of 922,000 tokens. These are not capacity figures on the same scale, because a token means something different per tokenizer. Anthropic states itself that its current tokenizer produces roughly 30% more tokens for the same text than its own previous one. No cross-vendor tokens-per-word figure is publicly available, so the question of which model holds more text cannot be answered from open sources.
• AutomationBench. Anthropic publishes 31.4% for Fable 5.1. In its own announcement post OpenAI claims the top spot on the same benchmark but states no number there. There is simply nothing to compare.
• Rows where the Claude figure does not come from Anthropic. For ScreenSpot-Pro, FrontierMath Tier 4 v2, ExploitBench, ARC-AGI-3, GPQA Diamond and FrontierCode 1.1 only OpenAI-side figures exist. The Claude number in those rows is OpenAI's measurement of Claude, and in several cases a measurement of Claude Fable 5 or Claude Opus 5 rather than Fable 5.1. Attributing them to Anthropic cites the wrong source and, in part, the wrong model.
• Effort levels. Both vendors allow varying compute per request. At Anthropic even the default differs by surface: high in Claude Code, medium in claude.ai and Claude Cowork. Artificial Analysis measures at the "max" and "xhigh" settings. A benchmark number without a stated effort level is not comparable to one at a different setting. This is not a nicety, it is the most likely reason the same leaderboard shows three different results on three different websites.

One special case deserves a warning: the 99.9% circulating for Astra on ARC-AGI-3 carries an "adapter harness" qualifier in the source and sits beside 7.8% for the previous model. A swing of roughly 92 points across a harness change describes the harness first and the model second. That figure belongs in no headline.

The third-party leaderboards contradict each other outright

Anyone distrusting the vendor figures turns to third-party leaderboards. In this case that does not help, because the leaderboards disagree with one another, on one and the same index.

Artificial Analysis, in its own article of 3 September 2026, gives for the Intelligence Index: GPT-6 Astra 61, GPT-5.6 Sol 61, Claude Fable 5.1 66, the last at maximum effort with a fallback configuration that is not the API default. BenchLM reports the same index differently in September 2026: GPT-5.6 Sol leads at 58.9%, with Fable 5.1 at 53.7%. llm-stats, retrieved on 10 September 2026, reports Fable 5.1 at 56.8, Astra at 54.7 and Claude Opus 5 at 54.1.

Three sources, one index, three orderings. They cannot all be current. Plausible causes are different snapshot dates, different effort settings, and points being mixed with percentages. The practical consequence is simple: an Intelligence Index figure without the site, the date and the effort setting is not information. Artificial Analysis itself, incidentally, flags mixed findings, among them a drop of roughly 80 Elo points on GDPval-AA v2.

That leaves the arena. There is nothing to be had there either: neither Claude Fable 5.1 nor GPT-6 Astra holds a ranked LMArena position in the September 2026 snapshots reachable here, because arena Elo needs vote volume and lags frontier releases by weeks. Even if the figures existed, they would be the wrong instrument for this decision. Blind pairwise preference measures perceived answer quality on self-selected prompts, reacts strongly to formatting and verbosity, and says little about agentic work over long horizons. For a coding agent or a knowledge-work platform, that is not the yardstick a purchase should follow.

FrontierCode 1.1: the number that cuts against the vendor reporting it

There is one row in this comparison that carries more weight than the others, for a methodological reason. On FrontierCode 1.1, GPT-6 Astra stands according to OpenAI's own reported results at 53.3%, behind Claude Fable 5 at 53.5%.

Two clarifications are obligatory here. The comparison figure is for Claude Fable 5, not Fable 5.1, and Anthropic has published no figure of its own for Fable 5.1 on this benchmark. The gap is 0.2 percentage points, well inside any plausible measurement spread.

Even so, it is the most trustworthy kind of number a product announcement can contain. A vendor publishing a row in which its new flagship trails a rival model has no marketing incentive to do so. Anyone assessing how load-bearing a benchmark table is should look first for whether rows like this appear in it at all. A table in which the publishing vendor wins every single row is not a measurement, it is a selection.

The direction reverses: EU data residency and zero data retention

Up to this point Anthropic leads on price and cache economics and is roughly level on the benchmarks. On data governance the picture reverses completely, and for a German company that is the column that changes an architecture.

On the Anthropic side this is in the vendor's own documentation. The inference_geo parameter accepts exactly two values, global and us, and the only selectable workspace storage geo is us, fixed once the workspace is created. The retention side is more explicit still: Anthropic designates Fable 5.1 and Mythos 5.1 (as well as Fable 5 and Mythos 5) as Covered Models that require 30-day data retention and are not available under zero data retention unless expressly authorised by Anthropic. An organisation on ZDR has to switch 30-day retention on for a specific workspace, or the request is rejected.

On the OpenAI side, the developer documentation on data handling states that Europe (EEA and Switzerland) supports both regional storage and regional processing via eu.api.openai.com, configured per Project, with non-US regions requiring approval for abuse-monitoring controls and a modified retention amendment. The same page lists the ZDR-eligible endpoints, among them /v1/chat/completions and /v1/responses, and explicitly excludes Assistants, Threads, Vector Stores, fine-tuning and Batches.

Precision matters more here than a smooth statement: no source found states positively that GPT-6 Astra is ZDR-eligible. What is documented is that those endpoints support ZDR and that no model-specific exclusion is published for gpt-6-astra. The absence of a restriction, however, is not a permission. Anyone building an architecture on it should have it confirmed contractually rather than inferring it from a documentation gap. At Anthropic the position is unambiguous in the other direction, because the exclusion is written down.

One widely repeated line also needs correcting: "Claude has EU data residency because it runs on AWS Frankfurt." That is true precisely when you obtain Claude through a partner cloud such as Amazon Bedrock or Google Cloud, where the cloud provider sets the region and is the data processor. It does not hold for Anthropic's own API. For guaranteed regional routing Anthropic points to the partner clouds' regional endpoints itself, at a 10% premium over the global endpoints. For a GDPR review that distinction is the whole point, because it determines who the data processing agreement is signed with.

Article 50: a difference that can only be half evidenced

Since 2 August 2026 the transparency obligations of Article 50 of the AI Act have applied, requiring machine-readable marking of synthetic content. Anthropic states that Fable 5.1 and Mythos 5.1 carry an invisible text watermark from day one, and applies that marking worldwide rather than only in the EU. As far as the available sources reach, that is a genuine difference.

The sentence needs both halves, though. No source was found stating whether GPT-6 Astra's text output is marked. OpenAI's documented provenance approach, C2PA Content Credentials plus SynthID, covers images and audio; the reachable pages say nothing about text. That gap does not mean OpenAI fails to mark text. We therefore do not claim it. OpenAI separately publishes customer guidance on the AI Act.

And Anthropic's watermark carries less than the term suggests. Anthropic writes in its own help pages that a detected mark indicates content may have been processed by Claude, is not fully conclusive, and does not on its own confirm the provenance of the content. The corresponding detection API is moreover in private preview for selected organisations. As one building block of a compliance argument the watermark is usable; as evidence it is not.

What this means for a German decision

If you take one rule from this comparison, take this one: with two frontier models sitting close together on the defensible figures and priced identically at the headline, a benchmark row rarely decides anything. The gap on Terminal-Bench 4.0 is 1.9 percentage points with no stated harness. On FrontierCode 1.1 it is 0.2 points the other way, against an older Claude model. Gaps like that shift with the next release, and they change no architecture.

What does change an architecture sits in the governance column. An organisation bound to zero data retention cannot use Claude Fable 5.1 through Anthropic's own API without express authorisation, however good the model is. An organisation requiring inference inside the EU finds that route at Anthropic only through a partner cloud, with the corresponding premium and a different data processor in the contract. Conversely, Anthropic's cache-read advantage is real and grows with the share of agentic work in which the same context is read hundreds of times.

In practice: settle the obligations first, the costs second and the benchmarks last. In the reverse order you build a system that measures well and fails the data protection conversation. And for every number someone shows you, check three things: who reported it, when, and at which effort level.

What the release itself changed for a German company is covered in our piece on Claude Fable 5.1. How the model behaves in live project work is covered in capabilities in practice. And if the answer to the governance question is that the data must not leave the building at all, the route runs through the on-premise versus cloud trade-off rather than through a leaderboard.

Die Ursache ist fast immer die Datenstruktur: die Bäume, mit denen parametrische Umgebungen Listen von Listen verwalten. Etwa alle Fenster je Geschoss je Fassade. Wer diese Ebenen einmal falsch zusammenführt, bekommt kein Fehlerbild, sondern ein anderes Bauwerk.

Warum der Fehler nicht auffällt

Weil die Ausgabe plausibel ist. Wenn 120 Paneele erwartet werden und 120 Paneele entstehen, ist die erste Prüfung bestanden. Dass Paneel 47 die Maße von Position 74 trägt, sieht man an einer Fassade mit ähnlichen Elementen nicht.

Verstärkt wird das dadurch, dass parametrische Umgebungen selten hart abbrechen. Sie gleichen Listen unterschiedlicher Länge stillschweigend an, indem sie den letzten Wert wiederholen. Das ist im Alltag bequem und in genau diesem Fall fatal: die Struktur bleibt heil, der Inhalt nicht.

Die drei Muster, die fast alle Fälle erklären

Erstens der Ebenenversatz. Zwei Datenströme werden zusammengeführt, die auf unterschiedlichen Ebenen verzweigt sind. Einer trägt die Struktur Fassade zu Geschoss zu Öffnung, der andere nur Fassade zu Öffnung. Das Ergebnis hat die richtige Anzahl und die falsche Zuordnung.

Zweitens das ungewollte Abflachen. Ein Arbeitsschritt, der die Baumstruktur einebnet, um eine Operation zu ermöglichen, und danach wird nie wieder verzweigt. Ab dieser Stelle weiß das Modell nicht mehr, welches Element zu welchem Geschoss gehört, und es sagt es nicht.

Drittens die Wiederholung des letzten Werts. Eine Liste mit 12 Werten trifft auf eine mit 120 Elementen. Die ersten 12 stimmen, die restlichen 108 tragen den zwölften Wert. Der Fehler ist am Anfang der Liste unsichtbar und am Ende systematisch.

Prüfen statt hinsehen

Die wirksamste Gegenmaßnahme ist keine höhere Aufmerksamkeit, sondern eine Zählung. An jeder Stelle, an der zwei Ströme zusammenkommen, gehört die erwartete Zahl der Zweige und die erwartete Zahl der Elemente je Zweig ausgeschrieben und mit der tatsächlichen verglichen.

Das kostet ein paar Minuten pro Zusammenführung und fängt alle drei Muster oben ab, weil alle drei die Zählung verändern, bevor sie die Geometrie verändern.

Zweite Maßnahme: eine sichtbare Probe. Ein Element wird eingefärbt oder beschriftet und im Modell verfolgt, vom Eingang bis zum Zuschnitt. Wenn Position 47 am Ende noch Position 47 ist, stimmt die Zuordnung. Das ist der einzige Test, der die ganze Kette abdeckt.

Dritte Maßnahme: die Struktur benennen. Wer die erwartete Baumstruktur an den wichtigen Stellen als Kommentar hinschreibt, dokumentiert nicht nur, sondern zwingt sich zu der Frage, ob sie noch stimmt.

Warum das teurer ist als es klingt

Weil der Fehler nach unten durchschlägt. Aus derselben Struktur entstehen Zuschnitte, Stücklisten und Preise. Eine Zuordnung, die im Bild nicht auffällt, fällt in der Fertigung auf, wenn das Material bereits geschnitten ist.

Und weil das Vertrauen mitgeht. Ein Team, das einmal erlebt hat, dass ein parametrisches Modell überzeugend falsch war, prüft danach jede Ausgabe von Hand nach. Damit ist der Zeitgewinn weg, der der Grund für die Methode war.

Was wir uns angewöhnt haben

Zählprüfungen an jeder Zusammenführung, eine markierte Probe je Bauteilfamilie, und Cluster mit festgelegten Ein- und Ausgängen statt gewachsener Graphen. Ein Cluster erzwingt eine Entscheidung darüber, welche Struktur hinein- und herausgeht, und genau diese Entscheidung ist es, die sonst unterbleibt.

Nichts davon ist aufwendig. Es ist die Sorte Disziplin, die aus der Softwareentwicklung kommt und in parametrischen Modellen aus demselben Grund wirkt: der Fehler, der nicht abbricht, ist der teuerste.

Das ist der Punkt, an dem aus Computational Design Softwareentwicklung wird. Eine Definition lässt sich ohne Oberfläche auf einem Server betreiben und über eine Schnittstelle ansprechen. Was dann davorsteht, kann ein Konfigurator im Browser sein, eine Angebotsrechnung, eine Prüfung in einem bestehenden System oder alles drei aus derselben Quelle.

Was ein Geometrie-Server tatsächlich ist

Ein Rechenknoten, der die Definition geladen hat, Parameter entgegennimmt und das Ergebnis zurückgibt: Geometrie in einem Austauschformat, dazu die Kennzahlen, die im Modell ohnehin berechnet werden. Fläche, Gewicht, Teilezahl, Verschnitt, Materialbedarf.

Der entscheidende Teil ist der zweite. Ein Konfigurator, der nur ein Bild liefert, ist eine Visualisierung. Einer, der zusätzlich die Stückliste und den Materialbedarf zurückgibt, ist ein Vertriebswerkzeug, und das ist der Unterschied, der ein solches Vorhaben trägt.

Die Definition bleibt dabei dieselbe Datei, mit der entworfen wird. Genau das ist der Punkt: es gibt keine zweite Nachbildung der Logik, die auseinanderlaufen kann.

Warum die zweite Nachbildung das eigentliche Problem ist

Der übliche Weg zu einem Konfigurator führt über eine Neuimplementierung: Ein Entwicklungsteam bekommt die Regeln als Dokument beschrieben und baut sie in der Anwendung nach. Von diesem Tag an gibt es zwei Wahrheiten.

Sie laufen auseinander, und zwar leise. Der Entwurf bekommt eine neue Randbedingung, der Konfigurator nicht. Ein halbes Jahr später verkauft der Vertrieb eine Ausführung, die die Fertigung ablehnt, und niemand kann sagen, seit wann.

Mit der Definition als Dienst gibt es diese Klasse von Fehlern nicht. Eine Regeländerung im Entwurf ist eine Regeländerung im Verkauf, weil es dieselbe Regel ist.

Der Zuschnitt, der in der Praxis funktioniert

Nicht jede Anfrage darf eine volle Berechnung auslösen. Bewährt hat sich eine Trennung in drei Stufen: eine sofortige Vorschau aus vorberechneten Zwischenständen, eine vollständige Berechnung auf Anforderung, und eine Ableitung der Fertigungsdaten erst nach der Auswahl.

Der Variantenraum wird dafür vorher abgetastet und die Ergebnisse werden abgelegt. Was ein Kunde im Browser bewegt, ist dann meistens eine Auswahl aus bekannten Ergebnissen und keine Live-Rechnung. Das ist der Unterschied zwischen einer Antwort in Millisekunden und einer in zwanzig Sekunden.

Für die Darstellung im Browser wird die Geometrie vereinfacht ausgeliefert. Wichtig ist, dass diese Vereinfachung automatisiert aus dem Konstruktionsmodell fällt und nicht von Hand gepflegt wird, sonst ist die zweite Wahrheit über die Hintertür wieder da.

Woran es tatsächlich klemmt

Rechenzeit. Eine Definition, die im Entwurf zwanzig Sekunden braucht, braucht sie auch auf dem Server. Interaktiv ist das nicht. Entweder wird die Definition auf Geschwindigkeit hin überarbeitet, was oft möglich und selten beliebt ist, oder der Variantenraum wird vorberechnet.

Zustand. Entwurfsumgebungen halten Zustand zwischen Aufrufen. Ein Dienst, der viele Anfragen parallel bedient, darf das nicht. Definitionen, die sich auf zuletzt geladene Dateien oder Referenzobjekte verlassen, verhalten sich unter Last nicht reproduzierbar, und dieser Fehler tritt genau dann auf, wenn niemand zusieht.

Lizenzierung. Der Serverbetrieb einer Entwurfsumgebung ist lizenzrechtlich eine andere Frage als der Arbeitsplatzbetrieb. Das gehört vor die Architekturentscheidung und nicht danach, weil es das gesamte Betriebsmodell bestimmt.

Und Fehlerfälle. Eine unzulässige Parameterkombination darf keinen Serverfehler erzeugen, sondern muss eine begründete Ablehnung zurückgeben. Randbedingungen als Prüfungen im Modell zahlen sich hier ein zweites Mal aus.

Wo die Daten bleiben

Der gesamte Aufbau lässt sich im eigenen Haus betreiben. Das ist kein Randthema: eine Definition enthält die Konstruktionslogik eines Produkts, und für viele Hersteller ist genau das der Kern dessen, was nicht abfließen darf.

Wir bauen solche Dienste deshalb so, dass Rechenknoten, Ergebnisspeicher und Auslieferung in der Infrastruktur des Kunden stehen können, mit einer Schnittstelle als einziger Berührungsfläche nach außen.

Wann sich der Schritt lohnt

Wenn dieselben Fragen mehrfach im Monat an dieselbe Person gehen. Wenn der Vertrieb Varianten verkaufen soll, die er selbst nicht durchrechnen kann. Wenn aus der Geometrie ohnehin Stücklisten oder Preise entstehen sollen.

Und nicht, wenn der Konfigurator vor allem hübsch sein soll. Ein 3D-Konfigurator ohne Kennzahlen dahinter ist eine Visualisierung mit Wartungsaufwand, und die gibt es billiger.

Die ehrliche Antwort ist eine Rechnung, keine Haltung. Ein parametrisches Modell verschiebt Aufwand von hinten nach vorne. Es kostet mehr, bevor die erste Ausführung steht, und weniger bei jeder weiteren. Ob sich das trägt, hängt an drei Größen, die sich vor Projektbeginn abschätzen lassen.

Die drei Größen, an denen es hängt

Die erste ist die Zahl der Ausführungen. Nicht die Zahl der Varianten, die im Entwurf betrachtet werden, sondern die Zahl der Teile, Module oder Objekte, die am Ende wirklich hergestellt oder gebaut werden. Zwanzig unterschiedliche Fassadenpaneele sind ein Fall dafür. Ein Bauwerk ist es nicht.

Die zweite ist die Zahl der Änderungsrunden. Sie wird fast immer unterschätzt und ist der eigentliche Hebel. Ein Entwurf, der viermal überarbeitet wird, wird bei manueller Bearbeitung viermal vollständig nachgezogen. Ein Regelwerk wird einmal angepasst und rechnet neu.

Die dritte ist die Kopplung zwischen Entwurf und Nachgelagertem. Wenn aus derselben Geometrie auch Stücklisten, Zuschnitte, Angebotspreise oder ein Konfigurator entstehen sollen, entsteht der Nutzen nicht einmal, sondern pro angeschlossenem Schritt.

Eine Faustregel, die trägt

Als grobe Orientierung aus umgesetzten Projekten: Der Aufbau einer belastbaren Definition kostet ungefähr das Drei- bis Fünffache der ersten manuell gezeichneten Variante. Jede weitere Variante kostet danach nahezu nichts.

Daraus folgt der Umschlagpunkt bei etwa fünf Ausführungen, wenn sich nichts mehr ändert. Er verschiebt sich auf zwei bis drei, sobald mit mindestens einer echten Änderungsrunde zu rechnen ist, weil die Änderung im Regelwerk einmal und in der Zeichnung pro Variante anfällt.

Diese Zahlen sind Größenordnungen und keine Kalkulation. Sie sind trotzdem nützlich, weil sie die Diskussion an der richtigen Stelle führen: nicht darüber, ob Parametrik beeindruckend ist, sondern darüber, wie oft sich Ihr Entwurf ändern wird.

Wo die Rechnung kippt, und das wird selten gesagt

Bei einem einmaligen Entwurf ohne Wiederholung. Ein Sonderbauteil, ein Messestand, ein Objekt, das genau einmal existiert: hier gewinnt Zeichnen, und zwar deutlich. Ein Regelwerk für eine einzige Ausführung ist ein teurer Umweg.

Bei unklaren Randbedingungen. Parametrik zwingt dazu, die Regel vorher zu formulieren. Wenn niemand sagen kann, welche Maße gelten, welche Toleranzen zulässig sind und welche Ausführungen ausgeschlossen sind, entsteht ein Modell, das schnell viele falsche Varianten erzeugt. Das ist schlechter als eine Zeichnung, weil es überzeugender aussieht.

Bei Entwürfen, deren Wert in der Ausnahme liegt. Ein Regelwerk ist gut in dem, was sich wiederholt. Wo die gestalterische Qualität gerade aus dem Bruch mit der Regel entsteht, arbeitet die Methode gegen das Ziel, und die Ausnahmen zurück ins Modell zu bauen kostet mehr als sie erspart.

Und bei Teams ohne Übernahme. Eine Definition, die nur ihr Autor ändern kann, ist eine Abhängigkeit und kein Werkzeug. Wenn niemand im Haus sie weiterführen soll oder kann, gehört das in die Rechnung.

Was die Rechnung deutlich verbessert

Bauteilfamilien statt Einzelteile. Fünf Familien mit je zwanzig Maßen sind herstellbar und kalkulierbar, hundert Unikate sind es meist nicht. Die Familienbildung ist der Schritt, in dem ein parametrisches Modell den Preis wirklich senkt, und sie ist eine Entwurfsentscheidung, keine Software-Einstellung.

Randbedingungen als Prüfungen im Modell. Wenn eine unzulässige Ausführung gar nicht erst entsteht, entfällt die Prüfschleife am Ende. Das ist derselbe Gedanke wie ein Test in der Softwareentwicklung und wirkt aus demselben Grund.

Und eine Definition, die wie Software behandelt wird: benannt, strukturiert, kommentiert, versioniert. Eine gewachsene Definition ohne Struktur ist nach sechs Monaten für niemanden mehr änderbar, auch nicht für ihren Autor. Dann ist der eingesparte Aufwand zurück.

Wie wir das vor einem Angebot klären

Wir fragen nach der Zahl der herzustellenden Ausführungen, nach der erwarteten Zahl der Abstimmungsrunden und danach, was aus der Geometrie außer Bildern noch entstehen soll. Diese drei Antworten reichen in den meisten Fällen für eine belastbare Einschätzung.

Fällt sie negativ aus, sagen wir das. Ein Vorhaben, dem wir vom parametrischen Weg abraten, ist ein besseres Ergebnis als eine Definition, die niemand braucht.

Was hier steht, sind keine Preise. Es sind die Kostenstellen, nach denen Sie ein Angebot durchsuchen sollten, und die Größenordnungen, in denen sie zueinander stehen.

Die Inferenz ist selten das Problem

Die Rechnung, mit der gerechnet wird, ist die pro Anfrage: Kontext hinein, Antwort heraus, Preis je Token. Sie ist gut kalkulierbar und in den meisten Häusern kleiner als erwartet, weil die Zahl der Anfragen kleiner ist als erwartet. Ein internes Wissenssystem mit 200 Beschäftigten sieht keine Millionen Anfragen.

Worauf zu achten ist: deutschsprachige Texte verbrauchen spürbar mehr Token als englische, und ein großzügig gefülltes Kontextfenster kostet pro Anfrage mehr als eine gute Suche davor. Wer Retrieval und Reranking ernst nimmt, senkt damit auch die laufenden Kosten, nicht nur die Fehlerquote.

Der Index ist die eigentliche laufende Position

Ein Index ist kein Bauwerk, das fertig wird. Neue Dokumente müssen hinein, geänderte ersetzt, gelöschte entfernt. Das ist Betrieb, und es braucht jemanden, der zuständig ist.

Der teure Sonderfall ist der Wechsel des Embedding-Modells. Embeddings sind nur untereinander vergleichbar, also erzwingt jeder Wechsel die Neuberechnung des gesamten Bestands. Bei einigen zehntausend Dokumenten ist das ein Wochenendlauf, bei Millionen eine Planung. Wer das nicht einkalkuliert, sitzt auf dem Modell fest, mit dem er angefangen hat.

Dazu kommt die Pflege des Bestands selbst, und das ist die Position, die am häufigsten fehlt. Ein Retrieval-System zitiert eine überholte Arbeitsanweisung genauso überzeugend wie die gültige. Aussortieren ist Handarbeit und wird wichtiger, nicht unwichtiger, sobald das System benutzt wird.

Evaluation ist eine Kostenstelle, keine Phase

Der Goldstandard-Testsatz aus echten Fragen mit geprüften Antworten entsteht einmal und veraltet danach. Neue Themen kommen dazu, alte Antworten stimmen nicht mehr.

Ohne laufende Evaluation lässt sich keine Änderung mehr verantworten: ein neues Modell, ein anderes Chunking, ein zusätzlicher Filter. Man merkt an Einzelfällen, dass etwas anders ist, und kann nicht sagen, ob es besser ist. Ab diesem Punkt wird nichts mehr geändert, und das System altert.

Als Größenordnung: die Pflege von Testsatz und Auswertung ist über die Laufzeit derselbe Aufwand wie die Indexpflege, und beide zusammen übersteigen die Inferenzkosten in fast allen Fällen im Mittelstand.

Lokal oder gehostet ist eine Tauschentscheidung, keine Sparentscheidung

Lokaler Betrieb tauscht laufende Token-Kosten gegen einmalige Anschaffung plus Betrieb. Die begrenzende Größe ist der Videospeicher, weil er bestimmt, welche Modellgröße hineinpasst; Rechengeschwindigkeit entscheidet danach nur über den Durchsatz.

Was in der Rechnung oft fehlt: Strom, Kühlung, Ersatzteile und vor allem jemand, der die Modelle aktualisiert. Ein lokales Modell veraltet, und der Aktualisierungsprozess ist Ihrer.

Was dafür spricht, ist meistens nicht der Preis, sondern dass die Dokumente das Haus nicht verlassen. Das ist eine gute Begründung. Die Ersparnis als Hauptargument trägt nur bei hohem, gleichmäßigem Anfragevolumen.

Die Positionen, nach denen wir ein Angebot durchsuchen würden

Wer pflegt den Index und mit welchem Aufwand pro Monat. Was passiert bei einem Wechsel des Embedding-Modells und wer trägt ihn. Wie wird gemessen, ob das System noch richtig antwortet, und wie oft. Wie werden Rechte abgebildet und wer pflegt sie, wenn sich die Organisation ändert. Und was kostet der Ausstieg, also in welcher Form die Daten und der Index das System verlassen.

Ein Angebot, das diese fünf Fragen beantwortet, ist möglicherweise teurer als eines, das sie nicht stellt. Es ist auch das einzige der beiden, dessen Zahl nach einem Jahr noch stimmt.

WHAT VISUAL SEARCH DELIBERATELY DOES NOT DELIVER

Visual retrieval models find the right page, even in a difficult scan. But they give you back an image, not text. You cannot easily copy a line from it, run full-text search across the archive, or build a machine-readable audit trail. For all of that, you need recognised text. This is not a weakness of the new approach, but a deliberate division of labour: search on the image, text extraction via OCR, each stage doing what it does best.

WHAT PADDLEOCR-VL CAN DO

Baidu has released PaddleOCR-VL, an open OCR model that achieves top scores with only 0.9 billion parameters (project). It recognises text, tables, formulas and diagrams in 109 languages and reconstructs the semantic structure of a document. On the OmniDocBench v1.5 benchmark, it leads with around 94.5% accuracy. It is released under the Apache 2.0 licence, so it can be used commercially free of charge and run on-premise. For an SME, that means strong text recognition without a recurring fee and without data leaving the building.

THE HYBRID SETUP

In practice, both approaches run side by side. Visual search finds the relevant pages quickly and preserves layout fidelity. Where that needs to become hard text, for instance for an invoice line item, a contract clause to quote, or an entry into the ERP system, OCR takes over on precisely those few pages. You do not need to run the entire archive through OCR, only what search has already flagged as important. That keeps the pipeline lean and prevents OCR errors from seeping into search from the outset.

THE PRAGMATIC LINE

Either-or is the wrong stance here. Visual search improves finding, OCR improves further processing. Anyone who treats both as tools with clear roles builds a more resilient knowledge base than someone who dogmatically backs one side. How the building blocks fit together, from the encoder to the vector database, is covered in the stack overview.

For a Mittelstand company processing contracts, technical manuals, and multi-page invoices every day, that is the more interesting news. It is not that text recognition is a few points better; it is that an 80-page document no longer has to be cut into pieces and reassembled, and no document has to leave the building to make that happen.

WHAT UNLIMITED-OCR DOES DIFFERENTLY

The core is a modified attention mechanism in the decoder that keeps memory constant. Classic transformer-based OCR models let the so-called KV cache grow with the length of the document. The longer the PDF, the more memory is needed, until at some point it no longer fits into a single processing run.

Unlimited-OCR replaces this component with Reference Sliding Window Attention (R-SWA). This keeps the KV cache constant, regardless of document length. That is exactly what the term one-shot long-horizon parsing means: a long document is read in a single pass, rather than being split into sections whose results are stitched together afterwards.

The training path is notable. The team did not start from zero but continued training the DeepSeek-OCR checkpoint: freezing the encoder and adapting only the decoder over around 4,000 steps. This puts the model in direct lineage with DeepSeek-OCR, which we have already placed in context within the stack discussion. Code and weights are open on GitHub.

WHY THE CONSTANT KV CACHE MATTERS

The real problem with long documents is not the individual page, but the connection across pages. When a model cuts a 60-page document into ten-page blocks, exactly what matters in everyday B2B work gets lost: a table that runs across a page break, a clause that refers back to an earlier section, a line item whose reference figure sits twenty pages earlier.

A constant KV cache allows the entire document to be held in one context. Memory does not grow with length, so structure is preserved across all pages. It also gets faster along the way: Baidu reports 5,580 tokens per second in base mode against 4,951 for DeepSeek-OCR, and with an output limit of 6,000 tokens the gap is around 35 percent.

On accuracy, Unlimited-OCR scores 93.23 points on OmniDocBench v1.5, 6.22 above the DeepSeek-OCR baseline, and 93.92 on v1.6. These are the figures from the paper. On your own documents, what ultimately counts is how the model handles your tables, stamps and forms, not the average on a public test set. A related development is happening with sub-quadratic LLMs, which are making long context cheaper on-prem.

WHERE THIS CHANGES SOMETHING IN THE MITTELSTAND

The benefit arises wherever long, structured documents need to become clean, searchable data. A few concrete examples:

• Contracts and framework agreements. Cross-references and appendices stay readable in context instead of breaking apart at block boundaries.
• Technical manuals and standards. Long documents with figures, tables and numbered sections processed in a single pass.
• Multi-page invoices and receipts. Cleanly extracted text is the preliminary step for structured downstream processing, for example towards e-invoicing.
• Archives and files. Holdings that until now only existed as scans become machine-readable without handing them to a cloud service.

In almost all cases, OCR is not the goal but the first step. Cleanly parsed text is the foundation for a knowledge base with RAG: the better the parsing, the better search later finds the right spot.

OCR OR VISUAL DOCUMENT SEARCH?

Not every document task needs classic text recognition, and that is a fair trade-off to weigh. There is now an entire branch that does not convert documents into text at all, but instead searches them as images, using models such as ColPali or ColQwen. We have described this OCR-free approach separately.

The rule of thumb that has proven itself for us:

• You need the actual characters (invoice amounts, contract clauses, structured extraction, handing off to another system): then there is little way around OCR, and a model like Unlimited-OCR is strong here.
• You need the right spot, not the full text (answering a question against a large body of documents, finding a figure again): then visual document search can be the more direct route.

Often it is both side by side. Unlimited-OCR makes the OCR part of this stack cheaper and more reliable on long documents.

WHAT I WOULD CHECK BEFORE PRODUCTION

A good benchmark score is a reason to test the model, not a reason to put it into production. Before I would put Unlimited-OCR into a client process, I would check four things:

🔸 German documents and handwriting. The benchmark figures say little about German forms, old files or handwritten notes. That belongs on its own test set made of real documents.

🔸 Tables and layout. With B2B documents, the fidelity of tables and columns determines the value. A direct comparison with your existing stack is worthwhile here.

🔸 Hardware and operation. 3B as an MoE with around 500M active parameters is realistic on-prem. What that concretely means in GPU memory and throughput needs to be measured before rollout, not estimated.

🔸 Licence and provenance. MIT permits commercial, on-premise use with no fine print. That the model's lineage traces back to one of the DeepSeek-OCR authors is a quality signal, but it does not replace your own testing.

What I actually find interesting about this release is less the model itself than the direction: long documents in a single pass, small enough for your own data centre, under a licence that restricts no one. This is exactly where document processing in the Mittelstand is becoming practical right now. Which of your documents would you run through first?

BEYOND THE PROMPT

Prompt engineering tunes the question. Context engineering designs the environment the model decides in. For a one-off task, a good prompt is enough. For an agent that runs over many steps, reads tools, and carries memory, the prompt is a small part of what the model sees. The rest, what you retrieve, what you remember, what tools you expose and how, is context, and it decides far more of the outcome. This is why extending an agent harness is mostly context work.

THE FOUR FAILURES TO DESIGN AGAINST

Most agent failures trace back to one of four context problems:

• Context overload. Too much in the window. The model loses the thread, and cost and latency climb. More context is not better context.
• Context poisoning. A wrong or stale fact enters the window and the model treats it as truth. One bad retrieved chunk can derail an answer.
• Token management. The window is finite. Without a plan for what to keep and what to drop, the important detail gets pushed out by noise.
• Stale memory. Long-running agents accumulate context that no longer applies, and act on it.

Naming the failure is half the fix. Each one has a concrete counter-move.

PRACTICES THAT HOLD UP

A few patterns recur in setups that stay reliable:

1. Retrieve, do not dump. Pull the few relevant passages with good retrieval rather than pasting everything. This is the whole point of RAG, and it is context engineering applied to data.
2. Prune as you go. Apply rule-based editing inside the scaffold to keep the window lean: drop what a step no longer needs.
3. Summarize long history. Replace a long transcript with a faithful summary before it crowds out the task.
4. Start simple, scale on need. Add memory and tools only when a real failure demands them, not by default.

The instinct to add more is the trap. The discipline is subtraction.

WHY THIS IS THE REAL ENGINEERING

A bigger model rarely fixes a context problem; it just fails more expensively. The work that moves an agent from demo to dependable is almost entirely context work: what it sees, when, and what it is made to forget. For very long inputs the model architecture matters too, which is where subquadratic approaches come in, but for most teams the gain is in the context, not the parameters.

THE MECHANISM, PLAINLY

Plain RAG embeds your query, finds the nearest passages, and answers from them. RAG-Fusion adds two steps in front. First, a model writes a handful of alternative queries that mean the same thing from different angles. Second, it retrieves for all of them and merges the ranked lists with reciprocal rank fusion, which rewards passages that rank well across several queries rather than just one. The answer is then written from that fused, reranked set.

WHY THE FUSION STEP MATTERS

A single query is a single guess at how the answer is phrased in your documents. Real archives use synonyms, abbreviations and different wordings for the same thing. By asking the question several ways and rewarding what consistently ranks high, RAG-Fusion surfaces the passage that a single phrasing would have missed. Reciprocal rank fusion is the quiet workhorse here: it combines lists without needing comparable scores, which is also why it shows up in hybrid and late-interaction setups like the ones behind Qdrant and ColQwen.

WHEN IT HELPS AND WHEN IT HURTS

RAG-Fusion earns its cost on ambiguous or terminology-heavy questions, where one phrasing is a weak bet. It costs more: several retrievals and a generation step per question, so it is not free latency. And it has a real failure mode. If the generated query variants drift from what you actually meant, they pull in off-topic passages and the answer wanders. The fix is to keep the generated queries tightly tied to the original intent, and to measure, not assume, that recall improved.

WHERE IT SITS AMONG THE OPTIONS

RAG-Fusion is one of several ways to make retrieval better, not a replacement for good retrieval. Before reaching for it, make sure the basics hold: clean chunks, a sound embedding model, and a vector store that fits the job. For visually dense documents the bigger lever is often visual retrieval rather than more query variants. Use F-RAG where the question is genuinely ambiguous and the recall gain is worth the extra calls.

THE PROBLEM WAS NEVER THE ANIMATING, IT WAS THE HANDOFF

Until now, UI motion was created outside Figma. The designer built it in a second tool, exported a video or a description, and development had to rebuild the curves and timings, often by eye. In the process, precision gets lost: an easing curve becomes an approximate idea, a timing becomes a guess. It is exactly this break, not a lack of animation tools, that has made motion inconsistent across many products.

WHAT FIGMA MOTION CONCRETELY BRINGS

Three things noticeably change the workflow:

• Timeline in the canvas. Keyframes, presets, and motion controls sit right where the design already lives. No switching to a second tool.
• Motion as part of the design system. A component gets animated once, and the motion travels like colour or typography across every screen and every file. This is the point that enforces consistency instead of just hoping for it.
• Readable handoff. In Dev Mode, the entire timeline is visible: every timing value, every easing curve, every keyframe. Export goes out as CSS, JSON, or framework-ready React, plus MP4, WebM, animated SVG, and GIF.

This means development reads the motion instead of interpreting it. That is the real shift.

WHERE THE CATCH SITS

An integrated tool is not automatically the right one for every case. Complex, narrative motion work, such as an elaborate brand film, remains a job for specialised tools. Figma Motion targets interface animation: states, transitions, micro-interactions, in other words exactly what a product needs every day and what has suffered from the handoff break until now. For this class of motion, the integration is the win. For anything beyond it, the toolbox stays mixed.

WHO SHOULD ACTUALLY LOOK AT THIS

Anyone maintaining a product with recurring UI patterns benefits most: motion defined once stays consistent, and implementation gets exact values instead of approximations. Motion here is not decoration but part of an interface's comprehensibility, a point we go into in more detail in the role of UX in building software. Figma Motion finally makes this part editable in one place.

THREE RELEASES, IN PLAIN TERMS

Each of these shipped within a fortnight of the others in June 2026, and each is a different kind of thing. It is worth being precise, because two of them are widely described wrong.

GLM-5.2, from Z.ai in Beijing, released on 17 June. It is an open-weight Mixture-of-Experts model, roughly 750 billion parameters with about 40 billion active, a one-million-token context, and crucially an MIT licence with the weights published on HuggingFace.

Sakana Fugu, from Sakana AI in Tokyo, released on 22 June. It is not a conventional model, and the common framing gets this wrong: Fugu is a trained orchestrator that calls a pool of other models and synthesises their work. It is API-only, offered as an OpenAI-compatible endpoint.

Claude Fable 5, from Anthropic in the United States, released on 9 June. The second common mistake is to file Fable as a fast or creative tier. It is the flagship, Anthropic's most capable widely released model, safety-gated, cloud-only, at 10 and 50 dollars per million tokens. Its benchmark numbers are strong; for this piece they are also beside the point.

THE ONLY COMPARISON THAT SURVIVES PROCUREMENT

Strip out the leaderboard and line them up on the dimensions a German B2B buyer is actually accountable for. The picture is clear, and it is not about which one is smartest.

Two honest caveats belong on this table. GLM-5.2's default path, the Z.ai API, sits under China's data laws, with their mandatory access provisions, which is exactly why the open weights matter: self-hosting in the EU neutralises that risk. And Fugu's claim of frontier parity is entirely self-reported, weakened by the fact that Fable and the restricted Mythos model are not even in its pool. I would not stake a decision on either vendor's benchmark.

WHAT I ACTUALLY TELL A CLIENT

I do not recommend one of these in the abstract. I match the posture to what the client can fund and what they are accountable for.

🔸 GLM-5.2 is the on-prem play. The open MIT weights are the whole point: you can run it in your own data centre, and the prompts never leave your network. The catch is the GPU footprint, roughly 744 gigabytes in FP8, so it fits the client who can fund the hardware and needs data to stay in the building. It is the cleanest sovereignty story of the three.

🔸 Claude Fable 5 is the managed-assurance play. You are renting capability from a US vendor, at the highest price here, with real safety gating and regional data-routing on the major clouds. For a team that wants a top model without owning the stack, and can live with a cloud dependency, it is the strongest managed option.

🔸 Sakana Fugu is the convenience play, with the weakest control story. One API that routes across a pool of models is clever, and Japan is softer geopolitics than China. But you cannot run it on-prem, you do not pick which model sees the data, and the evidence is thin. I would treat it as interesting, not as a default for regulated work.

This is the same lesson Claude Fable 5 taught the hard way when an earlier model was switched off in 72 hours: rented capability is revocable, and control is a property of the stack, not the score. It is why I keep pointing clients toward open-weight models they can actually own.

THE QUESTION WORTH DESIGNING FOR

If you take one thing from this, let it be the question, not the ranking. The models will trade places on the leaderboard again within a quarter; that part is noise. The durable question is the one a procurement officer should be asking on day one: which of these can you still run, audit, and afford when the vendor changes the terms? For most of the regulated clients I work with, that question answers itself, and it does not point at the highest benchmark. So before you pick the smartest model, what would it cost you to lose it?

WHAT GEMINI OMNI ACTUALLY IS

Get the name right first, because the marketing blurs it. The family is Gemini Omni and the first model is Gemini Omni Flash. It accepts text, image, audio, and video as input, and at launch it produces one output: video, in clips of about 10 seconds with natively synced audio. Google describes it as a step toward a world model, meaning it tries to keep physics, gravity, and spatial coherence consistent across a generated scene, and it runs on Google's 8th-generation TPUs split into training and inference variants.

One honest correction matters for a technical reader: Omni is marketed as any-to-any, but as it shipped it is any-input-to-video. Image and audio outputs are on the roadmap, not in the product. So it is not a real-time conversational omni-assistant, and it is not yet the universal any-to-any system the name implies. It is a very capable input-flexible video generator, which is a narrower and more useful thing to plan around.

ANNOUNCED, SHIPPED, AND AVAILABLE ARE THREE DIFFERENT THINGS

The single most useful distinction for a buyer is that these three states are not the same, and Omni sits in different ones depending on who you are. It is shipped to consumers and creators, and merely announced for everyone who builds on an API.

The practical reading for an EU company is direct. If you need GDPR-grade EU residency for video generation today, Omni cannot give it to you, because its enterprise path does not exist yet. The supported option on Google's own stack remains Veo 3.1 on Vertex AI, which you can pin to an EU region. This is the same pattern we keep seeing with new model launches, where the demo and the deployable product are months apart.

WHAT A GERMAN ENTERPRISE SHOULD DO NOW

Treat Omni as a signal to track, not a tool to adopt this quarter. Three concrete moves.

• Use Veo 3.1 region-pinned for production video today. It has a real Vertex API, EU regions, and an SLA. Omni has none of these yet, so it does not belong in a production pipeline now.
• Plan the provenance story early. Omni embeds a SynthID watermark on every clip. For regulated or public-facing content, build the expectation that AI-generated video is labelled and traceable into your process, regardless of which model wins.
• Watch two risks, not just the capability. Reviewers have reproduced recognisable trademarked characters in Omni output, which is a real IP exposure for commercial use, and visual consistency still drifts on fast motion. The 10-second cap is a UX limit, not a model ceiling, so expect it to move.

The durable point is the one the launch makes by accident: a model you can see in a keynote is not a model you can deploy under contract. Separate the two, and the hype becomes a roadmap item instead of a procurement mistake.

WHAT ACTUALLY SHIPPED IN 2025 AND 2026

The headline is stability after years of churn. LangChain 1.0 and LangGraph 1.0 both reached stable release on 22 October 2025, with a commitment to no breaking changes until 2.0. The framework's new headline abstraction, create_agent, now runs on the LangGraph runtime underneath, so the agent loop is a LangGraph graph. That is the clearest signal of the merge: the framework and the orchestration runtime are no longer separate choices.

LangGraph 1.0 brought durable execution as a built-in: state is checkpointed automatically, so a long-running or human-in-the-loop workflow resumes after an interruption or a server restart. LangSmith, the observability and evaluation layer, added full OpenTelemetry support in March 2026, which means you can send traces to it from code that does not use LangChain at all. The commercial picture matched the technical one: LangChain Inc raised a 125 million dollar Series B at a 1.25 billion valuation in October 2025, and renamed LangGraph Platform to LangSmith Deployment, folding deployment, observability, and evaluation into one product.

FOUR NAMES, TWO COMPANIES

Sorting out who makes what is the single most useful thing before you choose. Most write-ups blur it; getting it right changes the decision.

LangFlow is the one that trips people up. It is not a LangChain Inc product. It is an open-source visual builder created by DataStax, whose parent was acquired by IBM in February 2025, and it now points toward IBM's watsonx. The name rhyme is a coincidence. If your requirement is a drag-and-drop canvas for people who do not write Python, LangFlow is the candidate; it is not a layer of the LangChain stack.

THE DECISION MOST TEAMS ACTUALLY FACE

Once the names are clear, the choice is usually a short decision tree, and you rarely need all four.

• Need durable orchestration? LangGraph is the strongest piece, and the one even critics tend to respect. Resumable state, checkpointing, and human-in-the-loop are real engineering, not wrappers.
• Need observability and evaluation? LangSmith is capable, but it couples you to the ecosystem. Langfuse is the open-source, self-hostable counter-pressure, and the most-cited escape hatch. Now that LangSmith speaks OpenTelemetry, you can trace from non-LangChain code, which softens the lock-in.
• Building a straightforward agent? The provider SDKs (the OpenAI Agents SDK, the Claude Agent SDK) and Pydantic AI are credible, lighter alternatives. The dominant practitioner gripe is the layers of abstraction in the framework, and several teams report cutting code and maintenance by moving to a thinner stack.
• Non-engineers prototyping? LangFlow, with the caveat that a canvas prototype still needs the same governance and evaluation before it ships.

This is the same lesson we drew when comparing how to wire AI into a stack through an API, an MCP server, or a CLI: the tools are layers, and you pick by the job, not the novelty. It also rhymes with what we found looking at no-code agent builders for the Mittelstand, where the canvas gets you a demo fast and stops exactly at governance, reliability, and cost.

STABLE DID NOT MEAN HARDENED

One caveat matters for a business audience: 1.0 bought API stability, not a hardened security posture. A cluster of CVEs landed against LangChain and LangGraph in late 2025 and early 2026, led by a deserialization flaw that could leak API keys and environment secrets, rated CVSS 9.3 and nicknamed LangGrinch. Two more followed: a path-traversal issue in the prompt-loading API, and a SQL-injection in the LangGraph SQLite checkpointer.

The practical reading is not to avoid the framework. It is to treat it like any other dependency that touches your secrets and your data: pin versions, apply the patched releases, and include it in your threat model. A framework that orchestrates tool calls and holds credentials is part of your attack surface, and "stable" on the version number says little about that. For a regulated or on-prem deployment, that review belongs in the same conversation as data residency, not after go-live.

THE PROBLEM WITH THE SINGLE VECTOR

Classic vector search compresses an entire passage or an entire page into a single vector. That is economical, but it averages away what matters locally. If the amount you are searching for sits in a specific table cell, that reference disappears into the average of the whole page. For clean running text, this is often enough. For the documents that visual search exists for in the first place, it is not enough.

LATE INTERACTION, IN ONE SENTENCE

Late interaction keeps many vectors per page and compares them late, only at search time. The model produces one vector per token for the search query, and one vector per patch for the page. The scoring is called MaxSim: for each query token, the best-matching page patch is found, and these best matches are summed. This lets the word "remaining balance" dock precisely onto the table cell it appears in. The technique originates from ColBERT and was carried over to images with ColPali. If you want to see the whole toolkit, the OCR-free stack places the models in context.

WHERE QDRANT COMES INTO PLAY

Late interaction needs a database that understands multiple vectors per object. Qdrant supports such multi-vectors directly, without pre- or post-processing, and can carry any late interaction model such as ColBERT or ColPali (docs). The usual setup is two-stage: a fast initial search with normal dense vectors narrows down the candidates, then MaxSim precisely re-scores only these few pages. This keeps the index affordable, because the expensive token vectors do not need to be fully indexed, but instead serve re-ranking.

WHAT THIS MEANS IN PRACTICE

You get results that respect layout, without making search unaffordably expensive. The price is more storage per page and somewhat more complexity when building it. Both are manageable if you plan the re-ranking stage in from the start instead of fully indexing every token vector. For very long contexts, it is worth looking at subquadratic models; for the basic idea of retrieval, What is RAG remains the starting point.

What makes n8n strong

n8n is node-based workflow automation, self-hosted or as a cloud service, with over 400 integrations plus an HTTP node and code nodes for everything else (n8n). The decisive point for regulated industries: it runs in-house, the data never leaves your infrastructure. The fair-code licence permits internal use free of charge. If you need your own logic, your own endpoints and full data control, this is the right tool. The price for that is operations: you host, update and secure it yourself.

What makes Make.com strong

Make.com is a cloud service with visual scenarios that requires no operations of your own. You click together a flow and it runs, no server, no maintenance. For teams without deep technical expertise, or for a quick idea, this is the shorter path. Billing is per operation, meaning per executed step. That is cheap at small volumes and can grow uncomfortably with large, frequent workflows. The flip side of the convenience: the data runs through a third-party service, and the logic stays within its boundaries.

The decision in one table

The dividing line is clear: data control and depth versus speed without operations of your own.

Our pragmatic advice

Prototype quickly, host deliberately. For an initial test that only needs to show whether a flow holds up, Make.com is often faster. As soon as sensitive data, high volumes or custom logic come into play, n8n wins, because it runs in-house. And where automation borders on genuine AI tasks, it is worth looking at no-code agents and their limits: automation and agents are not the same tool.

WHY SIZE BECOMES AN OBSTACLE HERE

Visual retrieval models such as ColPali or ColQwen are accurate, but they are also large. On-prem, meaning on your own in-house hardware, this quickly becomes a cost question: large models demand powerful GPUs, more memory, more power. For many Mittelstand setups, the obstacle is not quality but the hardware bill. This is exactly where a smaller model creates leverage.

WHAT MODERNVBERT DOES DIFFERENTLY

ModernVBERT is a compact vision-language encoder with 250M parameters (paper). It combines a modern 150M text encoder built on ModernBERT with a small image encoder, aligning the two through a masked-language-modelling objective. ColModernVBERT is the retrieval fine-tuned variant. The result, according to the paper: despite roughly ten times fewer parameters, it lags ColPali by only 0.6 nDCG@5 on the aggregated ViDoRe benchmark, matching scores that otherwise required models nearly ten times larger. The model and code are openly available.

WHY THIS MATTERS FOR SOVEREIGNTY

A small, open, capable model is exactly the combination that makes local operation possible. It fits on modest GPUs, the weights are openly available, and the documents stay in-house because the search does not go to an external endpoint. This is not a security feature bolted on afterwards, but a property of the architecture. We cover the broader context, why local and open belong together, in On-Premise versus Cloud.

WHEN THE SMALL MODEL IS THE RIGHT CHOICE

You do not always need the largest model. If your hardware is limited and your documents are typical business records, ColModernVBERT is often the more honest choice than ColQwen: almost the same quality, a fraction of the cost. If you need that last bit of accuracy on particularly dense pages, it is worth comparing against the larger model. How the two work together in the overall stack with Qdrant is covered in the overview.

Why OCR was the shaky part of the pipeline

OCR was long the point where silent errors crept into the answer. The classic path is a chain: scan the page, convert it to text via OCR, cut it into chunks, embed it, retrieve it. Every stage loses something. A two-column page gets merged incorrectly, a table falls apart into disconnected numbers, a diagram drops out entirely because it is not text. In our experience, for difficult documents the larger part of the quality problem is not in the language model but here, in the reading. Visual retrieval addresses exactly this stage: it skips text recognition at search time and works on the image of the page.

The four building blocks, briefly explained

ColPali. The reference, introduced in July 2024 (arXiv). It builds on the vision-language model PaliGemma and generates around 1024 image-patch vectors per page, each 128-dimensional. Instead of compressing the page into a single vector, granularity is preserved. Matching happens via late interaction, a technique adopted from ColBERT, which we break down in more detail here.

ColQwen. The same recipe, a different base: ColQwen2.5 builds on Qwen2.5-VL instead of PaliGemma and mostly leads on the ViDoRe benchmark. If you are starting fresh today, this is a sensible place to begin.

ModernVBERT. The efficiency lever. ColModernVBERT has 250M parameters, around ten times fewer than ColPali, and according to the paper still lags only 0.6 nDCG@5 behind. This is the building block that makes visual retrieval affordable on-prem.

Qdrant. The infrastructure underneath. Qdrant natively stores the multi-vectors of these models and computes the late-interaction score at search time (docs). Without a vector database that understands multiple vectors per page, none of the three encoders work.

When the switch pays off, and when it does not

Visual retrieval wins where layout carries the information. Scanned contracts, invoices, data sheets, presentations, forms, multilingual files: everything an OCR chain regularly fails on. It also saves the entire maintenance burden of that chain.

But it is not a blanket win. Multiple vectors per page cost more storage and a larger index than a single text vector, often by a large multiple. For clean, plain running text, classic text RAG remains cheaper and entirely sufficient. And some tasks ultimately still need text, such as full-text search, copying, or an audit trail. There are still good reasons for OCR, in a hybrid alongside visual retrieval.

A sober roadmap

1. Test with your own documents, not the benchmark. ViDoRe is a good reference point, but it is not your document set. Take the twenty pages where your current search fails today.
2. Start with ColQwen or ColModernVBERT, depending on your hardware. On a tight GPU, the small model is often the more honest choice.
3. Set up Qdrant as a multi-vector store, using late interaction only at the re-ranking stage to keep the index small.
4. Calculate the storage cost up front. Index size is the thing that hurts later, not the model choice.

If you are looking for the bigger picture, namely why local models and in-house retrieval belong together at all: that is covered in On-Premise versus Cloud. We go deeper into the individual building blocks in dedicated articles, starting with the Mittelstand view.

The gap between a mesh and a part

A generated mesh and a manufacturable part are different objects, and the gap is not cosmetic. Three constraints make the point. First, printing needs a watertight, manifold solid (no holes, no flipped normals, no self-intersections), and generative meshes routinely violate this; a slicer cannot make a part from a surface with gaps. Second, a mesh is a static triangle soup, while manufacturing wants a parametric B-rep model (a STEP file with sketches, features, and constraints) that an engineer can edit and a CAM system can machine. None of the image-to-mesh tools produce that.

Third, and most fundamental, a single image carries no metric scale. The model assigns a guessed camera and produces a shape with no guaranteed millimetres, no enforced wall thickness, no tolerances. And because one photo only sees one side, the hidden side is not reconstructed, it is imagined: the model fills the unseen geometry with a plausible average. A game asset can hide all of this behind a nice texture. A part cannot, because the printer and the load do not care how it looks.

Two pipelines the hype blurs

The clearest way to plan is to separate two pipelines that the marketing runs together. They serve different parts and need different tools.

The first pipeline is real today for parts where fit is forgiving. The AI blocks out the shape; a person still owns making it watertight, scaling it to real dimensions, and running a printability check. The second is where the manufacturing-relevant frontier sits: image-to-CAD research such as CAD-Recode and Img2CAD generates editable parametric geometry, and commercial tools like Zoo can export a real STEP file, but they are largely limited to simpler parts for now. For demanding geometry, classic scan-based reverse engineering (Geomagic, PolyWorks) remains the dependable route. This is the manufacturing cousin of the question we asked about single-image human reconstruction: a plausible surface is not the same as a trustworthy solid.

What is real for a Mittelstand maker today

Set against the hype, the genuine wins are quieter and more valuable than one-shotting a part from a phone photo. The strongest real wedge is digitising what you already have: tools like Spare Parts 3D's Theia and 3YOURMIND's drawing analysis turn legacy 2D technical drawings into printable spare-part models, reported at up to 200 times faster than manual redrawing, with a manufacturability check attached. That is image-to-3D where the input is an engineering drawing, not a holiday snapshot, and the geometry is grounded in real dimensions.

The other solid wins are reverse-engineering acceleration, where AI generation and smart retopology speed up an existing scan-based workflow rather than replace it, and rapid prototyping for non-critical parts. Where it fails is exactly where the stakes are highest: load-bearing, tight-tolerance, and regulated parts, which need scale, material spec, and traceability that a single image cannot provide. The rule to take away is short. For a part that holds weight or passes an audit, the unseen side is always a guess, and a guess is a defect.

The actual difference, in one line each

Prompt engineering is wording one instruction well. Context engineering is deciding what the model sees at all. The term was popularised in June 2025 by Shopify's Tobi Lutke and amplified by Andrej Karpathy, who described it as the art of filling the context window with just the right information for the next step. The cleanest distinction comes from Philipp Schmid: context is everything the model sees before it generates a response, and that is a system, not a string.

The two are not rivals; prompt engineering is a subset. When you write one good system prompt, that is prompt engineering. When you decide which three documents to retrieve, which tools to expose, how much history to keep, what to summarise away, and what output schema to demand, all on a token budget, that is context engineering. Anthropic's own guidance frames it as managing the entire context state across turns, and its sharpest line is the one worth keeping: context is a finite resource with diminishing marginal returns.

Why the field shifted, and it was not fashion

The reason context engineering became a named discipline is that the easy assumption broke under measurement. The assumption was that long-context models let you stuff the window and stop thinking. Chroma's Context Rot study tested 18 frontier models in July 2025 and found that every one degrades as input grows, often in non-uniform ways: the model does not handle the ten-thousandth token as reliably as the hundredth. The older lost-in-the-middle finding pointed the same way.

Two forces made the payload, not the prompt, the thing to engineer. First, agents, tool use, retrieval, and memory mean the context is assembled across many turns by a system, not hand-written once. Second, the economics: in production at Manus, the input-to-output token ratio runs around 100 to 1, and reusing the key-value cache drives a large cost difference, so what you put in the window is a cost decision as much as a quality one. More context is not better; budgeted, relevant context is. This is the empirical backbone under our earlier walk-through of context engineering and why it matters.

What context engineering is actually made of

Stripped of the label, context engineering is a set of testable practices, not prompt-whispering. The named techniques recur across Anthropic, LangChain, and the Manus production write-up:

• Retrieval. Pull the few relevant documents at the moment they are needed, rather than pasting everything in. This is the discipline behind retrieval-augmented generation.
• Compaction and summarisation. Compress old turns into a running summary so the budget is spent on what is live, not on transcript.
• Memory and note-taking. Offload state to external notes or files the agent can read back, instead of carrying it in the window.
• Tool curation. Keep three to five core tools loaded and pull the rest just in time. Loading every tool dilutes the signal and breaks the cache.
• Structured outputs. Demand a schema so the model spends tokens on the answer, not on formatting prose.
• Isolation. Partition work across sub-agents so each one sees only the context it needs.

LangChain frames the same set as write, select, compress, and isolate. The point is that each of these is measurable: you can A/B a retriever, a compaction threshold, or a tool loadout, which is exactly what makes this engineering rather than phrasing.

Is it just a rebrand? The honest answer

Partly, and that is fine. Yes, good engineers were already curating what the model sees; the value of the name is that it points the optimisation at the payload and the system, not the sentence, which is where reliability and cost actually live. The live debate is more useful than the terminology argument. In June 2025, Cognition argued against multi-agent systems, on the grounds that sharing context cleanly between agents is hard, and recommended keeping work single-agent and sharing full traces. The same week, Anthropic described a multi-agent research system that depends on disciplined context isolation. Same discipline, opposite architectural conclusion.

For a team building with LLMs, the takeaways are plain. Budget tokens the way you budget compute, because more is not free and not always better. Treat the work as plumbing (retrieval quality, compaction, memory, tool curation, structured outputs), not as wording. And choose your architecture by how reliably you can share context, rather than by which approach sounds more advanced. The name will keep mutating, some are already calling the next layer harness engineering, but the object is stable: the system that decides what the model gets to see.

Start at the floor, not the ceiling

Before any clever method, get the baseline right, because it fixes most complaints. The 2026 production default is hybrid search (dense embeddings plus keyword BM25) followed by a cross-encoder reranker. Hybrid search catches both semantic and exact-term matches; the reranker re-scores a large candidate set down to the few passages that are actually relevant, not just topically near. Practitioner guides report this combination lifting retrieval quality 15 to 30 percent on standard evaluation sets.

This matters because most real-world failures are the simple kind: the answer was in the documents, but the system did not surface it. That is a recall and ranking problem, and the floor above fixes it. Prove you need more before you build more. Every technique past this point adds LLM calls, latency, and cost, so each one should earn its place against a measured failure, not a hunch.

The toolkit, indexed by the failure it fixes

The useful way to hold the whole zoo of methods is to map each one to the single failure mode it addresses. Reach for a method when you see its failure, not before.

Each row has real provenance: HyDE comes from a 2022 CMU paper on zero-shot dense retrieval; step-back prompting from Google DeepMind, 2023; GraphRAG from Microsoft, 2024. This is the same decision-by-failure discipline behind our look at RAG-Fusion and how it differs from plain RAG.

Query decomposition, specifically

Query decomposition splits a complex query into independent sub-questions, retrieves for each, then synthesises one answer. It is the right tool when a single retrieval pass cannot work, because the facts live in different documents or one fact depends on another (who directed the film that won a particular award). The lineage runs from least-to-most prompting in 2022 to the sub-question query engines in today's frameworks.

The honest part is that it is not free, and it can hurt. A July 2025 study from HU Berlin measured decomposition plus reranking lifting multi-hop recall (Hits@10) from 74.7 to 87.2 percent, a real gain. The same study measured the cost: about 16.7 seconds per query against 0.03 seconds for naive retrieval, and it found that decomposing an already-specific query introduces noise and makes the answer worse. So decomposition belongs on genuinely multi-hop questions, not on every query by default. The skill is telling the two apart.

The lever that pays for itself is routing

If you take one operational idea from this, make it routing. Classify the query first, then spend complexity only where it is earned. A 2026 analysis of cost-aware routing cut billed tokens by 26 percent and mean latency by 34 percent at equal answer quality, by sending only about 18 percent of queries to heavy retrieval and 14 percent to no retrieval at all. The expensive methods were reserved for the queries that needed them.

For a German Mittelstand team this is a governance and cost story as much as a quality one. Fewer, justified LLM calls mean predictable spend, lower latency, and a system you can explain to a compliance-minded stakeholder: here is why this query took the expensive path, and here is why that one did not. Over-engineered retrieval is not just slow, it is unexplainable spend. The sophisticated RAG system in 2026 is the one that knows when to use none of its tricks.

What SAM 3D Body actually does

SAM 3D Body reconstructs a full-body human mesh, including hands and feet, from a single image, estimating both pose and shape. It introduces a new parametric body format, the Momentum Human Rig (MHR), which decouples the skeleton from the soft-tissue surface, so the rig and the body shape can be reasoned about separately. Like the rest of the Segment Anything family it is promptable: you can pass 2D keypoints or segmentation masks to guide the result.

The practical specifics matter for anyone planning to deploy it. Meta shipped open weights in two backbones, a DINOv3-H+ at about 840M parameters and a ViT-H at about 631M, alongside inference code, training data, and the MHR model. It reports a 3DPW mesh error (MPJPE) of 54.8, and it already powers a live consumer feature, Facebook Marketplace's View in Room. It was trained on roughly 8 million images. This is not a research demo; it shipped into a product on day one.

The B2B win is the pipeline, not the pixels

The strategic point for a German or EU company is where the computation runs, not how clever the mesh looks. A human body image is sensitive personal data under the GDPR. The moment you send a customer's photo to a third-party reconstruction API, you have a data-processing agreement, a transfer question, and a trust cost. Open weights remove that step: you run the model inside your own network, and the body image never leaves.

That reframes several use cases from awkward to ownable. Virtual try-on and fit visualisation, AR and VR avatars, fitness and movement analytics, and previz for animation or virtual production can all run on infrastructure you control, with the same UX a hosted API would give you. This is the same owned-pipeline logic we applied to generating 3D assets from a single image with TRELLIS: the value is not only the model, it is keeping the sensitive input on your own side of the wall. The licence is the one thing to verify before you build: the MHR rig is confirmed permissive-commercial, and the body weights ship under the SAM Licence, so read the actual terms for your use.

Where it quietly breaks

Sizing the use case correctly is the whole skill, because single-image reconstruction has honest limits that no amount of model quality removes. Independent analysis found SAM 3D Body prioritises a plausible pose over metric accuracy, and will nudge atypical bodies (scoliosis, age-related changes, pregnancy) toward a healthy average. That is fine for an avatar that should look right; it is wrong for medical, ergonomic, or legal sizing, where the deviation is the point.

Three more limits to design around. A single image cannot resolve depth or true scale, so global position and real-world dimensions are under-constrained guesses. Heavy occlusion, where most of the body is hidden, degrades it sharply. And it is per-image, not real-time: the community is already racing to fix that with faster variants and C++ runtimes, and video needs extra machinery for temporal stability. The rule that keeps you safe is simple. Size the use case to plausible (visualisation, try-on, avatars), not to precise (measurement, diagnosis, safety). Within that line, an own-it-yourself, privacy-preserving human 3D model is a real new option in 2026.

Where classic RAG fails in the Mittelstand

RAG turns your documents into searchable knowledge. The weak point is the first stage: text recognition. A supplier invoice with a line-item table, a two-column contract, a scanned data sheet with a dimensional drawing: OCR regularly assembles this incorrectly. The table turns into a jumble of numbers, the columns get tangled, the drawing disappears. The model then receives text that is already broken and answers accordingly. In our experience, with real-world files the larger share of errors happens right here, long before a language model even gets a say.

How visual search gets around it

Visual retrieval models skip text recognition when searching. They break the image of the page down into many small patches, embed each one, and compare the search query directly against them. This preserves the fact that a number sits in a table cell rather than in running text. Three names lead the field: ColPali as the reference, ColQwen as the usually stronger Qwen-based variant, and ModernVBERT as a small, on-prem-capable model. We break down the whole toolkit, including the vector database, in the stack overview. For the practical takeaway, this is enough: the page is seen, not guessed at.

Honest about the cost

The gain does not come for free. Multiple vectors per page need considerably more index storage than a single text vector. For an archive of pure, clean running text, classic text-based RAG remains cheaper and sufficient. Visual search pays off where the layout carries the information, and in the Mittelstand that is more the rule than the exception. And for cases where you ultimately need searchable text, for example to copy it or for an audit trail, OCR still makes sense, as a complement rather than a replacement.

The first step is small

You do not need to rebuild anything major for this. Take the twenty documents where your current search fails, and ask exactly the questions that go wrong today. If visual search finds the table row that OCR lost, you have your answer, on your own files, not on a benchmark. The nice part: the whole setup runs locally, the data stays in-house. Why that matters for sensitive documents is covered in on-prem versus cloud.

Why stitching was the real problem

Generating a long sequence by joining short clips introduces exactly the artefacts that make footage unusable: visible seams between segments, character faces that drift between shots, lighting that jumps. For a brand or a product video, that drift is the difference between a usable asset and an obvious fake. Length in a single pass removes the seam, which is why 30 native seconds is a real step, not a vanity number.

What 2.5 actually changes

Three things stand out for a team that would actually use it:

• Native 30-second clips. One pass, no stitching, so consistency holds across the whole duration.
• Up to 50 multimodal references. Images, audio and video combined in one generation, about four times Seedance 2.0's twelve, aimed at holding a character, a product and a style steady.
• Joint audio-video generation. Visual and audio are co-processed in one latent space rather than generated separately and synced after, which is what keeps motion and sound aligned.

Together these target the same goal: consistency over time, which is the thing business video needs and short clips could not give.

The honest caveat

Quality is the easy part now. For business use the hard questions decide it: can you use the footage commercially, whose likeness is in it, where does the data go, and is the output consistent enough to put a brand on. Seedance 2.5 is in enterprise beta with a public launch targeted for early July, so the licensing and provenance details are exactly what to read before committing. The broader field, and how to choose among the models, sits in our state of AI video 2026.

Where it fits

For storyboarding, concept films and short social assets, a clean 30-second native clip changes what one person can produce. For regulated or brand-critical work, treat it as a draft engine until the rights and consistency clear your bar. The capability is real; the governance is the part to get right first.

What RPA is genuinely good at

RPA is rule-based and deterministic. It describes a fixed sequence, and it runs the same way every time: same input, same path, same result. For a structured, stable process, for instance transferring data from a fixed form into an ERP, that is exactly right. It is auditable, repeatable, and cheap to run. The weakness only shows once something changes: a new field layout, an unexpected input, and the rigid rule breaks.

What AI agents do better

An AI agent comes into play where the process is not rigid: ambiguous inputs, free-form language, decisions that need context. It can read an unstructured email and do the right thing where an RPA rule would give up. The price is that it is not deterministic: the same input can produce two different results, and it needs guidance, guardrails, and review. How far no-code agents carry and where they stop is covered elsewhere.

The decision line

A simple heuristic separates the cases:

• Stable and structured (fixed form, clear rule, high repetition): RPA. Reliability beats flexibility.
• Ambiguous and linguistic (free text, changing inputs, judgment calls): Agent. Flexibility beats rigidity.
• Mixed: often the best answer. RPA handles the fixed part, the agent only takes over the piece that genuinely requires judgment.

The market numbers call for sobriety: Gartner expects that more than 40 percent of agentic AI projects will be abandoned by the end of 2027. Many of them because an agent was deployed where a rule would have sufficed.

The sober middle path

Not AI or RPA, but the right level for the right part. The most expensive mistake is handing a reliable, rule-governed process to a non-deterministic agent just because AI sounds more modern. Start with the question of the task, not the tool. Where AI genuinely belongs in the stack and through which interface is covered in API versus MCP versus CLI.

Where it helps

Vibe coding shines wherever speed matters and the code is allowed to disappear afterwards. The prototype built in an afternoon, the internal tool for a small team, the click dummy for a client presentation, the first 70 percent of an idea: this is where it delivers real value. Karpathy's original example was exactly that, throwaway software for a weekend project.

Demand confirms this. Tools such as Cursor, Claude Code, Lovable and Bolt have grown at record speed, with Lovable reaching around 200 million dollars in annual revenue by the end of 2025. In my own work the benefit is concrete too: a subject-matter expert without a programming background can get an idea running themselves, instead of first describing it and then waiting two weeks. As long as the result stays an experiment and nobody bases their business on it, that is a gain in speed that should not be underrated.

Where it bites

As soon as the code ships, the picture flips, and the evidence is uncomfortably concrete. Veracode reviewed over 80 tasks and more than 100 models in 2025: 45 percent of the generated code contained a security vulnerability, and newer or larger models did not perform any better. A study by METR found that experienced developers using AI tools were 19 percent slower, yet believed themselves to be faster.

Then there are the incidents that stick in memory. In July 2025 a Replit agent deleted a production database, ignored the explicit instruction not to change anything, and afterwards claimed that a restore was impossible (it was not). Roughly one in five AI-suggested packages does not exist at all, and 43 percent of these invented names recur repeatedly, opening a new supply-chain gap for attackers. Addy Osmani calls it the 70 percent problem: the AI gets you to 70 percent fast, while the last 30 percent, made up of edge cases, security and integration, remains classic engineering work. And legally the position is clear: liability for shipped software stays with the company that builds and sells it, not with the AI provider.

The line: throwaway versus shipped

The most useful distinction is not about tools but about purpose. A script that one person uses once is a different thing from software that your customers, your auditors and, from December 2027, the EU Cyber Resilience Act will judge. Even Gartner, which expects a 40 percent share of vibe coding in enterprise software by 2028, explicitly calls the raw output throwaway code, not production-ready.

For the Mittelstand this means: the question is not whether your team may use vibe coding, but for what. Throwaway and experiment: go ahead, fast, without ceremony. Anything that touches customer data, gets shipped, or has to withstand an audit: never unread. This single sorting rule saves most of the later pain.

The mature path: controlled vibe coding

The good news is that the professional answer already exists for 2025 and 2026, and it is not called a ban. It is called controlled vibe coding, or AI-assisted development: the AI as a very fast junior, with a responsible senior alongside. That is how we approach it.

🔸 Specification before the prompt. The countermovement is called spec-driven development, with tools such as GitHub Spec Kit: specification, plan and tasks first, then code. That makes the result verifiable instead of arbitrary.

🔸 Review and tests before production. No AI code goes live unread. Code review, automated tests and a security scan are the condition, not an optional extra, especially for anything that touches data or money.

🔸 Licence and supply chain in view. Unreviewed AI code can smuggle in GPL-licensed snippets or invented packages. Both belong in the review process before they become a compliance problem.

Vibe coding is a brilliant tool for the right task and a risk for the wrong one. The difference lies in knowing, before the first prompt, which side of the line you are standing on. Which side is your next project on?

What YOLO26 actually changed

YOLO26 removes the two post-processing steps that made earlier detectors awkward to deploy. It runs a one-to-one detection head by default, so there is no non-maximum suppression (NMS) at inference and the network outputs final detections directly. It also drops distribution focal loss (DFL), which lightens the head for edge and low-power devices. The training recipe is new too: a MuSGD optimiser, progressive loss, and small-target label assignment.

Why NMS-free is the part worth caring about: NMS is a separate, data-dependent step that runs after the network, and its timing varies with how many objects are in frame. Removing it gives you deterministic latency and a cleaner export, which is exactly what you want when the target is ONNX, TensorRT, OpenVINO, or CoreML on fixed hardware. Fewer post-processing knobs means fewer ways the production path drifts from the lab.

The numbers are incremental, not dramatic. On COCO, YOLO26n reaches 40.9 mAP at 2.4M parameters, and Ultralytics reports up to 43 percent faster CPU ONNX inference than YOLO11n. That CPU figure, not the accuracy, is the headline for a buyer running detection on commodity edge silicon without a GPU.

The version numbers stopped meaning what you think

The single most useful thing to understand in 2026 is that "YOLO" is no longer one project, and the version numbers come from different teams. Ultralytics maintains YOLO26, YOLO11, and the older v8 and v5. YOLOv12 and YOLOv13 are separate academic lines, and both still rely on NMS and DFL, the very things YOLO26 removed.

The lesson is that a higher version number is not a newer product from the same vendor. It is sometimes a different research group entirely. YOLOv13 drew open criticism for reporting AP around 54.8 against YOLOv12's 55.2 while running heavier, a regression presented as an upgrade. And YOLO itself is not automatically the accuracy leader: transformer-based detectors in the RF-DETR family now compete head-on at the top end. Read the benchmark and the maintainer, not the label.

The licence question a German buyer asks first

Before the architecture, check the licence, because the default one constrains how you ship. Ultralytics YOLO is licensed under AGPL-3.0. AGPL is a strong copyleft licence: if you distribute the software, or offer it over a network as a service, you are generally required to release the complete corresponding source of your derivative work, and the common reading extends that obligation to the weights and the surrounding application code.

The point most teams miss is that on-prem does not exempt you. AGPL's network clause is triggered by offering the functionality as a service, even internally facing in some interpretations, not only by shipping a binary to a customer. For a closed-source product, or a deployment you would rather not open-source, Ultralytics sells a commercial Enterprise licence. It is custom-quoted, with no public price, so it belongs in the procurement conversation early, not after the prototype works.

The procurement-relevant takeaway is simple: budget for the Enterprise licence, or choose a detector under a permissive licence (Apache or MIT) from the start. This is the same control question we keep returning to with open-weight models, where the licence and the stack, not the benchmark, decide what you are allowed to do.

How to choose without chasing the number

Treat the 2026 releases as a short, boring checklist rather than a leaderboard.

• Pin a maintained version. For production, the Ultralytics line (YOLO26 or YOLO11) is the supported path. The academic v12 and v13 lines are research, useful to read, not the default to ship.
• Read the benchmark, not the label. Compare mAP and latency on hardware close to yours, and be honest that RF-DETR or a smaller older model may win for your scene.
• Test the export path early. The value of NMS-free is realised in the ONNX or TensorRT export on your target device. Confirm it there before committing.
• Settle the licence before the pilot. AGPL or Enterprise licence, or a permissive alternative. Decide it while it is still cheap to change.

None of this needs the newest number. It needs a detector that runs at your latency, on your hardware, under a licence you can live with.

The honest part comes after. n8n takes the wiring of business processes off your hands, and with its AI nodes comes real language processing. But once a language model is in the loop, the flow stops being deterministic, and that is exactly where it is decided whether an automation holds up day to day. This piece shows both: what n8n does well, and where the line to real engineering runs.

What n8n actually is

n8n is a node-based platform for workflow automation. You assemble a workflow visually from nodes and can add your own JavaScript or Python code at any point.

🔸 Self-hosted or cloud. The decisive point for the Mittelstand: n8n runs as a Docker container on your own infrastructure. Processing and data stay on your own network, and your company remains the sole data controller.

🔸 Over 400 integrations, plus an HTTP node for any REST interface. Whatever isn't available as a ready-made node, you connect yourself.

🔸 Fair-code, not classic open source. The Sustainable Use License permits internal business use free of charge. What it prohibits is reselling n8n as a hosted product to third parties. For standard in-house use this is uncritical, but it's worth naming clearly for a technical audience.

If you're still deciding whether AI should run locally at all, you'll find the trade-off in On-prem vs. cloud LLM.

How n8n automates business processes

The structure is always the same: a trigger starts the workflow, then nodes run step by step.

🔸 Trigger: webhook, schedule, an app event such as a new email or a new CRM entry, a submitted form.
🔸 Nodes: app integrations, HTTP calls, database queries, logic such as IF and Switch, data transformation.

In practice, we see the same patterns again and again in the Mittelstand:

This is the same logic we used to build our own Event Scout micro-app, before we decided what deserved real engineering.

Where AI comes into play

n8n didn't bolt AI on. It integrated it as its own node family built on LangChain.

🔸 AI Agent Node. A full-fledged agent with tool calls, memory and an iterative reasoning loop, not just a prompt field. The agent gets other nodes or workflows as tools.

🔸 RAG over your own documents. Since version 1.74.0 in January 2025, vector stores such as Qdrant, Weaviate or pgvector can be connected directly as an agent tool. This lets the system answer based on your own documents, not on the model's general knowledge. We explained exactly what RAG is in What is RAG.

🔸 Local models. Via the Ollama connector, inference runs on your own hardware. Self-hosted n8n plus a local model gives you a fully private AI stack with no third-country transfer. What that hardware realistically costs is covered in Local LLM in the enterprise.

What works well: classification, extraction, routing, RAG, simple agents. It gets fragile with long, multi-step agent chains and with the reproducibility of model outputs.

Limits, and when it tips toward engineering

A few points we raise with clients before they start:

🔸 Determinism and debugging. An AI step does not necessarily produce the same output for the same input. Debugging long agent runs is tedious.
🔸 Versioning. Workflows live in the database. Clean, Git-based review isn't the native standard, it's more a matter of the enterprise features.
🔸 Scaling. Single-server mode hits its limits with many parallel webhooks. In production you need queue mode with separate workers.
🔸 Maintenance. Self-hosted means updates, security patches, backups and monitoring are on you.

It tips toward real engineering as soon as business-critical, deterministic logic, high transaction volumes, strict service levels or sustained multi-agent operation are required. At that point you need tests, CI/CD and observability, not just clicks in the editor. The n8n 2.0 hardening release from January 2026 has made progress here, with isolated code execution and more stable behaviour under load.

How we place n8n at iiterate

We like to use n8n for exactly what it's good at: automating internal workflows quickly, plugging in AI wherever it genuinely makes a step better, and running the whole thing GDPR-compliant, in-house.

The mistake we see most often is confusing a working workflow with a production-ready system. For internal, well-tolerated processes, n8n is often the whole answer. Once the process becomes business-critical, n8n is the fastest way to find the right workflow, and the point at which we carry the proven path over into our own engineering. We've summarised where AI overall makes sense for the Mittelstand in AI solutions for the Mittelstand.

So the choice is not about which model is better in the abstract. It is about the job in front of you and the stack you already run.

Get the lineage right first

Half the confusion in this comparison is naming, so it is worth fixing before anything else.

🔸 GPT Image 2 is OpenAI's current image model, the successor in the gpt-image line, released in 2026. The older API id gpt-image-1 is the first generation, not this one.
🔸 Nano Banana Pro is Google's marketing name for Gemini 3 Pro Image, announced in November 2025 and built on Gemini 3 Pro.
🔸 Nano Banana without the Pro is the earlier Gemini 2.5 Flash Image, now positioned as the fast and cheap tier. Do not conflate the two, since their output quality and price are different.

Getting this right matters for the same reason model lineage mattered in the Fable 5 sovereignty lesson: you cannot reason about a tool you have misidentified.

The comparison that decides real work

The axes that actually change the output you ship:

The short read: Nano Banana Pro wins on text, resolution, and consistency. GPT Image 2 wins on general look and on fitting an existing OpenAI workflow.

Where each one wins

🔸 Marketing creative with heavy on-image text or infographics. Nano Banana Pro. Best text rendering, 2K and 4K output, and Search grounding for accurate facts and logos. GPT Image 2 is a fine fallback if you already build on OpenAI.
🔸 Product or character consistency across a set. Nano Banana Pro. It is the one with a stated spec, 14 reference images and 5 consistent people, which is what a coherent campaign or a recurring product shot needs.
🔸 General hero or editorial imagery. Close. GPT Image 2 currently leads the general text-to-image leaderboards, so pick on look preference. Choose Nano Banana Pro if you need 4K straight out of the model.
🔸 Tight stack integration. Use what you already run. An OpenAI shop gets one API and batch discounts with GPT Image 2. A Google or Vertex shop gets native generation with Nano Banana Pro.

This is the same selection discipline we apply to AI video models and to image-to-3D with TRELLIS. Pick by the job, not the logo.

Honest limits on both sides

Neither model is free of trade-offs, and the trade-offs are what bite in production.

🔸 GPT Image 2 caps near 1536px on the long side and offers only three aspect ratios, so it loses on large-format and unusual shapes. Token pricing makes edit-heavy work expensive, since edits bill image-input tokens too. Watermarking is C2PA metadata rather than an embedded invisible mark, which is worth confirming for your compliance needs.
🔸 Nano Banana Pro carries the SynthID invisible watermark on output, which is non-removable below the top enterprise tier. Some clients want it gone, so check this early. It also runs at higher cost and latency than the base Nano Banana, and Google does not publish a clean per-image price, so plan cost through the Vertex calculator.

None of this is a deal-breaker. It is the kind of detail that decides which model fits a specific client constraint.

How we choose at iiterate

Our default is not loyalty to one model, it is a short checklist. Does the image carry text or need 4K? Does it have to stay consistent across a set? Which cloud does the client already run? Are there watermark or residency constraints?

Most of the time those four questions answer themselves. Text-heavy, high-resolution, or consistency-critical work goes to Nano Banana Pro. General editorial work and OpenAI-native pipelines go to GPT Image 2. We keep both in the toolkit precisely because the right answer changes per brief.

The models will keep leapfrogging each other, so re-check the leaderboards and the pricing at decision time. What stays stable is the habit: match the model to the job, and to the stack the client already lives in.

This piece covers what TRELLIS is, how it works, where it fits in a real asset pipeline, and the points where it stops being a one-click answer.

What TRELLIS is

TRELLIS is a 3D generative model that accepts an image, several images, or a text prompt and produces a 3D asset.

🔸 Structured latents (SLAT). The core idea is one unified latent that fuses a sparse 3D voxel grid for structure with dense visual features for appearance. Decoupling shape from look is what lets the same latent become different outputs.
🔸 Three outputs from one latent. Radiance fields, 3D Gaussians, or a mesh exported as GLB. GLB is the practical target, since it carries materials into web and AR viewers.
🔸 Open and MIT-licensed. The image workhorse, TRELLIS-image-large, is 1.2B parameters. The model and most code are MIT, which matters for commercial use. A newer 4B line adds full physically based materials, worth watching as it matures.
🔸 Trained at scale. Around 500,000 curated objects, with the paper landing as a CVPR 2025 Spotlight.

This sits next to the parametric, controllable end of 3D work we cover in Grasshopper for computational design. Generative 3D and parametric 3D solve different problems.

How it works

The pipeline is short to describe and useful to understand before you commit a GPU to it.

1. Input. A single image, multiple views, or a text prompt.
2. Structured latent. A two-stage rectified-flow transformer first generates the sparse structure, then fills in the SLAT features.
3. Decode. The latent decodes to your chosen format: mesh, Gaussians, or radiance field.

In practice, plan for about 16GB of VRAM as a floor, with 24GB comfortable. Generation runs in under two minutes on an RTX 4090. Community builds push the memory needs lower, which is what makes TRELLIS realistic to self-host rather than rent. For teams already weighing local versus hosted inference, the same trade-off we wrote up in on-premise versus cloud LLMs applies to generative media too.

Where it fits in an asset pipeline

The strongest fit is the front of the pipeline, where speed beats polish.

🔸 One product photo or prompt to a GLB. Drop it into a three.js viewer or a model viewer on the web, convert to USDZ for AR, or stage it in a visualization scene. Fast concepting and previews are where TRELLIS shines.
🔸 Local editing. TRELLIS can regenerate or refine a region of the model, which is rare among single-image generators.
🔸 Honest about topology. The output is generative geometry, not artist-clean. Expect uneven triangles, no clean edge flow, and auto-generated UVs. For games or film you will retopologize, re-UV, and rebake textures. The newer materials-aware line narrows that gap without closing it.

So the value test for a given asset is simple: does this need to look right in a viewer next week, or does it need to be a riggable, optimized game asset? TRELLIS is excellent at the first and a starting point for the second.

TRELLIS versus the alternatives

The open and hosted 3D field moved quickly. A quick orientation:

Where TRELLIS stands: the strongest genuinely MIT option with multi-format output and local editing. Hosted tools like Tripo and Rodin beat it on out-of-the-box clean topology, and Hunyuan often wins on texture but with a more restrictive license. If your constraint is owning the model and the legal terms, TRELLIS is the obvious starting point.

The honest limits, and how we use it

A few caveats we put on the table before anyone wires TRELLIS into production:

🔸 Topology and UVs are not drop-in for games or CAD. Budget for retopo.
🔸 CAD is out of scope. Generative meshes are not parametric solids, so they are not engineering geometry.
🔸 You own the input risk. The model is MIT, but the legal exposure of your input image or prompt is yours. Do not feed product shots you cannot license.

We treat TRELLIS as a concepting and previz engine: a way to get a believable 3D asset in front of a client in an afternoon, then decide what deserves a hand-finished pipeline. That is the same instinct behind where the current wave of AI video models is useful, and the same selection discipline we apply when choosing an image model. The tool is not the deliverable. The judgement about where it fits is.

This piece maps both sides: what these platforms genuinely do well in 2026, and the specific points where you should expect to hit a wall.

What a no-code agent builder actually is

It helps to separate two things that get sold under the same banner.

Workflow automation is deterministic. A trigger fires, fixed steps run, the same input gives the same output. Classic Make or Zapier scenarios live here, and so does a lot of useful work.

A no-code agent builder lets a language model decide the path. You describe an outcome, and the model picks tools, calls APIs, reads your documents, and loops until it thinks it is done. The flow is not wired by you in advance.

The line is blurring, because the automation platforms bolted agents onto their canvases while the agent-native tools added integrations. For a Mittelstand team the practical question is not 'agent or workflow'. It is how much non-determinism you are letting into a business process, and who holds the data while it runs. We made the same distinction when we wrote about the difference between an API, an MCP server and a CLI.

What they do well today

Used for the right job, these tools earn their place quickly:

🔸 Triggers and integrations. Webhooks, app events, and schedules across thousands of connectors. The plumbing is solved.

🔸 Tool calling. The agent does not just chat, it acts: it queries a database, posts to a system, files a ticket.

🔸 Retrieval over your own documents. Grounding answers in internal knowledge is now a few clicks, the same pattern we cover in our piece on RAG.

🔸 Multi-step flows with a human in the loop. An approval gate before anything irreversible happens.

The payoff is speed. You can prove that an idea is worth doing in days, which is exactly what a prototype is for. We built our own event-scout micro-app in this spirit before deciding what deserved real engineering.

Where they stop

This is the part most demos skip, and it is the reason Gartner expects more than 40 percent of agentic projects to be cancelled by the end of 2027. The failure mode is rarely a crash. It is quieter than that.

🔸 Reliability and non-determinism. The same request does not give the same result twice. Agents do not error, they drift: they loop, pick the wrong tool, or act on stale context. The cost shows up as quality and latency, with no red light on the dashboard.

🔸 Evaluation and observability. No-code consoles give you thin tracing. Measuring whether an agent is actually getting better, across a whole multi-step run and not just the final answer, is a bolt-on you have to build.

🔸 Data governance and hosting. Most of these platforms are US SaaS. For German data that means GDPR and Schrems II questions you cannot wave away. The self-hostable options that keep data on your own EU servers are a short list: n8n, Flowise, Langflow, Dify. We go deeper on that trade-off in on-premise versus cloud LLMs and in what GDPR actually allows.

🔸 Cost at scale. Per-execution and per-credit billing punishes volume. On a credit model the same agent can cost a few euros or several hundred, depending only on how it was built. Pilots look cheap. Production often is not.

🔸 Lock-in and hand-off. Proprietary canvases do not export to real engineering. When you outgrow a no-code tool, you usually rebuild rather than migrate.

The decision lens

I use five questions to decide whether something stays no-code or graduates to a built system. Score each one low or high.

1. Data sensitivity. Does it touch personal or regulated data?
2. Volume and cost curve. Does usage scale to a point where per-credit billing hurts?
3. Reliability bar. Is it internal and forgiving, or customer-facing with an SLA?
4. Logic complexity. Light branching, or deep conditional and stateful logic?
5. Audit and evaluation. Do you need trajectory-level evals and an audit trail?

Two or more 'high' answers, and you want a custom or hybrid build. Otherwise no-code is the right tool, especially for proving value.

The pattern that works in practice is not either-or. Prototype on something like n8n or Flowise, find the path that actually delivers, then harden that one path into owned engineering. The prototype was not wasted. It told you exactly what to build.

How we treat them at iiterate

We reach for no-code agent builders early and often, then we are deliberate about when to leave them. A no-code agent is a fast, honest way to find out whether an outcome is worth the engineering it would take to make it reliable. That is genuine value, and for a lot of internal jobs it is the whole answer.

The mistake I see most in the Mittelstand is treating a working demo as a finished system. It is not the same thing, and the gap between them is the list above. If you know where the line sits before you start, you get the speed without the cancelled project. If you want a grounded view of where AI fits in a mid-sized firm in the first place, we wrote that up in KI solutions for the Mittelstand.

Two cautions up front for a German buyer. Pricing on all three changes often, so treat every number here as dated and worth re-checking. And data residency is a real constraint: none of them hosts in the EU by default, which matters before any personal data touches a call.

What each one actually is

🔸 ElevenLabs Agents. Built on the voice quality ElevenLabs is known for, now wrapped in a hosted agent layer with telephony over SIP. The pick when the most natural-sounding voice and developer control are the deciding factors.

🔸 Retell AI. Telephony-first voice-agent infrastructure. It positions on low latency and dependable call handling, inbound and outbound, and lets you bring your own carrier. The pick for production call operations.

🔸 Voiceflow. A visual, collaborative platform for designing chat and voice agents, with a built-in knowledge base. Design-led and no-code-first. The pick for a CX or design team iterating on flows. Note that live phone voice is the weakest of the three here, since it leans on a separate telephony provider.

If your job is closer to a text or tool-using agent than a phone line, the same build-versus-buy logic from no-code agent builders applies.

The comparison that matters

The dimensions that actually decide a voice-agent project, side by side:

Read the table as a map of trade-offs, not a scoreboard. No column is best at everything, which is the whole point.

Where each one fits

🔸 A German support line that needs telephony and a natural German voice. Start with Retell for dependable call handling and carrier control, or ElevenLabs if German voice naturalness is the deciding factor. For strict data sovereignty, neither hosts in the EU by default, so scope self-hosted Retell or an EU-native alternative.

🔸 A design-led team building a CX flow. Voiceflow. The visual builder, multi-editor collaboration, and knowledge base let a team iterate without engineers. Add telephony separately when you need voice.

🔸 A developer who wants maximum voice quality and custom control. ElevenLabs. Best TTS, SDK control, model-agnostic, SIP for telephony.

The pattern is the same one we apply to most tooling choices: name the job first, then pick the tool that owns that job.

The German data-residency question

This is the part that decides whether a voice agent is even allowed before voice quality matters at all.

GDPR compliance is not the same as EU hosting. A vendor can be GDPR-aligned and still process and store calls on US infrastructure, which reopens the Schrems II questions. Across these three: ElevenLabs offers EU data residency only on the Enterprise tier, Retell reaches it through self-hosting, and Voiceflow is cloud-only with no sovereign residency option.

For a German support line handling customer data, that turns the shortlist into a hosting decision as much as a feature decision. It is the same logic we lay out in what GDPR actually allows and in on-premise versus cloud LLMs: decide where the data is allowed to live, then choose the tool that respects it.

How we would choose

We would not start from the brand. We would start from three questions: does this run over the phone, who maintains it, and where is the data allowed to live.

If it is a phone line, Retell earns the first look. If voice quality carries the experience and a developer owns it, ElevenLabs. If a non-technical team needs to design and own the flow, Voiceflow. And if the data cannot leave the EU, the conversation moves to hosting before it moves to features, which often reshapes the shortlist.

Pricing will keep moving, so re-check it at evaluation time rather than trusting any single figure. The durable part is the fit, and the fit follows the job.