Should AI Functionality be an extension?

Should AI be moved to an extension?

Should AI Models be moved to sub-extensions? (or extensions that add to the extension?)

Using 7.x/8.x now and wondering if this would be better served / updated as an extension? (as it’s not really core imho)

7 Likes

I agree with this thought. Maybe worth consideration.

1 Like

100%

1 Like

I would agree with this as well.

1 Like

depends on how tight the coupling is tho. if AI needs to stay synced with core changes, keeping them separate could just add headaches.

email is an extension and is coupled.

AI in Lucee is already built the way you’re asking for. Like many parts of Lucee (datasources, caches and file systems such as S3), AI sits on a public interface, and core simply ships a few implementations of it.

The interfaces (lucee.runtime.ai.AIEngine, AISession and so on) have been in the loader since 7.0, so they are public API that any extension can implement. Core comes with three engines: OpenAI (which also covers Ollama, Perplexity, DeepSeek and other OpenAI-compatible endpoints), Gemini and Claude.

Each engine also comes with an admin driver. That’s just a simple component that describes the settings, so you can set up an endpoint in the Lucee admin. An extension can ship its own driver the same way: put the component in the extension and your engine gets its own form in the admin.

The built-in engines don’t add any library. They only use what core already has anyway (Apache HttpClient, the same one cfhttp uses, plus Lucee’s own JSON handling), so they’re very small. Moving them into an extension wouldn’t take anything heavy out of core. It would only add one more thing to install for a feature that’s becoming pretty essential.

If you want a different provider, or want to replace one of the built-in ones, you can do that today with your own extension. We’ve written a recipe that walks through it step by step, with a working example engine and admin driver: Creating an Extension that provides an AI Engine