managing-cohere

name	managing-cohere
description	Use when working with Cohere — cohere AI platform management covering models, embeddings, reranking, datasets, fine-tuning, and connectors. Use when monitoring API usage, analyzing model performance, reviewing fine-tuning jobs, managing datasets and connectors, or troubleshooting Cohere API issues.
connection_type	cohere
preload	false

Cohere Management Skill

Manage and analyze Cohere AI platform resources including models, datasets, and fine-tuning.

API Conventions

Authentication

All API calls use Bearer API key, injected automatically.

Base URL

https://api.cohere.com/v1

Core Helper Function

#!/bin/bash

cohere_api() {
    local method="$1"
    local endpoint="$2"
    local data="${3:-}"

    if [ -n "$data" ]; then
        curl -s -X "$method" \
            -H "Authorization: Bearer $COHERE_API_KEY" \
            -H "Content-Type: application/json" \
            "https://api.cohere.com/v1${endpoint}" \
            -d "$data"
    else
        curl -s -X "$method" \
            -H "Authorization: Bearer $COHERE_API_KEY" \
            "https://api.cohere.com/v1${endpoint}"
    fi
}

Output Rules

• Target ≤50 lines per script output
• Use jq to extract only needed fields
• Never dump full API responses

Phase 1: Discovery

#!/bin/bash
echo "=== Available Models ==="
cohere_api GET "/models" \
    | jq -r '.models[] | "\(.name)\t\(.endpoints | join(","))\t\(.context_length // "N/A")"' \
    | column -t | head -20

echo ""
echo "=== Connectors ==="
cohere_api GET "/connectors" \
    | jq -r '.connectors[] | "\(.id[0:16])\t\(.name)\t\(.active)\t\(.created_at[0:10])"' \
    | column -t | head -15

echo ""
echo "=== Datasets ==="
cohere_api GET "/datasets" \
    | jq -r '.datasets[] | "\(.id[0:16])\t\(.name[0:30])\t\(.dataset_type)\t\(.validation_status)\t\(.created_at[0:10])"' \
    | column -t | head -15

echo ""
echo "=== Fine-Tuning Jobs ==="
cohere_api GET "/finetuning/finetuned-models" \
    | jq -r '.finetuned_models[] | "\(.id[0:16])\t\(.name[0:30])\t\(.status)\t\(.created_at[0:10])"' \
    | head -10

Phase 2: Analysis

API Health & Usage

#!/bin/bash
echo "=== API Health Check ==="
RESULT=$(cohere_api POST "/chat" '{"message": "test", "model": "command-r", "max_tokens": 1}')
echo "$RESULT" | jq '{response_id: .response_id, model: .generation_id, meta: .meta}' 2>/dev/null \
    || echo "Error: $(echo $RESULT | jq -r '.message // "unknown"')"

echo ""
echo "=== Model Endpoints ==="
cohere_api GET "/models" \
    | jq -r '.models[] | {name: .name, endpoints: .endpoints}' | head -30

Fine-Tuning & Dataset Health

#!/bin/bash
echo "=== Fine-Tuning Status Summary ==="
cohere_api GET "/finetuning/finetuned-models" \
    | jq -r '.finetuned_models[] | .status' | sort | uniq -c | sort -rn

echo ""
echo "=== Dataset Validation Status ==="
cohere_api GET "/datasets" \
    | jq -r '.datasets[] | .validation_status' | sort | uniq -c | sort -rn

echo ""
echo "=== Dataset Sizes ==="
cohere_api GET "/datasets" \
    | jq -r '.datasets[] | "\(.name[0:30])\t\(.dataset_parts[0].num_rows // "N/A") rows\t\(.size_bytes // 0) bytes"' \
    | column -t | head -10

echo ""
echo "=== Connector Health ==="
cohere_api GET "/connectors" \
    | jq -r '.connectors[] | "\(.name)\t\(.active)\t\(.url[0:40])"' | head -10

Output Format

=== Cohere Platform ===
Models: <n>  Connectors: <n>  Datasets: <n>

--- Fine-Tuning ---
Active: <n>  Completed: <n>  Failed: <n>

--- Datasets ---
Total: <n>  Valid: <n>  Invalid: <n>

--- API Health ---
Status: <healthy|degraded>

Anti-Hallucination Rules

1. NEVER assume resource names — always discover via CLI/API in Phase 1 before referencing in Phase 2.
2. NEVER fabricate metric names or dimensions — verify against the service documentation or --help output.
3. NEVER mix CLI commands between service versions — confirm which version/API you are targeting.
4. ALWAYS use the discovery → verify → analyze chain — every resource referenced must have been discovered first.
5. ALWAYS handle empty results gracefully — an empty response is valid data, not an error to retry.

Counter-Rationalizations

Shortcut	Counter	Why
"I'll skip discovery and check known resources"	Always run Phase 1 discovery first	Resource names change, new resources appear — assumed names cause errors
"The user only asked for a quick check"	Follow the full discovery → analysis flow	Quick checks miss critical issues; structured analysis catches silent failures
"Default configuration is probably fine"	Audit configuration explicitly	Defaults often leave logging, security, and optimization features disabled
"Metrics aren't needed for this"	Always check relevant metrics when available	API/CLI responses show current state; metrics reveal trends and intermittent issues
"I don't have access to that"	Try the command and report the actual error	Assumed permission failures prevent useful investigation; actual errors are informative

Common Pitfalls

• Model names: Use exact model IDs (e.g., command-r, command-r-plus, embed-english-v3.0)
• Rate limits: Vary by plan; check X-RateLimit-* response headers
• Pagination: Use page_size and page_token for list endpoints
• Fine-tuning: Only specific base models support fine-tuning
• Connector auth: Connectors may need separate OAuth configuration