Performance: Beyond 13,000 Requests Per Second

If you have been following the web framework’s performance numbers over the releases, you know they have been steadily improving. In 2024r2, benchmarks were sitting at around 8-9k requests per second. In 2026r2, we are beyond 13k. That is a significant jump, and it comes from a fundamental change in how the framework handles connections under the hood.

Xojo Web is essentially a Console project built on top of ServerSocket and TCPSocket. Previously, each incoming connection would spawn a new Thread, process the request, and then that thread would be destroyed. In 2026r2, threads are created when the TCPSocket is created, before the connection even arrives. When a request comes in, the thread is already there, sleeping, waiting. No need to spin one up from scratch. And when a TCPSocket can be reused, so can its thread, meaning fewer kernel calls and less overhead overall.

That said, even with a 50% increase in this benchmark, most developers won’t notice a big difference. When the application has to deal with frequent database queries, for example, shaving a few milliseconds off request handling is a drop in the bucket. But where it does matter, it matters a lot. If your application is a plain REST API serving data for a mobile app with thousands of concurrent users, or when it is deployed to a constrained environment like a Raspberry Pi, this kind of improvement can make a real difference.

SEO Improvements Done Right

In 2026r1 we introduced the ability to call WebPage.Show from within the HandleURL event, which opened the door for serving pages to search engine crawlers. It worked, but it came with a significant cost: even for users who were not using this feature at all, benchmark numbers dropped from 7-8k requests per second down to 1-2k. That was not acceptable (pushing us to review the overall web framework performance on this release), and it also introduced edge cases for codebases that expected HandleURL to run without any session context active, because creating a session context on top of an existing one is not allowed.

In 2026r2, this is fixed properly. The performance penalty is gone for everyone. If you want to use WebPage.Show from HandleURL for SEO purposes, you now opt in explicitly by creating a WebSessionContext instance yourself, passing the requestparameter, before calling Show. It is a small step, but it makes the intent clear and keeps things safe for everyone else.

WebSessionContext has a new Constructor, accepting a request As WebRequest parameter.

We are not stopping here. SEO is important, and we are already working on a proper URL router to make these workflows easier and more capable. Stay tuned!

DatabaseConnection Gets a PerSession Mode

If you use a Database Connection in your web project, you are probably familiar with how they work: you add one to your project in the Navigator, give it a name, say MyDatabaseConnection, and then you reference it by that name anywhere in your code to run queries.

By default, that connection behaves like a singleton. Every session in your web app shares the same MyDatabaseConnectioninstance. For most read-only usage that is fine, but the moment you start using transactions, you can run into trouble. One session’s transaction can interfere with another’s, or worse, data from one session can leak into another’s results.

The new PerSession property in 2026r2 solves this at design time. When you enable it in the Inspector, MyDatabaseConnectionstops being a shared instance. Instead, each session gets its own connection, created lazily the first time that session needs it, and automatically destroyed when the session ends. Your code does not change, you still write MyDatabaseConnection.SelectSQL(...) as you always have, but now you can be confident each session is operating in complete isolation.

WebGraphics Gets DrawPath and FillPath

WebGraphics now supports DrawPath and FillPath, bringing it in line with what Desktop and Mobile targets have had for a while. If you have been writing custom drawing code for other targets using Graphics.DrawPath or Graphics.FillPath, that code can now be reused in your web projects without modification.

This is exactly the kind of cross-target parity that makes Xojo powerful. Check the WebGraphics documentation for the full details on how paths work.

WebImageViewer: Goodbye, Flicker

A small but welcome fix. When updating the Picture property on a WebImageViewer, previous versions would show a brief but noticeable blink, the image would disappear for a few milliseconds before the new one appeared. In 2026r2, the new image is shown directly. No blink, no flicker. It just works.

Wrapping Up

As usual, 2026r2 also includes a solid round of bug fixes across the web framework. Check the full release notes for the complete list. This is a release that delivers on multiple fronts: raw performance, correctness, cross-target parity, and laying better groundwork for SEO. The thread handling changes alone make this a compelling update for anyone running Xojo web apps under load. And with a proper URL router on the horizon, the SEO story is only going to get better.

Happy coding!

Ricardo has always been curious about how things work. Growing up surrounded by computers he became interested in web technologies in the dial-up connections era. Xojo has been his secret weapon and language of preference since 2018. When he’s not online, chances are he will be scuba diving … or crocheting amigurumis. Find Ricardo on Twitter @piradoiv.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Copying

Copying individual members (methods, properties, etc.) from a project item continues to work as before. However, we have added the ability for you to copy some entire project items out of Xojo as text.

Note: When copying a project item (or a member), the Navigator, not one of the editors, must have focus. You can tell it has focus by its color, which is non-gray (green on macOS, for example).

For example, you can select a class (or module or interface) and then paste its contents as text into your favorite text editor, blog editor or AI chat. As an example, here is the DataPoint class (from the Desktop Eddie’s Electronics example project) copied as text and pasted into this post:

Class DataPoint
  Public Sub Constructor(value as Integer, shape as Integer = 0)
    Self.Value = value
    Self.Shape = shape
  End Sub

  Public Function PointNearby(x as integer, y as integer, tolerance as integer = 10) As Boolean
    If Abs(x-Self.x) < tolerance And Abs(y-Self.y) < tolerance Then
      Return True
    End If
  End Function

  Public Property Label As String

  Public Property Shape As Integer

  Public Property Value As Integer

  Public Property X As Integer

  Public Property Y As Integer

End Class

This is surprisingly handy and is a great way to share your code outside Xojo. You can also select multiple project items at once, plus it works with layouts such as Windows, WebPages, Screens and Containers.

Pasting

Pasting code into Xojo has even more improvements. Previously you could paste single members (Methods, Enums, etc., but not properties) into a project item. Now you can paste multiple members at once, including properties. For example, select and copy the list of properties below and paste them onto a project item.

Note: When pasting the project item, the Navigator, not one of the editors, must have focus. You can tell it has focus by its color, which is non-gray (green on macOS, for example).

Public Property Company As String
  Private Property Country As String
Property Address As String
Public Property City As String

Public Property State As String // State code

You can even have different types of members in the selected text, like this:

Public Property Taxable As Boolean
Get
  Const kMax = 42
  Return False
End Get
Set
  Company = "TaxMan”
  Const kMin = 0
End Set
End Property
Public Property Company As String


Public Function Average(A As Double, B As Double) As Double
  Return (A + B) / 2
End Function

And taking things a step further, you can even paste in an entire class:

Class Calculator
  Public Sub Calc()
    Var i As Integer
  End Sub

End Class

Go ahead and copy the DataPoint class from the top and trying pasting it into a project.

And yes, you can also have multiple classes in the selected text:

Class Test
  Public Sub Hello()
    MessageBox("Hello")
  End Sub

End Class

Class Foo
  Public Sub Bar()
    Var i As Integer
  End Sub

End Class

If you paste in a block of text that is not recognized as Xojo code, it is inserted into a new Note, which is a quick way to get some docs added to your classes.

This pasting of project items works for classes, interfaces and non-nested modules. Now when an LLM creates a class for you, you can easily select the entire thing and paste it to add it to your Xojo project!

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

The good news is starting with Xojo 2026r2, your debugged macOS apps will exhibit the same behavior your users expect when the app is distributed. For example, if you use sandboxing and hardened runtime, these will be applied. Thus, all the regular operations dealing with files will occur in the sandboxed environment and will meet the settings made under the Build Settings > macOS > Sign > Sandbox panel. This same applies when hardened runtime is selected.

In addition, especially for more advanced macOS apps that need to use entitlements and provisioning profiles, these will also be applied when the app is Run / Debug from the Xojo IDE. In this case, make sure to select the Build For > Development Certificate required for signing the app.

Debugging with Entitlements in Action

In order to show how convenient it is to debug macOS apps with entitlements and provisioning profiles applied to them, let’s make use of one of the small improvements also introduced in Xojo 2026r2: synced KeyChain Passwords. For this to work you will need to have iCloud > Passwords enabled under System Settings > Apple Account > iCloud.

The first step is to create the development provisioning profile from Apple’s developer portal (specifically for keychain-access-groups), download it and add it to the project using a Copy Build step, making sure that Contents Folder is selected as the destination for the copied file.

Then, we need to create the associated entitlements file using your favourite text editor for that. Make sure it looks like this for the purpose of this example (you will need to change all the references to the app bundle ID and the Developer ID so these match yours):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>keychain-access-groups</key>
	<array>
		<string>BW7PU32485.*</string>
	</array>
	<key>com.apple.application-identifier</key>
	<string>BW7PU32485.com.aprendexojo.Cheese</string>
</dict>
</plist>

Once created and saved using the “.entitlements” extension, add it to Build Settings > macOS > Sign > User Entitlements.

Creating a Synced Password

After adding a button to the default project Window, implement the Pressed event handler and add this fragment of code into the associated Code Editor:

Var newItem As KeychainItem

If System.KeychainCount > 0 Then

  newItem = New KeychainItem
  newItem.Label = "This is a Label"
  newItem.Description = "This is a description"
  newItem.ServiceName = "MyApplication"
  newItem.AccountName = "XojoTest"
  newItem.Comment = "This is a comment"
  
  ' Assign a password to the item
  ' Passing True as the third parameter means we want this one
  ' to be created / saved under the iCloud keychain,
  ' so it will be automatically synced with other Macs using
  ' the same iCloud user account.
  
  System.Keychain.AddPassword(newItem, "SecretPassword", true)
Else
  System.Beep
  MessageBox("You don't have a key chain.")
End If

Exception e As KeychainException
  MessageBox("Keychain error: " + e.Message)

Run the app from the IDE (you can enable both sandboxing and hardened runtime too if you wish), click the button and it will behave the same way it will when deployed. If you open Keychain Access app, select the iCloud entry in the Keychain window sidebar, and select then the Passwords option you will see the new added password from the debugged app.

Obviously, if you have more than a Mac using the same user iCloud account, you wil be able to see how that password will be synced and added to its Keychain too after a few seconds.

All in all, this means two things:

1. macOS debugged apps exhibit the same behavior expected when these are deployed, which means that you will be able to debug them in more real conditions.
2. The new ability to create synced passwords is quite convenient for those macOS apps making use of these, so your users won’t be required to create them again on each of their Macs or create different ones on each Mac they own.

In Summary

As we saw, setting sandboxing, hardened runtime, using entitlements and even provisioning profiles in you macOS apps during the debugging process now avoids conditional compilation branches, and provides a closer experience to the final (distributed) app, and even makes it easier to detect bugs in the code.

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

This is an important change for those who want modern web rendering on Windows without the large deployment footprint required by the Chromium Embedded Framework (CEF).

Why WebView2 Matters

Until now, Windows HTML rendering in DesktopHTMLViewer has primarily relied on CEF. While CEF provides excellent compatibility and a consistent Chromium-based rendering engine, it also comes with a substantial deployment cost. Including the required CEF runtime files can add well over 200 MB to an application’s distribution size.

Using CEF also means applications are tied to specific Chromium and CEF versions bundled with the app itself. Keeping current requires continuously rebuilding and redistributing newer CEF releases as Chromium evolves and security updates are released.

WebView2 changes that equation considerably.

Because WebView2 uses the Microsoft Edge rendering engine already present on many modern Windows systems, applications can avoid bundling a large embedded Chromium runtime entirely. Security and changes to WebView2 are handled through the operating system via Windows Update, rather than requiring applications to ship and maintain their own browser engine updates.

WebView2 Runtime Requirements

One important consideration is that WebView2 may require the Microsoft Edge WebView2 Runtime to be installed on the target system.

Windows 11

Most Windows 11 systems already include WebView2 as part of the operating system, so no additional installation is usually necessary.

Windows 10

Many Windows 10 systems already have the runtime installed because Microsoft distributes it through Edge and Microsoft 365 updates. However, older or managed systems may still require a separate runtime installation.

Applications that depend on WebView2 should verify runtime availability during installation and, if it is not present, either prompt the user or provide a link to download and install the required runtime.

You can also check DesktopHTMLViewer.IsAvailable at runtime to determine whether WebView2 is available.

Microsoft provides the runtime here:
https://developer.microsoft.com/en-us/microsoft-edge/webview2/

WinUI Targets Use WebView2 by Default

For WinUI desktop targets, WebView2 is now the default (and only) HTML rendering engine for the DesktopHTMLViewer. In addition, any new projects created in Xojo 2026r2 or later will default to using the WebView2 engine whenever a DesktopHTMLViewer is added to the layout.

Enabling WebView2 in older projects or non-WinUI Windows targets

For traditional Windows desktop targets that are not using WinUI, you can still opt into WebView2 support by enabling the HTMLViewer uses WebView2 option in the Advanced Windows build setting in the IDE:

When enabled, DesktopHTMLViewer will use WebView2 instead of CEF for HTML rendering.

This gives you the flexibility to choose between:

• smaller deployment size with WebView2, or
• fully self-contained deployment with CEF

depending on the needs of your application and target audience. However, moving forward we will be transitioning away from CEF entirely, and it is likely that we will no longer support or update our CEF based HTMLViewer in future releases.

Differences from CEF

Although both CEF and WebView2 are Chromium-based technologies, there are some behavioral differences you should be aware of:

• You may notice some subtle differences in how WebView2 returns results for JSON.Stringify when executed using ExecuteJavaScriptSync. i.e. the result coming back may be quoted.
• executeInXojoSync is supported, but it uses JavaScript Promises to simulate synchronous behavior, so existing code may need to be updated to use async/await. Example: const result = await executeInXojoSync("addNumbers", 2, 3);
• A WebView2-specific cache folder is created alongside the executable. If that directory is not writable, the cache folder is instead created in the user’s local AppData directory.

Final Thoughts

The addition of WebView2 support for DesktopHTMLViewer is a major improvement for Windows desktop deployment in Xojo, and reducing runtime size by hundreds of megabytes while still delivering modern Chromium-based rendering is a significant win.

Those who require rendering consistency or offline/self-contained deployments may still prefer CEF, but WebView2 offers an excellent modern alternative that better matches the direction of the Windows platform itself.

For now, you can choose between either engine depending on your needs, but moving forward we believe WebView2 is the preferred path on Windows. Happy browsing!

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Behind the Scenes…

Let’s start with a non-visible change, but a major and important one. In fact, this responds to one of Apple’s requirements for iOS apps:

“In the next major release following iOS 26, UIScene lifecycle will be required when building with the latest SDK; otherwise, your app won’t launch.”

Xojo has made the necessary underlying changes in the iOS Framework, and starting with Xojo 2026r2, all iOS apps are compiled/built so they can be run and published meeting this requirement.

What does this mean for you in practice? For any existing Xojo iOS projects, all you need to do is rebuild them with the current version of Xojo. This guarantees that the apps implement the required UIScene lifecycle and can be run without issues both on the iOS simulators and real iOS devices using iOS 26+.

MobilePopupMenu Arrives to iOS

Until now, making simple selections in iOS projects required a complex UI design involving navigation to different screens, the use of tables, containers, etc. Starting with Xojo 2026r2, we have simplified everything with the new MobilePopupMenu control.

In fact, the feature also uses a newly added class for the displayed menu entries: MobileMenuItem (more on this a bit later). It is also possible to add new entries to the menu as text, if you prefer. No matter how entries are added to the PopupMenuControl’s menu, the underlying items are MobileMenuItem instances, and these are the ones received in the SelectionChanged event handler.

You can populate the MobilePopupMenu entries at design time via the associated Inspector Panel, and select the default SelectedRowIndex value. Of course, you can do the same at runtime and change the control’s menu entries as you would with the equivalent control on Desktop.

MobileMenuItem

This new class added to the iOS Framework lets you create menu entries for the MobilePopupMenu, as well as for the newly added Menu properties on MobileButton and MobileToolbarButton.

Like its Desktop counterpart, it is possible to create hierarchical menu entries and assign icons to each item. What is specific to MobileMenuItem on iOS are the Destructive (Boolean) and DisplayMode (Enum) properties. When a MobileMenuItem instance is set to Destructive, it will be displayed as such under the iOS Design Guidelines, giving users a clear visual clue about the potentially destructive action.

The DisplayMode property can be set as Regular (the usual dropdown displaying of a menu) or as Palette. With Palette, child entries are presented in a smaller palette with horizontal navigation, which is especially recommended for tight UI designs where options are shown as icons.

If a MobileMenuItem is set to a MobilePopupMenu, it will not display the icons for the menu entries and will discard any child hierarchies (submenus), as is also the case for DesktopPopupMenu and WebPopupMenu. On the other hand, MobileButton and MobileToolbarButton are able to support submenus and will display the associated icons for every menu entry.

MobileButton

As previously noted, this control has new properties related to displaying a menu. It is possible to set the menu (MobileMenuItem instance) at runtime, and the behavior is controlled by the DisplayMenuAsAction (Boolean) property.

When DisplayMenuAsAction is set to False (the default), the Button fires its Pressed event as usual, and the menu is displayed only after a long press on the button. The menu selection made by the user will be received through the new MenuItemSelected(menu As MobileMenuItem) event handler that can be implemented on the button instance itself. All in all, this provides a good way for the button to react to two different user interactions.

If the DisplayMenuAsAction property is set to True, the associated menu is presented when the button is pressed. In this case, the Pressed event handler will not fire, only its MenuItemSelected (menu as MobileMenuItem) handler will fire after the user makes a selection in the menu.

MobileToolbarButton

MobileToolbarButton also has the new Menu and DisplayMenuAsAction properties, and these behave in the same way as described above. The main difference is that, in this case, the MenuItemSelected event handler needs to be implemented in the containing Screen instance for the NavigationBar to which the MobileToolbarButton has been added, just as the pre-existing ToolbarButtonPressed event handler was.

Badges

In addition to the support of menus, MobileToolbarButton also got the ability to display badges. This is useful in order to simplify many mobile apps UI designs.

The information shown in the badge is set through the MobileToolbarButton.BadgeText property. If this property is set to an empty string, the badge will not be displayed. In addition, there are other properties you can use to customize the badge’s appearance:

• BadgeColor As ColorGroup. Set the background color for the badge.
• BadgeTextColor As ColorGroup. Set the color for the text displayed in the badge.
• BadgeTextFont As Font. Set the font, style and font size to be used by the text in the badge.

In Summary

The new iOS Scenes based lifecycle will keep your apps in compliance with the requirement from Apple for future iOS releases beyond iOS 26, and we hope you will find the new menu items useful additions to simplify your iOS UI designs.

We are interested to know more about how you use these features, and invite you to share your iOS stuff on the Xojo Forum iOS channel!

Special thanks to Xojo MVP Jérèmie Leroy, he is always pushing and helping improve Xojo’s iOS support.

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

These changes focus on two main areas:

• Expanded button symbol support in DesktopToolbarButton
• New layout and presentation control via toolbar style options

Smarter Icon Handling with Symbols

A key addition is the new Symbol property on DesktopToolbarButton. It lets you provide a single string containing multiple symbol names separated by semicolons. Each platform will then check that list and use the first symbol it recognizes.

The Symbol feature is only supported on Windows when using the WinUI target.

AllowMulticolorSymbol was added for macOS. When enabled, the OS may render toolbar symbols using multicolor variants where available, instead of enforcing monochrome styling.

Example

home.Symbol = "house.fill;home;go-home"
home.AllowMulticolorSymbol = True
back.Symbol = "chevron.left;back;go-previous"
forward.Symbol = "chevron.right;forward;go-forward"
search.Symbol = "magnifyingglass;find;system-search"

How it works

Instead of relying only on a static icon, the toolbar now attempts to resolve a symbol first. If a symbol is found, it is used in preference to any icon.

The lookup order is:

1. First matching symbol in the list
2. If none resolve, fallback to the standard icon (if one is set)

This allows you to provide multiple symbolic names as a fallback chain, improving cross-theme and cross-platform reliability.

Where to find the list of supported symbols

WinUI: https://learn.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.symbol

Linux: https://specifications.freedesktop.org/icon-naming

macOS: https://developer.apple.com/design/human-interface-guidelines/sf-symbols

Better Control Over Toolbar Layout

The toolbar itself now supports a new Style property. This controls how buttons are visually arranged.

DesktopToolbarStyles options:

• Default
  • Generally icon/symbol on top, caption below
  • On Linux and WinUI: icon/symbol on left, caption on right
• IconCaptionVertical
  • Forces vertical layout (icon/symbol above text)
• IconCaptionHorizontal
  • Forces horizontal layout (icon/symbol beside text)
  • Only supported on Linux and Windows
• IconOnly
  • Displays only the icon/symbol
• CaptionOnly
  • Displays only text labels

In Conclusion

With support for symbols, additional layout styles, and WinUI support on Windows, we’re making it easier to create toolbars that look more modern, feel more native on each operating system, and adapt better to different user environments. Whether you prefer icon-only toolbars, text labels, or platform-specific symbols, the new options give you more ways to fine-tune the experience for your users without adding extra complexity to your projects.

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Settings

Let’s start with the Settings window, which now has its own AI panel for adjusting how Jade works.

By default, “Enable AI Features” is checked. However, if you are not onboard the AI train, then you can uncheck that setting to turn off Xojo AI integration. This removes the Jade button from the toolbar and also disables the Help menu option.

With AI Features enabled, you can choose the Service to use. By default, “Anthropic Claude” is selected so that your previous Jade configuration works the same as before, but you now also have all these services to choose from:

• Anthropic Claude
• OpenAI GPT
• OpenRouter (Anthropic)
• OpenRouter (OpenAI)
• Local

More information about each of these is in the next section.

The “Allow access to project context” option lets Jade ask for information about your project, such as the names of project items, their source code and any compile errors.

The “Restore conversation from last time” option indicates if your last Jade conversation will be restored to the chat window when the IDE restarts.

Below this are the text areas where you can enter API keys for the services you are using.

Services

Anthropic Claude

When Anthropic Claud is selected, Xojo uses the most recent version of the Claude Sonnet model, which is currently 4.6. To use this service, you will need to create an Anthropic account, generate an API key and add some credits.

Access to project context is supported with Anthropic Claude.

OpenAI GPT

When choose OpenAI, Xojo uses a recent version of the gpt-mini model, currently gpt-5.4-mini. This particular model is fast, relatively inexpensive and well suited for coding purposes. To use OpenAI, you will need to create an OpenAI account , generate an API key and add some credits. There is also an option to earn some free credits that you can optionally turn on.

Access to project context is supported with OpenAI.

OpenRouter

OpenRouter is a unified API service that gives access to hundreds of LLMs from different providers (OpenAI, Anthropic, Google, Meta, etc.) through a single endpoint and key.” Like the others you will first need to create an account, generate an API key and purchase credits. OpenRouter applies these credits as appropriate when using the models you have configured.

There are two options for OpenRouter, so that you can tell it whether to use the Anthropic or OpenAI API. When you choose Anthropic, OpenRouter will automatically route you to Claude models. When you choose OpenAI, OpenRouter will direct you to the default model specified in your OpenRouter account settings.

Not all models will work with Jade and some models have limitations. Currently, only OpenRouter with OpenAI and an OpenAI GPT model supports project context. If you want to try other models, you will likely need to disable the “Allow access to project context” setting in Xojo.

Local LLM

A local LLM is a model that you are running locally on your computer or server you control. To run a local LLM, we recommend using LM Studio which makes it easy to download and run models on a local server.

When this is selected, you also need to provide the base URL for your server. With LM Studio, it is typically:

http://127.0.0.1:1234

In our testing with Xojo we’ve found that a Qwen model, such as qwen3-coder-30b works OK. Other models may not provide useful responses or even work at all. Even though this model works, it is far less capable than Anthropic Claude or OpenAI GPT.

If you want to use Ollama, you’ll have to specify the model name as part of the base URL like this:

http://127.0.0.1:11434#qwen2.5-coder:14b

A local LLM does not have access to project context and choosing this service option currently ignores that setting.

Which Should You Use?

Based on our internal testing, Anthropic Claude has the most accurate responses. It is also the slowest and most expensive.

OpenAI with GPT is the fastest and is relatively inexpensive for what you get.

OpenRouter is really only recommended for advanced users, but it does provide an easy way to switch to specific models.

A local LLM is free to use and completely private, but it is also much slower and far less accurate. Depending on the model you choose, a local LLM also requires significant computing resources (RAM and GPU).

I hope you find these Jade improvements useful to you!

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube