Can AI deploy your entire EUC infrastructure?

Table of Contents

• Why research AI in the context of GO-EUC?
• Setup and scenarios
• Scoring the rules and constraints
• Hypothesis
• Results
• Breakdown per model
  • Auto
  • Claude Fable 5.1
  • Claude Opus 5.5
  • Claude Sonnet 5.5
  • Gemini 4 Argon
  • GPT-5.6 Sol
  • Grok 4.6
  • Grok 4.7
  • Muse Wonder
• Conclusion

Generative AI is becoming part of our daily work, whether it is used for writing emails, summarizing documents, generating code or scripts, or troubleshooting technical issues, AI often is a companion and is changing the way people work. As AI models continue evolving and becoming increasingly capable of handling complex tasks, does the End User Computing (EUC) industry need to adjust? Can generative AI go beyond assisting an EUC administrator and actually take over an entire deployment? This research will find out whether generative AI can replace the EUC administrator.

Why research AI in the context of GO-EUC?

It is important to provide background on the decision to expand GO-EUC’s research into AI-related topics. As you might know, GO-EUC is primarily a research platform focused on performance-related questions within the EUC industry. This has been the core focus since GO-EUC was founded in 2017. However, the EUC industry is continuously changing.

With the shift towards cloud computing and hyperscalers, traditional platform performance and scalability questions as we know them from the early days of server-based computing, have become less prominent. Instead, organisations are increasingly focusing on user experience and cost-effectiveness of their environments. This shift is also reflected in GO-EUC’s research over the past couple of years, where the focus has gradually expanded beyond traditional performance metrics to include user experience and cost considerations.

As the industry continues to move, the GO-EUC team regularly evaluates its research topics and the overall direction of the platform. Recently, the team reached out to the community to gather feedback on potential research topics. One of the most common responses was the question of how AI will impact the EUC industry.

AI is a broad topic, and many organisations are currently exploring how to adopt AI while maintaining control over security, privacy, and data protection. While cloud-based AI services are currently widely adopted, there is an expectation that more AI models will eventually run locally on endpoint devices or within organisations’ own infrastructure. This introduces new questions about hardware requirements, performance, resource consumption, and ultimately, how these technologies can be integrated into existing EUC environments.

AI is a topic that cannot be ignored. Based on the feedback from the community, combined with the team’s own curiosity, GO-EUC has decided to expand its research into this area. This article marks the first AI-specific research published on GO-EUC.

While the team continues to explore and evaluate potential AI use cases within the EUC industry, it has been decided to start with a practical use case that is relevant to EUC administrators and engineers.

Setup and scenarios

To answer this question, can generative AI replace an adminadministrator/engineer in building a EUC infrastructure deployment? Our team are also experts in infrastructure as code (IaC) deployments, as these tools and methods are used to build up the infrastructure for our research. To read more about this, please see the development section on our website.

As the goal is to let AI produce infrastructure as code deployment, it is important to scope the research and determine how to evaluate the results.

In this scenario, the criteria evaluated has been set as valid Terraform code, surviving a terraform validate, a deployment of the code, a review of the environment, and a percentage against each rule in the prompt.

The test is a single prompt, given once, with no follow-up correction.

Nine models each produced a Terraform project for the same deployment:

• Auto
• Claude Fable 5.1
• Claude Opus 5.5
• Claude Sonnet 5.5
• Gemini 4 Argon
• GPT-5.6 Sol
• Grok 4.6
• Grok 4.7
• Muse Wonder

The primary IDE is Cursor version 3.27 using a pro subscription, which enables making use of all the models listed above. Cursor also allows you to adjust the context size, effort and if it should be fast. For all models, it has been left at the default settings as described in the table below.

• N/A means the setting is not available to be adjusted.

The scenario in question is a personal Azure Virtual Desktop deployment in West Europe. It contains a resource group, a virtual network, one Windows 11 Enterprise session host on Standard_D4s_v5, Microsoft Entra ID join without Active Directory Domain Services, hibernation, a personal scaling plan, a workspace, a desktop application group, and access for an existing test user. Licensing and Conditional Access sit outside the code, and they are not part of the comparison.

The results are judged on three points.

• The project contains the deployment above.
• The configuration survives the Azure requirements that decide if a user can sign in and whether the desktop hibernates.
• An administrator could operate the project: a README document is provided, variables instead of a hardcoded user, the token kept out of clear text, and a role at the scope of Microsoft documents.

There are a couple of key configurations that are important to note. From March 31 2026 new virtual networks will default to private subnets, so a session host without a public IP address needs a NAT gateway. 

Encryption at host fails virtual machine creation unless that feature is already registered on the subscription. 

Start VM on Connect and autoscale power management need Desktop Virtualization Power On Off Contributor at subscription scope, on the Azure Virtual Desktop service principal or on a managed identity attached to the host pool. An assignment on the resource group does not meet that requirement. 

Finally, the session host joins the pool only when the agent receives the registration token in the form the Azure Virtual Desktop service accepts.

Each project was initialized and validated with Terraform. terraform validate checks that the configuration parses and that the provider schemas accept it. It does not create resources in Azure. For deployment, terraform apply builds the resources in the configured Azure subscription. 

The nine projects share a naming prefix, so they cannot be deployed together. Each one was applied on its own, in West Europe, and destroyed before the next began. A completed Terraform apply means Azure accepted the resources. It does not mean a user signed in, and it does not mean the scaling plan later hibernated the desktop.

Scoring the rules and constraints

The prompt sets 17 rules for the generated project. Each rule is marked met, partial, or missed. A met rule scores 1, a partial rule scores 0.5, and a missed rule scores 0. The percentage is that total divided by 17.

The rules cover Terraform practice, security, least privilege, supported providers, a design that can be run again, variables instead of hardcoded values, Azure architecture, cost, a complete set of resources, no extra components, a deployment that does not need a later manual change, no secrets in the source, documentation, a validate-deploy-destroy cycle, complete code, and a decision made without asking a question.

A failed apply scores on the rules it breaks. Validate, deploy, and destroy is one of the 17. One defect can count against two rules when both rules name it. The power management role on the resource group counts under architecture and under automation. A pinned source image reference counts under reproducibility and under hardcoding.

Six rules are a full mark for every model. Those are naming, separate files, the ten resources in the task, no secrets written into the source, complete code, and a decision made without a question. The spread is in the other eleven.

Hypothesis

The hypothesis is that a current model, given one prompt and no follow-up correction, can produce infrastructure as code for a complete Azure Virtual Desktop deployment that an administrator could apply and provide a desktop to a user. If that holds, the model has done the deployment work. If it does not, the useful result is how far the code gets, and which parts are still left with the administrator.

All nine configurations are valid. terraform validate succeeded for every project. The generated Terraform parses, the provider schemas accept it, and an administrator is not starting from a file that Terraform itself rejects.

The shared result is that every model understood the shape of the deployment. All nine built a personal host pool, a single-session Windows 11 Enterprise image, Standard_D4s_v5 in West Europe, Entra join, hibernation on the virtual machine, a workspace, a desktop application group, a registration token, and role assignments for a test user. None of them built a domain controller, and none of them put a public IP address on the session host. All nine also worked around the same provider limit. The AzureRM scaling-plan resource can only describe a pooled plan, so the personal plan is created through the Azure API. That is the sort of detail an administrator usually learns after a failed Terraform apply.

The projects separate on the requirements that decide whether a user can sign in, and whether the desktop hibernates.

Results

The following table shows a complete overview scoring per model (higher is better), including the cost estimation (lower is better). Prices are collected from public sources and the generated prices are estimated prices based on the cost model. They might vary due to complexity in the pricing model, but overall, it gives a clear indication of the price.

The token usage is extracted from Cursor and provides a breakdown per model and the prompt date and time, and is specific to this research.

As the token export includes a breakdown of cache, input, and output, it provides the ability to make a price breakdown.

Seven of the nine projects completed terraform apply, while both Auto and Claude Fable 5.1 did not.

Auto failed where the review expected, on encryption at host, after the default user had already stopped a first attempt.

Fable failed on the hibernation extension the review had treated as part of a finished configuration. The virtual machine, the agent and Entra join were already in place when Azure rejected that extension.

Fable is, together with GPT 5.6 Sol, the most expensive model in the set, at two and a half times the input and output rate of Claude Opus 5.5. On the rules score those two failed Terraform apply operations are 67.6 percent and 70.6 percent. The apply is one rule, and the rest of each project still counts.

The rules score ties four models at 94.1 percent: Claude Sonnet 5.5, GPT-5.6 Sol, Grok 4.7 and Muse Wonder. Claude Opus 5.5 is just behind, at 91.2 percent, on the same role-scope partial as Sonnet plus a Premium disk. Grok 4.6 is at 82.4 percent and Gemini 4 Argon at 79.4 percent. The tie at the top is four different projects. Sonnet and Grok 4.7 lose their points on the power role, which is still on the resource group. GPT-5.6 Sol and Muse Wonder already place that role at subscription scope, and lose their points on a pinned source image reference, and on open device redirection with a weekday-only schedule.

Of the projects Azure accepted in full, Grok 4.7 has the lowest published output price and the same rules score as Sonnet. The correction left in both is the role scope. Claude Sonnet 5.5 is the deployment to read when an administrator wants the agent install in a script they can follow, at 2 and 10 dollars, one fifth of Fable’s output price. Opus needs the same role correction at twice that rate, and scores 91.2 percent. GPT-5.6 Sol and Muse Wonder are the two at 94.1 percent that already had the role at subscription scope when the apply finished. Gemini 4 Argon shares Sonnet’s current 2 and 10 dollar rate and scores 79.4 percent, with the registration token left in clear text and no README.

Price does not sort these results into a straight line. The most expensive model produced the configuration that looked finished, scored 70.6 percent, and failed the apply. Four models at 94.1 percent were accepted by Azure. The cheapest output rate is one of those four, and the permission it selected is the one that stops autoscale.

When sorting by price, the most cost-efficient model is Grok 4.6, which has a rules score of 82.40% with a price of just $0.80. Based on this research, Claude Sonnet 5.5 is scoring high at 94.10% and, with a cost of just over $1.0 is it the most efficient and cost effective model.

Breakdown per model

Auto

Auto produced a project that is valid based on Terraform and the one that would fail earliest. Encryption at host is turned on with no switch to disable it, so virtual machine creation fails on a subscription where that feature is not already registered. There is no NAT gateway, so on a new subnet the session host has no path to Entra ID or the AVD agent endpoints. The power management role is on the resource group. A real user principal name is also filled in as the default, so an apply without an override would target that account. The registration token itself is passed correctly, in the protected settings of the DSC extension.

The deployment failed. The default user is not in the tenant used for this test, so the first apply stopped before creating resources. Pointed at an existing user, Auto created the resource group, the network and the host pool, and then virtual machine creation was rejected because Microsoft.Compute/EncryptionAtHost is not enabled on the subscription. The partial deployment was destroyed. Against the 17 rules, Auto scores 67.6 percent, the lowest in the set. The missed rules are the hardcoded user, Azure architecture, and a deployment that still needs a change before it can finish. The failed apply is a partial mark on the validate, deploy and destroy rule.

There is no public per-token list price for Auto. In Cursor, Cost mode is included usage, and the router chooses the model.

Claude Fable 5.1

Claude Fable 5.1 is the standout. The configuration is valid using the terraform validate command, and it is the only project that is consistent on the points that make this desktop work. Outbound access is a NAT gateway, with default outbound access turned off on the subnet. The power management role is granted to the Azure Virtual Desktop service principal on the subscription, which is the scope Microsoft documents. The registration token is in the protected settings. The session host installs the AVD agent, joins Entra ID, and then applies the hibernation extension, in that order. Disconnected sessions hibernate, signed-out machines are deallocated, and the schedule covers the week. The README states the assumptions an administrator still has to meet, including the permission required to create role assignments and the fact that the Entra device object survives terraform destroy.

Fable’s apply got through the virtual machine, the AVD agent, and the Entra ID join. Azure then rejected the last extension, WindowsHibernateExtension, from the publisher Microsoft.CPlat.Core. That extension is reserved for Microsoft. The error was 409 OperationNotAllowed. The 26 resources already created were destroyed. Hibernation on the virtual machine was already set. The extra extension is what stopped the apply.

The published list price is the highest in the set, 10 dollars per million input tokens and 50 dollars per million output tokens.

Claude Opus 5.5

Claude Opus 5.5 is the closest project to Fable. It is valid Terraform, with a NAT gateway, encryption at host is left off unless the operator turns it on, and a registration token passed through the credential reference that the current gallery package supports. The schedule covers weekdays and the weekend, hibernates a disconnected session, and deallocates after sign-out. The power management role is still on the resource group, so Start VM on Connect and autoscale would not run until that assignment is moved to the subscription.

The deployment succeeded. Terraform created 26 resources, including the session host, and the deployment was then destroyed. The apply does not show whether autoscale runs with the role still on the resource group. Against the 17 rules, Opus scores 91.2 percent. The partial marks are that role scope, a Premium SSD as the default disk, and the power management role change left after the apply.

The list price is 4 dollars per million input tokens and 20 dollars per million output tokens.

Claude Sonnet 5.5

Claude Sonnet 5.5 is valid and lands in the same place as Opus, at half the list price: 2 dollars per million input tokens and 10 dollars per million output tokens. Outbound access, the image, hibernation, and a full-week schedule that deallocates after sign-out are all in place. The distinctive choice is the agent install. Instead of the gallery DSC package, the project waits until the Entra join has completed and then installs the current agent and boot loader with a small script, passing the token as a protected parameter. Of the approaches in this comparison, that script is the easiest one for an administrator to read. The power management role is on the resource group, which is the same correction Opus still needs.

The deployment succeeded. Terraform created 25 resources, including that scripted agent install, and the deployment was then destroyed. Sonnet does not declare the hibernation extension that stopped Fable. It leaves that extension to the platform, and Azure accepted the virtual machine. Against the 17 rules, Sonnet scores 94.1 percent. Both partial marks are the power role on the resource group, counted once under architecture and once under a deployment that should not need a later change.

The list price is 2 dollars per million input tokens and 10 dollars per million output tokens, half the list price of Opus.

Gemini 4 Argon

Gemini 4 Argon is valid Terraform and contains the full deployment, including a NAT gateway and a personal scaling plan attached back to the host pool. It has no README. The registration token is written into the extension settings in clear text rather than the protected settings, so the token is visible on the virtual machine resource. The older gallery package it pins is still published, so registration can succeed. The power management role is on the resource group.

Google lists this model at 2 dollars per million input tokens and 10 dollars per million output tokens through 30 November 2026, and at 4 and 20 dollars from 1 December 2026. The output price includes thinking tokens.

The deployment succeeded. Terraform created 27 resources and the deployment was then destroyed. The registration token in clear text did not stop Azure from accepting the resources. Against the 17 rules, Gemini scores 79.4 percent. The missed rule is documentation, because there is no README. The partial marks are the token in clear text, login and power roles on the resource group, and a Premium disk.

GPT-5.6 Sol

GPT-5.6 Sol produced valid Terraform code, and it is the project that follows the newer autoscale option. The host pool is created through the current Azure API, with a user-assigned identity, and Desktop Virtualization Power On Off Contributor is granted to that identity at subscription scope. Microsoft’s autoscale documentation allows a host-pool managed identity or the first-party service principal, at subscription scope. Start VM on Connect is still documented against the service principal, so that path is the part an administrator would prove in a tenant. The marketplace image is pinned to one exact version rather than latest, so the apply depends on that version remaining available in West Europe. The Entra join extension is the legacy 1.0 handler. Hibernation is applied outside working hours, and a disconnect during the day is left alone, which is a reasonable office schedule.

OpenAI lists the short-context rate at 4 dollars per million input tokens and 20 dollars per million output tokens, as promotional pricing at least through 21 November 2026. Above 272,000 input tokens the rate doubles.

The deployment succeeded. Terraform created 27 resources. The pinned image version was still available in West Europe, and the deployment was then destroyed. Against the 17 rules, GPT-5.6 Sol scores 94.1 percent. The subscription-scoped role meets the architecture and automation rules. Both partial marks are pinned source image reference, once for reproducibility and once because the version is hardcoded.

Grok 4.6

Grok 4.6 is valid based on the Terraform validate command. It has a NAT gateway, a full-week hibernate schedule, and a registration token in the protected settings. The marketplace offer is written as Windows-11, while the image is published as windows-11, so image lookup is the risk at apply time. The Entra join extension is the 1.0 handler. The power management role is on the resource group. An antimalware extension is added on top of the AVD configuration.

The deployment succeeded. Terraform created 26 resources. Azure accepted the marketplace offer as written, so the casing did not stop this apply. The deployment was then destroyed. Against the 17 rules, Grok 4.6 scores 82.4 percent. There is no missed rule. The partial marks are Virtual Machine User Login on the resource group, the marketplace offer casing, the power role, the Premium disk, the extra antimalware extension, and the role change still required after the apply.

The list price matches Grok 4.7: 2 dollars per million input tokens and 6 dollars per million output tokens under 200,000 input tokens, and 4 and 12 once the request reaches that size.

Grok 4.7

Grok 4.7 is a valid Terraform configuration and is the most careful of the lower-priced projects about the network. It disables default outbound access, adds a NAT gateway, and writes an outbound security policy that still leaves the paths AVD, Entra join, Windows activation and time sync needs. The session host image is Windows 11 Enterprise 25H2, where the other projects stay on 24H2. The scaling plan hibernates outside working hours. The power management role is on the resource group, and the README explains that this was done so separate runs would not share one subscription assignment. That is a reasonable isolation argument, and it is also the assignment scope Microsoft says will stop autoscale.

The deployment succeeded. Terraform created 43 resources, including the Windows 11 Enterprise 25H2 image, and the deployment was then destroyed. Against the 17 rules, Grok 4.7 scores 94.1 percent. Both partial marks are the power role on the resource group, under architecture and under the rule that the deployment should not need a later change.

The list price is the lowest output rate in the comparison, 6 dollars per million tokens, on the same terms as Grok 4.6.

Muse Wonder

Muse Wonder produced a valid Terraform configuration, and it is one of the three projects that puts power management on the subscription. The role is granted to the Azure Virtual Desktop service principal, which matches the documented service identity, and outbound access is a NAT gateway. The scaling plan covers weekdays only, so a disconnect on Saturday is not handled by autoscale. The Entra join extension is the 1.0 handler. The RDP properties leave drive, USB, COM port and smart-card redirection open, where the stronger projects close them.

The deployment succeeded. Terraform created 24 resources and the deployment was then destroyed. Against the 17 rules, Muse Wonder scores 94.1 percent. The subscription-scoped role meets the architecture and automation rules. The partial marks are the open drive and USB redirection, and a schedule that does not cover the weekend.

Meta lists Muse Wonder 1.0 at 4 dollars per million input tokens and 20 dollars per million output tokens, with no long-context surcharge.

Conclusion

Generative AI can produce Terraform configurations for an EUC deployment that succeed with the Terraform validate command. However, this research shows that none of the generative AI models can produce a perfect scoring result. While some models are very close, each one needs tweaks to fully comply with the rules and constraints set in this research.

Can generative AI replace an administrator or engineer in building a EUC infrastructure deployment? Based on the results, no; however, it can produce configurations that are very close and help administrators or engineers get a quick start. As this deployment requires a couple of key configurations, it shows the importance of understanding the requirements and deployment details for both the administrator and the generative AI.

Every model handled several decisions that usually take an administrator a few failed deployments to learn. Personal versus pooled, Entra join versus a domain, no public IP on the session host, and a scaling plan that the standard provider cannot express were all present, and terraform validate accepted all nine projects.

That is not the same as taking over the deployment. Seven projects applied without error, and two did not. Scored on the 17 rules, the set runs from 67.6 percent for Auto to 94.1 percent for Claude Sonnet 5.5, GPT-5.6 Sol, Grok 4.7 and Muse Wonder. Auto never created the session host. Claude Fable 5.1 created it, joined it to Entra ID, and then failed on an extension an administrator is not allowed to install. That project scores 70.6 percent. The other seven were accepted by Azure and then destroyed so the next project could use the same names. The hypothesis does not hold. A score of 94.1 percent is still short of a desktop a user has signed in to, and for Sonnet and Grok 4.7 the power management role is still on the resource group, which is the scope Microsoft says will stop autoscale. For this deployment, the models can replace the first draft, and several of them can replace the apply as well. They do not replace the administrator who has to decide whether that draft will hibernate, and whether a user can connect.

When selecting the auto model, it is unclear which model is used; therefore, the output is unknown. While this might be acceptable for simple instructions, for complex tasks, selecting a specific model is recommended.

A degree of caution belongs with that result. The token cost for the nine runs were not saved, so the cost comparison is a rate conversion rather than an invoice. On the rules score, four models are level at 94.1 percent. Grok 4.7 is the lowest output rate in that group, with the role still to move. Claude Sonnet 5.5 is the readable deployment at the next output rate, with the same role left to move. GPT-5.6 Sol and Muse Wonder are the projects in that group that already had the role at subscription scope. Claude Fable 5.1 came closest in the code review and scored 70.6 percent after the apply.

Photo by Zac Wolff on Unsplash