step 01
Frame the question in words
your criteria Write the acceptance criteria as you would explain them to a new inspector. That prompt is the specification, it is versionable, and changing it does not mean retraining anything.
use cases · Visual inspection
Ask a model what it sees
A photo of a weld, a dented bumper, a substation, a shelf. Describing what is in an image and judging it against your own criteria used to need a model trained per defect. A multimodal model does it from a written instruction, which changes how fast you can start.
how it works
How it is built.
Three steps, with the component that does the work in each one.
step 02
Look and judge
gemma-4-26b The multimodal model takes the image and returns a structured verdict with the reason it gave it. The reason matters more than the verdict: an inspector who cannot see why will not trust the tool twice.
step 03
Escalate the exception
threshold + review queue Clear passes go through, anything uncertain goes to a person with the image and the reasoning attached. The point is to spend human attention on the hard 5% rather than on all of it.
drop-in
Change one line. Keep your code.
Point the OpenAI SDK, or LangChain, LlamaIndex, your own pipeline, at Helmcode. Same calls, same shapes, private models on EU infrastructure.
read_the_docsfrom openai import OpenAI client = OpenAI( api_key="sk-...", base_url="https://api.helmcode.com/v1", # one line changes ) # the acceptance criteria are the prompt: no retraining verdict = client.chat.completions.create( model="gemma-4-26b", messages=[{ "role": "user", "content": [ {"type": "text", "text": criteria}, {"type": "image_url", "image_url": {"url": frame}}, ], }], response_format={"type": "json_object"}, )
why here
Why on Helmcode.
What changes when you run it on open models, on infrastructure you control.
Images are the most revealing payload you own
A photo of your line shows your process, your tooling and your defects to anyone who receives it. A claim photo shows somebody home. This is the case where sending data to an external API is hardest to justify, and it is why on-premise is the usual answer here.
Frames add up fast
One camera at one frame a second is 86,400 images a day. Any per-image price makes you sample; a flat rate lets you look at all of them and keep the ones that matter.
Where it stops
A general multimodal model is excellent at describing and comparing, and it is not a metrology instrument. For a tolerance measured in microns you want a camera and a classical vision system, and we will say so rather than sell you the wrong thing.
industries
Where it is used.
The sectors where this case has traction, each with its own page and its own regulation.
// faq
Visual inspection, answered.
What plant and claims teams ask before a model judges an image.
Do we need to train a model per defect?
Not to start. A written instruction gets you a working prototype in an afternoon, which is enough to find out whether the case is worth the project. If you then need the last few points of accuracy on one repetitive defect, a fine-tuned small model on a dedicated or on-premise plan is the next step.
Can it run at the edge, next to the line?
Yes, and for OT networks that is usually the requirement rather than a preference. The same API runs inside your perimeter, and the smaller open models fit on a single GPU near the process instead of needing a datacenter.
What about video rather than stills?
The practical approach is to sample frames on an event, not to stream everything: the trigger comes from your existing system and the model looks at the frames around it. That keeps the volume sane and the answers specific.
// get started
START BURNING TOKENS
Skip the AI infra work. Deploy your first private inference endpoint today.
Flat rate. EU data. OpenAI API compatible.