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

[richardchen874-sys]

This is a strong direction, especially if current workflows are already hitting usage limits across Copilot, Claude Max, and Google Pro.

I’d evaluate providers with a workload-based matrix instead of only comparing model quality:

• interactive coding / agent loops
• long-context reasoning
• batch jobs
• document processing
• low-latency tasks
• fallback when a vendor limit is reached

For each workload, I’d compare cost per successful task, rate limits, reliability, latency, context length, tool/function calling support, API compatibility, and fallback options.

DeepSeek / Llama / OpenAI-compatible providers could be useful, but the safer setup is probably a routing layer based on task type, cost, and reliability rather than depending on one vendor.

I’m working around lower-cost OpenAI-compatible API access for small AI builders, so this kind of multi-provider evaluation is exactly the area I’m focused on.

[don-petry]

Thank you for the input. We are already using a model selector based upon the type of job to be done. And a fall back across multiple providers. Would like to take this further by adding more providers and even lower cost models to increase the range of options.

[richardchen874-sys]

That makes sense — if you already have job-type model selection and multi-provider fallback, then the next useful step is probably expanding the provider pool with models that are cheap enough for high-volume or non-critical workloads.

I’d probably separate the evaluation into a few buckets:

• coding / agent loops
• document processing
• batch jobs
• long-context reasoning
• low-latency utility tasks
• fallback-only models

For lower-cost models, the key question is not only price, but whether they are reliable enough for a specific job type after retries and validation.

DeepSeek / Qwen / Llama-style OpenAI-compatible models could be useful additions, especially for execution-heavy or batch-style workloads where premium models may not be necessary.

Curious — are you mainly looking for lower-cost models for coding workflows, document processing, batch jobs, or general fallback capacity?