openadapt-ml 0.2.2__tar.gz → 0.3.0__tar.gz

{openadapt_ml-0.2.2 → openadapt_ml-0.3.0}/CHANGELOG.md

@@ -1,6 +1,120 @@
 # CHANGELOG
 
 
+## v0.3.0 (2026-02-05)
+
+### Bug Fixes
+
+- **cli**: Improve pool-create reliability and error handling
+  ([`f23bd57`](https://github.com/OpenAdaptAI/openadapt-ml/commit/f23bd571a76c361d9e46d99820728ffdedb5cef5))
+
+- Properly clean up test VM and associated resources during quota check - Use sudo for docker pull
+  (usermod not effective in same session) - Add pool-cleanup command for orphaned resources - Show
+  full error messages in pool creation failures
+
+Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
+
+- **pool**: Use WAA native task distribution with --worker_id/--num_workers
+  ([`ef0d8c7`](https://github.com/OpenAdaptAI/openadapt-ml/commit/ef0d8c7ecf60b1644dbc5a40ed0a05b1b4c2f597))
+
+- Fixed task distribution: WAA ignores --start_idx/--num_tasks, use native --worker_id and
+  --num_workers parameters instead - Worker 0 gets tasks 0, N, 2N... Worker 1 gets tasks 1, N+1,
+  2N+1... - Use vanilla windowsarena/winarena image with correct IP (20.20.20.21) - Add container
+  reuse check (skip restart if already running) - Pass API key via env var instead of config file -
+  Fix QMP port exposure (7200) for QEMU control - Store Windows disk on /mnt for 300GB temp storage
+  (D8ds_v5)
+
+Tested: 2-worker pool running 4 tasks in parallel successfully
+
+Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
+
+- **waa**: Use D4ds_v4 VM size for quota compatibility
+  ([`2a51a97`](https://github.com/OpenAdaptAI/openadapt-ml/commit/2a51a976f10db135ed79971162f5605de944dd6e))
+
+Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
+
+- **waa**: Use D8ds_v5 VM size for Azure ML workers
+  ([`71a0fdd`](https://github.com/OpenAdaptAI/openadapt-ml/commit/71a0fddfa4216a49b3a37c1ff1cc2d98d1f605a1))
+
+Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
+
+### Documentation
+
+- Add Azure ML log streaming and cost tracking guides
+  ([`59c3a3e`](https://github.com/OpenAdaptAI/openadapt-ml/commit/59c3a3ef852d747599de53fe74f660aea6d5b033))
+
+Document the new CLI commands for: - Live log streaming from Azure ML jobs - Cost tracking for
+  compute instances - Teardown procedures
+
+Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
+
+### Features
+
+- **cli**: Add Azure ML log streaming, cost tracking, and teardown
+  ([`59e3cf7`](https://github.com/OpenAdaptAI/openadapt-ml/commit/59e3cf7fbdb53f07866709efd60b05a1aa511ed5))
+
+Add comprehensive Azure ML management commands: - azure-ml-stream: Stream logs from running jobs
+  using Python SDK with account key auth (works around DefaultAzureCredential permission issues) -
+  azure-ml-cost: Track compute instance uptime and estimated costs - azure-ml-teardown: Cancel jobs
+  and delete compute instances
+
+Also improves: - azure-ml-quota: Shows both ML Dedicated quota (what Azure ML actually uses) and
+  regular VM quota - Better error handling and logging throughout
+
+Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
+
+- **cli**: Add Azure ML status, VNC, and monitor commands
+  ([`7985cff`](https://github.com/OpenAdaptAI/openadapt-ml/commit/7985cff95cc50d0313b3f3cb8ff5a1a1de039a71))
+
+New commands for end-to-end Azure ML automation: - azure-ml-status: Show jobs and compute instances
+  - azure-ml-vnc: Set up VNC tunnel to compute instance - azure-ml-monitor: Monitor jobs with auto
+  VNC setup
+
+Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
+
+- **cli**: Add azure-ml-quota command for quota management
+  ([`eecb3a4`](https://github.com/OpenAdaptAI/openadapt-ml/commit/eecb3a461c2b5f6882755dab52f2cfb0c9a9616a))
+
+Semi-automated quota increase workflow: - Checks current quota for WAA-compatible VM families -
+  Shows which families have sufficient quota - Opens Azure Portal quota page with instructions -
+  Guides user through the request process
+
+Usage: uv run python -m openadapt_ml.benchmarks.cli azure-ml-quota
+
+Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
+
+- **cli**: Add multi-VM pool commands for parallel WAA evaluation
+  ([`005664a`](https://github.com/OpenAdaptAI/openadapt-ml/commit/005664ab0ec6c425ac9ebe1af19b23e552b9bf90))
+
+Add pool-create, pool-wait, and pool-run commands for running WAA benchmarks across multiple VMs in
+  parallel:
+
+- pool-create --workers N: Create N VMs with Docker and WAA image - Parallel VM creation using
+  ThreadPoolExecutor - Auto-selects available region and VM size - Configures Docker with /mnt
+  storage - Registers pool for tracking
+
+- pool-wait: Wait for WAA to be ready on all workers - Starts WAA containers on each worker - Polls
+  /probe endpoint until ready - Configurable timeout
+
+- pool-run --tasks N: Distribute tasks across pool - Round-robin task distribution - Parallel
+  execution on all workers - Progress tracking in registry
+
+This enables ~5x faster benchmark completion with 5 workers, or full 154-task evaluation in ~10min
+  with 10+ workers.
+
+Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
+
+### Refactoring
+
+- **waa**: Update submodule with SDK v2 migration
+  ([`5080ad6`](https://github.com/OpenAdaptAI/openadapt-ml/commit/5080ad697e88ff297dfbb14f2c0756f53ebfd496))
+
+Updates WindowsAgentArena submodule to include Azure ML SDK v2 migration that enables job submission
+  from macOS ARM64.
+
+Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
+
+
 ## v0.2.2 (2026-01-29)
 
 ### Bug Fixes

{openadapt_ml-0.2.2 → openadapt_ml-0.3.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: openadapt-ml
-Version: 0.2.2
+Version: 0.3.0
 Summary: Model-agnostic, domain-agnostic ML engine for GUI automation agents
 Project-URL: Homepage, https://github.com/OpenAdaptAI/openadapt-ml
 Project-URL: Repository, https://github.com/OpenAdaptAI/openadapt-ml

openadapt_ml-0.3.0/docs/AZURE_ML_COST_TRACKING.md

@@ -0,0 +1,268 @@
+# Azure ML Cost Tracking and Teardown
+
+## Overview
+
+This document describes how to track costs and perform full teardown of Azure ML resources used for WAA benchmark evaluation.
+
+## Cost Components
+
+### 1. Compute Instances
+
+Azure ML Compute Instances are the primary cost driver.
+
+| VM Size | vCPU | Memory | Price/hour |
+|---------|------|--------|------------|
+| Standard_D4_v3 | 4 | 16 GB | $0.19/hr |
+| Standard_D8_v3 | 8 | 32 GB | $0.38/hr |
+| Standard_D4s_v3 | 4 | 16 GB | $0.19/hr |
+| Standard_D8s_v3 | 8 | 32 GB | $0.38/hr |
+| Standard_D4ds_v5 | 4 | 16 GB | $0.42/hr |
+| Standard_D8ds_v5 | 8 | 32 GB | $0.38/hr |
+
+**Note**: Compute instances continue billing while running, even if idle. Always delete after use.
+
+### 2. Blob Storage
+
+Used for the golden Windows image and benchmark results.
+
+| Component | Size | Price |
+|-----------|------|-------|
+| Golden image (data.img) | ~25 GB | ~$0.45/month |
+| OVMF firmware | ~8 MB | negligible |
+| Benchmark results | Variable | ~$0.018/GB/month |
+
+**Blob Container**: `azureml-blobstore-84e6d3a8-2f98-4ff9-9ee1-b2f84ebc0d90`
+
+### 3. File Share
+
+Startup scripts and code mounted to compute instances.
+
+| Component | Size | Price |
+|-----------|------|-------|
+| Startup script | ~1 KB | negligible |
+| Mounted code | Variable | ~$0.06/GB/month |
+
+**File Share**: `code-391ff5ac-6576-460f-ba4d-7e03433c68b6`
+
+### 4. API Calls (External)
+
+OpenAI/Anthropic API costs depend on model and task count.
+
+| Model | Input | Output | Est. per task |
+|-------|-------|--------|---------------|
+| GPT-4o | $2.50/1M | $10/1M | ~$0.05 |
+| GPT-4o-mini | $0.15/1M | $0.60/1M | ~$0.003 |
+| Claude Sonnet 4.5 | $3/1M | $15/1M | ~$0.06 |
+
+## CLI Commands
+
+### Cost Summary
+
+Show current Azure ML resource costs and usage.
+
+```bash
+# Show cost summary
+uv run python -m openadapt_ml.benchmarks.cli run-azure-ml --cost-summary
+```
+
+Output:
+```
+=== Azure ML Cost Summary ===
+
+Compute Instances:
+  w0Expe02021336  STANDARD_D4_V3  Running   2.5 hrs  $0.48
+  w0Expe02020148  STANDARD_D4_V3  Failed    -        -
+
+  Total compute: 2.5 hrs, ~$0.48
+
+Blob Storage:
+  storage/data.img       24.8 GB
+  storage/OVMF_CODE...   3.5 MB
+  storage/OVMF_VARS...   3.5 MB
+
+  Total storage: 24.81 GB, ~$0.45/month
+
+Experiments:
+  openadapt-ml: 3 runs (last 7 days)
+
+Estimated Monthly Cost: ~$0.50 (storage only, compute billed hourly)
+```
+
+### Resource Listing
+
+List all Azure ML resources that can be torn down.
+
+```bash
+# List all resources
+uv run python -m openadapt_ml.benchmarks.cli run-azure-ml --list-resources
+```
+
+Output:
+```
+=== Azure ML Resources ===
+
+Compute Instances (2):
+  - w0Expe02021336  STANDARD_D4_V3  Running
+  - w0Expe02020148  STANDARD_D4_V3  CreateFailed
+
+Blob Storage (storage/ prefix):
+  - data.img (24.8 GB)
+  - OVMF_CODE_4M.ms.fd (3.5 MB)
+  - OVMF_VARS_4M.ms.fd (3.5 MB)
+
+File Share (Users/openadapt/):
+  - compute-instance-startup.sh (1 KB)
+
+Azure ML Jobs (last 7 days): 3
+```
+
+### Full Teardown
+
+Delete all Azure ML resources to stop all costs. This is the recommended way to clean up after benchmarking.
+
+```bash
+# Teardown (dry run - shows what would be deleted)
+uv run python -m openadapt_ml.benchmarks.cli run-azure-ml --teardown
+
+# Teardown with confirmation
+uv run python -m openadapt_ml.benchmarks.cli run-azure-ml --teardown --confirm
+```
+
+**What gets deleted:**
+- All compute instances (stops compute billing)
+- Golden image in blob storage (optional, use --keep-image to preserve)
+- Benchmark result files in blob storage
+- Startup script in file share
+
+**What is NOT deleted:**
+- Azure ML Workspace (shared resource)
+- Resource Group (shared resource)
+- Storage Account (just the data inside)
+- Azure ML Experiments (metadata only, no cost)
+
+Output:
+```
+=== Azure ML Teardown ===
+
+Will delete:
+  Compute Instances:
+    - w0Expe02021336 (Running, ~$0.48 billed)
+    - w0Expe02020148 (Failed)
+
+  Blob Storage:
+    - storage/data.img (24.8 GB)
+    - storage/OVMF_CODE_4M.ms.fd
+    - storage/OVMF_VARS_4M.ms.fd
+
+  File Share:
+    - Users/openadapt/compute-instance-startup.sh
+
+Use --confirm to proceed with deletion.
+Use --keep-image to preserve the golden image for future runs.
+```
+
+### Keeping the Golden Image
+
+If you plan to run more benchmarks later, you can preserve the golden image to avoid re-uploading 30GB.
+
+```bash
+# Teardown but keep the golden image
+uv run python -m openadapt_ml.benchmarks.cli run-azure-ml --teardown --confirm --keep-image
+```
+
+## Cost Tracking Implementation
+
+### Approach 1: Azure CLI Queries (Implemented)
+
+Uses `az ml compute list` and `az storage blob list` to enumerate resources and estimate costs based on known pricing.
+
+**Pros:**
+- No additional Azure permissions needed
+- Real-time resource visibility
+- Works with existing service principal
+
+**Cons:**
+- Estimates only (not actual billed amounts)
+- Manual pricing table maintenance
+
+### Approach 2: Azure Cost Management API (Future)
+
+Uses `az consumption usage list` to get actual billed amounts.
+
+```bash
+# Get actual usage (requires Cost Management Reader role)
+az consumption usage list \
+  --start-date 2026-01-01 \
+  --end-date 2026-02-02 \
+  --query "[?contains(resourceGroup, 'openadapt')].{Resource:resourceId, Cost:cost, Date:usageEnd}"
+```
+
+**Pros:**
+- Actual billed amounts
+- Historical cost tracking
+
+**Cons:**
+- Requires additional Azure role assignment
+- 24-48 hour data delay
+
+## Resource Hierarchy
+
+```
+Azure Subscription: 78add6c6-c92a-4a53-b751-eb644ac77e59
+└── Resource Group: openadapt-agents
+    ├── Azure ML Workspace: openadapt-ml
+    │   ├── Compute Instances (BILLABLE - delete after use)
+    │   │   └── w0Exp* (created by run_azure.py)
+    │   └── Experiments (metadata, no cost)
+    │       └── openadapt-ml
+    │
+    └── Storage Account: openadapstoraged655a89ec
+        ├── Blob Container: azureml-blobstore-*
+        │   └── storage/ (golden image, ~$0.45/month)
+        │
+        └── File Share: code-*
+            └── Users/openadapt/ (startup script, negligible)
+```
+
+## Best Practices
+
+### During Development
+
+1. **Use single worker**: `--workers 1` to minimize compute costs
+2. **Use gpt-4o-mini**: Cheapest OpenAI model for testing
+3. **Delete immediately**: Run `--teardown --confirm` after each session
+
+### For Full Evaluation
+
+1. **Estimate costs first**: `--cost-summary` before running
+2. **Use appropriate workers**: Match to your task count and budget
+3. **Keep golden image**: `--keep-image` if running multiple evaluations
+4. **Monitor progress**: Check Azure portal for stuck instances
+
+### Cost Optimization
+
+| Scenario | Est. Cost | Recommendation |
+|----------|-----------|----------------|
+| Single task test | ~$0.10 | 1 worker, gpt-4o-mini |
+| 10 tasks | ~$1.50 | 1 worker, gpt-4o-mini |
+| Full 154 tasks | ~$20-50 | 4-8 workers, depends on model |
+
+## Troubleshooting
+
+### "Permission denied" on cost queries
+
+The service principal may not have Cost Management Reader role. Use the resource listing approach instead.
+
+### Compute instances stuck in "Creating"
+
+Delete manually: `az ml compute delete --name <name> --workspace-name openadapt-ml --resource-group openadapt-agents --yes`
+
+### Storage costs continue after teardown
+
+Check if you used `--keep-image`. Golden image alone costs ~$0.45/month.
+
+## References
+
+- [Azure ML Pricing](https://azure.microsoft.com/en-us/pricing/details/machine-learning/)
+- [Azure Blob Storage Pricing](https://azure.microsoft.com/en-us/pricing/details/storage/blobs/)
+- [WAA Azure Setup](./VANILLA_WAA_AZURE_AUTOMATION.md)

openadapt_ml-0.3.0/docs/AZURE_ML_LIVE_LOGGING.md

@@ -0,0 +1,255 @@
+# Azure ML Live Logging Design Document
+
+## Problem Statement
+
+When running WAA benchmark evaluations on Azure ML compute instances, we need to see real-time logs from inside the Docker container to:
+1. Verify patches are being applied correctly (e.g., IP address fix)
+2. Monitor Windows VM boot progress
+3. Debug issues without waiting for job completion
+4. Confirm the WAA server is responding
+
+**Current pain point**: Jobs run for 15-30+ minutes, and we can't see what's happening inside until they complete or fail.
+
+## Architecture
+
+```
+Azure ML Job
+└── Compute Instance (Standard_D8ds_v4)
+    └── Docker Container (windowsarena/winarena)
+        └── run_entry.py (entry point)
+            └── /entry_setup.sh
+                └── QEMU (Windows 11 VM)
+                    └── WAA Flask Server (port 5000)
+```
+
+## Approaches Tried
+
+### 1. Azure ML SDK `jobs.stream()` ❌
+```python
+client.jobs.stream('job_name')
+```
+**Result**: Appears to hang indefinitely. May be waiting for job to complete before returning any output.
+
+**Why it doesn't work**:
+- `stream()` may only stream *control plane* logs (job start, provisioning), not container stdout
+- Container logs need different endpoint/mechanism
+
+### 2. Azure ML SDK `jobs.download()` ❌
+```python
+client.jobs.download(name='job_name', download_path='/tmp', output_name='default')
+```
+**Result**: Error - "Download is allowed only in states ['Completed', 'Failed', 'Canceled', ...]"
+
+**Why it doesn't work**: By design, artifacts are only available after job termination.
+
+### 3. SSH to Compute Instance ⚠️ (Partial)
+```bash
+ssh azureuser@104.43.139.26 -p 50000
+docker exec <container_id> cat /path/to/logs
+```
+**Result**: Works but requires:
+- Finding the compute instance IP (not easily available from SDK)
+- Finding the SSH port (default 50000 for Azure ML)
+- Finding the container ID inside the instance
+- Navigating into container to find logs
+
+**Challenge**: Compute instance IPs aren't exposed in the standard SDK. Need to use lower-level Azure APIs or parse from job metadata.
+
+### 4. Reading Blob Storage Directly ⚠️ (Investigating)
+Azure ML writes job artifacts to blob storage at path: `ExperimentRun/dcid.<job_name>/`
+```bash
+az storage blob list --container-name azureml --prefix "ExperimentRun/dcid.job_name"
+```
+**Result**: Logs may not be written in real-time. Standard output goes to `user_logs/std_log.txt` but sync timing is unclear.
+
+## Potential Solutions
+
+### Option A: Write Logs to Blob Storage in Real-Time
+**Approach**: Modify `run_entry.py` to write logs directly to mounted blob storage.
+
+```python
+# In run_entry.py
+import sys
+
+# Azure ML mounts output paths - write logs there
+log_path = "/mnt/azureml/cr/j/.../user_logs/live_log.txt"
+with open(log_path, 'a') as f:
+    f.write("Starting VM...\n")
+    f.flush()  # Ensure immediate write
+```
+
+**Pros**: Uses existing infrastructure
+**Cons**: Need to determine exact mount path; may still have sync delays
+
+### Option B: Configure Application Insights/Log Analytics
+**Approach**: Stream container logs to Azure Monitor.
+
+```python
+# In job environment
+from applicationinsights import TelemetryClient
+tc = TelemetryClient('<instrumentation_key>')
+tc.track_trace('Starting VM...')
+tc.flush()
+```
+
+**Pros**: Centralized logging, queryable, real-time
+**Cons**: Additional Azure resource, more complexity
+
+### Option C: HTTP Webhook for Status Updates
+**Approach**: Have `run_entry.py` POST status updates to an external endpoint.
+
+```python
+import requests
+
+def log_status(message):
+    requests.post('https://your-endpoint.com/log', json={
+        'job': job_name,
+        'message': message,
+        'timestamp': time.time()
+    })
+```
+
+**Pros**: Real-time, flexible
+**Cons**: Requires external endpoint, network connectivity from Azure ML
+
+### Option D: Write to Mounted Output Directory (RECOMMENDED)
+**Approach**: Azure ML automatically mounts output directories. Write logs there.
+
+```python
+# run_entry.py
+import os
+import sys
+from datetime import datetime
+
+# Azure ML sets this to the mounted output path
+output_dir = os.environ.get('AZUREML_OUTPUT_PATH', '/mnt/azureml/outputs')
+log_file = os.path.join(output_dir, 'live_log.txt')
+
+class TeeLogger:
+    def __init__(self, *files):
+        self.files = files
+    def write(self, data):
+        for f in self.files:
+            f.write(data)
+            f.flush()
+    def flush(self):
+        for f in self.files:
+            f.flush()
+
+# Redirect stdout to both console and file
+log_handle = open(log_file, 'w')
+sys.stdout = TeeLogger(sys.__stdout__, log_handle)
+```
+
+Then read from blob storage:
+```bash
+az storage blob download \
+    --account-name <storage_account> \
+    --container-name azureml \
+    --name "ExperimentRun/dcid.<job_name>/outputs/live_log.txt" \
+    --file /tmp/live_log.txt
+```
+
+**Pros**: Uses existing infrastructure, no additional setup
+**Cons**: Still have blob sync delays (typically 30-60 seconds)
+
+### Option E: Azure ML Run Logging API
+**Approach**: Use Azure ML's built-in logging that's designed for real-time streaming.
+
+```python
+from azureml.core import Run
+run = Run.get_context()
+
+run.log('status', 'Starting VM...')
+run.log('ip_patch', 'Applied')
+run.log('windows_boot', 'In progress')
+```
+
+Then query via SDK:
+```python
+run = client.runs.get(job_name)
+metrics = run.get_metrics()
+```
+
+**Pros**: Built-in, designed for this use case
+**Cons**: Requires azureml-core package in container; may conflict with existing setup
+
+### Option F: Compute Instance SSH with Automation (SIMPLEST)
+**Approach**: Automate the SSH process to extract container logs.
+
+```python
+def get_live_logs(job_name):
+    # 1. Get compute instance from job
+    job = client.jobs.get(job_name)
+    compute_name = job.compute  # e.g., "w0Expe02041220"
+
+    # 2. Get compute instance IP via Azure Resource Manager API
+    # (Need to call ARM directly as SDK doesn't expose this)
+
+    # 3. SSH and get logs
+    ssh_cmd = f"ssh -p 50000 azureuser@{ip} 'docker logs $(docker ps -q)'"
+    logs = subprocess.run(ssh_cmd, capture_output=True)
+    return logs.stdout
+```
+
+**Pros**: Works with existing setup, real-time
+**Cons**: Requires parsing ARM API for IP; SSH key must be configured
+
+## Recommendation
+
+**Short-term (now)**: Use **Option F** - SSH automation. We already have SSH access working; just need to automate finding the IP and container ID.
+
+**Medium-term**: Use **Option D** - Write to mounted output + poll blob storage. More reliable and doesn't require SSH.
+
+**Long-term**: Use **Option E** - Azure ML Run logging. Most integrated solution.
+
+## Implementation Plan
+
+### Phase 1: SSH Automation (This Week)
+
+1. Add CLI command to get compute instance IP:
+```bash
+uv run python -m openadapt_ml.benchmarks.cli azure-logs --job quiet_pasta_byvjklj2q8
+```
+
+2. Implementation:
+```python
+def cmd_azure_logs(job_name: str, follow: bool = False):
+    """Get live logs from Azure ML job via SSH."""
+    # Get job
+    job = client.jobs.get(job_name)
+    compute_name = job.compute
+
+    # Get compute IP via ARM API
+    ip = get_compute_ip(compute_name)
+
+    # SSH command
+    if follow:
+        cmd = f"ssh -p 50000 azureuser@{ip} 'docker logs -f $(docker ps -q)'"
+    else:
+        cmd = f"ssh -p 50000 azureuser@{ip} 'docker logs $(docker ps -q)'"
+
+    subprocess.run(cmd, shell=True)
+```
+
+### Phase 2: Blob Storage Logging (Next Week)
+
+1. Modify `run_entry.py` to tee stdout to output directory
+2. Add CLI command to poll blob storage for live logs
+3. Add background agent that polls and streams logs to terminal
+
+## Open Questions
+
+1. Does Azure ML SDK have undocumented methods for live log streaming?
+2. What's the actual blob sync delay for output directories?
+3. Can we use Azure SignalR for real-time log push?
+4. Is there a REST API endpoint for log streaming (used by Azure Portal)?
+
+## References
+
+- [Azure ML Job Logging](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-log-view-metrics)
+- [Azure ML Run Context](https://learn.microsoft.com/en-us/python/api/azureml-core/azureml.core.run.run)
+- [Streaming Logs in Azure ML](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-debug-visual-studio-code)
+
+---
+*Last updated: 2026-02-04*