Edit a Model Key

Edit your model key to update the unique identifier assigned to your model checkpoint. Model keys help you organize and reference specific checkpoints from your training runs.

🔑

What are model keys?

Model keys are unique identifiers assigned to model checkpoints. They help you:

• Reference specific checkpoints — Identify particular versions of your trained model
• Organize models — Keep track of different checkpoints and versions
• Integrate with workflows — Use consistent identifiers across your deployment pipelines
• Maintain clarity — Distinguish between multiple checkpoints from the same training run

When to edit model keys

Update your model keys in these situations:

• Improved organization — Create more descriptive or meaningful identifiers
• Consistent naming — Align model keys with your team's naming conventions
• Version tracking — Use keys that reflect model versions or iterations
• Integration requirements — Match identifiers expected by your deployment systems
• Clarity improvements — Replace auto-generated keys with human-readable ones
• Project reorganization — Update keys to reflect current project structure

Navigate to model key settings

1. Navigate to your training project

2. Click the Models tab in the sidebar

3. Locate the model whose key you want to edit

4. Click the three-dot menu (⋮) on the right side of the model card

5. A dropdown menu appears with these options:

   • View Run — View detailed run information
   • Export Model — Download model for deployment
   • Create Deployment — Deploy model to production (if configured)
   • Rename Model — Update model name
   • Edit Model Key — Update model identifier (select this)
   • Delete Model — Permanently remove model

Update your model key

1. Click Edit Model Key from the dropdown menu

2. A dialog appears showing the current model key

3. The dialog displays:

   • Current key — Your existing model checkpoint identifier
   • Key format — Expected format or pattern (if applicable)
   • Usage notes — Where this key is currently referenced

4. Enter your new model key in the input field

   💡

   Key naming tips

   • Be descriptive — Use keys that indicate the checkpoint's purpose
   • Follow conventions — Match your team's identifier format
   • Include version — Consider adding version numbers (e.g., pcb-v2-checkpoint-35)
   • Avoid special characters — Stick to alphanumeric characters, hyphens, and underscores
   • Keep it concise — Shorter keys are easier to reference and remember
   • Be consistent — Use similar patterns across related models

5. Click Save or Confirm to apply the new key

✅

Model key updated

Your model checkpoint identifier has been updated. You may need to update references in:

• Deployment configurations
• Integration scripts
• Documentation and wikis
• Workflow automation
• Team member notes

What changes when you edit

Updated:

• Model checkpoint identifier
• References in the platform UI
• Key returned in API responses
• Identifier used in deployment configurations
• Key shown in model export operations

Unchanged:

• Model ID (Run ID) — The underlying model identifier remains the same
• Model weights and configurations
• Training history and metrics
• Model performance characteristics
• Model name (change separately via Rename Model)
• Downloaded model files (already exported)

🔑

Model ID vs Model Key

• Model ID (Run ID) — Permanent unique identifier that never changes
• Model Key — Customizable reference label you can update anytime

Your Model ID remains constant and is used internally by the platform. The Model Key is a human-readable identifier you can customize for your workflows.

Update references after editing

After changing a model key, update any external references:

Deployment configurations

If your deployment scripts reference the model key:

# deployment-config.yml
model:
  name: "PCB Defect Detection"
  key: "pcb-v2-checkpoint-35"  # Update this if changed
  run_id: "run_abc123"  # This never changes

Documentation

Update any documentation that references the old key:

• Project wikis and README files
• Deployment guides and runbooks
• Integration documentation
• Team onboarding materials
• API integration guides

Integration scripts

If your scripts use the model key for identification:

# Update model key references in your code
MODEL_CONFIGS = {
    "pcb-v2-checkpoint-35": {  # New key
        "run_id": "run_abc123",
        "description": "PCB defect detection model"
    }
}

Team communication

• Notify team members of the key change
• Update shared spreadsheets or tracking documents
• Inform stakeholders who reference the model
• Update project management tools

Model key naming conventions

Establish consistent patterns for better organization:

Pattern 1: Version-based

Include version numbers for clear progression:

• model-v1-checkpoint-final
• model-v2-checkpoint-epoch-50
• model-v3-checkpoint-best

Pattern 2: Task-based

Emphasize what the model does:

• defect-detection-checkpoint-35
• quality-control-checkpoint-final
• classification-checkpoint-best

Pattern 3: Date-based

Include training dates for temporal tracking:

• pcb-model-2026-01-checkpoint
• qc-model-202601-v2
• detection-20260105-final

Pattern 4: Performance-based

Reflect model characteristics:

• high-accuracy-checkpoint-89
• fast-inference-checkpoint-final
• balanced-model-checkpoint-best

💡

Choose what works for your team

Select a naming pattern that makes sense for your workflow and apply it consistently across all your models.

Common questions

import vi

client = vi.Client(
    secret_key="your-secret-key",
    organization_id="your-organization-id"
)

# Models are accessed by Run ID, not by model key
model_data = client.get_model(run_id="run_abc123")

# For loading models
from vi.inference import ViModel

model = ViModel(
    run_id="run_abc123",  # Always use Run ID
    secret_key="your-secret-key",
    organization_id="your-organization-id"
)

Best practices

When model keys are useful

Troubleshooting

Next steps