Evaluate additional providers, models, and optimizations

[don-petry]

Our current org development rate is consuming a GitHub Copilot Pro, Claude Max 20x, and Google Pro subscription credits and hitting usage limits. These vendors have been changing their usage limits, pricing model and reliability which adds risk to our system.

Strategically, we should have access to more vendors, models and usage patterns to ensure we can select and use the optimal approach based on use case, performance, reliability and cost.

Investigate additional vendors, models and subscription/API access such as:
DeepSeek
Open Weight
Llama
OpenAI
Cursor

Consider alternative consumption approach for some workloads:
Batch Endpoints

[github-actions[bot]]

Enhancement: Multi-Vendor & Multi-Model Strategy

Sharpened problem & goal
The org is hitting vendor-imposed usage ceilings across GitHub Copilot Pro, Claude Max 20x, and Google Pro simultaneously — this is both a cost and an availability/reliability risk when any single vendor has an outage or changes limits without notice. The goal is a vendor-diversification playbook: a documented decision matrix for routing agent invocations to the right provider by use case, plus at least one alternative provider integrated end-to-end. Ambiguity to resolve: the idea mentions "Cursor" — does that mean a standalone developer-seat subscription or API access? Clarifying whether the scope is developer-seat tools (Copilot, Cursor) vs. API-billed agentic pipelines (Claude, Gemini, Llama-via-API) is important since these have different integration paths.

Context
This repo already has a strong foundation to build on:

• scripts/lib/model-pricing.tsv + model-pricing.sh — effective-dated per-model cost lookup; adding new providers is a row addition, not a code change
• scripts/token_report.sh / token-report.yml — org-wide ET metric aggregation; breaking this down by model would surface per-provider spend without new infrastructure
• scripts/engine.sh — the agentic execution layer; a provider-routing shim would logically live here
• Discussion 💡 Token Cost Observatory with Pre-Agentic Optimization #332 (Token Cost Observatory) is already approved and partially live — adding model as a dimension to the existing tracking is the quickest win

Impact / Effort

• Impact: HIGH — vendor lock-in is a live reliability risk, not theoretical; a single vendor outage already forces manual fallback
• Effort: L — a vendor decision matrix doc is M; actual API integration of one alternative provider against engine.sh is L given the current script architecture

Suggested acceptance criteria

• A decision matrix (docs/vendor-strategy.md) maps each agent use case (PR review, dev-lead, compliance) to a primary + fallback provider, with reasoning (cost, capability, latency, reliability track record)
• scripts/lib/model-pricing.tsv is extended with at least one non-Anthropic model (e.g., GPT-4o, DeepSeek-V3) with accurate effective-dated pricing
• token-report.yml breaks down ET and USD cost by model field so the weekly report surfaces per-provider spend — enabling data-driven vendor selection
• At least one workflow (pr-review.yml or dev-lead.yml) has a documented and tested fallback path to an alternative provider when the primary returns a rate-limit or availability error
• A subscription vs. API cost comparison table is included in the decision matrix for the top 3 evaluated vendors (including per-token API rates vs. per-seat flat rates)