Free Consultation Case Studies

This is a library of free LLM selection consultations.

Each case starts from a real, public GitHub question where a user was trying to decide which model, provider, or stack to use. The user pain is abstracted into a general selection problem — no personal data is copied.

For each case we run llm-selector, then write the kind of short, practical answer we would give in a free consultation.

These are advisory examples, not guarantees. Always validate with your own tasks, data policy, and cost profile.

How to read each case:

Case 1 — Smallest local model that runs on old hardware

python selector.py --scenario office_automation --sensitivity public --budget low --deployment private

Free consultation:

On 4GB RAM, CPU-only, the realistic answer is a small local open-source model. Aim for a 1-2B class model in a low quant (for example a Q3/Q4 build) through llama.cpp or a friendly runtime. Do not expect agentic coding; expect a basic assistant for short tasks, drafting, and Q&A. Keep context small to avoid swapping.

7-day action plan:

  1. Day 1-2: install a runtime and pull one small model (1-2B, Q4).
  2. Day 3-4: test 5 real tasks you actually do (summaries, short replies, notes).
  3. Day 5: if it’s too slow, drop to a smaller model or lower quant.
  4. Day 6-7: decide if local is good enough, or if a cheap hosted API is worth it for harder tasks.

Verification:

Case 2 — Best local model for a specific (non-English) language

python selector.py --scenario translation --sensitivity internal --budget low --deployment private

Free consultation:

For local multilingual document work on 8GB VRAM, a Qwen-class model (7B, quantized) is a strong default because of solid multilingual behavior. Keep it local for privacy. The common failure here is the model silently answering in English — fix that with an explicit system prompt that pins the output language, and prefer instruction-tuned variants. If quality is not enough at 7B, the trade-off is either a smaller quant of a larger model or a privacy-safe hosted API for the hardest documents.

7-day action plan:

  1. Day 1: run a 7B instruct model locally with a language-locked system prompt.
  2. Day 2-3: test on 10 real documents in your language.
  3. Day 4: log where it drifts to English or loses terminology.
  4. Day 5-6: try one alternative model and compare.
  5. Day 7: lock the model + prompt template that stays in-language.

Verification:

Case 3 — Is the cheaper “mini” model good enough?

python selector.py --scenario document_summary --sensitivity internal --budget medium --deployment api

Free consultation:

The right question is not “mini vs full” — it’s “what’s the cheapest model that passes my quality bar on real documents.” For summarization, long-context handling and hallucination control matter more than raw size. Define a small eval set of real documents with a known “good summary,” then test candidates. A mini tier often passes for routine summaries and fails on nuanced or long content. The cost-smart pattern is a tiered setup: cheap model for routine summaries, stronger model only when the input is long or high-stakes.

7-day action plan:

  1. Day 1: pick 10 representative documents and write the ideal summary for each.
  2. Day 2-3: run mini vs full vs a shortlisted alternative on all 10.
  3. Day 4: score accuracy, missing points, and hallucinations.
  4. Day 5: estimate monthly cost at your real volume for each option.
  5. Day 6-7: choose a tiered routing rule (cheap by default, escalate on long/critical docs).

Verification:

Case 4 — Execution stack for sensitive financial analysis

python selector.py --scenario data_analysis --sensitivity regulated --budget high --deployment hybrid

Free consultation:

With regulated financial data, the execution environment matters as much as the model. For auditability and compliance, prefer a controlled sandbox you own (self-hosted execution with logging) over a fully managed black box, even if the managed option is more convenient. Keep raw data inside your boundary; let the model orchestrate and generate code, but run it in your audited environment. Model strength matters for code/SQL quality, but the governance layer is what makes this deployable. This is a hybrid pattern: strong model for reasoning, private execution for data.

7-day action plan:

  1. Day 1-2: define what must be logged (inputs, code, outputs, who ran it).
  2. Day 3-4: stand up a controlled sandbox (containerized execution + audit log).
  3. Day 5: test a real analysis with synthetic or redacted data first.
  4. Day 6: review the audit trail with whoever owns compliance.
  5. Day 7: decide managed vs self-hosted based on the audit gap, not convenience.

Verification:

Case 5 — Cheapest “good enough” API to build a chatbot

python selector.py --scenario customer_service --sensitivity public --budget low --deployment api

Free consultation:

For a beginner chatbot with public data and a tight budget, optimize for free/cheap tier + easy SDK + stable output. A low-cost provider (Qwen or DeepSeek tier) is a sensible start; keep a mainstream API as a fallback for quality comparison. Don’t over-engineer: build the smallest working chatbot first, with a clear system prompt and a way to hand off to a human or a canned answer when unsure. Quality is “good enough if users get correct, on-topic answers,” not benchmark score.

7-day action plan:

  1. Day 1: pick one low-cost API and get a hello-world chatbot running.
  2. Day 2-3: add your real FAQ/knowledge as context.
  3. Day 4: test bilingual prompts and common user questions.
  4. Day 5: add a fallback for “I don’t know” instead of hallucinating.
  5. Day 6-7: compare against one alternative API for quality and cost.

Verification:

Case 6 — Which model for daily agentic coding

python selector.py --scenario ai_coding --sensitivity internal --budget medium --deployment hybrid

Free consultation:

For daily agentic coding, the metric is cost-per-successful-task and tool-call reliability, not benchmark rank. A strong coding model like GLM-5.2 is a good primary, with a cheaper model (DeepSeek/Qwen tier) as a router fallback for simple steps. The hybrid pattern works: route easy edits/autocomplete to the cheap model, escalate hard reasoning and multi-step tool loops to the stronger one. If you access GLM-5.2 through a gateway or Claude Code, verify the endpoint is actually GLM-5.2 before trusting it for daily work and before scaling spend.

7-day action plan:

  1. Day 1: set your primary model and run 10 real coding tasks.
  2. Day 2-3: track success rate, retries, and tool-call failures.
  3. Day 4: add a cheaper fallback model for simple steps.
  4. Day 5: measure cost per successful task for each route.
  5. Day 6: verify the endpoint identity if using a gateway.
  6. Day 7: lock a routing rule that balances cost and reliability.

Verification:

How to get your own free case

These are examples. If you want a free first-pass selection for your own situation:

  1. Run the CLI: python selector.py
  2. Or open a selection request: https://github.com/xiaoyanfei-tech/llm-selector/issues/new/choose

Include your scenario, data sensitivity, budget range, deployment preference, and current tools. Do not include API keys, private URLs, customer records, contracts, or confidential screenshots.