The biggest wins

Clearing a SWT.MULTI List with 100,000 entries took almost a minute on GTK and now takes under a second, which also speeds up JFace ListViewer.setInput and refresh. Disposing tree items one by one, as JFace AbstractTreeViewer does on remove and refresh, no longer walks all root rows on every call, so 50,000 items go away in about 0.15 s instead of 8 to 10 s. On GTK, Tree.getItemCount() and TreeItem.getItemCount() are now cached instead of walking the sibling list on every call, so 40,000 calls on an item with 40,000 children take about 1 ms instead of 7 to 12 s. GridLayout grows its grid geometrically instead of four rows at a time, which turns a quadratic computeSize into a linear one for composites with many children. List.setSelection(String[]) stops copying the whole list natively for every string.

How it was measured

All numbers are from Linux with GTK 3.24 on X11 under Xvfb, Java 21 and 25, comparing the old and the new class on the same build on a single machine. Ranges show run-to-run variation. Most hot spots are GTK specific; #3640, #3642, #3646, #3649, #3650 and #3654 are platform independent or touch all platforms.

Performance changes

Code simplification

Alongside the performance work, a handful of pull requests remove about 245 lines without changing behaviour. #3648 drops unused internal members on GTK (-95 lines). #3653 shares the cell renderer lookups of Table, Tree and List in Scrollable (-51 lines). #3646 simplifies the CTabFolder gradient setters with Arrays utilities, checked equivalent on 4 million random inputs (-42 lines). #3649 replaces 28 hand-written array copies with Arrays.copyOf and clone (-32 lines). #3647 extracts the search column update that was copied three times in Table and Tree (-18 lines), and #3654 above removes another 7.

Interested?

If you are also looking to improve your code base, have a look at our AI-based services.

The palette

The theme is based on the VS Code extension of Gruvbox Material with its default medium background and the material foreground. Editors and views sit on a soft dark brown #292828, while the surrounding window chrome uses the darker #1C1C1C of the extension’s flat workbench. Text is a warm #D4BE98, and Java code uses the extension’s syntax roles: red keywords, yellow strings and green functions.

We made one deliberate change to the original. The extension’s lighter greys, which it uses for muted text, fail the WCAG AA contrast ratio on these surfaces. The Eclipse theme uses the brighter grey #A89984 for muted text and the tab keyline instead, so secondary information stays readable.

Like the other themes, Gruvbox Material also writes its editor, syntax highlighting and console colors into the matching preferences, so the Java editor, the console and the views all follow the palette.

The screenshot was taken through our MCP server for the Eclipse IDE: an agent installed the theme from the update site, restarted the IDE, switched the theme and captured the window.

Installing

In Eclipse, choose Help > Install New Software and add the update site:

https://vogellacompany.github.io/eclipse-themes/

Select the Gruvbox Material feature, restart, and switch to it under Preferences > General > Appearance. If you already added the update site for one of our other themes, Gruvbox Material is listed there as well.

Sources and issues: github.com/vogellacompany/eclipse-themes. Please open an issue there if the theme renders something wrong on your platform.

The change

The Dependencies page of the PDE manifest editor lists the Import-Package entries of a bundle. For every row the label provider asks whether some bundle in the target platform exports that package, and picks the icon accordingly.

The stock implementation answered that question through State.getExportedPackages(). That method is not cached: every call takes the state monitor and copies the exports of all resolved bundles into a freshly allocated array. With an SDK sized target platform that is about 3200 exports copied per row, on the UI thread, for every refresh of the table.

eclipse.pde#2444 replaces the copy with a walk over the resolved bundles that reads the exports in place and stops at the first match. The PR description argues with reference stores: roughly 9600 per call before, 731 after.

On the related Equinox change, equinox#1347, the reviewer asked for performance metrics instead: fewer reference stores do not always result in a measurable improvement. That is a fair question, and it needs numbers from a real IDE rather than a microbenchmark.

Setup

Eclipse SDK 4.42 I-build 20260902-2327, stock org.eclipse.osgi 3.24, running headless under Xvfb. The target platform is the running platform: 850 bundles, about 3200 exported packages.

Before: stock org.eclipse.pde.core 3.21.500.v20260902-1925. After: org.eclipse.pde.core built from the PR branch, everything else identical, IDE started with -clean.

Two manifests: org.eclipse.equinox.p2.tests with 48 Import-Package rows and a copy of the org.apache.ant manifest with 105 rows. The table refreshes twice per open, once on creation and once on page activation, so each open is 96 or 210 calls of isResolved().

The scenario, ten iterations per run: close the manifest editor, open META-INF/MANIFEST.MF, switch to the Dependencies page, wait until the UI thread is idle.

Results

Before the change, every sampled stack is one path: the Dependencies page refreshes its table viewer, the label provider asks for the image, ImportPackageObject.isResolved calls StateImpl.getExportedPackages. The allocation under it is the fresh ExportPackageDescription[] plus the ArrayList growth that builds it.

After the change the method no longer appears in the 10 ms samples at all. What JFR still attributes to isResolved is the BundleDescription[] copy returned by State.getResolvedBundles().

What the numbers say

The work and the allocation scale with the row count, as the PR says, and the change removes them. Both are real: a few hundred kilobytes of garbage per row, on every refresh, on the UI thread.

The page does not get measurably faster at 48 or 105 rows. The 5 to 12 ms per open were already below the cost of the page switch itself, and no garbage collection was triggered on either side, so the removed allocation never turned into a pause during these runs. A visible difference would need several hundred imports, or the garbage coinciding with a collection.

So the reviewer’s caution holds up as well as the PR does. The change is an improvement in work done and memory allocated, not a latency win a user would notice on a typical manifest. That is the answer a reviewer asking for metrics needs, and it is a better basis for the discussion than either “fewer reference stores” or “no visible difference” alone.

How we measured

The measurement was driven by an agent through our MCP server for the Eclipse IDE, against the real IDE instead of a benchmark harness.

eclipse_run_script runs the scenario: close the editor, open the manifest, switch to the Dependencies tab, then eclipse_wait_until_settled until the UI thread is idle. It repeats this ten times and reports the milliseconds per step, which gives the page switch row of the table.

eclipse_start_sampling and eclipse_stop_sampling sample the UI thread at 10 ms. A frameFilter restricts the result to samples that contain the frame of interest, here getExportedPackages, and eclipse_show_trace renders them as the flame graph above.

eclipse_start_flight_recording and eclipse_stop_flight_recording record the same ten iterations with JFR allocation sampling. The same frameFilter attributes the allocation by stack, which gives the allocation rows.

For the after side, eclipse_substitute_bundle installed a org.eclipse.pde.core jar built from the PR branch and restarted the IDE with -clean. Everything else stayed the same, so the two runs differ only in the bundle under test.

The server is open source: github.com/vogellacompany/eclipse-mcp-server.

The editor has two tabs: Source for editing and Preview for the rendered HTML, which updates as you type. The preview covers lists, tables, admonitions, source blocks, images and includes.

Beyond the preview, the editor offers:

• Errors for missing included files, and warnings for missing images, broken cross-references, duplicate anchors and broken file links
• Code completion for snippets, image and include paths, anchors and document attributes
• Go to Definition for anchors, headings and included files, plus clickable include::, image:: and URL links
• Folding for sections, comment blocks and delimited blocks
• Image lookup through imagesdir, with a fallback to a sibling images/ or img/ folder

Installing

In Eclipse, choose Help > Install New Software and add the update site:

https://vogellacompany.github.io/eclipse-asciidoc/

The editor is also listed on the Eclipse Marketplace.

Sources and issues: github.com/vogellacompany/eclipse-asciidoc. Please open an issue there if a document does not render the way you expect.

Every theme builds on the platform stylesheets of org.eclipse.ui.themes and recolors them through shared color definitions, so a theme change is a palette change rather than a rewritten stylesheet. A theme also writes its editor, syntax highlighting and console colors into the affected preferences, the same way the built-in dark theme does.

AI Neon

Near black surfaces with cyan and magenta accents on active elements.

Dracula

The official Dracula palette on purple tinted surfaces with pink and purple accents.

VS Code Dark

The VS Code Dark Modern look, including its tab styling and the Dark+ syntax colors.

The screenshots show the same workspace, the same file and the same window, captured on Linux with GTK. They were taken through our MCP server for the Eclipse IDE: an agent switched the theme, restarted the IDE and captured the window, three times in a row.

Why we build themes

The themes are also our test bed for the theming capabilities of the Eclipse platform itself. Every palette that does not fit exposes a widget the CSS engine cannot reach, a color that is hard coded somewhere in SWT or JFace, or a preference that is not styled at all. We fix those in the platform, which benefits every theme and every Eclipse RCP application.

If your RCP application needs a modern look or an upgrade to a current Eclipse release, we offer this as a service: Eclipse RCP upgrade.

Installing

In Eclipse, choose Help > Install New Software and add the update site:

https://vogellacompany.github.io/eclipse-themes/

Every theme is a feature of its own, so install one, several or all six. Then switch under Preferences > General > Appearance.

Sources and issues: github.com/vogellacompany/eclipse-themes. Please open an issue there if a theme renders something wrong on your platform.

We now offer dead code removal as a fixed-scope service for Eclipse RCP and Java code bases. This post shows what it found in the Eclipse Platform, Platform UI and PDE repositories.

Example: Eclipse Platform, Platform UI and PDE

As a dry run we cleaned the internal API of three Eclipse repositories, eclipse.platform, eclipse.platform.ui and eclipse.pde, with the complete Eclipse SDK open in the workspace so that references from other projects count. The sweep removed 12,676 lines in 147 files: 126 classes, among them a complete About dialog package that was never wired to anything, plus the message keys and package exports that only served them. The workspace showed no additional warning or error afterwards, and a full build of the Eclipse SDK aggregator passed.

The safety net mattered as much as the deletions. Dozens of classes had no reference inside their own repository but were used from other Eclipse projects. Two classes are referenced only from another plug-in’s plugin.xml, through their nested classes; deleting them would compile and fail at runtime. A few e4 addons exist only through bundleclass:// URIs in .e4xmi files. All of them were kept, and public API was excluded from the start, because zero references in one workspace proves nothing for an exported package.

Interested?

Details and a contact form: Dead code removal.

An agent with a shell already has files, grep and git. What it does not have is the resolved Java model, the problem markers of the incremental builder and the file you are currently looking at. Those are the capabilities exposed here.

It exposes the JDT search engine for references and type hierarchies, the source of types from jars, the compilation errors of the workspace, the entries of the Error Log including the stack traces of UI freezes, the preferences with the scope each value comes from, and the active editor with its cursor and selection. A few tools write: organize imports, format, run a build, open and close projects, and set the execution environment of plug-in projects together with the matching compiler settings. There is no general file writing, no refactoring, no terminal and no debugger control.

The server is disabled by default, binds to the loopback interface only and rejects every request without a bearer token. Enable it in Preferences > General > MCP Server.

Install it from the update site:

https://vogellacompany.github.io/eclipse-mcp-server/

Sources, documentation and issues: github.com/vogellacompany/eclipse-mcp-server. Please open an issue there if something does not work or if a tool you need is missing.

For help, support or commercial enquiries, write to info@vogella.com.

• Extending Copilot in Visual Studio Code
• Getting Started with Theia AI

Note:
This blog post is based on Visual Studio Code 1.113.0 and Eclipse Theia 1.70.0. There may be differences if you read it when newer versions have been released.

Strategic Comparison

In the article Why Extending GitHub Copilot in VS Code May Not Be the Best Fit for Your AI-Native Development Tool, you can already find a comprehensive overview of the differences between GitHub Copilot in Visual Studio Code and Theia AI. The article is around half a year old and is therefore not fully up to date with the latest features. However, the strategic perspective is still well described and remains valid, so the article is still worth reading if you plan to adopt either technology.

The following table extracts and summarizes an initial comparison of key aspects from that article:

AI Extension Comparison

Visual Studio Code GitHub Copilot extensions and Eclipse Theia AI extensions target similar use cases: extending the AI capabilities of the IDE. There are differences in terminology, implementation, extension capabilities, and features. In previous blog posts, I explained how to contribute Tools, MCP Servers, and Chat Extensions. The concepts already differ in naming, as shown in the following table:

The following sections will explain the differences in more detail.

Language Model Tool vs. Tool Function

Tools provide additional capabilities to perform specialized tasks when interacting with an LLM. In Visual Studio Code, they are called Language Model Tools; in Theia, they are called Tool Functions.

Visual Studio Code

To contribute a Language Model Tool via Copilot Extension, you follow the typical contribution pattern in Visual Studio Code Extensions:

• Configure the contribution via contributes/languageModelTools section in the extensions package.json
• Implement a new class that implements the vscode.LanguageModelTool interface
• Register it in the extension via vscode.lm.registerTool()

Further details can be found in Extending Copilot in Visual Studio Code - Language Model Tool.

Eclipse Theia

To contribute a Tool Function via Theia Extension, you follow the typical contribution pattern in Theia:

• Implement a new class that implements the ToolProvider interface from the @theia/ai-core package
• Register it in a ContainerModule for injection via bindToolProvider() from @theia/ai-core/lib/common

Further details can be found in Getting Started with Theia AI - Tool Functions.

MCP Support

MCP Servers are typically configured by users via a configuration file. The usage comparison is described later in Configuring MCP Servers. MCP Servers can also be contributed and configured programmatically, for example when you contribute an extension that provides an advanced AI use case requiring dedicated tools via MCP.

Note:
MCP servers that are programmatically registered via a Visual Studio Code Copilot extension can also be installed in a Theia application if the @theia/plugin-ext extension is available.

Visual Studio Code

To contribute a MCP Server via Copilot Extension, you follow the typical contribution pattern in Visual Studio Code Extensions:

• Configure the contribution via contributes/mcpServerDefinitionProviders section in the extensions package.json
• Register a McpServerDefinitionProvider in the extension via vscode.lm.registerMcpServerDefinitionProvider()
• Add MCP servers via McpServerDefinitionProvider#provideMcpServerDefinitions()
  • A local MCP server can be configured by creating a vscode.McpStdioServerDefinition
  • A remote MCP server can be configured by creating a vscode.McpHttpServerDefinition
• Dynamic resolution (e.g. asking the user for an authorization token) can be added via McpServerDefinitionProvider#resolveMcpServerDefinition()

There are some limitations:

• To ensure that the MCP servers are registered automatically on start, you need to configure the activationEvents accordingly, e.g. onStartupFinished
• There is no API to programmatically start or stop an MCP Server in Visual Studio Code.
• Programmatically registered MCP servers do not show up in the MCP Servers section of the Extensions view.
• Programmatically registered MCP servers do not get roots set based on the current workspace directory.

Further details can be found in Extending Copilot in Visual Studio Code - Add MCP server programmatically via VS Code Extension.

Eclipse Theia

To contribute a MCP Server via Theia Extension, you follow the typical contribution pattern in Theia:

• Implement a FrontendApplicationContribution
• Get the MCPFrontendService injected
• Add MCP servers via MCPFrontendService#addOrUpdateServer()
  • A local MCP server can be configured by creating a LocalMCPServerDescription
  • A remote MCP server can be configured by creating a RemoteMCPServerDescription
• Dynamic resolution (e.g. asking the user for an authorization token) can be added directly to the MCPServerDescription via the MCPServerDescription#resolve() function
• Register it in a ContainerModule via bind()

Compared to the limitations in Visual Studio Code, programmatically registered MCP servers in Theia

• are automatically registered if the FrontendApplicationContribution is registered correctly in a ContainerModule
• can be started and stopped programmatically via MCPFrontendService#startServer() and MCPFrontendService#stopServer()
• do show up in the AI Configuration view
• Since Theia 1.69.0, roots are supported. This support was added via PR. You can configure whether the workspace should be used as a Root via the preference ai-features.mcp.useWorkspaceAsRoot.

Further details can be found in Getting Started with Theia AI - Add MCP server programmatically via Theia Extension.

Chat Participant vs. Custom Agent

To extend the AI capabilities of an IDE or application with a specialized assistant that provides domain-specific expert knowledge, you can implement and contribute a Chat Participant in Visual Studio Code or a Custom Agent in Eclipse Theia. In both cases, the benefits of such a programmatically created AI assistant are:

• you can manage the end-to-end prompt/response conversation
• you have access to the respective API, which allows deep integration with the underlying platform
• you can distribute and deploy it via extensions

Custom Agents defined via configuration files can only interact with the underlying platform if the required functionality is available as a Language Model Tool or Tool Function, or via MCP. They are also available only when the corresponding configuration files are present in the user’s workspace. Custom Agents from a user’s perspective are covered in a later section. In this section, I focus on the differences in programmatically created AI extensions.

Visual Studio Code

As the name implies, a Chat Participant contributed via a Visual Studio Code Copilot extension is intended for and limited to chat. There are no other use cases where a Chat Participant can be integrated, such as the terminal.

To contribute a Chat Participant via Copilot Extension, you follow the typical contribution pattern in Visual Studio Code Extensions:

• Configure the contribution via contributes/chatParticipants section in the extensions package.json
• Define a vscode.ChatRequestHandler which sends the chat request and handles the response
• Create a vscode.ChatParticipant via vscode.chat.createChatParticipant() by using the id defined in the package.json and the defined vscode.ChatRequestHandler
• Register the vscode.ChatParticipant in the extension by pushing it to the context.subscriptions

To use the Chat Participant, you need to invoke it with the @ syntax, e.g. @joker tell me a joke.

Further details can be found in Extending Copilot in Visual Studio Code - Chat Participant.

Eclipse Theia

Compared to Visual Studio Code, a Custom Agent in Theia is not limited to the chat. It can also be integrated into other parts of the IDE, such as the editor, the terminal, or a custom widget.

To contribute a Custom Agent via a Theia Extension, you follow the typical contribution pattern in Theia:

• Implement an AbstractStreamParsingChatAgent and define the necessary attributes such as id, name, description, prompt(s), Tool Functions, and Agent-Specific Variables, if needed.
• Register it in a ContainerModule via bind()

When implementing a Custom Agent, there are several advanced features that can improve the user experience, for example:

• Prompt Variants
• Agent-specific Variables
• Agent-to-Agent Delegation
• Custom Response Part Rendering

To use a Custom Agent in Theia, you need to invoke it with the @ syntax, e.g. @Joker a joke about scarecrow.

Further details can be found in Getting Started with Theia AI - Implement a Custom Agent.

AI Usage Comparison

The sections above covered differences in programmatic AI customization. In the following sections, I compare AI usage differences from a user’s point of view.

Using tools in prompts

How tools are used in prompts differs between Visual Studio Code and Theia. In general, there are three types of tools:

• Built-in tools provided by the platform
• MCP tools added via MCP servers
• Extension tools provided programmatically (Language Model Tool vs. Tool Function)

Visual Studio Code

In Visual Studio Code, a Tool is used when processing a prompt if:

• the tool is in the list of enabled tools and is selected automatically

  

• the tool is used explicitly by mentioning it using a leading #

  #jokeFileCreator create a file that contains a joke in the folder test
  

For tools provided via MCP, the tool is also selected by name. Assuming you added the fetch MCP server, you can use the provided tool via #fetch. Unfortunately, this is not unique because there is also a built-in fetch tool in Visual Studio Code.

By default, you will be prompted before a Language Model Tool is executed.

In the Allow dropdown, you can choose whether to allow execution once, for the current session, or generally in the current workspace. This setting is not directly accessible at the time of writing this blog post. To reset saved tool approvals, run the Chat: Reset Tool Confirmations command from the Command Palette (Ctrl+Shift+P).

In Visual Studio Code, it is also possible to configure URL approval, which becomes active when a tool attempts to access a URL.

Further details about using tools in chat in Visual Studio Code can be found in Use tools with agents.

Eclipse Theia

In Eclipse Theia, a Tool is used by mentioning it with a leading ~. There is no automatic tool resolution for prompts, so you always need to mention the tool explicitly.

@Universal create a file that contains a joke in the folder test. Use a file name that relates to the joke. ~jokeFileCreator

The name of an MCP server tool in Theia is derived from the server name and function name. It uses the following syntax:

~{mcp_<server-name>_<function-name>}

For example, to use the fetch function of the fetch MCP server, you could write a prompt like this:

@Universal show me the allowed directories ~{mcp_fetch_fetch}

By default, the Tool Confirmation Mode is Always Allow. Users can change this setting.

• Open the AI Configuration view via Menu -> View -> AI Configuration
• Switch to the Tools tab

  

• Alternatively, edit settings.json and configure ai-features.chat.toolConfirmation. For example, if you want to be prompted for approval for every tool call but allow jokeFileCreator to execute without confirmation:

  "ai-features.chat.toolConfirmation": {
    "*": "confirm",
    "jokeFileCreator": "always_allow"
  },
  

The URL approval feature is currently not supported in Eclipse Theia.

Further details about using tools in chat in Eclipse Theia can be found in Tool Functions, Using MCP Server Functions, and Tool Call Confirmation UI.

Configuring MCP Servers

As a user, you typically add MCP servers to your development environment via a configuration file. There are two basic types of MCP servers:

• local MCP servers, which are software installed on your system
• remote MCP servers, which are hosted elsewhere and provide functionality without needing local system access.

Visual Studio Code

In Visual Studio Code, you typically add MCP servers via an mcp.json file, either in the workspace .vscode folder or in the user profile to configure MCP servers for all workspaces. A mcp.json file has two main sections:

• "servers": {} - Contains the list of MCP servers and their configurations
• "inputs": [] - Optional placeholders for sensitive information like API keys

You can use predefined variables in the servers section and the variables defined in the inputs section.

{
  "servers": {
    "filesystem": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem"]
    },
    "fetch": {
      "url": "https://remote.mcpservers.org/fetch/mcp",
      "type": "http"
    },
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "type": "sse",
      "headers": {
        "X-MCP-Toolsets": "gists",
        "Authorization": "Bearer ${env:GITHUB_TOKEN}"
      }
    }
  },
  "inputs": []
}

From the example above, you can see that you need to specify the type field to define whether it is a local or a remote MCP server.

You can manage the MCP server either via

• MCP SERVERS - INSTALLED section in the Extensions view

  

• Inline actions in the mcp.json editor (codelenses)

  

• MCP: List Servers command from the Command Palette

  

After the first start of an MCP server, the server’s capabilities and tools are discovered and cached. The next time a tool is used in a prompt while the server is not running yet, Visual Studio Code can auto-start the server because of this cached information.

Using the chat.mcp.autostart setting, you can configure whether MCP servers should be restarted automatically when configuration changes are detected. This autostart setting is available only globally, not per server.

Further information can be found in Use MCP servers in VS Code.

Eclipse Theia

In Eclipse Theia, you typically add MCP servers via the general settings.json file. There is currently no support for an mcp.json file.

The settings.json file contains many settings that can be applied in Theia, not just MCP-related configuration. There is no support for predefined variables or inputs like the inputs section in mcp.json.

Comparing Visual Studio Code mcp.json and Eclipse Theia settings.json MCP server configuration, there are a few differences:

• In Theia, you do not need to specify the type field.
  For local servers, this is straightforward because only one type is available (stdio). For remote servers, Theia first tries to connect via sse, and if that fails, it falls back to http.
• In Eclipse Theia, there is an autostart field that lets you configure whether an MCP server should start automatically. The default is true if it is not set.
• For remote servers, the main URL is set as url in Visual Studio Code, while in Eclipse Theia the field is called serverUrl.
• In Eclipse Theia, you can specify the authentication token via serverAuthToken, which defaults to an Authorization header with Bearer. You can change that via serverAuthTokenHeader.

{
  "ai-features.mcp.mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/home/node/examples"
      ],
      "autostart": false
    },
    "fetch": {
      "serverUrl": "https://remote.mcpservers.org/fetch/mcp",
      "autostart": false
    },
    "github": {
      "serverUrl": "https://api.githubcopilot.com/mcp/",
      "serverAuthToken": "<your-token>",
      "headers": {
        "X-MCP-Toolsets": "gists"
      }
    }
  }
}

You can manage the MCP server either via

• AI Configuration view: Menu -> View -> AI Configuration -> MCP Servers tab

  

• Command palette: F1
  • MCP: Start MCP Server -> filesystem
  • MCP: Stop MCP Server -> filesystem

If an MCP server is not started, its capabilities and tools cannot be used. There is no auto-start based on cached information as in Visual Studio Code. However, you can configure auto-start behavior per server via the autostart field, which is enabled by default.

Further information can be found in MCP Integration.

Chat Variables

In Visual Studio Code and Eclipse Theia, it is possible, and usually recommended, to add specific context to your request. To do this explicitly, you can use the # syntax with some predefined options.

In Theia, it is also possible to implement and provide additional Context Variables as Global Variables or Agent-Specific Variables.

Further information for Visual Studio Code can be found in Add context to your prompts.

Further information for Eclipse Theia can be found in Context Variables.

Prompt Files vs Prompt Fragments

Visual Studio Code and Eclipse Theia both allow users to define reusable prompts for recurring development tasks. Although the feature is similar, there are differences.

Visual Studio Code

In Visual Studio Code, you can create and use Prompt Files to define reusable prompts for recurring development tasks.

Prompt Files are Markdown files with a .prompt.md file extension. They are located either in the .github/prompts folder in the workspace or in the prompts folder in the user profile (for example on Windows, C:\Users\<username>\AppData\Roaming\Code\User\prompts).

In the optional YAML frontmatter header, the prompt behavior can be configured, for example:

• agent header to define the agent that should be used for running the prompt
• tools header to define the list of tools or tool sets that are available for the prompt

You can use variables in the prompt file using the syntax ${variableName}. The following variables can be used:

• Workspace variables - ${workspaceFolder}, ${workspaceFolderBasename}
• Selection variables - ${selection}, ${selectedText}
• File context variables - ${file}, ${fileBasename}, ${fileDirname}, ${fileBasenameNoExtension}
• Input variables - ${input:variableName}, ${input:variableName:placeholder}

Arguments passed in chat via key=value syntax (e.g. _target=robin) are available in the prompt via ${input:variableName} or ${input:variableName:placeholder}.

Tools configured as available in the prompt via the tools frontmatter header can be referenced in the prompt via #tool:<tool-name>.

To use a Prompt File in the Chat view, type / followed by the prompt name. For example, if you created a harley.prompt.md file, you could execute it via the slash command /harley.

Further information can be found in Extending Copilot in Visual Studio Code - Further Customization - Prompt Files.

Eclipse Theia

In Eclipse Theia, you can create and use Prompt Fragments to define reusable prompts for recurring development tasks.

Prompt Fragments are Markdown files with a .prompttemplate file extension. They are located either in the .prompts folder in the workspace or in user-wide local directories configured in the settings (AI Features -> Prompt Templates).

In the optional YAML frontmatter header, prompts can be configured as a Slash Command:

• isCommand header needs to be set to true
• commandName header specifies the name of the command
• commandAgents header can be used to limit the visibility of the command to the specified agents.

You can use any available Context Variable in the prompt.

Command arguments passed via chat can be used in the prompt via Argument placeholders $ARGUMENTS or $1, $2, $3 for arguments by position.

The tools that should be used inside the prompt do not need to be preconfigured in the YAML frontmatter and can be referenced in the prompt via ~<tool-name>.

To use a Prompt Fragment in the Chat view, you can use the special variable #prompt:promptFragmentID, for example @Universal #prompt:harley joke about batgirl. When configured as a Slash Command, type / followed by the prompt name, for example @Universal /harley batgirl.

Further information can be found in Getting Started with Theia AI - Further Customization - Prompt Fragments and Getting Started with Theia AI - Further Customization - Slash Commands.

Custom Agents

Custom Agents are a mechanism that allows users to create specialized assistants for specific tasks in the chat. For example, users can create different personas tailored to development roles and tasks such as planning, research, or specialized workflows.

Custom Agents are similar to Visual Studio Code Chat Participants or programmatically contributed Custom Agents in Eclipse Theia. However, instead of contributing them programmatically, users define and configure them through dedicated agent files.

Visual Studio Code

In Visual Studio Code, Custom Agents are configured in custom agent files. Custom Agent Files are Markdown files with a .agent.md extension. They are located either in the .github/agents folder in the workspace or in the user profile folder (interestingly, also in the prompts folder). There is one dedicated .agent.md file for each Custom Agent.

Similar to Prompt Files, Custom Agents can be configured via an optional YAML frontmatter header. You can, for example:

• select the model that should be used when running the agent prompt via the model header
• select the tools or tool sets that can be used by the custom agent via the tools header
• select the agents that are available as subagents in the custom agent via the agents header
• configure handoffs for orchestrating multi-step workflows via the handoffs header

To use a Custom Agent, select it from the agents dropdown in chat and enter a prompt, for example joke about alfred.

Further information can be found in Extending Copilot in Visual Studio Code - Further Customization - Custom Agents.

While the usage of agents in Visual Studio Code and Eclipse Theia is quite similar, Visual Studio Code has some features that are currently not available in Eclipse Theia:

• You can select an Agent type to control where and how an agent runs: local, background, cloud, or third-party.
• There is a distinction between calling a Subagent, which spawns a child agent within a session to handle a subtask in its own isolated context window, and performing a Hand off, which transfers a session from one agent type to another while carrying over the conversation history.

Further information can be found in Using agents in Visual Studio Code.

Eclipse Theia

In Eclipse Theia, multiple Custom Agents are configured in a single custom agent configuration file. The Custom Agent File is a YAML file named customAgents.yml. It is located either in the .prompts folder in the workspace or in user-wide local directories configured in the settings (AI Features -> Prompt Templates).

Because there is only one file for multiple Custom Agents, there is no frontmatter configuration header. Instead, each Custom Agent configuration has its own attributes. In addition to the obvious fields such as id, name, description, and prompt, you need to specify the model via the defaultLLM field.

You can use any available Context Variable in the prompt.

The tools that should be used inside the prompt do not need to be preconfigured in any way. They can be referenced in the prompt via ~<tool-name>.

You can delegate to another agent by using the delegateToAgent Tool Function.

To use a Custom Agent, you need to use the @ syntax in the chat view, just like for any other agent in Theia, e.g. @Joker joke about alfred.

If you use a specific agent most of the time and do not want to type the @ syntax every time, you can configure a default agent via the preference ai-features.chat.defaultChatAgent, for example to use the Universal agent whenever no agent is explicitly mentioned in the chat:

"ai-features.chat.defaultChatAgent": "Universal"

Further information can be found in Getting Started with Theia AI - Further Customization - Custom Agents and Getting Started with Theia AI - Further Customization - Agent-to-Agent Delegation (function).

Agent orchestration

When talking about AI agents, we now often refer to Agentic AI workflows, where multiple agents collaborate to achieve complex goals. When creating Custom Agents, you need to consider collaboration options, especially if you design your agents for dedicated tasks rather than having one agent do everything. This is important because you should keep the context of your agent or prompt as small as possible while still providing enough information to achieve the desired results. Creating agents for dedicated tasks with a limited scope or context is similar to the encapsulation principle in object-oriented programming, and likewise, you need to consider processing or orchestration patterns.

Apart from a Single Agent that does all the work alone, you currently have two options:

• Delegate Pattern
  Create guided sequential workflows that transition between agents. The agents are called one after the other.
• Coordinator and Worker Pattern
  The main/coordinator agent receives the task, delegates subtasks to subagents, and combines the subagent results into the final result.

You can also combine these patterns to have multiple “main” agents that use worker agents for specific tasks. Each “main” agent can delegate to the next “main” agent once it is done, creating a sequential workflow of main tasks.

While the patterns are generally the same, technically there are differences between Visual Studio Code and Eclipse Theia.

Visual Studio Code

The Delegate Pattern is supported via Handoffs when creating Custom Agents in Visual Studio Code. A handoff is configured in the YAML frontmatter header. The user needs to actively proceed with the handoff by clicking a button in the chat UI. The token usage with a handoff is similar to having a single agent that processes all the tasks itself, as the whole context is passed from one agent to the next.

The Coordinator and Worker Pattern is supported through Subagents. To call a subagent, the built-in agent/runSubagent tool needs to be enabled for the coordinator agent. Using a subagent means spawning a child agent within a session to handle a subtask in its own isolated context window. This reduces the token usage, as subagents are not called with the whole context compared to a Handoff.

Each subagent call is sequential (the coordinator waits for that call to return), but the coordinator can spawn multiple subagent calls in parallel.

Further information can be found in AI Agent Orchestration - Visual Studio Code.

Eclipse Theia

Theia does not provide a feature like Handoffs in Visual Studio Code. Instead, Theia provides the built-in Tool Function delegateToAgent to support Agent-to-Agent Delegation, which is comparable to Subagents. Whether you implement the Delegate Pattern or the Coordinator and Worker Pattern depends on how you use the delegateToAgent tool in the prompt.

Using a subagent means spawning a child agent within a session to handle a subtask in its own isolated context window. Because Theia has no Handoff concept that forwards processing to another agent, but only the concept of subagents, you do not see the same token-usage difference there.

Each subagent call via delegateToAgent is sequential (the coordinator waits for that call to return), but the coordinator can spawn multiple subagent calls in parallel.

Further information can be found in AI Agent Orchestration - Eclipse Theia.

Context Monitoring / Token Usage

In Visual Studio Code, it is possible to monitor context window usage. This helps indicate how much context a conversation uses. Theia does not yet support such context-window monitoring, but this feature has been requested via Context window inspection / analysis command.

In Theia, token usage can be inspected via AI Configuration by switching to the Token Usage tab, at least for LLMs that provide usage metadata for a request. Token usage is accumulated within a session, so you do not get the information per request. Token usage is not persisted and is reset when restarting the application. Visual Studio Code does not support tracking token usage at that level.

Agent Skills

Agent Skills is a simple, open format for giving agents new capabilities and expertise. Basically, a skill is a folder containing a SKILL.md file that includes metadata in the form of a YAML frontmatter header and instructions that tell an agent how to perform a specific task. It can also contain subfolders with scripts, templates, and referenced materials. Because it is an open format, it is supported in various AI tools.

Agent Skills are a fairly new format, and both Visual Studio Code and Eclipse Theia support it, although in Eclipse Theia the feature is still in alpha. There are some differences in where skills are stored and how they are used, which I list in the following sections. If you are interested in examples, have a look at awesome-agent-skills.

Visual Studio Code

• The location of the skills folder for a project in your repository is .github/skills/, .claude/skills/ or .agents/skills/.
• The location for personal skills in the user home is ~/.copilot/skills/, ~/.claude/skills/ or ~/.agents/skills/.
• You can configure additional locations for skills via the chat.agentSkillsLocations setting to share skills across projects or keep them in a central location.
• You can use skills directly in the chat via a slash command. For example, if you created a skill with the name webapp-testing, you can use it directly in the chat via /webapp-testing for the login page.
• Copilot discovers the skills to use automatically by matching the user prompt with the skill description. Only the body of a matching skill will be loaded into the context. Additional resources will only be added if they are referenced in the instructions.
• You can create a new skill manually by creating the required folder and a SKILL.md file in that folder
• You can create a new skill with the help of AI by using the /create-skill slash command in the chat
• You can use the Chat Customizations dialog by clicking the gear icon in the upper-right corner of the Copilot chat window, select the Skills menu item on the left side and select an option to generate a skill via the dropdown on the upper right corner to guide you through the initial creation.

  

  

You can learn more about the use of Agent Skills in Visual Studio Code in Use Agent Skills in VS Code and Extending Copilot in Visual Studio Code - Further Customization - Agent Skills.

Eclipse Theia

Support for Agent Skills in Eclipse Theia is still in alpha and currently has known limitations. For example, in Theia 1.70.0, automatic skill discovery is not working reliably. Automatic execution and tool calls can also fail. These issues are likely to improve in upcoming releases.

• The location of the skills folder for a project in your repository is .prompts/skills/.
• The location for personal skills in the user home is ~/.theia/skills/.
• You can configure additional locations for skills via the ai-features.skills.skillDirectories setting to share skills across projects or keep them in a central location.
• You can use skills directly in the chat as a slash command. For example, if you created a skill with the name webapp-testing, you can use it directly in the chat via /webapp-testing for the login page.
• You can enable agents to load skills on demand by using the `` variable in an agent’s prompt to list all available skills, and use the ~getSkillFileContent function to load a selected skill on demand.
• You can create a new skill manually by creating the required folder and a SKILL.md file in that folder
• You can create a new skill with the help of AI by using the built-in @CreateSkill agent in the chat
• There is a Skills and Slash Commands View available via the AI Configuration via the Skills tab, which provides a convenient overview of the discovered skills and a button to directly open the corresponding SKILL.md file in an editor.

  

You can learn more about the use of Agent Skills in Eclipse Theia via Agent Skills (Alpha) and Getting Started with Theia AI - Further Customization - Agent Skills.

Conclusion

As you can see, the AI capabilities of Visual Studio Code GitHub Copilot and Eclipse Theia AI are very similar. Both ecosystems evolve quickly, and while writing this post, I had to update findings and screenshots several times to keep it current.

At a high level, both platforms support the same core building blocks: tools, MCP integration, custom agents, reusable prompts, and skills. The main differences are in product strategy and developer control:

• Visual Studio Code with GitHub Copilot gives you a polished product with strong built-in workflows and broad adoption.
• Eclipse Theia gives you an open platform you can own and shape deeply for your own product and domain.

From a practical perspective, your choice usually depends less on feature checklists and more on your goals:

• Choose Visual Studio Code GitHub Copilot if you want fast adoption, familiar UX, and minimal platform-level ownership.
• Choose Eclipse Theia if you need full control, deeper integration into your own application, and an open customization model.

It is also worth noting that AI customization now offers multiple overlapping mechanisms for similar outcomes. Deciding whether to use a Custom Agent, a Prompt File/Fragment, or an Agent Skill is not always straightforward and often depends on scope, reuse, and ownership.

If you want to dive deeper into that topic, there is a valuable discussion in the Theia repository: Agent vs PromptTemplate vs Skill. The response by Jonas Helming provides useful guidance on how these mechanisms differ and when each is a good fit.

In short: both platforms are strong, modern foundations for AI-assisted development. If you optimize for ready-to-use productivity, Visual Studio Code is a strong choice. If you optimize for extensibility and product ownership, Eclipse Theia is compelling.

Apart from a Single Agent that does all the work alone, you currently have two options:

• Delegate Pattern
  Create guided sequential workflows that transition between agents. The agents are called one after the other.
• Coordinator and Worker Pattern
  The main/coordinator agent receives the task, delegates subtasks to subagents, and combines the subagent results into the final result.

You can also combine these patterns to have multiple “main” agents that use worker agents for specific tasks. Each “main” agent can delegate to the next “main” agent once it is done, creating a sequential workflow of main tasks.

I will explain these patterns and show the differences between Visual Studio Code and Eclipse Theia using the following example: get a list of links for a specific topic. To get those links, first check a GitHub user’s gists for a publication collection. Then inspect the list of publications for links contained in the posts.

Visual Studio Code

In the following sections, I describe how to create Custom Agents in Visual Studio Code and compare the different orchestration patterns.

GitHub MCP Server

As explained earlier, I want to set up an example process where the first step is to retrieve a list of publications from a GitHub Gist. For this, we need to configure the GitHub MCP Server with the gists toolset enabled.

• Open the file .vscode/mcp.json (create one if you do not already have that file in your workspace)
  • Add the following full configuration (or merge the github server entry into your existing servers object):

  {
    "servers": {
      "github": {
        "url": "https://api.githubcopilot.com/mcp/",
        "type": "sse",
        "headers": {
          "X-MCP-Toolsets": "gists"
        }
      }
    },
    "inputs": []
  }
  

  If you already have other servers configured in .vscode/mcp.json, keep them and only add the github entry under servers.

  This adds the Remote GitHub MCP Server with the gists toolset and OAuth authentication.

  Note:
  If you want to use a Personal Access Token (PAT) for the authorization instead of OAuth, have a look at Extending Copilot in Visual Studio Code - Remote MCP Server with authorization.

• In the editor, you will see actions provided as CodeLens that let you interact with the server. Click Start to start the GitHub MCP server.

  

  The first time, you will be prompted via dialog to authenticate with GitHub. After clicking Allow, a website opens where you can log in to the account you want to connect the MCP server to.

  

  After the authentication succeeds, the server starts and the capabilities and tools provided by the server are discovered.

Single Agent

We start by creating a single Custom Agent that performs all steps itself. This agent will then be split to explain the orchestration patterns.

• Create a new Custom Agent that executes the previously described process to provide the user with a collection of links for a specific topic.

  • In the Copilot chat window, click the gear icon in the upper right corner (Configure Chat…) and select
    Custom Agents -> Create new custom agent… -> .github/agents -> name: research

    This creates the file .github/agents/research.agent.md

• Add the tools web/fetch and github/list_gists
• Add a prompt that defines the steps to process

• The following snippet shows how such an agent could look like

  ---
  description: "This agent provides a collection of links for a specific topic."
  tools: [web/fetch, github/list_gists]
  ---
  
  You are an agent that helps the developer by extracting and providing links mentioned in blog posts.
  
  To provide the necessary links execute the following steps:
  
  1. Fetch the publications of Dirk Fauth in the gists of the user fipro78. Use #tool:github/list_gists to find the correct gist.
  2. Use #tool:web/fetch to fetch the content of the gist with a max-length parameter of 15000.
  3. Filter the fetched content for links about the requested information.
  4. For every found blog post, use #tool:web/fetch to fetch the content of the given blog post with a max-length parameter of 15000.
  5. Collect all links that are mentioned in the blog post and relevant for the topic.
  6. Filter out duplicate links and links that are not relevant for the topic. Relevance can be determined by the presence of keywords related to the topic in the context of the link.
  7. Provide a collection of the extracted filtered links ordered by the blog post they are mentioned in. Use the anchor text as the name of the link if available. If the anchor text is not available, use the URL as the name of the link. Order them alphabetically by the name of the link.
  

Hint:
The built-in web/fetch tool asks for approval to execute fetch and to access the URLs it wants to retrieve, ensuring no malicious content is fetched. If you use the custom agent prompts that I prepared, it will fetch my gist with my publications and blog posts published at https://vogella.com/blog/. If you trust these sources (at least I do :smile:), you can configure trust in settings.json by adding the following configuration to reduce the number of prompts during processing:

  "chat.tools.urls.autoApprove": {
    "https://vogella.com/blog/": true,
  },

• Use the Custom Agent research by selecting it in the agents dropdown in the chat view, then enter a prompt, for example show links about visual studio code.

  

  • When asked to allow fetching the gist and the content of the gist, select Allow and Review Once for the first request, and Allow Once afterwards.
    Further information can be found in the official documentation: Use tools with agents - URL approval

After the agent finishes its task, you can monitor the context window usage. The following screenshots show the context window usage when I ran the Custom Agent with Gemini 2.5 Pro and GPT-5.3-Codex. The values might be different when executing it again.

This is the context window usage with Gemini 2.5 Pro:

This is the context window usage with GPT-5.3-Codex:

Delegate Pattern

The Delegate Pattern is supported via Handoffs when creating Custom Agents in Visual Studio Code. For this scenario, we split the previous research agent into two Custom Agents, one per task:

• One agent to get the information from a gist to find the blog posts

• One agent to extract the links from the found blog posts

• Create a new Custom Agent that extracts links from the text of a given blog post.

  • In the Copilot chat window, click the gear icon in the upper right corner (Configure Chat…) and select
    Custom Agents -> Create new custom agent… -> .github/agents -> name: link_extractor

    This creates the file .github/agents/link_extractor.agent.md

• Add the built-in web/fetch tool to fetch the content
• Add a prompt that defines the steps to process

• The following snippet shows how such an agent could look like

  ---
  description: "This agent provides a list of links extracted from blog posts."
  tools: [web/fetch]
  ---
  
  You are an agent that helps the developer by extracting links mentioned in a blog post and providing them in a structured format.
  
  To provide the necessary links execute the following steps:
  
  1. Use #tool:web/fetch to fetch the content of the given blog post with a max-length parameter of 15000.
  2. Collect all links that are mentioned in the blog post and relevant for the topic.
  3. Filter out duplicate links and links that are not relevant for the topic. Relevance can be determined by the presence of keywords related to the topic in the context of the link.
  4. Provide a collection of the extracted filtered links ordered by the blog post they are mentioned in. Use the anchor text as the name of the link if available. If the anchor text is not available, use the URL as the name of the link. Order them alphabetically by the name of the link.
  

• Create a new Custom Agent that is able to retrieve information from a gist.

  • In the Copilot chat window, click the gear icon in the upper right corner (Configure Chat…) and select
    Custom Agents -> Create new custom agent… -> .github/agents -> name: gists

    This creates the file .github/agents/gists.agent.md

• Add the GitHub MCP tool github/list_gists to list the gists
• Add the built-in web/fetch tool to fetch the content
• Configure a handoff to delegate processing to the link_extractor agent

• The following snippet shows how such an agent could look like

  ---
  description: "This agent provides a list of links to blog posts from a GitHub Gist."
  tools: [github/list_gists, web/fetch]
  handoffs:
    - label: Extract Links from posts
      agent: link_extractor
      prompt: Extract links from the given list of blog posts
      send: true
  ---
  
  You are an agent that helps the developer by providing links to blog posts.
  
  To provide the necessary links execute the following steps:
  
  1. Fetch the publications of Dirk Fauth in the gists of the user fipro78. Use #tool:github/list_gists to find the correct gist.
  2. Use #tool:web/fetch to fetch the content of the gist with a max-length parameter of 15000.
  3. Filter the fetched content for links about the requested information.
  4. Provide a list of links to the relevant blog posts.
  

• Use the Custom Agent gists by selecting it in the agents dropdown in the chat view, then enter a prompt, for example show links about visual studio code.

  

  • When asked to allow fetching the gist and the content of the gist, select Allow and Review Once for the first request, and Allow Once afterwards.
    Further information can be found in the official documentation: Use tools with agents - URL approval
  • After the gists agent finishes its task, the user must actively proceed with the handoff by clicking the Proceed button in the chat.

    

  • You can see that the agent switches to the link_extractor agent in the chat

    

After the agent finishes its task, you can monitor the context window usage. The following screenshots show the context window usage when I ran the Custom Agent with Gemini 2.5 Pro and GPT-5.3-Codex. The values might be different when executing it again.

This is the context window usage with Gemini 2.5 Pro:

This is the context window usage with GPT-5.3-Codex:

You can see that the context window looks quite similar to executing the process with a single agent. The reason is that we stay in the same conversation, so the relevant context is largely the same. This means the context contains information from the first agent that is also available to the second agent. The Delegate Pattern therefore helps create a better structure for a multi-agent system and reusable agents for various scenarios via “encapsulation”, but it has little to no effect on token usage compared to the single-agent solution.

Coordinator and Worker Pattern

In Visual Studio Code, you implement the Coordinator and Worker Pattern by using Subagents. Using a subagent means spawning a child agent within a session to handle a subtask in its own isolated context window. From a pattern perspective, this means there is a main coordinator agent that manages the overall task and delegates subtasks to specialized subagents. To call a subagent, the built-in agent/runSubagent tool needs to be enabled for the coordinator agent. Each subagent call is sequential (the coordinator waits for that call to return), but the coordinator can spawn multiple subagent calls in parallel.

In this section, the previously created agents are converted into coordinator and worker agents.

• Open the file .github/agents/gists.agent.md
• Remove the handoffs header
• Ensure that the agent returns something at the end

• The following snippet shows how such an agent could look like

  ---
  description: "This agent provides a list of links to blog posts from a GitHub Gist."
  tools: [github/list_gists, web/fetch]
  ---
  
  You are an agent that helps the developer by providing links to blog posts.
  
  To provide the necessary links execute the following steps:
  
  1. Fetch the publications of Dirk Fauth in the gists of the user fipro78. Use #tool:github/list_gists to find the correct gist.
  2. Use #tool:web/fetch to fetch the content of the gist with a max-length parameter of 15000.
  3. Filter the fetched content for links about the requested information.
  4. Provide a list of links to the relevant blog posts.
  

• Open the file .github/agents/research.agent.md
• Add the built-in agent tool to call subagents and remove the other tools
• Configure the agents gists and link_extractor as agents that can be used as subagents

• The following snippet shows how such an agent could look like

  ---
  description: "This agent provides a collection of links for a specific topic."
  tools: [agent]
  agents: ["gists", "link_extractor"]
  ---
  
  You are an agent that helps the developer by providing links to blog posts about a specific topic.
  To provide the necessary links use subagents to execute the following steps:
  
  1. Use the gists subagent to fetch a collection of blog posts about the specific topic.
  2. For each of the found blog posts use the link_extractor subagent to fetch the content of the blog post and extract all links that are mentioned in the blog post.
  3. Provide a collection of the extracted links ordered by the blog post they are mentioned in. Use the anchor text as the name of the link if available. If the anchor text is not available, use the URL as the name of the link. Order them alphabetically by the name of the link.
  

• The link_extractor agent can stay as it is, since it does not specify a handoff and already returns the result in its prompt.

• Use the Custom Agent research by selecting it in the agents dropdown in the chat view, then enter a prompt, for example show links about visual studio code.

  

When watching the execution, you should notice that:

• The research agent stays active as the coordinator agent
• While the subagents are called, the coordinator waits until they are done
• The link_extractor agent is called multiple times, once per found blog post. These multiple agent calls are executed in parallel, while the coordinator agent waits until all spawned child agents are finished.

After the agent finishes its task, you can monitor the context window usage. The following screenshots show the context window usage when I ran the Custom Agent with Gemini 2.5 Pro and GPT-5.3-Codex. The values might be different when executing it again.

This is the context window usage with Gemini 2.5 Pro:

This is the context window usage with GPT-5.3-Codex:

You can see that the context window is smaller compared to the other patterns, which can be explained by the fact that each subagent is executed in its own isolated context window.

Eclipse Theia

If you are new to Eclipse Theia and want to try out the examples in the following sections, you have three options:

• Try Theia IDE online
• Get Theia IDE for desktop
• Build your own Theia application
  Have a look at Getting Started with Eclipse Theia and Getting Started with Theia AI if you are interested in that topic.

For the following sections, I assume that you have a Theia application with AI support. To enable AI features inside a Theia application, such as Theia IDE, you need access to an LLM and must configure it accordingly. I will give an example using the Google Gemini free tier. This only works if you have a Google account. If you want to use another LLM, have a look at the LLM Providers Overview to see which LLMs are currently supported by Theia. If you have a subscription for an LLM that is not listed here, check whether it is compatible with the OpenAI API and try to configure it as an OpenAI Compatible Model.

• If you have a Google account, you can try out the Google AI Studio
  • Create a new project via Google AI Studio - Projects
    • Click on Create a new project
    • Provide a name like theia-evaluation
    • Click on Create project
  • Create a new API key via Google AI Studio - API Keys
    • Click on Create API Key
    • Give the key a name like theia
    • Select the previously created theia-evaluation project
    • Click on Create key
• Switch to the Theia application (e.g. the Theia IDE)
  • Open the settings page by pressing CTRL + ,
    • Select the AI Features
    • Check Enable AI
    • Configure the LLM you want to use
      • Google
        • Api Key: Copy and paste your Google AI API key (see above)
          For this tutorial we simply configure the API key via preferences as it is easier than setting up the environment. In a productive environment you should use the environment variable GOOGLE_API_KEY to set the key securely.
        • Models: Ensure to have models in the list that are currently available according to Gemini Models
    • Configure the Model Aliases
      • Open the AI Configuration via Menu -> View -> AI Configuration
      • Switch to the Model Aliases tab
      • For every model alias, select the model that you configured, e.g. google/gemini-3.1-flash-lite-preview

Since version 1.68.0 Theia also supports a GitHub Copilot language model integration. To try it out, you need to authenticate with GitHub

• Click on Sign in to GitHub Copilot in the footer of the Theia application

  

• This will open the following window

  

• Copy the key
• Click on Open GitHub
• Follow the instructions on the GitHub website to grant the device permission
• After the device activation is successful, switch back to the Theia browser window and click on I have authorized to finish the authentication process in Theia
• After successful authentication, you can select a Copilot model as Model Alias, e.g. copilot/gpt-4o

Note:
At the time of writing this article, the only Copilot models that are working in Theia are gpt-4o and gpt-4o-mini. Using other models results in the following issue: AI Chat with GitHub Copilot fails with: 400 The requested model is not supported.

MCP Server Configuration

To set up the example process like in Visual Studio Code to retrieve a list of publications from a GitHub Gist and then fetch the data for further processing, we need to configure the necessary MCP server. This is again the GitHub MCP Server with the gists toolset enabled, and the fetch MCP Server as Theia does not provide a built-in fetch tool.

• Open the AI Configuration via Menu -> View -> AI Configuration
  • Switch to the MCP Servers tab
  • Add the Fetch MCP Server as a remote MCP Server
    • Click on Add MCP Server
    • Set the following values in the dialog
      • Server Name: fetch
      • Server Type: Remote (URL)
      • Server URL: https://remote.mcpservers.org/fetch/mcp
      • Keep the Autostart flag checked
    • Click Add Server

    

  • Add the Remote GitHub MCP Server with the gists toolset
    • Click on Add MCP Server
    • Set the following values in the dialog
      • Server Name: github
      • Server Type: Remote (URL)
      • Server URL: https://api.githubcopilot.com/mcp/x/gists
      • Auth Token: Your Personal Access Token (PAT) with repo scope. See Creating a personal access token (classic) if you do not already have a PAT.
      • Keep the Autostart flag checked
    • Click Add Server

    

• Instead of configuring everything via user interface, you can also directly paste one of the following configurations directly in the settings JSON
  • Switch to the JSON view of the settings by clicking the curly braces on the upper right corner of the editor (Open Settings (JSON))
  • Alternatively use the Command Palette (F1) and search for Preferences: Open Settings (JSON)
  • Copy the following snippet and paste it in the editor

    {
      "window.titleBarStyle": "custom",
      "ai-features.AiEnable.enableAI": true,
      "ai-features.google.apiKey": "<your-api-key>",
      "ai-features.google.models": [
        "gemini-3.1-flash-lite-preview",
        "gemini-3-flash-preview",
        "gemini-2.5-flash",
        "gemini-2.5-flash-lite",
        "gemini-2.5-pro"
      ],
      "ai-features.languageModelAliases": {
        "default/code": {
          "selectedModel": "google/gemini-3.1-flash-lite-preview"
        },
        "default/universal": {
          "selectedModel": "google/gemini-3.1-flash-lite-preview"
        },
        "default/code-completion": {
          "selectedModel": "google/gemini-3.1-flash-lite-preview"
        },
        "default/summarize": {
          "selectedModel": "google/gemini-3.1-flash-lite-preview"
        }
      },
      "ai-features.chat.defaultChatAgent": "Universal",
      "ai-features.mcp.mcpServers": {
        "fetch": {
          "serverUrl": "https://remote.mcpservers.org/fetch/mcp",
          "autostart": true
        },
        "github": {
          "serverUrl": "https://api.githubcopilot.com/mcp/x/gists",
          "autostart": true,
          "serverAuthToken": "<your-github-pat>"
        }
      }
    }
    

  • Replace <your-api-key> with your Google AI Studio AI key and <your-github-pat> with your PAT.

After performing the above steps, you should see the two MCP servers in the overview and they should directly be Connected as the servers are configured to autostart.

Single Agent

We again first create a single Custom Agent that performs all steps itself. This agent will then be split to explain the orchestration patterns.

• Create a new Custom Agent that executes the previously described process to provide the user with a collection of links for a specific topic.
  • Open the AI Configuration via Menu -> View -> AI Configuration
  • Switch to the Agents tab
  • Click on Add Custom Agent

    

  • Select the .prompts folder of the current workspace
  • Verify that a .prompts folder is generated in your workspace that contains a customAgents.yml file
  • Define a custom agent with the name Research by defining the following information
    • id: A unique identifier for the agent.
    • name: The display name of the agent.
    • description: A brief explanation of what the agent does.
    • prompt: The default prompt that the agent will use for processing requests.
    • defaultLLM: The language model used by default.
    • showInChat: Whether the agent should be shown in the chat UI. This one is optional and defaults to true.
  • Replace the content of the customAgents.yml with the following snippet

  - id: Research
    name: Research
    description: This agent provides a collection of links for a specific topic.
    prompt: >-
      You are an agent that helps the developer by extracting and providing links mentioned in blog posts.
  
      To provide the necessary links execute the following steps:
  
      1. Fetch the publications of Dirk Fauth in the gists of the user fipro78. Use ~{mcp_github_list_gists} to find the correct gist.
      2. Use ~{mcp_fetch_fetch} to fetch the content of the gist with a max-length parameter of 15000.
      3. Filter the fetched content for links about the requested information.
      4. For every found blog post, use ~{mcp_fetch_fetch} to fetch the content of the given blog post with a max-length parameter of 15000.
      5. Collect all links that are mentioned in the blog post and relevant for the topic.
      6. Filter out duplicate links and links that are not relevant for the topic. Relevance can be determined by the presence of keywords related to the topic in the context of the link.
      7. Provide a collection of the extracted filtered links ordered by the blog post they are mentioned in. Use the anchor text as the name of the link if available. If the anchor text is not available, use the URL as the name of the link. Order them alphabetically by the name of the link.
  
    defaultLLM: default/universal
    showInChat: true
  

  Compared to a custom agent in Visual Studio Code, we do not need to configure which tools we want to use in the prompt. They can simply be referenced in the prompt via ~<tool-name>.

• Use the Custom Agent Research by selecting it in the chat prompt via @ syntax and add the prompt to execute, for example @Research show links about theia.

  

Theia does not yet support context window monitoring like Visual Studio Code, so we cannot inspect detailed context usage. This feature has been requested via Context window inspection / analysis command. For several LLMs, token usage can still be inspected via AI Configuration by switching to the Token Usage tab. I tested the example using GPT-5.3-Codex hosted on Azure, GPT-4o via Copilot, and Gemini 3.1 Flash Lite Preview via Google AI Studio in the Free Tier.

Note:
The token counts reported for Gemini models are incorrect in Theia 1.69.0. I created the ticket Token usage shows incorrect values for Gemini models and submitted a pull request that fixes this issue. The screenshot above shows token usage with the fix applied for a fair comparison.

Token usage is not persisted and is reset when restarting the application. To get a better comparison, I restart after each example.

Delegate Pattern

Theia does not provide a feature like the Handoffs in Visual Studio Code. Instead Theia provides the built-in Tool Function delegateToAgent to support Agent-to-Agent Delegation. To show this scenario, we split the previous Research agent into two Custom Agents, one per task:

• One agent to get the information from a gist to find the blog posts
• One agent to extract the links from the found blog posts

In Eclipse Theia, multiple Custom Agents are configured in a single custom agent configuration file. We therefore add the new agents to the previously created customAgents.yml.

• Open the .prompts/customAgents.yml file
• Add a new Link_Extractor agent
  • Use the MCP Tool mcp_fetch_fetch to fetch the content of the blog posts
  • Add a prompt that defines the steps to process
  • The following snippet shows how such an agent could look like

  - id: Link_Extractor
    name: Link_Extractor
    description: This agent provides a list of links extracted from blog posts.
    prompt: >-
      You are an agent that helps the developer by extracting links mentioned in blog posts and providing them in a structured format.
  
      To provide the necessary links execute the following steps:
  
      1. Iterate over the list of provided blog posts
      2. For every blog post use ~{mcp_fetch_fetch} to fetch the content of the blog post with a max-length parameter of 15000.
      3. Collect all links that are mentioned in the blog post and relevant for the topic.
      4. Filter out duplicate links and links that are not relevant for the topic. Relevance can be determined by the presence of keywords related to the topic in the context of the link.
      5. Provide a collection of the extracted filtered links ordered by the blog post they are mentioned in. Use the anchor text as the name of the link if available. If the anchor text is not available, use the URL as the name of the link. Order them alphabetically by the name of the link.
  
    defaultLLM: default/universal
    showInChat: true
  

• Add a new Gists agent
  • Use the MCP Tool mcp_github_list_gists to list the gists
  • Use the MCP Tool mcp_fetch_fetch to fetch the content
  • Use the Theia built-in Tool Function delegateToAgent to delegate processing to the Link_Extractor agent
  • The following snippet shows how such an agent could look like

  - id: Gists
    name: Gists
    description: This agent provides a list of links to blog posts from a GitHub Gist.
    prompt: >-
      You are an agent that helps the developer by providing links to blog posts.
  
      To provide the necessary links execute the following steps:
  
      1. Fetch the publications of Dirk Fauth in the gists of the user fipro78. Use ~{mcp_github_list_gists} to find the correct gist.
      2. Use ~{mcp_fetch_fetch} to fetch the content of the gist with a max-length parameter of 15000.
      3. Filter the fetched content for links about the requested information.
      4. Provide a list of links to the relevant blog posts.
      5. Pass the provided list of links to the Link_Extractor agent via ~{delegateToAgent} to extract links from the given list of blog posts
  
    defaultLLM: default/universal
    showInChat: true
  

• Use the Custom Agent Gists by selecting it in the chat prompt via @ syntax and add the prompt to execute, for example @Gists show links about theia.

  

You can see in the chat response that the Gists agent stays the active agent, and Link_Extractor is called as part of it. So it is not actually a Handoff like in Visual Studio Code, where the active agent really switches.

Theia does not yet support context window monitoring like Visual Studio Code, so we cannot inspect detailed context usage. This feature has been requested via Context window inspection / analysis command. For several LLMs, token usage can still be inspected via AI Configuration by switching to the Token Usage tab. I tested the example using GPT-5.3-Codex hosted on Azure, GPT-4o via Copilot, and Gemini 3.1 Flash Lite Preview via Google AI Studio in the Free Tier.

Note:
The token counts reported for Gemini models are incorrect in Theia 1.69.0. I created the ticket Token usage shows incorrect values for Gemini models and submitted a pull request that fixes this issue. The screenshot above shows token usage with the fix applied for a fair comparison.

Interestingly, token usage for the Delegate Pattern in Theia is slightly higher compared to the single-agent solution. It is also interesting that the Delegate Pattern is not exactly the same as in Visual Studio Code via Handoffs. It seems that Agent-to-Agent Delegation is similar to Subagents in Visual Studio Code, at least based on the chat output.

At the time of writing this blog post, Theia does not support an automatic Handoff similar to Visual Studio Code. But you can try to simulate this manually.

• Update the Gists agent
  • Remove the last step that passes the processing to the Link_Extractor agent
  • The following snippet shows how such an agent could look like

  - id: Gists
    name: Gists
    description: This agent provides a list of links to blog posts from a GitHub Gist.
    prompt: >-
      You are an agent that helps the developer by providing links to blog posts.
  
      To provide the necessary links execute the following steps:
  
      1. Fetch the publications of Dirk Fauth in the gists of the user fipro78. Use ~{mcp_github_list_gists} to find the correct gist.
      2. Use ~{mcp_fetch_fetch} to fetch the content of the gist with a max-length parameter of 15000.
      3. Filter the fetched content for links about the requested information.
      4. Provide a list of links to the relevant blog posts.
  
    defaultLLM: default/universal
    showInChat: true
  

• Use the Custom Agent Gists by selecting it in the chat prompt via @ syntax and add the prompt to execute, for example @Gists show links about theia.

  

• Once the Gists agent is done, use the Link_Extractor agent by selecting it in the chat prompt via @ syntax and add the prompt to execute, for example @Link_Extractor fetch the previously found blog posts and extract further links.

  

As a result of manually changing the active agent, Link_Extractor is now the active agent.

The token usage increased as the whole conversation is passed to the next agent as context, and the token usage is accumulated over the whole session. Therefore the Input Tokens and the Output Tokens are higher than compared to using the Agent-to-Agent Delegation with an isolated context or the Single Agent, where only a single request is processed.

Coordinator and Worker Pattern

In Eclipse Theia, you implement the Coordinator and Worker Pattern by using Subagents via the built-in Tool Function delegateToAgent. Using a subagent means spawning a child agent within a session to handle a subtask in its own isolated context window. This can be seen in the delegateToAgent implementation. From a pattern perspective, this means there is a main coordinator agent that manages the overall task and delegates subtasks to specialized subagents. Each subagent call is sequential (the coordinator waits for that call to return), but the coordinator can spawn multiple subagent calls in parallel.

In this section, the previously created agents are converted into coordinator and worker agents.

• Open the .prompts/customAgents.yml file
• Change the prompt of the Research agent
  • Use ~{delegateToAgent} to delegate tasks to the Gists and the Link_Extractor agent

  • The following snippet shows how such an agent could look like

    - id: Research
      name: Research
      description: This agent provides a collection of links for a specific topic.
      prompt: >-
        You are an agent that helps the developer by providing links to blog posts about a specific topic.
        To provide the necessary links use subagents to execute the following steps:
    
        1. Use the Gists subagent via ~{delegateToAgent} to fetch a collection of blog posts about the specific topic.
        2. For each of the found blog post link use the Link_Extractor subagent via ~{delegateToAgent} to fetch the content of the blog post and extract all links that are mentioned in the blog post.
        3. Provide a collection of the extracted links ordered by the blog post they are mentioned in. Use the anchor text as the name of the link if available. If the anchor text is not available, use the URL as the name of the link. Order them alphabetically by the name of the link.
    
      defaultLLM: default/universal
      showInChat: true
    

• Change the prompt of the Gists agent
  • Remove the last step that delegates to the Link_Extractor agent
  • Ensure that the agent returns something at the end

  • The following snippet shows how such an agent could look like

    - id: Gists
      name: Gists
      description: This agent provides a list of links to blog posts from a GitHub Gist.
      prompt: >-
        You are an agent that helps the developer by providing links to blog posts.
    
        To provide the necessary links execute the following steps:
    
        1. Fetch the publications of Dirk Fauth in the gists of the user fipro78. Use ~{mcp_github_list_gists} to find the correct gist.
        2. Use ~{mcp_fetch_fetch} to fetch the content of the gist with a max-length parameter of 15000.
        3. Filter the fetched content for links about the requested information.
        4. Provide a list of links to the relevant blog posts.
    
      defaultLLM: default/universal
      showInChat: true
    

• Change the prompt of the Link_Extractor agent
  • Remove the iteration, as now the agent is called once per blog post
  • Ensure that the agent returns something at the end

  • The following snippet shows how such an agent could look like

    - id: Link_Extractor
      name: Link_Extractor
      description: This agent provides a list of links extracted from blog posts.
      prompt: >-
        You are an agent that helps the developer by extracting links mentioned in a blog post and providing them in a structured format.
    
        To provide the necessary links execute the following steps:
    
        1. Use ~{mcp_fetch_fetch} to fetch the content of the blog post with a max-length parameter of 15000.
        2. Collect all links that are mentioned in the blog post and relevant for the topic.
        3. Filter out duplicate links and links that are not relevant for the topic. Relevance can be determined by the presence of keywords related to the topic in the context of the link.
        4. Provide a collection of the extracted filtered links ordered by the blog post they are mentioned in. Use the anchor text as the name of the link if available. If the anchor text is not available, use the URL as the name of the link. Order them alphabetically by the name of the link.
    
      defaultLLM: default/universal
      showInChat: true
    

• Use the Custom Agent Research by selecting it in the chat prompt via @ syntax and add the prompt to execute, for example @Research show links about theia.

  

I noticed that it depends on the model used whether subagent calls are executed sequentially or in parallel. For example, with gemini-3.1-flash-lite-preview in the free tier, the delegateToAgent tool calls were executed sequentially. When executing the same workflow with gpt-5.4, the calls were executed in parallel, as you can see in the following screenshot:

Theia does not yet support context window monitoring like Visual Studio Code, so we cannot inspect detailed context usage. This feature has been requested via Context window inspection / analysis command. For several LLMs, token usage can still be inspected via AI Configuration by switching to the Token Usage tab. I tested the example using GPT-5.3-Codex hosted on Azure, GPT-4o via Copilot, and Gemini 3.1 Flash Lite Preview via Google AI Studio in the Free Tier.

Note:
The token counts reported for Gemini models are incorrect in Theia 1.69.0. I created the ticket Token usage shows incorrect values for Gemini models and submitted a pull request that fixes this issue. The screenshot above shows token usage with the fix applied for a fair comparison.

Interestingly, token usage for the Coordinator and Worker Pattern in Theia uses fewer tokens than the Delegate Pattern but still slightly more than the single-agent solution.

Conclusion

There is no single “best” orchestration pattern for every scenario. The right choice depends on whether your priority is simplicity, reuse, user guidance, or token efficiency.

For quick implementations and straightforward tasks, a single agent is often the easiest and most reliable option. If you want to split responsibilities into reusable building blocks and keep a guided user flow, delegation is a good fit. If you need better context isolation and potentially lower token usage for larger workflows, a coordinator with specialized worker subagents is usually the strongest approach.

The key takeaway is to treat orchestration as an architectural decision, not just a prompt-writing detail. In Visual Studio Code, the selected orchestration pattern can have a clear impact on token usage, while in Eclipse Theia the impact is almost negligible in this scenario. Start with the simplest setup that works, measure behavior and token usage with your target model, and then evolve toward delegation or coordinator-worker designs when your workflow grows in complexity.

As agent tooling in Visual Studio Code and Eclipse Theia continues to evolve, these patterns will likely become even more powerful. Revisit your agent design regularly to benefit from new capabilities and improved model behavior.

Testing New Icons in Your IDE

To try them out in your existing Eclipse installation, you can use the provided replace_icons.sh script.

Prerequisites

• jq (for JSON parsing)
• A JDK with the jar command

Steps

1. Clone the repository:

git clone https://github.com/eclipse-platform/ui-best-practices.git
cd ui-best-practices

1. Run the replacement script, pointing it to your Eclipse plugins directory and the desired icon mapping file:

./scripts/replace_icons.sh /path/to/eclipse/plugins iconpacks/eclipse-dual-tone/icon-mapping.json

The script reads the JSON mapping file, locates each icon in the icon pack, and replaces the corresponding icons inside the Eclipse plugins — whether they are folder-based or packaged as JARs.

1. Restart Eclipse with the -clean -clearPersistedState flags to clear the icon cache:

./eclipse -clean -clearPersistedState

You should now see the updated icons in your IDE.

Note: To see the new icons in EGit, you need a nightly build of EGit, as it only recently moved to SVG images.

Kudos to the Contributors

This project would not exist without the dedicated work of its contributors. Special thanks to Jasmin Hundt, Matthias Becker, Daniela Stegaru, and Michael Bangas. Their efforts are making the Eclipse IDE more visually modern and consistent.