Claude Fable 5.2, the latest version of Anthropic’s Fable model, is now rolling out in Copilot Cowork and Copilot Studio. It expands the choice of frontier models in Copilot, so your teams can match the model to the work as they hand more complex tasks to AI. 

 

A model is only as useful as the context it works with. In Copilot, Work IQ grounds Fable 5.2 in your organization’s files, meetings, chats, and business data—within your existing permissions—so responses reflect your actual work rather than the prompt alone. That makes answers more accurate and easier to trust. 

Get started today 

Fable 5.2 is now rolling out to eligible users in Copilot Cowork and Copilot Studio. 

Admins stay in control: they can manage access and set availability for their organization in the Microsoft 365 admin center. Availability may vary by region and organization.  

You can follow the rollout on the AI at Work Roadmap and in the Microsoft 365 Copilot release notes. 

For details on the model itself, read Anthropic’s announcement of Claude Fable 5.2. 

AI applications often start as prototypes running locally on a developer’s machine. A Streamlit application may work perfectly in a development environment, but making it accessible to users introduces a different set of infrastructure and operational considerations.

From an infrastructure engineer’s perspective, the key questions are:

• How do we package the application?
• Where do we store and manage container images?
• How do we securely manage API keys and secrets?
• How do we expose the application to users?
• How do we scale it as usage increases?
• How do we automate deployments and future releases?
• How do we monitor and troubleshoot the application after deployment?

This article walks through the end-to-end deployment lifecycle of an AI application using Azure Container Apps (ACA), focusing on infrastructure, security, deployment and operational responsibilities rather than application development.

1. Understanding the Architecture

Before starting the deployment, it is important to understand how the different components fit together.

At a high level, the deployment follows this flow:

Application Source Code → Container Image → Azure Container Registry → Azure Container Apps → Azure OpenAI

Additional Azure services provide identity, security, networking and operational capabilities around the application.

High-level architecture

The responsibilities of the major components are:

The overall infrastructure lifecycle can be summarized as:

Package → Build → Registry → Deploy → Secure → Scale → Automate → Monitor

2. Start with a Clear Application Handoff

As an infrastructure engineer, I should not need to redesign the application before deploying it.

The application team should provide a deployment-ready application package with the following information:

• Application source code
• Dockerfile
• Dependency file, such as requirements.txt
• Application listening port
• Required environment variables
• External service endpoints
• Health-check requirements
• Expected CPU and memory requirements
• Authentication and integration requirements

For example, a Streamlit application commonly uses port 8501.

It is important to establish clear ownership between the teams.

Application team responsibilities:

• Application functionality and business logic
• Application dependencies
• Application-level configuration
• Application testing
• Application-level troubleshooting

Infrastructure team responsibilities:

• Container build infrastructure
• Container registry
• Azure resource provisioning
• Identity and access management
• Secrets management
• Networking and ingress
• Application deployment
• Scaling and monitoring
• CI/CD infrastructure

This separation prevents an infrastructure deployment activity from unintentionally becoming an application development task.

3. Containerize the Application

Before deploying an application to Azure Container Apps, we need to package it as a container image.

The Dockerfile defines how the application is packaged, including its base image, dependencies, working directory and startup command.

From an infrastructure perspective, the following items should be validated:

1. Is the expected base image being used?
2. Are application dependencies installed successfully?
3. Is the correct application port configured?
4. Does the application listen on 0.0.0.0 rather than only localhost?
5. Is the container configured to run as a non-root user wherever possible?
6. Are sensitive files and credentials excluded from the image?

For example, build and test the container locally:

Build the image:

docker build -t ai-app:v1 .

Run the container:

docker run -p 8501:8501 ai-app:v1

Podman can also be used in environments where Docker is unavailable or not permitted.

For a Streamlit application, ensure that the application startup configuration listens on all interfaces:

streamlit run app.py --server.address=0.0.0.0 --server.port=8501

Before introducing Azure into the troubleshooting process, validate that the container starts and the application is accessible locally.

The objective at this stage is simple:

Can the application run successfully as a container?

If not, resolve the container or application startup issue first. Introducing Azure Container Apps at this point adds another troubleshooting layer.

4. Store the Container Image in Azure Container Registry

Once the container image has been validated, it needs to be stored in a registry that Azure Container Apps can access.

For an Azure-native deployment, Azure Container Registry (ACR) is a suitable option.

The deployment flow now becomes:

Application Code → Build Container → Test Container → Push Image to ACR → Deploy to Azure Container Apps

One convenient option is to build the image directly using ACR.

az acr build \ --registry <ACR_NAME> \ --image ai-app:v1 \ .

This command builds the image from the current directory and pushes it to the specified Azure Container Registry.

For production deployments, avoid relying exclusively on a mutable tag such as latest.

Prefer traceable image versions:

ai-app:v1 ai-app:v2 ai-app:v3

For automated deployments, the image can also be tagged using a source commit ID or build number.

For example:

ai-app:build-1025

The complete image reference will look like:

<ACR_NAME>.azurecr.io/ai-app:v1

This makes it easier to identify which application version is deployed and simplifies rollback and troubleshooting.

Infrastructure consideration: Ensure that Azure Container Apps has the appropriate permissions to pull images from the private registry. Managed identity with the required ACR permissions can be used instead of maintaining registry credentials.

5. Deploy the Application to Azure Container Apps

Once the container image is available in ACR, the next step is deploying it to Azure Container Apps.

Two important concepts need to be understood.

Azure Container Apps Environment

The Container Apps Environment provides the managed hosting boundary for container applications.

It provides shared capabilities such as networking, logging and integration with the underlying managed platform.

Multiple container apps can run within the same environment.

Azure Container App

The Container App represents the actual application deployment.

It contains the configuration required to run the workload, including:

• Container image and version
• CPU and memory allocation
• Environment variables
• Ingress configuration
• Target application port
• Secrets
• Scaling configuration
• Health probes

The deployment structure can be visualized as:

For a Streamlit application, the Container Apps target port should match the port on which the application listens inside the container.

At this stage, the infrastructure team owns the hosting configuration while the application code remains within the application team's ownership.

6. Secure Application Secrets

This is one of the most important considerations when deploying AI applications.

AI applications frequently require credentials to access Azure OpenAI, external APIs or other services.

A simple rule should always be followed:

Never store production API keys or credentials inside application source code or container images.

Avoid hardcoded credentials:

API_KEY = "xxxxxxxx"

Production credentials should also not be committed to source repositories through .env files.

There are three important approaches to consider.

Option 1: Managed Identity

Where the target Azure service supports Microsoft Entra authentication, use Managed Identity instead of storing application credentials.

For example, an application can authenticate to supported Azure services using its assigned identity.

Option 2: Azure Key Vault

When an application requires a secret, such as an API key or connection string, store it centrally in Azure Key Vault.

Access should be controlled through Managed Identity and appropriate RBAC permissions.

Option 3: Azure Container Apps Secrets

Azure Container Apps supports application-level secrets that can be referenced by container environment variables or mounted as files.

It can also reference secrets stored in Azure Key Vault using Managed Identity.

A recommended secret-management flow is:

The objective is to minimize the number of long-lived credentials that application and infrastructure teams need to manage.

7. Configure Managed Identity

Managed Identity helps reduce credential-management overhead and eliminates the need to maintain application credentials for supported Azure integrations.

For example, the access pattern can look like this:

Instead of storing a service principal password or application credential, the application uses its assigned identity to authenticate.

For Azure OpenAI, assign the appropriate role, such as Cognitive Services OpenAI User, when using Microsoft Entra authentication.

For Key Vault, assign Key Vault Secrets User when the application identity needs to retrieve secrets.

The exact role depends on the target service and the operations the application needs to perform.

From an infrastructure perspective, the principle is straightforward:

Grant only the permissions required by the application.

This follows the principle of least privilege and reduces unnecessary access across the Azure environment.

8. Configure Ingress and Application Connectivity

Once the application is deployed, users need a way to access it.

Azure Container Apps provides managed ingress capabilities, allowing applications to be exposed through HTTPS without manually managing an application gateway for every basic deployment scenario.

The infrastructure team needs to decide whether the application should be accessible through:

• External ingress – Accessible through a public application endpoint, subject to configured access controls.
• Internal ingress – Accessible within the Container Apps Environment and its supported internal networking configuration.

Before enabling ingress, validate the following:

• Is ingress enabled?
• Should the application be internal or external?
• Does the target port match the application listening port?
• Is HTTPS configured correctly?
• Does the application require additional authentication?
• Are network restrictions required?
• Are outbound connections to dependent services permitted?

A common deployment issue is a healthy container that is not reachable because the application listening port and the Container Apps target port do not match.

For connectivity troubleshooting, validate the path in order:

This helps determine whether the issue is related to ingress, networking, container configuration or the application itself.

9. Plan Scaling Before Production

Getting one container running is only the first step.

The next question is:

What happens when multiple users start accessing the application?

Azure Container Apps supports replica-based scaling using configurable scaling rules, including HTTP traffic and other supported KEDA-based triggers.

Infrastructure teams should consider:

• Minimum replicas
• Maximum replicas
• CPU allocation
• Memory allocation
• Scaling triggers
• Concurrent requests
• Expected user traffic
• Application startup time

For an interactive application, maintaining a minimum replica count may be appropriate when avoiding cold-start latency is important.

However, AI applications introduce another important consideration.

The container application is not necessarily the bottleneck.

Azure OpenAI has its own model deployment capacity, quota and throttling considerations.

Therefore:

Increasing Container Apps replicas does not automatically increase Azure OpenAI model capacity.

Scaling decisions should consider two separate layers.

Application capacity:

• Container Apps replicas
• CPU and memory
• Request concurrency
• Application-level performance

AI model capacity:

• Azure OpenAI deployment capacity
• Model quota
• Token throughput
• Request throttling
• Retry and backoff behavior

Load testing should be performed to establish appropriate limits rather than simply configuring a high maximum replica count.

10. Consider Stateful Application Behaviour

Interactive applications may maintain user or session state during execution.

This becomes particularly important when the application scales horizontally.

With a single replica, user interactions are handled by one running application instance.

With multiple replicas, requests may potentially be handled by different instances depending on the ingress and session configuration.

The infrastructure and application teams should establish one important detail:

Is application state stored only inside the container, or is it persisted externally?

If application or session state must survive container restarts, scaling events or deployments, an external persistence mechanism should be evaluated.

Container memory and local container storage should not be treated as durable application storage.

For Streamlit and similar interactive applications, the application team should also validate session handling and WebSocket connectivity under the expected ingress and scaling configuration.

This discussion should happen before increasing the application's replica count.

11. Validate the Manual Deployment Before Automating It

It can be tempting to start immediately with CI/CD pipelines.

However, from an infrastructure perspective, I prefer validating the complete deployment lifecycle manually before introducing automation.

The initial deployment should establish that the following process works:

Once this process is successful, the same steps can be automated through Azure DevOps or GitHub Actions.

The automated deployment lifecycle then becomes:

 

This approach makes troubleshooting easier because each deployment stage has already been validated independently.

The CI/CD pipeline simply automates a process that is known to work.

12. Authenticate the CI/CD Pipeline Securely

The deployment pipeline also needs access to Azure resources.

Pipeline authentication should receive the same security attention as application authentication.

Where supported, use Workload Identity Federation (OIDC) rather than maintaining long-lived client secrets in pipeline variables.

The authentication flow looks like this:

This avoids creating another permanent credential simply to automate deployment.

Pipeline permissions should also follow least privilege.

The deployment identity should have sufficient permissions to perform the required deployment operations without receiving unnecessary access to unrelated subscriptions or resources.

13. Manage Application Releases Using Revisions

Application deployment does not end with the first successful release.

There will be a version 2, version 3 and eventually another release that may need to be rolled back.

Azure Container Apps provides a revision-based deployment model.

A revision represents a version of the application configuration and container template.

For example:

Depending on the configured revision mode, the application can use single-revision or multiple-revision deployment.

Multiple-revision mode is particularly useful when implementing controlled traffic splitting, blue-green deployments or canary releases.

This allows infrastructure teams to validate a new application version before directing all production traffic to it.

Combined with traceable container image tags, revisions make it easier to answer a common operational question:

Which application version is actually running?

A rollback strategy should also be defined before production deployment.

14. Monitoring and Operational Visibility

A successful infrastructure deployment should not end with:

"The container is running."

Once users start accessing the application, the infrastructure team needs operational visibility.

At a minimum, consider monitoring the following:

Azure Monitor and Log Analytics can provide the operational visibility needed around the deployed workload.

A practical troubleshooting sequence is:

Following this sequence prevents infrastructure, application and downstream-service issues from being mixed together.

For production environments, configure diagnostic settings and appropriate alerts rather than relying only on manual log inspection.

15. Common Deployment Issues and Troubleshooting

Here are some common issues that infrastructure engineers may encounter during an Azure Container Apps deployment.

Issue 1: Container Image Cannot Be Pulled

Possible causes:

• Incorrect registry configuration
• Incorrect image name or tag
• Missing registry permissions
• Managed Identity misconfiguration
• Private registry connectivity issues

What to check:

• Validate the complete image reference.
• Confirm the image exists in ACR.
• Check the Container App registry configuration.
• Verify the required registry pull permissions.

Issue 2: Application Starts and Immediately Restarts

Possible causes:

• Missing environment variables
• Incorrect startup command
• Missing application dependencies
• Missing secrets
• Insufficient CPU or memory

What to check:

• Container console logs
• Container Apps system logs
• Application startup configuration
• Environment variable references
• Resource allocation

Issue 3: Application Is Deployed but Not Reachable

Possible causes:

• Incorrect target port
• Application listening only on localhost
• Ingress disabled
• Incorrect internal or external ingress configuration
• Network restrictions

What to check:

• Container Apps ingress configuration
• Application listening port
• Application binding address
• Network connectivity
• HTTPS endpoint

Issue 4: Azure OpenAI Returns Authentication Errors

Possible causes:

• Managed Identity not enabled
• Incorrect role assignment
• Incorrect endpoint configuration
• Unsupported authentication method
• Missing application configuration

What to check:

• Managed Identity assignment
• Azure RBAC permissions
• Azure OpenAI endpoint
• Application authentication configuration

Issue 5: Azure OpenAI Returns HTTP 429 Responses

Do not immediately assume that the Container App needs more replicas.

Investigate:

• Azure OpenAI deployment capacity
• Model quota and throughput
• Request frequency
• Token consumption
• Retry and exponential backoff configuration

The important distinction is:

Container scaling and AI model capacity are two different things.

Final Thoughts

Deploying an AI application is about much more than getting a container to start.

From an infrastructure perspective, the complete lifecycle involves packaging, registry management, identity, deployment, security, scaling, automation and monitoring.

Azure Container Apps provides a managed container platform that allows infrastructure teams to focus on these operational responsibilities without having to manage the underlying Kubernetes infrastructure.

For a Streamlit-based AI application, a practical implementation approach is to start small:

Get one container running securely → Configure Managed Identity → Validate secrets and connectivity → Configure ingress → Test scaling → Automate deployment → Implement production monitoring.

This incremental approach keeps application and infrastructure responsibilities clear and makes troubleshooting considerably easier.

The goal is not simply to get an AI application running.

The goal is to make the deployment:

Secure. Repeatable. Observable. Scalable. Production-ready.

It’s time to say goodbye to platform channel boilerplate and call native code directly from Dart!

Flutter 3.50 is here, and one feature I’m personally very excited about is direct native interop going stable!

If you have ever written a platform channel, you know the drill. A channel name string in Dart. The same string again in Kotlin. The same again in Swift. And if any one of them doesn’t match, you find out at runtime with a MissingPluginException. We all have been there 😅

With Flutter 3.50, that changes. Let’s understand what it is and how to use it!

What is Direct Native Interop?

Until now, the standard way to talk to Android or iOS from Flutter was platform channels. Your Dart code sends a message, it gets serialized, it reaches the native side, native code does the work, and the reply comes back the same way. Every call is async and pays this cost.

Direct native interop means your Dart code calls Java, Kotlin, or Objective-C APIs directly, using type-safe Dart bindings generated for you.

In simple words, calling a native API becomes just like calling a normal Dart function. No channel names, no MethodCall switch, no Future for something that should be a simple function call.

What’s new in Flutter 3.50?

• JNIgen (for Java and Kotlin) is now production-ready.
• FFIgen (for Objective-C) is now production-ready. Swift works too, as long as your Swift code is exposed to Objective-C using @objc.
• A Pigeon Native Interop (Preview) that generates type-safe bindings on top of both.
• You can call native code synchronously, and even from background isolates.

PS: This was possible because of the thread merge that started in Flutter 3.29. Dart code now runs on the platform’s main thread on Android and iOS (and later on desktop too), so there is no wall between Dart and native anymore.

How to use it?

Let’s take the classic “show a toast” example.

Earlier, with a platform channel, you had to write Dart:

const channel = MethodChannel('com.example/toast');
Future<void> showToast(String message) async {
  await channel.invokeMethod('showToast', {'message': message});
}

And Kotlin in MainActivity:

MethodChannel(
    flutterEngine.dartExecutor.binaryMessenger,
    "com.example/toast",
).setMethodCallHandler { call, result ->
    if (call.method == "showToast") {
        val message = call.argument<String>("message")
        Toast.makeText(this, message, Toast.LENGTH_LONG).show()
        result.success(null)
    } else {
        result.notImplemented()
    }
}

Now, with JNIgen, you just need 3 steps:

Step 1: Add the packages:

flutter pub add jni jni_flutter
flutter pub add dev:jnigen

As of today (10th November 2026), the latest versions are jni 1.1.2, jni_flutter 1.0.4 and jnigen 1.0.1.

Step 2: Create a config file, tool/jnigen.dart:

import 'dart:io';
import 'package:jnigen/jnigen.dart';
void main(List<String> args) async {
  final packageRoot = Platform.script.resolve('../');
  final generator = JniGenerator(
    input: Input(
      classes: ['android.widget.Toast', 'java.lang.CharSequence'],
      androidSdk: AndroidSdk(
        addGradleDeps: true,
        androidExample: packageRoot,
      ),
    ),
    output: Output(
      dart: DartOutput(
        path: packageRoot.resolve('lib/android_utils.g.dart'),
        structure: OutputStructure.singleFile,
      ),
    ),
  );
  await generator.generate();
}

Step 3: Run dart run tool/jnigen.dart and call Android directly from Dart:

import 'package:jni/jni.dart';
import 'package:jni_flutter/jni_flutter.dart';
import 'android_utils.g.dart';
void showToast(String message) {
  Toast.makeText$1(
    androidApplicationContext,
    message.toJString().as(CharSequence.type),
    Toast.LENGTH_LONG,
  )!.show();
}

That’s it! No Kotlin file, no channel. And notice that it returns void, not Future<void>. It's a direct call!

The $1 suffix is how JNIgen handles Java method overloads, since Dart doesn't have overloading. Always check the generated file to make sure you picked the right one.

On iOS, it’s the same idea with FFIgen. You generate bindings from the Objective-C headers (for example, Apple’s EventKit) and use them like this:

final store = EKEventStore();
final start = NSDate.date();
final end = NSDate.dateWithTimeIntervalSinceNow(30.0 * 24 * 60 * 60);
final predicate = store.predicateForEventsWithStartDate(
  start,
  endDate: end,
);
final events = store.eventsMatchingPredicate(predicate);

You can find complete examples in the official Flutter native interop demos (android_toast_demo and ios_calendar_demo).

Already using Pigeon?

You can try the new Native Interop (Preview) by turning it on in your Pigeon file. Pigeon then runs JNIgen and FFIgen for you:

@ConfigurePigeon(
  PigeonOptions(
    kotlinOptions: KotlinOptions(useJni: true),
    swiftOptions: SwiftOptions(useFfi: true, ffiModuleName: 'Runner'),
  ),
)

Keep in mind that it is still a preview: it supports Android, iOS and macOS only (no Windows or Linux), and @TaskQueue is not supported. Check out the Pigeon Native Interop guide for the full setup.

Advantages of Direct Native Interop

• Type safety: No more string-based method names. If something is wrong, the compiler tells you.
• Synchronous calls: Get results directly, without await.
• Better performance: No serialization and no thread hops. Great for frequent calls or large data.
• Less code: You can use Android SDK or Apple framework APIs without writing a native wrapper.

Things to keep in mind

Direct interop takes you closer to native, so there are a few rules to follow:

• Memory: On Android, every Java object you hold in Dart uses a JNI global reference, and there is a limit of around 50,000. Call .release() in dispose() for long-lived objects. On iOS, use WeakReference to avoid reference cycles.
• Threads: Synchronous doesn’t mean free. Slow calls on the main thread will still drop frames, so move heavy work to a background isolate. Also, UI-related Objective-C calls must run on the main thread.
• Type checks: Dart’s is and as don't check the native runtime type. Use .isA(Foo.type) and .as(Foo.type) instead.
• R8 / ProGuard: Release builds can strip classes that are only used from Dart. Add @Keep to your own Kotlin classes and methods.
• Build first: JNIgen needs your Android app to be built at least once before generating bindings.
• Swift: FFIgen talks to Swift through Objective-C, so classes need @objc and should extend NSObject. Pure Swift interop (swiftgen) is still experimental.

Should I migrate my platform channels now?

No need to rush! If your platform channel code works well and is tested, it’s not suddenly bad code. Please don’t feel pressured to rewrite it.

Use direct interop for new native integrations, or for calls where you really need sync results or better performance. If you maintain a plugin, a planned migration in a future major version is totally fine. Your users will thank you for stability.

Also, a big thank you to the Dart and Flutter teams and to everyone in the community who tested this early and reported issues. That’s the reason it’s stable today 💙

Hope you enjoyed this article!

Doubts? Feel free to drop a message @AbhishekDoshi26
Checkout abhishekdoshi.dev for more info 💙

Don’t stop, until you are breathing!💙
- Abhishek Doshi

---

Direct Native Interop in Flutter 3.50: Let’s understand it! 💙 was originally published in Flutter Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

I'd bet just about everyone has at least one containerized workload running in production by now. Plenty of organizations have several flavors of Kubernetes spread across a handful of clusters, too. If you're not there yet, you probably will be soon, because AI is helping developers and platform engineers build + ship software faster than any of us expected. What I keep running into when I talk with clients (and work alongside them) is that the end-to-end container strategy is where things...

If you have ever compiled a local large language model runtime like llama.cpp, vLLM, or custom CUDA kernels inside Windows Subsystem for Linux (WSL 2), you have probably noticed something frustrating. Even on a multi-core processor paired with a fast NVMe SSD and an NVIDIA RTX graphics card, parallel CMake and Ninja builds inside WSL often take twice as long as they do on a native Ubuntu installation.

 

The culprit is not virtualization overhead from Hyper-V, but two conservative default settings buried inside WSL's per-distribution /etc/wsl.conf and global %USERPROFILE%\.wslconfig files. Here is how disabling automatic Windows path injection and switching WSL's memory reclamation mode from aggressive cache dropping to gradual reclaim cuts parallel C++ and CUDA compile times in half.

 

 

Table of Contents

• Why Stock WSL Silently Chokes Parallel CUDA and C++ Builds
• The Per-Distro Interop Tweak That Stops Plan Nine Path Stalls
• The Global WSLConfig Tweak for Gradual Memory Reclaim and RAM Headroom
• Why You Must Keep LLM Repositories on Native Ext Four Storage
• Comparing Default WSL Against Tuned WSL for Local AI Compilation
• Applying the Eight-Second Shutdown Rule and Verifying Your Build
• Frequently Asked Questions (FAQ)
• End Note

 

 

 

Why Stock WSL Silently Chokes Parallel CUDA and C++ Builds

When you compile custom inference engines like llama.cpp (with GGML_CUDA=ON), vLLM, or FlashAttention to power local Retrieval-Augmented Generation (RAG) pipelines or local Model Context Protocol (MCP) servers, the build system spawns thousands of short-lived compiler, assembler, and linker processes. Even on a high-end PC configured with our modern Windows 11 developer workstation guide, default WSL 2 settings sabotage that workload in two invisible ways.

 

First, WSL automatically injects your entire Windows host PATH into the Linux environment, forcing every subprocess lookup to cross the virtual machine boundary over a slow Plan 9 (9P) file server. Second, WSL caps your Linux virtual machine at just 50% of your physical RAM while defaulting its memory reclamation engine to dropCache, which ruthlessly purges cached header files the moment a compilation step pauses.

 

 

The Per-Distro Interop Tweak That Stops Plan Nine Path Stalls

Run echo $PATH inside a stock Ubuntu WSL terminal and you will see dozens of /mnt/c/Program Files/... entries appended at the tail end. Whenever CMake, Ninja, pkg-config, or nvcc checks for helper binaries or compiler wrappers during a multi-threaded build, Linux stats each directory in $PATH—crossing the Hyper-V socket into Windows NTFS via DrvFs (Plan 9 protocol) thousands of times per minute.

 

As documented in the official Microsoft Learn WSL configuration guide, you can eliminate this bottleneck per distribution by editing /etc/wsl.conf inside your Linux shell (`sudo nano /etc/wsl.conf`) and adding these exact sections:

• [boot] with systemd=true to keep background services like Ollama managed cleanly.
• [interop] with enabled=true and appendWindowsPath=false to strip slow /mnt/c/ folders from $PATH while still allowing you to invoke explicit Windows binaries by full path when needed.
• [automount] with enabled=true, options="metadata,umask=22,fmask=11", and ldconfig=true so Windows-supplied NVIDIA CUDA libraries remain linked.
• [gpu] with enabled=true and appendLibPath=true to preserve /usr/lib/wsl/lib/libcuda.so.1 GPU acceleration, as verified in the WSL-UI technical troubleshooting reference.

 

If you still want to launch Visual Studio Code or Windows Explorer directly from your Ubuntu prompt after disabling automatic Windows path injection, simply create a targeted symbolic link inside /usr/local/bin for those two binaries alone. That way, you keep instant desktop integration without polluting compiler lookup tables with thirty slow Windows system directories.

 

 

The Global WSLConfig Tweak for Gradual Memory Reclaim and RAM Headroom

Next, fix the virtual machine hardware ceiling by creating or editing %USERPROFILE%\.wslconfig on your Windows host (`notepad $env:USERPROFILE\.wslconfig` in PowerShell). When you compile CUDA device code for multiple NVIDIA Compute Capability architectures, each parallel cicc and ptxas compiler thread consumes 1.5 GB to 3 GB of RAM; hitting the default 50% RAM cap on a 32 GB PC forces Linux to thrash against `%Temp%\swap.vhdx` on disk.

 

Even worse, Microsoft's current default for [experimental] autoMemoryReclaim is dropCache, which immediately dumps the Linux Virtual File System (VFS) page cache whenever CPU activity dips—destroying incremental build speeds when switching between your terminal and Visual Studio 2026 v18.11. Add these parameters to %USERPROFILE%\.wslconfig (adjusting memory=24GB on a 32 GB PC or 48GB on a 64 GB PC):

• Under [wsl2]: set memory=24GB, processors=16 (matching your logical cores), swap=8GB, networkingMode=mirrored, and dnsTunneling=true.
• Under [experimental]: set autoMemoryReclaim=gradual and sparseVhd=true so WSL reclaims idle memory slowly in the background without flushing hot C++ header and ccache pages from RAM.

 

 

Why You Must Keep LLM Repositories on Native Ext Four Storage

Configuration files alone cannot save a build if your source code sits inside /mnt/c/Users/.... On systems running the latest Windows 11 26H2 update, WSL 2 runs a real Linux 6.18 LTS kernel backed by an ext4.vhdx virtual disk, which delivers near-native NVMe throughput only when files reside inside the Linux root filesystem.

 

Always clone your repositories (`git clone https://github.com/ggerganov/llama.cpp`) and store your GGUF weights inside ~/projects or ~/models rather than `/mnt/c/`. Also remember the golden CUDA rule for WSL 2: never install the Linux NVIDIA display driver inside Ubuntu, or you will overwrite the para-virtualized Windows stub at `/usr/lib/wsl/lib/libcuda.so.1`—install only the cuda-toolkit package inside Linux.

 

 

Comparing Default WSL Against Tuned WSL for Local AI Compilation

STOCK WSL 2 DEFAULTS (BOTTLENECKED)

Default Unconfigured WSL 2 Environment

• Windows PATH Injection: appendWindowsPath=true forces CMake and Ninja to scan dozens of slow 9P /mnt/c/ paths.
• VM Memory Ceiling: Capped at 50% of host RAM (16 GB on a 32 GB PC), causing nvcc swap thrashing on -j 16 builds.
• VFS Cache Behavior: autoMemoryReclaim=dropCache flushes cached C++ headers and object files whenever the VM idles.
• Typical llama.cpp CUDA Build: ~5 minutes 45 seconds (clean build) and sluggish incremental re-links.

TUNED .WSLCONFIG + WSL.CONF (2X FASTER)

Optimized Local LLM Workstation Profile

• Pure Linux $PATH: appendWindowsPath=false in /etc/wsl.conf keeps all compiler lookups on native ext4.
• Uncapped RAM Allocation: memory=24GB (on 32 GB host) allows 12 to 16 parallel nvcc threads with zero swap I/O.
• Warm VFS Page Cache: autoMemoryReclaim=gradual retains header trees and ccache objects in RAM across builds.
• Typical llama.cpp CUDA Build: ~2 minutes 15 seconds (clean build) and near-instant incremental rebuilds.

 

 

Applying the Eight-Second Shutdown Rule and Verifying Your Build

After saving both `/etc/wsl.conf` and `%USERPROFILE%\.wslconfig`, simply closing your Ubuntu tab will not apply the changes—Microsoft enforces an 8-second rule before a background WSL utility VM terminates. Open Windows PowerShell, run wsl --shutdown, wait a full eight seconds, and verify that wsl --list --running reports no active distributions before relaunching your terminal.

 

Once back inside Ubuntu, run free -h to confirm your new 24 GB RAM ceiling and echo $PATH to verify that `/mnt/c/` paths are gone while `/usr/lib/wsl/lib` remains active. Then compile llama.cpp on your native ext4 drive using cmake -B build -DGGML_CUDA=ON && cmake --build build --config Release -j 12 to experience the full two-fold speed jump firsthand.

 

 

Frequently Asked Questions (FAQ)

1. What is the difference between .wslconfig and /etc/wsl.conf in Windows Subsystem for Linux?
   The .wslconfig file resides in your Windows user profile folder (%USERPROFILE%\.wslconfig) and configures global virtual machine settings across all WSL 2 distributions, such as RAM limits, CPU cores, swap size, and experimental memory reclamation. By contrast, /etc/wsl.conf lives inside each individual Linux distribution and controls per-distro behavior like Windows $PATH injection, DrvFs automount flags, and systemd initialization.

 

2. Why does setting appendWindowsPath=false in /etc/wsl.conf speed up local LLM compilation?
   By default, WSL appends dozens of Windows host directories mounted under /mnt/c/ into your Linux $PATH variable. When CMake, Ninja, Make, or nvcc spawns thousands of compiler subprocesses during a llama.cpp or vLLM build, Linux traverses those slow Plan 9 (9P) network-mounted Windows folders on every lookup. Disabling appendWindowsPath restricts $PATH searches to native ext4 directories, cutting subprocess spawn latency dramatically.

 

3. If I set appendWindowsPath=false, does NVIDIA CUDA GPU passthrough still work inside WSL 2?
   Yes. NVIDIA GPU para-virtualization in WSL 2 is controlled by the [gpu] enabled=true and [automount] ldconfig=true settings, which inject the Windows host driver stub into /usr/lib/wsl/lib/libcuda.so.1. Setting appendWindowsPath=false under [interop] does not affect CUDA libraries or GPU acceleration.

 

4. Can I still run Windows executables like explorer.exe or code from WSL if appendWindowsPath is false?
   Yes, as long as you keep enabled=true under the [interop] section in /etc/wsl.conf. You can either invoke Windows binaries using their full path (such as /mnt/c/Windows/explorer.exe) or symlink only the specific Windows tools you need—like VS Code—into /usr/local/bin.

 

5. Why does WSL 2 default to 50% of system RAM, and how does that hurt CUDA and C++ builds?
   Microsoft sets the default WSL 2 VM memory ceiling to 50% of host RAM to prevent background Linux containers from starving Windows desktop apps. However, compiling CUDA kernels with nvcc (cicc and ptxas) using parallel threads (-j) easily consumes 1.5 GB to 3 GB of RAM per thread. Hitting the 50% cap forces the WSL VM into heavy swap.vhdx disk thrashing or triggers the Linux out-of-memory (OOM) killer.

 

6. Why should I set autoMemoryReclaim=gradual instead of the default dropCache in .wslconfig?
   In recent WSL 2 releases, Microsoft set [experimental] autoMemoryReclaim to dropCache by default, which immediately flushes the Linux VFS page cache whenever the VM idles. Flushing the page cache wipes out cached C++ header trees and ccache objects between builds. Switching to autoMemoryReclaim=gradual reclaims idle RAM smoothly over time while keeping active build caches warm.

 

7. Why is compiling a repository inside /mnt/c/ so much slower than compiling inside ~/projects?
   Files under /mnt/c/ live on the Windows NTFS drive and are accessed across the virtual machine boundary using the Plan 9 (9P) protocol over Hyper-V sockets. Native Linux directories like ~/projects reside inside an ext4 virtual hard disk (ext4.vhdx) with direct block I/O, running metadata-heavy Git and CMake operations up to 5x to 10x faster.

 

8. What is Microsoft's 8-second rule when applying changes to .wslconfig or /etc/wsl.conf?
   Simply closing your Linux terminal window does not immediately apply configuration changes because the background WSL utility VM stays alive for at least 8 seconds after the last shell closes. To apply edits immediately, run wsl --shutdown in PowerShell, wait 8 seconds, and verify with wsl --list --running before reopening your terminal.

 

9. Should I ever install the native Linux NVIDIA graphics driver inside a WSL 2 Ubuntu distribution?
   No. You must never install a native Linux NVIDIA display driver inside WSL 2 because it overwrites the para-virtualized /usr/lib/wsl/lib/libcuda.so.1 stub provided by your Windows host driver. Install the latest NVIDIA Game Ready or Studio driver on Windows, and install only the CUDA Toolkit (cuda-toolkit) package inside WSL.

 

10. How many threads should I pass to CMake or Ninja when compiling llama.cpp in a tuned WSL 2 VM?
    Once you raise your .wslconfig memory ceiling to 75% of host RAM, divide your allocated WSL RAM (in GB) by 2 to determine the safe maximum parallel thread count for nvcc CUDA builds—for example, use cmake --build build --config Release -j 12 on a 24 GB WSL allocation so linker threads never swap.

 

 

End Note

You do not need to dual-boot Ubuntu on a separate NVMe partition just to compile local LLMs and custom CUDA kernels at full hardware speed. By stripping Windows 9P directories out of your Linux $PATH in /etc/wsl.conf, switching .wslconfig from dropCache to gradual memory reclamation, and giving your WSL 2 VM enough RAM headroom to link in parallel without swapping, your Windows 11 workstation matches bare-metal Linux build times. Have you tuned your .wslconfig for local AI development yet? Share your compile times and hardware specs in the comments below!

 

 

The post Uno Platform 7.0: 2x faster, 5x smaller, built for the agentic era appeared first on Uno Platform.