api/transformerlab/compute_providers/local.py (1)

158-176: Consider using the logging module instead of print() for debug statements.

The debug statements are useful for visibility, but print() doesn't integrate with log level filtering. Using Python's logging module would allow these to be controlled via configuration.

♻️ Suggested refactor to use logging

+import logging
+
+logger = logging.getLogger(__name__)
+
 class LocalProvider(ComputeProvider):
     # ...
     
     def launch_cluster(self, cluster_name: str, config: ClusterConfig) -> Dict[str, Any]:
         # ...
-        print(f"DEBUG: LocalProvider.launch_cluster: cluster_name={cluster_name}")
-        print(f"DEBUG: LocalProvider.launch_cluster: job_dir={job_dir}")
+        logger.debug(f"LocalProvider.launch_cluster: cluster_name={cluster_name}")
+        logger.debug(f"LocalProvider.launch_cluster: job_dir={job_dir}")
         if config.setup:
-            print(f"DEBUG: LocalProvider.launch_cluster: running setup: {config.setup}")
+            logger.debug(f"LocalProvider.launch_cluster: running setup: {config.setup}")
             # ...
             if setup_result.returncode != 0:
-                print(f"DEBUG: LocalProvider.launch_cluster: setup failed with code {setup_result.returncode}")
-                print(f"DEBUG: LocalProvider.launch_cluster: setup stderr: {setup_result.stderr}")
+                logger.debug(f"LocalProvider.launch_cluster: setup failed with code {setup_result.returncode}")
+                logger.debug(f"LocalProvider.launch_cluster: setup stderr: {setup_result.stderr}")
                 raise RuntimeError(...)
         
-        print(f"DEBUG: LocalProvider.launch_cluster: running command: {config.command}")
+        logger.debug(f"LocalProvider.launch_cluster: running command: {config.command}")

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@api/transformerlab/compute_providers/local.py` around lines 158 - 176,
Replace the ad-hoc print() debug statements in LocalProvider.launch_cluster with
the Python logging module: add "import logging" and obtain a module logger via
logging.getLogger(__name__), then change prints to logger.debug(...) for the
debug traces (cluster_name, job_dir, running setup, running command) and use
logger.error(...) when logging setup_result.stderr/returncode before raising the
RuntimeError; keep the same variable names (config.setup, setup_result) and
preserve the raised RuntimeError text but log the detailed error via the logger
instead of print.

src/renderer/components/Experiment/Interactive/Interactive.tsx (1)

339-344: Consider defining an interface for the template type instead of using any.

The template selection logic is correct, but the use of any type violates coding guidelines. Consider defining a proper interface for the gallery template structure.

As per coding guidelines: "Avoid using any type in TypeScript; define interfaces for all props and API responses to ensure type safety."

♻️ Suggested interface definition

interface InteractiveTemplate {
  id: string;
  interactive_type: string;
  name: string;
  description: string;
  setup: string;
  command: string;
  env_parameters: Array<{
    field_name: string;
    env_var: string;
    field_type: string;
    required: boolean;
    placeholder?: string;
    help_text?: string;
    password?: boolean;
  }>;
  icon: string;
}

Then update the find call:

-const template = galleryData.data?.find((t: any) => {
+const template = galleryData.data?.find((t: InteractiveTemplate) => {
   if (data.template_id) {
     return t.id === data.template_id;
   }
   return t.interactive_type === interactiveType;
 });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/renderer/components/Experiment/Interactive/Interactive.tsx` around lines
339 - 344, The code uses an `any` in the template selection which breaks
TypeScript safety: define a proper interface (e.g., InteractiveTemplate)
describing the template shape (id, interactive_type, name, description, setup,
command, env_parameters, icon, etc.) and replace the `any` with that interface
on `galleryData.data` elements so the `find` call that assigns `template` uses
typed objects; update the type of `galleryData` or the array element type where
`galleryData.data` is declared and change the find callback signature from `(t:
any)` to `(t: InteractiveTemplate)` (or the appropriate alias) to restore type
safety while keeping the same selection logic.

api/transformerlab/routers/compute_provider.py (1)

1506-1521: Hardcoded commands may drift from gallery definitions.

The local mode implementation bypasses the interactive gallery and hardcodes commands directly in the router. While this works, it creates a maintenance risk where the gallery commands and local commands could diverge over time.

Consider extracting these command templates to a shared location or generating local variants from the gallery definitions to ensure consistency.

Additionally, per coding guidelines, business logic like command generation could be moved to a service module. As per coding guidelines: "Place business logic in api/transformerlab/services/ using the Service pattern; routers should only handle HTTP request/response validation."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@api/transformerlab/routers/compute_provider.py` around lines 1506 - 1521, The
router compute_provider.py currently hardcodes per-interactive-type local
command strings (see request.local, request.subtype, request.interactive_type
and the command_with_secrets assignments), which risks drifting from gallery
definitions and mixes business logic into the router; refactor by extracting the
command templates and local-variant generation into a new service (e.g., a
CommandGenerationService in api/transformerlab/services/) that exposes a method
like get_local_command(interactive_type, model_name, tp_size, ...) and have the
router call that service to obtain command_with_secrets instead of embedding the
strings; ensure the service sources templates from the gallery definitions (or a
shared templates module) so local variants are derived programmatically, and
update the router to only perform request validation and delegate command
construction to the new service.

api/transformerlab/compute_providers/config.py (1)

39-41: Type inconsistency between ComputeProviderConfig and ProviderConfigBase.

ComputeProviderConfig.supported_accelerators uses Optional[list[str]], while ProviderConfigBase in schemas/compute_providers.py uses Optional[List[AcceleratorType]]. This type inconsistency could cause validation issues or confusion when data flows between these models.

Consider aligning the types for consistency:

♻️ Suggested fix

+from transformerlab.shared.models.models import AcceleratorType
+from typing import Dict, Any, Optional, List
 ...
     # Accelerators supported by this provider
-    supported_accelerators: Optional[list[str]] = Field(default=None)
+    supported_accelerators: Optional[List[AcceleratorType]] = Field(default=None)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@api/transformerlab/compute_providers/config.py` around lines 39 - 41, The
ComputeProviderConfig model's supported_accelerators field is typed as
Optional[list[str]] while ProviderConfigBase uses
Optional[List[AcceleratorType]], causing inconsistency; update
ComputeProviderConfig.supported_accelerators to use the same type
(Optional[List[AcceleratorType]]) and import or reference AcceleratorType from
the same module where ProviderConfigBase defines it, and run/adjust any imports
or type aliases so both models share the identical type definition.

api/transformerlab/shared/models/models.py (1)

136-142: Inconsistent casing in AcceleratorType enum values.

The enum values use inconsistent casing: "AppleSilicon" (PascalCase), "NVIDIA" (uppercase), "AMD" (uppercase), and "cpu" (lowercase). This inconsistency could cause matching issues when comparing accelerator strings from different sources (e.g., gallery JSON, provider configs, frontend).

Consider standardizing the casing, for example using uppercase for all hardware-specific types:

♻️ Suggested fix

 class AcceleratorType(str, enum.Enum):
     """Enum for accelerator types."""
 
-    APPLE_SILICON = "AppleSilicon"
+    APPLE_SILICON = "APPLE_SILICON"
     NVIDIA = "NVIDIA"
     AMD = "AMD"
-    CPU = "cpu"
+    CPU = "CPU"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@api/transformerlab/shared/models/models.py` around lines 136 - 142, The
AcceleratorType enum has inconsistent member string values
(APPLE_SILICON="AppleSilicon", NVIDIA="NVIDIA", AMD="AMD", CPU="cpu"); normalize
them to a single casing (e.g., all uppercase: APPLE_SILICON="APPLE_SILICON",
NVIDIA="NVIDIA", AMD="AMD", CPU="CPU") so comparisons are stable across sources,
and update any code that relies on the old literal strings
(parsing/serialization/deserialization points that reference AcceleratorType) to
use the new standardized values or use AcceleratorType members instead of raw
strings.

api/transformerlab/galleries/interactive-gallery.json (1)

11-11: supported_accelerators uses string instead of array format.

The supported_accelerators field uses a single string (e.g., "cpu", "NVIDIA") rather than an array. If a template supports multiple accelerator types, this format won't accommodate that. Consider using an array format for future extensibility:

"supported_accelerators": ["cpu", "NVIDIA"]

Also applies to: 32-32, 78-78, 107-107, 127-127, 148-148

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@api/transformerlab/galleries/interactive-gallery.json` at line 11, Update the
JSON entries where the key supported_accelerators is currently a string (e.g.,
"cpu") to use an array format (e.g., ["cpu"]) so multiple accelerator types can
be listed; find every occurrence of the supported_accelerators key in this file
(notably the entries referenced around lines 11, 32, 78, 107, 127, 148) and
replace the string value with an array value, and ensure any consumer logic that
reads supported_accelerators expects an array (or normalize a string to a
single-item array) so parsing remains backward-compatible.

api/transformerlab/routers/compute_provider.py (1)

1508-1524: Hardcoded commands duplicate gallery logic and create maintenance burden.

The local interactive mode bypasses the gallery with hardcoded commands (lines 1518-1523), duplicating logic from interactive-gallery.json. This means changes to commands must be made in two places. The comment at line 1510 acknowledges this is a temporary solution.

Consider extracting local-mode commands into the gallery JSON (e.g., a separate local_command field) or a dedicated configuration, so all interactive commands are centralized.

Additionally, the vscode case (line 1517) is a no-op (pass), meaning VS Code local mode still uses the tunnel command, which may not work locally.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@api/transformerlab/routers/compute_provider.py` around lines 1508 - 1524, The
local interactive branch in compute_provider.py duplicates hardcoded commands
for request.interactive_type (jupyter, vllm, ollama) and leaves the vscode
branch as a no-op; extract these local-mode commands out of the function and
centralize them in the interactive gallery config (e.g., add a local_command
field to interactive-gallery.json) and then load and use that config here
instead of hardcoding strings; update the vscode branch to read a local_command
from the gallery (or fall back to the tunnel only if no local_command exists)
and change any places referencing request.interactive_type or the current
hardcoded command_* variables to use the new config lookup so updates live in
one place.

src/renderer/components/Experiment/Tasks/QueueTaskModal.tsx (1)

1012-1012: Consider defining a proper interface for provider instead of any.

The provider parameter uses any type. Define an interface for the provider object to ensure type safety, per coding guidelines which advise avoiding any in TypeScript.

interface Provider {
  id: string;
  name: string;
  type: string;
  config?: {
    supported_accelerators?: string[];
  };
}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/renderer/components/Experiment/Tasks/QueueTaskModal.tsx` at line 1012,
The providers.map callback in QueueTaskModal.tsx uses the unsafe any type for
provider; define a Provider interface (e.g., fields id, name, type, optional
config.supported_accelerators) and replace any with Provider wherever provider
is used (including the providers array declaration and the map callback
signature), update imports/exports or local type declarations as needed, and
ensure references in the component (e.g., inside the providers.map loop in
QueueTaskModal) access typed fields rather than arbitrary properties to restore
type safety.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

src/renderer/components/Experiment/Tasks/NewInteractiveTaskModal.tsx (3)

856-865: Replace any for team gallery items.
This repeats a previously flagged issue; add a typed interface for team gallery tasks and use it in the filter/map.

As per coding guidelines: Avoid using any type in TypeScript; define interfaces for all props and API responses to ensure type safety.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/renderer/components/Experiment/Tasks/NewInteractiveTaskModal.tsx` around
lines 856 - 865, Define a proper TypeScript interface for team gallery items
(e.g., TeamGalleryItem) that includes fields used here like
supported_accelerators, config (with supported_accelerators), title/label, id,
etc., then replace the use of any in the filter/map callbacks by typing
teamGallery as TeamGalleryItem[] (or casting elements as TeamGalleryItem) and
update the callback signatures to (task: TeamGalleryItem, index: number) so
isProviderCompatible(selectedProvider, task.supported_accelerators ||
task.config?.supported_accelerators) and subsequent uses of task are typed;
update the NewInteractiveTaskModal component props/state types accordingly so
teamGallery is strongly typed throughout.

---

38-43: Replace any in provider config and guard undefined providers.
This repeats a previously flagged issue (config?: any, provider: any) and can crash when provider is undefined.

As per coding guidelines: Avoid using any type in TypeScript; define interfaces for all props and API responses to ensure type safety.

Also applies to: 132-138

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/renderer/components/Experiment/Tasks/NewInteractiveTaskModal.tsx` around
lines 38 - 43, The ProviderOption type and usages in NewInteractiveTaskModal use
`any` and assume `provider` is defined; replace `config?: any` with a stricter
type (e.g., an interface like ProviderConfig or `Record<string,
unknown>`/`unknown`) and add a runtime guard where `provider` is accessed (in
the component logic around the provider selection and the code at lines
referenced ~132-138) to handle undefined providers safely—update the
ProviderOption type definition, change places that declare `provider: any` to
the new typed shape, and add null/undefined checks before reading
provider.config or calling provider-specific methods so the modal no longer
crashes when provider is missing.

---

132-183: Add unit tests for isProviderCompatible.
This utility encodes multiple accelerator rules and needs coverage; this was already flagged in a prior review.

As per coding guidelines: Write unit tests for all utility functions and complex hooks in the frontend.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/renderer/components/Experiment/Tasks/NewInteractiveTaskModal.tsx` around
lines 132 - 183, Add unit tests covering the isProviderCompatible callback in
NewInteractiveTaskModal.tsx: create tests that assert true/false for
AppleSilicon matches when taskSupportedAccelerators contains "apple" or "mps"
and provider.config.supported_accelerators includes/excludes "AppleSilicon";
similar tests for NVIDIA variants ("nvidia","cuda","rtx","a100","h100","v100")
against "NVIDIA"; AMD variants ("amd","rocm") against "AMD"; CPU strings against
"cpu"; a numeric accelerator string (e.g., "8") should map to NVIDIA presence;
and edge cases where provider.config.supported_accelerators is empty and where
taskSupportedAccelerators is undefined (both should return true). Ensure each
test uses the isProviderCompatible function reference from
NewInteractiveTaskModal and covers both positive and negative matches.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

api/transformerlab/galleries/interactive-gallery.json (1)

114-115: Consider loopback-only binding for local (no-tunnel) mode.

Since this is explicitly “no tunnel,” binding to 0.0.0.0 exposes the services on the LAN. If the intent is local-only access, prefer loopback (127.0.0.1) or make it configurable.

Suggested change

-    "command": "export OLLAMA_HOST=0.0.0.0:11434 && ollama serve > /tmp/ollama.log 2>&1 & sleep 3 && ollama pull $MODEL_NAME > /tmp/ollama-pull.log 2>&1 & sleep 5 && OLLAMA_BASE_URL=http://127.0.0.1:11434 ~/ollama-venv/bin/open-webui serve --host 0.0.0.0 --port 8080 > /tmp/openwebui.log 2>&1 & sleep 5 && echo 'Local Ollama API: http://localhost:11434'; echo 'Local Open WebUI: http://localhost:8080'; tail -f /tmp/ollama.log /tmp/ollama-pull.log /tmp/openwebui.log",
+    "command": "export OLLAMA_HOST=127.0.0.1:11434 && ollama serve > /tmp/ollama.log 2>&1 & sleep 3 && ollama pull $MODEL_NAME > /tmp/ollama-pull.log 2>&1 & sleep 5 && OLLAMA_BASE_URL=http://127.0.0.1:11434 ~/ollama-venv/bin/open-webui serve --host 127.0.0.1 --port 8080 > /tmp/openwebui.log 2>&1 & sleep 5 && echo 'Local Ollama API: http://localhost:11434'; echo 'Local Open WebUI: http://localhost:8080'; tail -f /tmp/ollama.log /tmp/ollama-pull.log /tmp/openwebui.log",

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@api/transformerlab/galleries/interactive-gallery.json` around lines 114 -
115, The current startup script in the "command" and "setup" strings binds
services to 0.0.0.0 (e.g., OLLAMA_HOST and the open-webui serve call), exposing
them to the LAN; change those bindings to loopback (127.0.0.1) or make the host
configurable so local "no-tunnel" runs are loopback-only: update occurrences
where "ollama serve" is started (and where OLLAMA_HOST is set) and where
open-webui is served (the open-webui serve --host flag) to use 127.0.0.1 (or
read a config/env var like OLLAMA_BIND or WEBUI_HOST) so services are not
publicly reachable by default.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

src/renderer/components/Experiment/Tasks/NewInteractiveTaskModal.tsx (3)

858-866: 🛠️ Refactor suggestion | 🟠 Major

Replace any type annotations with TeamGalleryTask.

After defining the TeamGalleryTask type, update the filter and map callbacks:

 {teamGallery
-  .filter((task: any) =>
+  .filter((task: TeamGalleryTask) =>
     isProviderCompatible(
       selectedProvider,
       task.supported_accelerators ||
         task.config?.supported_accelerators,
     ),
   )
-  .map((task: any, index: number) => {
+  .map((task: TeamGalleryTask, index: number) => {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/renderer/components/Experiment/Tasks/NewInteractiveTaskModal.tsx` around
lines 858 - 866, Update the anonymous callback parameter types in the
teamGallery filter and map to use the defined TeamGalleryTask type instead of
any: change the filter callback signature (task: any) to (task: TeamGalleryTask)
and the map callback signature (task: any, index: number) to (task:
TeamGalleryTask, index: number), keeping the existing uses of
isProviderCompatible and selectedProvider unchanged so TypeScript correctly
infers task.supported_accelerators and task.config?.supported_accelerators.

---

38-43: 🛠️ Refactor suggestion | 🟠 Major

Define a typed interface for config instead of using any.

The config?: any defeats TypeScript's type checking. Based on usage in the component (accessing config.supported_accelerators), define a proper type:

+type ProviderConfig = {
+  supported_accelerators?: string[];
+};
+
 type ProviderOption = {
   id: string;
   name: string;
   type?: string;
-  config?: any;
+  config?: ProviderConfig;
 };

As per coding guidelines: "Avoid using any type in TypeScript; define interfaces for all props and API responses to ensure type safety."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/renderer/components/Experiment/Tasks/NewInteractiveTaskModal.tsx` around
lines 38 - 43, The ProviderOption type uses config?: any which bypasses type
checking; replace it with a typed interface (e.g., ProviderConfig) that captures
fields the component reads such as supported_accelerators: string[] (and any
other known keys), then change ProviderOption.config?: ProviderConfig; update
references in NewInteractiveTaskModal where config.supported_accelerators is
accessed to rely on the new typed shape and adjust optional chaining if needed
(e.g., config?.supported_accelerators) to satisfy nullability.

---

132-184: ⚠️ Potential issue | 🟠 Major

Fix type annotation and add null safety for provider parameter.

The function uses provider: any but is called with selectedProvider which can be undefined. This will cause a runtime error when accessing provider.config.

 const isProviderCompatible = React.useCallback(
-  (provider: any, taskSupportedAccelerators: string | undefined) => {
+  (provider: ProviderOption | undefined, taskSupportedAccelerators: string | undefined) => {
     if (!taskSupportedAccelerators) return true;

-    const supported = provider.config?.supported_accelerators || [];
+    const supported = provider?.config?.supported_accelerators || [];
     if (supported.length === 0) return true;

This change requires the ProviderConfig type from the previous suggestion.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/renderer/components/Experiment/Tasks/NewInteractiveTaskModal.tsx` around
lines 132 - 184, The isProviderCompatible callback currently types provider as
any and assumes provider is defined, causing runtime errors when called with
selectedProvider which can be undefined; update the signature to accept
provider: ProviderConfig | undefined (import or define ProviderConfig) and add a
null/undefined guard at the top (e.g., return true/false or treat missing config
as compatible per existing logic) before accessing provider.config; also adjust
uses of provider.config?.supported_accelerators to handle provider being
undefined and keep the existing accelerator-matching logic intact.

api/transformerlab/routers/experiment/jobs.py (1)

446-449: Inconsistent provider type check compared to similar code.

This code correctly uses ProviderType.LOCAL.value, but the equivalent code in get_provider_job_logs at line 327 uses the string literal "local":

# Line 327
if getattr(provider, "type", None) == "local" and hasattr(provider_instance, "extra_config"):

Consider updating line 327 to also use the enum for consistency.

Additionally, this logic is duplicated between both functions. You could extract it into a small helper to reduce duplication.

♻️ Suggested fix for consistency at line 327

     # For local provider, set workspace_dir (job dir) so LocalProvider can read logs.
     # Use the dedicated local-only directory so this works even when TFL_REMOTE_STORAGE_ENABLED is set.
-    if getattr(provider, "type", None) == "local" and hasattr(provider_instance, "extra_config"):
+    if getattr(provider, "type", None) == ProviderType.LOCAL.value and hasattr(provider_instance, "extra_config"):
         job_dir = get_local_provider_job_dir(job_id, org_id=user_and_team["team_id"])
         provider_instance.extra_config["workspace_dir"] = job_dir

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@api/transformerlab/routers/experiment/jobs.py` around lines 446 - 449, The
provider-type check in get_provider_job_logs currently compares to the string
literal "local"; change that check to use ProviderType.LOCAL.value for
consistency with the other block (use the same getattr(provider, "type", None)
== ProviderType.LOCAL.value pattern) and ensure the hasattr(provider_instance,
"extra_config") guard remains; then extract the duplicated logic that computes
the local job_dir and sets provider_instance.extra_config["workspace_dir"] into
a small helper (e.g., set_local_provider_workspace(provider, provider_instance,
job_id, user_and_team) or set_local_workspace_dir) and call it from both
get_provider_job_logs and the other function (referencing
get_local_provider_job_dir and provider_instance.extra_config inside the
helper).

Configuration used: defaults

Review profile: CHILL

Plan: Pro