Embarcadero are looking for submissions of projects built in Delphi and C++Builder, using the new Kai IDE tooling.
2 Likes
It took me ages to learn how to surf…
1 Like
@ianbarker You should have tried one of those AI tools that can make it look like you’re doing something when you’re actually not.
Think of how much time that would have saved.
2 Likes
We would have saved a fortune in purple food dye too when trying to turn the sea “Kai colored”. 
1 Like
@ianbarker
Has there been any discussion in video, or blogs, or wherever about Kai vs CodeBot vs any other tools?
Not that I am aware of. Usually I personally wouldn’t do a kind of comparison thing (for example “TMS vs DevExpress” etc. I also don’t allow our team to do any “Microsoft vs Embarcadero” kind of articles either, even if they make a good case for us being better in some way. I don’t agree with it and, luckily, I get a veto, which I use if somebody gets a bit carried away. 
CodeBot is excellent, and I said as much previously in webinars. Kai/CodeBot have differences in how they do things, and there are other systems around too (and I expect there will be more to come) which provide their own interpretations of agentic AI, either outside the IDE but working with it, or inside the IDE.
A lot of it all depends on the AI LLMs and chosen models, too. Right now, using Claude with Fable 5 has been godlike for some people but I’ve also seen a lot of people in the Anthropic Subreddit saying it has been butchered to the point of uselessness. I also read rumblings about other governments such as the Chinese who are also waking up to the idea that very capable LLMs in the hands of mere mortals might be a Very Bad Idea. The US already freaked out, and I am sure Europe is not far behind in the AI panic.
This is why we can’t have nice things.
1 Like
Yeah he’s wrong - the models are nothing to do with Kai at all. When he says “all supported models” - that’s inaccurate. The available models are whatever your provider issues/hosts.
I have not played with hosted models for Kimi - they are enormous to host locally unless you use some ridiculous quantization. Kimi 3 in GGUF format, for example. is 595gb.
Personally, I have found the Qwen 3 models to work the best and I have tried them in Ollama, oMLX, and LM Studio. I do have a fairly beefy Mac so my preference is oMLX although LM Studio has some great extra toys like the Locally app which is awesome.
For the models hosted by Moonshot AI for Kimi it looks like they support an API which could theoretically work with Kai. We have an update coming that would definitely sort that.
With regard to “I don’t want this hosted on American servers” - they do realize that Kimi is Chinese, right? I have no objections at all to any nation (our only politics are tabs v spaces and our only religion is Delphi) - just a bit odd that they are wanting to avoid non Euro territorial hosting and go with a Chinese provider. I’m not sure that achieves the compliance effect they were looking for 
Woah there, big fella, no need to get all passive-aggressive over perceived anti-American bias.
Whilst Ian’s response is technically correct in places, it doesn’t fully engage with what Harald was actually saying.
Harald’s key points are:
. He is legally prohibited from using U.S.-hosted models.
. He is looking for European-hosted inference providers (he mentions TensorX specifically).
. He wants to use models such as Kimi-K3 and GLM 5.3 hosted on those European providers.
. He believes the models currently supported by Kai are U.S.-hosted.
Against that background, Ian makes several assumptions.
Assumption 1: Harald thinks Kai “supports models”
Ian writes:
“the models are nothing to do with Kai at all.”
But Harald never actually says Kai contains the models. He says:
“all supported models in KAI are U.S. hosted.”
That sentence is admittedly imprecise, but it can equally mean:
“All of the providers Kai currently knows how to talk to are U.S.-hosted.”
That’s a very different claim.
So Ian may be correcting a misunderstanding that Harald never actually had.
Assumption 2: Harald wants Moonshot’s Chinese API
Ian immediately pivots to discussing Moonshot AI:
“they do realize that Kimi is Chinese, right?”
But Harald never says he wants Moonshot’s servers.
He explicitly says:
“TensorX which is European hosted”
In other words, Harald appears to want:
European infrastructure
running Chinese-developed models
Those are completely different things.
Modern AI models are routinely hosted by third parties.
Assumption 3: The origin of the model matters more than where it is hosted
Ian treats:
“Chinese model”
as if it necessarily implies
“Chinese hosting”.
Harald appears to distinguish them.
That’s an important distinction.
For many organisations, compliance concerns revolve around:
. where inference occurs,
. where data is stored,
. which legal jurisdiction governs the provider,
rather than who originally trained the model.
You can quite plausibly have:
. French-hosted Llama,
. German-hosted Qwen,
. Dutch-hosted Kimi,
and satisfy an organisational policy that forbids U.S.-hosted services.
Assumption 4: Harald’s legal concern is about geopolitics
Ian jokes:
“I’m not sure that achieves the compliance effect they were looking for.”
But Harald never mentions politics.
He says:
“We are legally bound…”
That sounds much more like:
. procurement rules,
. contractual obligations,
. data sovereignty,
. classified work,
. government regulations,
than a personal preference.
Those requirements may have nothing to do with whether China is “better” than America.
Assumption 5: API support is theoretically enough
Ian says:
“they support an API which could theoretically work with Kai.”
That’s fair, but Harald wasn’t asking whether it was theoretically possible.
He was asking whether anyone had actually connected Kai to:
. TensorX,
. European Mistral hosting,
. DeepSeek,
. Kimi,
. GLM.
Those are practical interoperability questions.
One point where Ian is probably right
If Harald literally believes:
“Kai only supports U.S.-hosted models”
then Ian’s correction is important.
Kai doesn’t inherently limit you to OpenAI or Anthropic.
It’s simply an IDE client.
If Kai allows custom OpenAI-compatible endpoints (or will shortly), then Harald’s desired setup may indeed become possible.
Reading Harald’s post, I think the real question is:
“Can Kai connect to arbitrary OpenAI-compatible endpoints hosted by European providers such as TensorX, regardless of whether the underlying model is Kimi, GLM, Mistral, or Qwen?”
Ian mostly answers a different question:
“Kimi is Chinese, not American.”
Those two questions intersect, but they are not the same.
So I’d say Ian slightly misread Harald’s concern. Harald’s emphasis is on hosting jurisdiction and API connectivity, whereas Ian focuses on the nationality of the model developer. In many compliance environments, those are separate issues, and it’s entirely plausible for a European-hosted deployment of a Chinese-developed model to satisfy organisational requirements while a U.S.-hosted deployment would not.
Prepared by your friendly local American-hosted LLM
No, I understand, but isn’t Moonshot AI based in China? Moonshot produce and host Kimi. It is, of course, downloadable in various formats from all sorts of providers like HuggingFace.
I thought he was referring to hosted LLMs but of course from what you’re saying I misunderstood. If he’s using Kimi on hosting from elsewhere then I assume his hosting concerns go away - or at least they do until Brussels declares war on New Zealand or whatever other insanity the current World order can throw up Nowadays science fiction and John le Carré can’t keep up.
Kai definitely does not only support US providers - it’s the exposed API which is important, not necessarily the endpoint’s provider. For example, you can use an Ollama API against some kind of weird non Ollama hosting as long as whatever it exposes is compatible with the Ollama API. Same with LM Studio. The URL you put in is usually local, or at least on your LAN but it could be elsewhere such as a WAN or web endpoint.
An example of this would be oMLX which I am quite literally using at the same time as typing this. It supports the Ollama API and Kai doesn’t know any different. Shhh, don’t tell it 
We plan to fully support ACP (current aim is in the next imminent release) and that will actually open up a massive number of other providers who support the ACP protocol.