terradev-cli 5.3.2__tar.gz → 5.3.4__tar.gz

terradev_cli-5.3.4/.terradev/custom_providers.example.yaml

@@ -0,0 +1,39 @@
+# Custom Provider Profiles Example
+# Copy this file to ~/.terradev/custom_providers.yaml and add your custom providers
+# Then load with: terradev providers load-profiles ~/.terradev/custom_providers.yaml
+
+profiles:
+  # Example: Internal GPU cluster
+  my_internal_cluster:
+    api_style: rest
+    auth_type: bearer
+    egress_cost: 0.0
+    supports_spot: false
+    compute_model: vm
+    isolation_level: vm
+    supports_stop_start: true
+    region_specific_availability: true
+
+  # Example: Custom cloud provider
+  my_cloud_provider:
+    api_style: rest
+    auth_type: x_api_key
+    egress_cost: 0.02
+    supports_spot: true
+    spot_interruption_notice_minutes: 5
+    rate_limit_per_minute: 60
+    compute_model: vm
+    isolation_level: vm
+    supports_stop_start: true
+    provision_requires_location_id: true
+
+  # Example: GPU marketplace with SSH quirks
+  my_gpu_marketplace:
+    api_style: rest
+    auth_type: bearer
+    egress_cost: 0.01
+    supports_spot: true
+    ssh_port_fixed: false  # Dynamic SSH ports
+    compute_model: vm
+    isolation_level: vm
+    supports_stop_start: true

{terradev_cli-5.3.2 → terradev_cli-5.3.4}/Dockerfile

@@ -18,7 +18,7 @@ RUN apt-get update && apt-get install -y \
     && rm -rf /var/lib/apt/lists/*
 
 # Copy requirements and install Python dependencies
-COPY requirements.txt .
+COPY terradev_cli/requirements.txt .
 RUN pip install --no-cache-dir -r requirements.txt
 
 # Install Terradev CLI

{terradev_cli-5.3.2 → terradev_cli-5.3.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: terradev-cli
-Version: 5.3.2
+Version: 5.3.4
 Summary: An imperative command-line-interface for AI workload orchestration.
 Author-email: Terradev Team <team@terradev.com>
 Maintainer-email: Terradev Team <team@terradev.com>
@@ -93,7 +93,7 @@ Requires-Dist: redis>=5.0.0; extra == "enterprise"
 Requires-Dist: PyJWT>=2.8.0; extra == "enterprise"
 Dynamic: license-file
 
-# Terradev CLI v5.3.2
+# Terradev CLI v5.3.4
 
 **An imperative command-line-interface for AI workload orchestration.**
 
@@ -105,18 +105,26 @@ pypi.org/project/terradev-cli/
 
 Terradev is a cross-cloud compute-provisioning CLI that compresses + stages datasets, provisions optimal instances + nodes, and deploys **3-5x faster** than sequential provisioning.
 
-**NOTES ON 5.3.0**
 
-Added **transport-agnostic Prefill/Decode (P/D) disaggregation layer** and **multi-agent KV cache sharing planner**:
+**NOTES ON 5.3.3**
 
-- **Transport-agnostic P/D layer** (`core/pd_transport.py`): KV cache transfer is abstracted across NIXL/NVLink (600 GB/s), NIXL/InfiniBand (200–400 GB/s), CXL 3.0 (planned migration), RoCE RDMA, and TCP fallback. The `TransportSelector` probes at provision time and selects the best available transport. Documented NIXL→CXL migration path (Phase 1 co-existence → Phase 2 CXL-primary → Phase 3 fabric switch).
+Added **provider registration and profiling system** for intelligent quirk-aware routing across 23 cloud providers, and registration for custom providers from .yaml import:
 
-- **Multi-agent KV sharing planner** (`core/kv_sharing.py`): Computes fleet VRAM requirements with KV cache sharing topologies (broadcast/star/chain/none). For 20 agents with 70% shared context (broadcast), VRAM reduces by 66% → 3× more agents per GPU, 3× fewer GPUs needed, ~$14/hr savings on H100 fleet. Includes `EvictionCostModel` to quantify re-prefill penalty when VRAM is under-provisioned.
+- **ProviderProfile schema** (`providers/types.py`): Encodes provider-specific behaviors including API style (REST/GraphQL/JSON:API), authentication type (Bearer/Basic/HMAC/X-Api-Key), rate limits, spot instance support, egress costs, fallback routing, capacity checks, container image pinning, and spot interruption handling.
 
-- **CLI integration**: `terradev provision` now supports `--agents`, `--context`, `--sharing-topology`, `--dtype` flags. When `--agents` is passed, the KV planner outputs the heterogeneous fleet spec with cost savings:
+- **Built-in profiles** (`providers/provider_profiles.py`): Pre-configured profiles for all 23 providers (RunPod, Vast.ai, Lambda Labs, AWS, GCP, Azure, Oracle, Crusoe, CoreWeave, DigitalOcean, Yotta Labs, E2E Networks, FluidStack, Alibaba, OVHcloud, Hetzner, SiliconFlow, TensorDock, Baseten, HuggingFace, Hyperstack, InferX, Latitude).
+
+- **Dynamic registration**: Users can register custom provider profiles programmatically or load from YAML/JSON files for internal clusters or proprietary cloud providers.
+
+- **Profile-aware routing** (`providers/registry.py`): `ProviderRegistry.ranked_providers()` now incorporates provider profiles into scoring, using egress costs, fallback routing preferences, and spot preemption rates for intelligent provider selection.
+
+- **CLI commands** (`terradev providers`): New command group for managing custom provider profiles:
   ```bash
-  terradev provision -g H100 --agents 20 --context 32k --model-name llama-70b
-  terradev provision -g H100 --agents 20 --context 32k --sharing-topology broadcast --dry-run
+  terradev providers load-profiles ~/.terradev/custom_providers.yaml
+  terradev providers list-profiles
+  terradev providers show-profile runpod
+  terradev providers remove-profile my_custom_provider
+  terradev providers export-example -o ~/.terradev/custom_providers.yaml
   ```
 
 **NOTES ON 5.2.1**
@@ -611,115 +619,6 @@ echo "3. Test failover: terradev inferx failover --endpoint burst-llm-api --test
 echo "4. Update adapters: terradev lora update -n customer-enterprise-a -p ./new-adapters/"
 ```
 
-## Bare Metal GPU Access with IPMI Management (Latitude.sh)
-
-Most GPU clouds give you a virtual machine. You get a slice of hardware, shared kernel paths, and a hypervisor layer between your workload and the GPU. For most ML workloads this is fine. For compliance-sensitive deployments — HIPAA, FedRAMP, financial services, defense contractors — it isn't. Virtualization introduces attestation gaps that auditors reject.
-
-Latitude.sh is the only provider in Terradev's fleet that offers both **bare metal** and **virtual machine** GPU instances from the same API. Bare metal gives you the physical server — dedicated hardware, no virtualization overhead, and IPMI out-of-band management.
-
-```bash
-# See both bare metal and VM options side by side
-terradev quote -g H100 --provider latitude
-
-# Provision dedicated bare metal with IPMI access
-terradev provision --provider latitude --gpu H100 --instance-type bare-metal
-
-# Provision a VM (faster spin-up, slightly lower cost)
-terradev provision --provider latitude --gpu H100 --instance-type vm
-```
-
-### IPMI: Why It Matters for Enterprise
-
-IPMI (Intelligent Platform Management Interface) gives you out-of-band server management independent of the OS and GPU stack. If a training job deadlocks the kernel, you don't wait for a cloud provider ticket — you power-cycle via IPMI directly. Security teams can verify hardware attestation. Compliance frameworks that require dedicated hardware and physical access controls are satisfied.
-
-```bash
-# Instance status includes IPMI access endpoint when bare metal
-terradev status --live --provider latitude
-
-# Output includes:
-# ipmi_access: true
-# ipmi_endpoint: 10.x.x.x
-# isolation: bare_metal
-```
----
-
-## Local GPU Discovery and Hybrid Compute Pools
-
-Every other GPU orchestration platform assumes you're renting compute. Terradev doesn't.
-
-If you have a GPU in your local machine — a gaming rig, a workstation, a university compute node you have SSH access to — Terradev can discover it, register it into your compute pool, and incorporate it into provisioning decisions alongside cloud providers.
-
-```bash
-# Scan local machine for GPUs
-terradev local scan
-
-# Output:
-# Found 1 local GPU:
-#   [0] NVIDIA RTX 4090  24GB  Driver 545.29  Util: 3%  Temp: 42C
-#
-# Register in pool? [y/N]:
-
-# Register local GPU into your pool
-terradev local register --name "workstation-4090"
-
-# Scan a remote machine you have SSH access to
-terradev local scan --host 192.168.1.50 --user ubuntu --key ~/.ssh/id_rsa
-
-# View your full compute pool (local + cloud)
-terradev local pool
-```
-
-Pool output:
-```
-COMPUTE POOL (4 resources)
-workstation-4090    RTX 4090    24GB    local        $0.00/hr   Free
-runpod-h100-001     H100        80GB    runpod       $2.49/hr   Running
-vastai-a100-002     A100        40GB    vastai        $1.82/hr   Running
-lambda-a10g-003     A10G        24GB    lambda_labs  $0.60/hr   Idle
-```
-
-### Why This Matters
-
-The `terradev quote` command normally shows cloud provider pricing. With local GPUs registered, the pool includes your own hardware — priced at $0/hr. For a university researcher with a 3090 workstation running overnight jobs, or a startup with a rack of 4090s before they've moved to cloud: Terradev routes workloads to the cheapest available compute, and $0/hr always wins.
-
-```bash
-# Get quotes including local pool
-terradev quote -g RTX4090 --include-local
-
-# Output:
-# GPU       PROVIDER                 $/HR    AVAILABLE
-# RTX 4090  local (workstation-4090) $0.00   Yes
-# RTX 4090  vastai                   $0.34   Yes
-# RTX 4090  runpod                   $0.39   Yes
-
-# Provision to cheapest available — prefers local automatically
-terradev provision -g RTX4090 --prefer-local
-
-# Launch training on local GPU with cloud overflow
-terradev train --script train.py --pool workstation-4090 --overflow-to-cloud
-```
-
-### How Discovery Works
-
-The local scanner uses direct NVML bindings (Rust backend, 5–10x faster than `nvidia-smi` parsing) to introspect every GPU on the target machine:
-
-- GPU model, memory, PCIe bus ID, NUMA affinity
-- Current utilization, memory usage, temperature, clock speeds
-- Driver version, CUDA version, compute capability
-- Multi-GPU topology (NVLink, PCIe switch topology)
-
-Falls back to `nvidia-smi` parsing automatically if the Rust NVML extension isn't available.
-
-```bash
-# Detailed hardware report for local GPU
-terradev local scan --detailed
-
-# Output includes:
-# GPU 0: RTX 4090  VRAM 24GB  PCIe x16  NUMA node 0
-#   NVLink: none (single GPU)
-#   Compute: 8.9  Driver: 545.29  CUDA: 12.3
-#   P-state: P0  Temp: 42C  Power: 45W / 450W TDP
-```
 ---
 
 ## Quick Reference
@@ -859,6 +758,5 @@ Apache 2.0.
 
 ## Support
 
-- **Documentation**: [Full User Guide](USER_GUIDE.md)
 - **Issues**: [GitHub Issues](https://github.com/theoddden/Terradev/issues)
 - **Discussions**: [GitHub Discussions](https://github.com/theoddden/Terradev/discussions)

{terradev_cli-5.3.2 → terradev_cli-5.3.4}/README.md

@@ -1,4 +1,4 @@
-# Terradev CLI v5.3.2
+# Terradev CLI v5.3.4
 
 **An imperative command-line-interface for AI workload orchestration.**
 
@@ -10,18 +10,26 @@ pypi.org/project/terradev-cli/
 
 Terradev is a cross-cloud compute-provisioning CLI that compresses + stages datasets, provisions optimal instances + nodes, and deploys **3-5x faster** than sequential provisioning.
 
-**NOTES ON 5.3.0**
 
-Added **transport-agnostic Prefill/Decode (P/D) disaggregation layer** and **multi-agent KV cache sharing planner**:
+**NOTES ON 5.3.3**
 
-- **Transport-agnostic P/D layer** (`core/pd_transport.py`): KV cache transfer is abstracted across NIXL/NVLink (600 GB/s), NIXL/InfiniBand (200–400 GB/s), CXL 3.0 (planned migration), RoCE RDMA, and TCP fallback. The `TransportSelector` probes at provision time and selects the best available transport. Documented NIXL→CXL migration path (Phase 1 co-existence → Phase 2 CXL-primary → Phase 3 fabric switch).
+Added **provider registration and profiling system** for intelligent quirk-aware routing across 23 cloud providers, and registration for custom providers from .yaml import:
 
-- **Multi-agent KV sharing planner** (`core/kv_sharing.py`): Computes fleet VRAM requirements with KV cache sharing topologies (broadcast/star/chain/none). For 20 agents with 70% shared context (broadcast), VRAM reduces by 66% → 3× more agents per GPU, 3× fewer GPUs needed, ~$14/hr savings on H100 fleet. Includes `EvictionCostModel` to quantify re-prefill penalty when VRAM is under-provisioned.
+- **ProviderProfile schema** (`providers/types.py`): Encodes provider-specific behaviors including API style (REST/GraphQL/JSON:API), authentication type (Bearer/Basic/HMAC/X-Api-Key), rate limits, spot instance support, egress costs, fallback routing, capacity checks, container image pinning, and spot interruption handling.
 
-- **CLI integration**: `terradev provision` now supports `--agents`, `--context`, `--sharing-topology`, `--dtype` flags. When `--agents` is passed, the KV planner outputs the heterogeneous fleet spec with cost savings:
+- **Built-in profiles** (`providers/provider_profiles.py`): Pre-configured profiles for all 23 providers (RunPod, Vast.ai, Lambda Labs, AWS, GCP, Azure, Oracle, Crusoe, CoreWeave, DigitalOcean, Yotta Labs, E2E Networks, FluidStack, Alibaba, OVHcloud, Hetzner, SiliconFlow, TensorDock, Baseten, HuggingFace, Hyperstack, InferX, Latitude).
+
+- **Dynamic registration**: Users can register custom provider profiles programmatically or load from YAML/JSON files for internal clusters or proprietary cloud providers.
+
+- **Profile-aware routing** (`providers/registry.py`): `ProviderRegistry.ranked_providers()` now incorporates provider profiles into scoring, using egress costs, fallback routing preferences, and spot preemption rates for intelligent provider selection.
+
+- **CLI commands** (`terradev providers`): New command group for managing custom provider profiles:
   ```bash
-  terradev provision -g H100 --agents 20 --context 32k --model-name llama-70b
-  terradev provision -g H100 --agents 20 --context 32k --sharing-topology broadcast --dry-run
+  terradev providers load-profiles ~/.terradev/custom_providers.yaml
+  terradev providers list-profiles
+  terradev providers show-profile runpod
+  terradev providers remove-profile my_custom_provider
+  terradev providers export-example -o ~/.terradev/custom_providers.yaml
   ```
 
 **NOTES ON 5.2.1**
@@ -516,115 +524,6 @@ echo "3. Test failover: terradev inferx failover --endpoint burst-llm-api --test
 echo "4. Update adapters: terradev lora update -n customer-enterprise-a -p ./new-adapters/"
 ```
 
-## Bare Metal GPU Access with IPMI Management (Latitude.sh)
-
-Most GPU clouds give you a virtual machine. You get a slice of hardware, shared kernel paths, and a hypervisor layer between your workload and the GPU. For most ML workloads this is fine. For compliance-sensitive deployments — HIPAA, FedRAMP, financial services, defense contractors — it isn't. Virtualization introduces attestation gaps that auditors reject.
-
-Latitude.sh is the only provider in Terradev's fleet that offers both **bare metal** and **virtual machine** GPU instances from the same API. Bare metal gives you the physical server — dedicated hardware, no virtualization overhead, and IPMI out-of-band management.
-
-```bash
-# See both bare metal and VM options side by side
-terradev quote -g H100 --provider latitude
-
-# Provision dedicated bare metal with IPMI access
-terradev provision --provider latitude --gpu H100 --instance-type bare-metal
-
-# Provision a VM (faster spin-up, slightly lower cost)
-terradev provision --provider latitude --gpu H100 --instance-type vm
-```
-
-### IPMI: Why It Matters for Enterprise
-
-IPMI (Intelligent Platform Management Interface) gives you out-of-band server management independent of the OS and GPU stack. If a training job deadlocks the kernel, you don't wait for a cloud provider ticket — you power-cycle via IPMI directly. Security teams can verify hardware attestation. Compliance frameworks that require dedicated hardware and physical access controls are satisfied.
-
-```bash
-# Instance status includes IPMI access endpoint when bare metal
-terradev status --live --provider latitude
-
-# Output includes:
-# ipmi_access: true
-# ipmi_endpoint: 10.x.x.x
-# isolation: bare_metal
-```
----
-
-## Local GPU Discovery and Hybrid Compute Pools
-
-Every other GPU orchestration platform assumes you're renting compute. Terradev doesn't.
-
-If you have a GPU in your local machine — a gaming rig, a workstation, a university compute node you have SSH access to — Terradev can discover it, register it into your compute pool, and incorporate it into provisioning decisions alongside cloud providers.
-
-```bash
-# Scan local machine for GPUs
-terradev local scan
-
-# Output:
-# Found 1 local GPU:
-#   [0] NVIDIA RTX 4090  24GB  Driver 545.29  Util: 3%  Temp: 42C
-#
-# Register in pool? [y/N]:
-
-# Register local GPU into your pool
-terradev local register --name "workstation-4090"
-
-# Scan a remote machine you have SSH access to
-terradev local scan --host 192.168.1.50 --user ubuntu --key ~/.ssh/id_rsa
-
-# View your full compute pool (local + cloud)
-terradev local pool
-```
-
-Pool output:
-```
-COMPUTE POOL (4 resources)
-workstation-4090    RTX 4090    24GB    local        $0.00/hr   Free
-runpod-h100-001     H100        80GB    runpod       $2.49/hr   Running
-vastai-a100-002     A100        40GB    vastai        $1.82/hr   Running
-lambda-a10g-003     A10G        24GB    lambda_labs  $0.60/hr   Idle
-```
-
-### Why This Matters
-
-The `terradev quote` command normally shows cloud provider pricing. With local GPUs registered, the pool includes your own hardware — priced at $0/hr. For a university researcher with a 3090 workstation running overnight jobs, or a startup with a rack of 4090s before they've moved to cloud: Terradev routes workloads to the cheapest available compute, and $0/hr always wins.
-
-```bash
-# Get quotes including local pool
-terradev quote -g RTX4090 --include-local
-
-# Output:
-# GPU       PROVIDER                 $/HR    AVAILABLE
-# RTX 4090  local (workstation-4090) $0.00   Yes
-# RTX 4090  vastai                   $0.34   Yes
-# RTX 4090  runpod                   $0.39   Yes
-
-# Provision to cheapest available — prefers local automatically
-terradev provision -g RTX4090 --prefer-local
-
-# Launch training on local GPU with cloud overflow
-terradev train --script train.py --pool workstation-4090 --overflow-to-cloud
-```
-
-### How Discovery Works
-
-The local scanner uses direct NVML bindings (Rust backend, 5–10x faster than `nvidia-smi` parsing) to introspect every GPU on the target machine:
-
-- GPU model, memory, PCIe bus ID, NUMA affinity
-- Current utilization, memory usage, temperature, clock speeds
-- Driver version, CUDA version, compute capability
-- Multi-GPU topology (NVLink, PCIe switch topology)
-
-Falls back to `nvidia-smi` parsing automatically if the Rust NVML extension isn't available.
-
-```bash
-# Detailed hardware report for local GPU
-terradev local scan --detailed
-
-# Output includes:
-# GPU 0: RTX 4090  VRAM 24GB  PCIe x16  NUMA node 0
-#   NVLink: none (single GPU)
-#   Compute: 8.9  Driver: 545.29  CUDA: 12.3
-#   P-state: P0  Temp: 42C  Power: 45W / 450W TDP
-```
 ---
 
 ## Quick Reference
@@ -764,6 +663,5 @@ Apache 2.0.
 
 ## Support
 
-- **Documentation**: [Full User Guide](USER_GUIDE.md)
 - **Issues**: [GitHub Issues](https://github.com/theoddden/Terradev/issues)
 - **Discussions**: [GitHub Discussions](https://github.com/theoddden/Terradev/discussions)

{terradev_cli-5.3.2 → terradev_cli-5.3.4}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "terradev-cli"
-version = "5.3.2"
+version = "5.3.4"
 description = "An imperative command-line-interface for AI workload orchestration."
 readme = "README.md"
 license = {text = "Apache-2.0"}

{terradev_cli-5.3.2 → terradev_cli-5.3.4}/terradev_cli/README.md

@@ -1,4 +1,4 @@
-# Terradev CLI v5.3.2
+# Terradev CLI v5.3.3
 
 **An imperative command-line-interface for AI workload orchestration.**
 
@@ -10,6 +10,27 @@ pypi.org/project/terradev-cli/
 
 Terradev is a cross-cloud compute-provisioning CLI that compresses + stages datasets, provisions optimal instances + nodes, and deploys **3-5x faster** than sequential provisioning.
 
+**NOTES ON 5.3.3**
+
+Added **provider profile system** for intelligent quirk-aware routing across 23 cloud providers:
+
+- **ProviderProfile schema** (`providers/types.py`): Encodes provider-specific behaviors including API style (REST/GraphQL/JSON:API), authentication type (Bearer/Basic/HMAC/X-Api-Key), rate limits, spot instance support, egress costs, fallback routing, capacity checks, container image pinning, and spot interruption handling.
+
+- **Built-in profiles** (`providers/provider_profiles.py`): Pre-configured profiles for all 23 providers (RunPod, Vast.ai, Lambda Labs, AWS, GCP, Azure, Oracle, Crusoe, CoreWeave, DigitalOcean, Yotta Labs, E2E Networks, FluidStack, Alibaba, OVHcloud, Hetzner, SiliconFlow, TensorDock, Baseten, HuggingFace, Hyperstack, InferX, Latitude).
+
+- **Dynamic registration**: Users can register custom provider profiles programmatically or load from YAML/JSON files for internal clusters or proprietary cloud providers.
+
+- **Profile-aware routing** (`providers/registry.py`): `ProviderRegistry.ranked_providers()` now incorporates provider profiles into scoring, using egress costs, fallback routing preferences, and spot preemption rates for intelligent provider selection.
+
+- **CLI commands** (`terradev providers`): New command group for managing custom provider profiles:
+  ```bash
+  terradev providers load-profiles ~/.terradev/custom_providers.yaml
+  terradev providers list-profiles
+  terradev providers show-profile runpod
+  terradev providers remove-profile my_custom_provider
+  terradev providers export-example -o ~/.terradev/custom_providers.yaml
+  ```
+
 **NOTES ON 5.3.0**
 
 Added **transport-agnostic Prefill/Decode (P/D) disaggregation layer** and **multi-agent KV cache sharing planner**:
@@ -516,115 +537,6 @@ echo "3. Test failover: terradev inferx failover --endpoint burst-llm-api --test
 echo "4. Update adapters: terradev lora update -n customer-enterprise-a -p ./new-adapters/"
 ```
 
-## Bare Metal GPU Access with IPMI Management (Latitude.sh)
-
-Most GPU clouds give you a virtual machine. You get a slice of hardware, shared kernel paths, and a hypervisor layer between your workload and the GPU. For most ML workloads this is fine. For compliance-sensitive deployments — HIPAA, FedRAMP, financial services, defense contractors — it isn't. Virtualization introduces attestation gaps that auditors reject.
-
-Latitude.sh is the only provider in Terradev's fleet that offers both **bare metal** and **virtual machine** GPU instances from the same API. Bare metal gives you the physical server — dedicated hardware, no virtualization overhead, and IPMI out-of-band management.
-
-```bash
-# See both bare metal and VM options side by side
-terradev quote -g H100 --provider latitude
-
-# Provision dedicated bare metal with IPMI access
-terradev provision --provider latitude --gpu H100 --instance-type bare-metal
-
-# Provision a VM (faster spin-up, slightly lower cost)
-terradev provision --provider latitude --gpu H100 --instance-type vm
-```
-
-### IPMI: Why It Matters for Enterprise
-
-IPMI (Intelligent Platform Management Interface) gives you out-of-band server management independent of the OS and GPU stack. If a training job deadlocks the kernel, you don't wait for a cloud provider ticket — you power-cycle via IPMI directly. Security teams can verify hardware attestation. Compliance frameworks that require dedicated hardware and physical access controls are satisfied.
-
-```bash
-# Instance status includes IPMI access endpoint when bare metal
-terradev status --live --provider latitude
-
-# Output includes:
-# ipmi_access: true
-# ipmi_endpoint: 10.x.x.x
-# isolation: bare_metal
-```
----
-
-## Local GPU Discovery and Hybrid Compute Pools
-
-Every other GPU orchestration platform assumes you're renting compute. Terradev doesn't.
-
-If you have a GPU in your local machine — a gaming rig, a workstation, a university compute node you have SSH access to — Terradev can discover it, register it into your compute pool, and incorporate it into provisioning decisions alongside cloud providers.
-
-```bash
-# Scan local machine for GPUs
-terradev local scan
-
-# Output:
-# Found 1 local GPU:
-#   [0] NVIDIA RTX 4090  24GB  Driver 545.29  Util: 3%  Temp: 42C
-#
-# Register in pool? [y/N]:
-
-# Register local GPU into your pool
-terradev local register --name "workstation-4090"
-
-# Scan a remote machine you have SSH access to
-terradev local scan --host 192.168.1.50 --user ubuntu --key ~/.ssh/id_rsa
-
-# View your full compute pool (local + cloud)
-terradev local pool
-```
-
-Pool output:
-```
-COMPUTE POOL (4 resources)
-workstation-4090    RTX 4090    24GB    local        $0.00/hr   Free
-runpod-h100-001     H100        80GB    runpod       $2.49/hr   Running
-vastai-a100-002     A100        40GB    vastai        $1.82/hr   Running
-lambda-a10g-003     A10G        24GB    lambda_labs  $0.60/hr   Idle
-```
-
-### Why This Matters
-
-The `terradev quote` command normally shows cloud provider pricing. With local GPUs registered, the pool includes your own hardware — priced at $0/hr. For a university researcher with a 3090 workstation running overnight jobs, or a startup with a rack of 4090s before they've moved to cloud: Terradev routes workloads to the cheapest available compute, and $0/hr always wins.
-
-```bash
-# Get quotes including local pool
-terradev quote -g RTX4090 --include-local
-
-# Output:
-# GPU       PROVIDER                 $/HR    AVAILABLE
-# RTX 4090  local (workstation-4090) $0.00   Yes
-# RTX 4090  vastai                   $0.34   Yes
-# RTX 4090  runpod                   $0.39   Yes
-
-# Provision to cheapest available — prefers local automatically
-terradev provision -g RTX4090 --prefer-local
-
-# Launch training on local GPU with cloud overflow
-terradev train --script train.py --pool workstation-4090 --overflow-to-cloud
-```
-
-### How Discovery Works
-
-The local scanner uses direct NVML bindings (Rust backend, 5–10x faster than `nvidia-smi` parsing) to introspect every GPU on the target machine:
-
-- GPU model, memory, PCIe bus ID, NUMA affinity
-- Current utilization, memory usage, temperature, clock speeds
-- Driver version, CUDA version, compute capability
-- Multi-GPU topology (NVLink, PCIe switch topology)
-
-Falls back to `nvidia-smi` parsing automatically if the Rust NVML extension isn't available.
-
-```bash
-# Detailed hardware report for local GPU
-terradev local scan --detailed
-
-# Output includes:
-# GPU 0: RTX 4090  VRAM 24GB  PCIe x16  NUMA node 0
-#   NVLink: none (single GPU)
-#   Compute: 8.9  Driver: 545.29  CUDA: 12.3
-#   P-state: P0  Temp: 42C  Power: 45W / 450W TDP
-```
 ---
 
 ## Quick Reference

{terradev_cli-5.3.2 → terradev_cli-5.3.4}/terradev_cli/__init__.py

@@ -3,6 +3,6 @@ Terradev CLI - Cross-Cloud Compute Optimization Platform
 Parallel provisioning and orchestration for optimized compute costs
 """
 
-__version__ = "5.3.2"
+__version__ = "5.3.4"
 __author__ = "Terradev Team"
 __description__ = "Open Source BYOAPI Multi-Cloud GPU Infrastructure Platform"