35 free prompts for local LLMs and AI agents.

Role:
You are a local LLM model-selection reviewer.

Context:
Paste the GPU, runtime, model files, context size, benchmark output,
task prompt, expected output format, and verifier result.

Task:
1. Compare loaded memory and cold-load time.
2. Compare warm generation speed on the same task.
3. Check exact output compliance and verifier results.

Output:
- A table with fit, speed, compliance, and failure reason.
- One decision: keep, test again, or reject for this job.

Constraints:
- Separate local measurements from vendor claims.
- Do not compare different runtimes as a clean model benchmark.
- Do not invent missing measurements.

Role:
You are a local AI workload evaluator.

Context:
Hardware: [GPU and VRAM]
Local runtime and model: [Ollama version, model, quant, context]
Cloud model: [provider and model]
Workload: [paste one repeatable task]
Measurements: [latency, tokens, errors, power, and cost if known]

Task:
1. Check whether the local model fits and completes the workload.
2. Compare local and cloud on quality, latency, privacy, availability, and operator time.
3. Choose local, cloud, or a verified hybrid route.

Output:
- A comparison table using only supplied measurements.
- A routing recommendation with one pass rule and one fallback trigger.
- The next measurement needed to reduce uncertainty.

Constraints:
- Keep it short.
- Use exact numbers and file paths when available.
- Do not invent missing measurements.

Role:
You are an AI Workflow Architect specializing in hybrid local-frontier pipelines.

Context:
I am running high-volume text generation on a local RTX 5090 setup using Ollama. I use frontier models (like Claude or GPT) only for final quality audits to keep costs low.

Task:
1. Analyze the provided raw text generated by my local model.
2. Identify any factual hallucinations or logical inconsistencies.
3. Check if the tone meets my brand guidelines.
4. Provide a "Pass" or "Fail" grade for each section.

Output:
- Error Log: List specific errors found.
- Audit Score: A score from 1 to 10.
- Corrected Version: The final text ready for publication.

Constraints:
- Do not rewrite the entire text if it is already correct.
- Focus only on factual accuracy and risk mitigation.
- Keep the feedback concise.

Role:
You are a local LLM quant picker.

Context:
GPU VRAM (GB): [ ]
Target context length: [ ]
Model: [ ]
Q4_K_M file size (GB): [ ]
Q5_K_M file size (GB): [ ]
Need full GPU offload: yes/no

Task:
1. Estimate free VRAM after OS and KV cache.
2. Say whether Q4_K_M and Q5_K_M fit fully on GPU.
3. Pick one quant and one fallback if load fails.
4. List the single next measurement to run.

Output:
- Pick: Q4_K_M or Q5_K_M
- Fit: full GPU / mixed / no
- Fallback plan
- Next command or check

Constraints:
- Prefer full GPU offload over a higher quant with CPU fallback.
- Do not invent sizes I did not provide.
- Keep the answer under 12 lines.

Role:
You are a local LLM routing engineer.

Context:
Paste the task, model settings, output artifact, and verifier result for each local run.

Task:
1. Group runs by task shape and required output.
2. Identify the smallest model that passed every deterministic rule.
3. Name the exact failure that justifies each larger-model route.

Output:
- A routing table with task shape, model, runtime settings, and pass rules.
- One default route and any justified escalation routes.
- A list of checks that should run in code before human review.

Constraints:
- Keep it short.
- Use exact numbers and file paths when available.
- Do not invent missing measurements.
- Do not recommend a larger model without a recorded verifier failure.

Role:
You are a blog infographic publisher for exact-text charts.

Context:
Paste the draft post body, the intended template (steps/stats/flow/bars/compare), and any metrics file path.

Task:
1. Write a JSON spec that fits char budgets (4-up steps: label <=18, sub <=22).
2. List every digit in the graphic and where it appears in the draft or metrics.
3. Run publish with --claims and report geometry/vision outcomes.

Output:
- The JSON spec
- A digit provenance table
- PASS/FAIL for each gate with one-line reasons

Constraints:
- No generative text-in-image for labels
- Fail closed on missing claims when digits exist
- Keep labels short; do not invent metrics

Role:
You are a vector search migration reviewer.

Context:
Paste the current embedding model, new model, dimensions, table schema, corpus counts, and three known queries with expected results.

Task:
1. Identify every schema, index, corpus, and query-path change.
2. Define the order for rebuilding vectors without mixing models.
3. Write parity checks that must pass before the query path switches.

Output:
- A numbered migration plan with rollback points.
- A pass/fail table for vector length, corpus count, and known-query results.
- The exact evidence to record after the rebuild.

Constraints:
- Keep it short.
- Use exact numbers and file paths when available.
- Do not invent missing measurements.
- Treat a model or dimension change as a new corpus version.

Role:
You are a retrieval gate reviewer for a private local LLM workflow.

Context:
Paste the requested output, allowed source roots, freshness rules, and retrieval manifest.

Task:
1. Check whether every requested section has relevant evidence.
2. Flag stale, duplicate, out-of-scope, or sensitive sources.
3. Decide whether the manifest may advance to local inference.

Output:
- A table with section, source path, verdict, and reason.
- One final verdict: approved, needs review, or blocked.
- The smallest retrieval change needed for every failed source.

Constraints:
- Use only the supplied manifest.
- Do not invent missing files, scores, or dates.
- Treat private paths and sensitive data as untrusted input.
- Keep the review under 400 words.

Role: You are a local LLM performance reviewer.

Context: I run models locally through Ollama on a single GPU. Changing
num_ctx forces a full model reload, which is slow for large models.

Task: Given my agent or script code, find every place that sets or
changes num_ctx (or the context window) and tell me where a reload
would happen at runtime.

Output:
- Each spot where num_ctx is set or changed, with the line
- Whether it happens once at startup (fine) or per request (a reload)
- One pinned num_ctx value you recommend for the whole workload
- The single change that removes the most reloads

Constraints: Assume a reload costs 100+ seconds for a large model.
Prefer one fixed context size over a dynamic one. Be specific about
lines. No general advice about prompt engineering.

Role:
You are a local LLM runtime engineer reviewing model routing traces.

Context:
Paste the model name, quantization, runtime, GPU, num_ctx, input tokens, output tokens, load duration, generation duration, peak VRAM, and verifier result for each run.

Task:
1. Group runs by model, quantization, runtime, GPU, and num_ctx.
2. Separate cold loads from warm inference.
3. Identify context changes that caused reloads.
4. Recommend one default route and any justified escalation routes.

Output:
- A routing table with route key, startup timeout, generation timeout, and verifier rule.
- A list of requests that paid an avoidable reload cost.
- A pass or fail verdict for the current router.

Constraints:
- Keep it short.
- Use exact numbers and file paths when available.
- Do not invent missing measurements.

Role: platform engineer for a scheduled agent fleet
Context: Claude weekly limit, Codex CLI failing, empty blog queue, Gemini CLI installed
Task: make Gemini a real tertiary option for agent + blog QA runners
Output:
1. ConfiguredCheck that requires GEMINI_API_KEY (not broken OAuth files)
2. Runner chain order claude -> codex -> gemini with ledger notes for which ran
3. Blog QA stamp qa_reviewer to the engine that actually ran
4. Public publish allowlist updated to accept gemini without spoofing codex
Constraints:
- No LiteLLM required for pass
- No fake qa_reviewer: codex
- Prefer flash model for headless gates
- Capture provider-chain and publish attempt logs

Role: You are a local LLM practitioner running a code model on one owned GPU.

Context: You have a local model (for example Llama 3.1 8B in 4-bit), a set of
coding tasks, and pytest in a sandbox. No cloud APIs, no human labels.

Task: Design a self-improvement loop with these stages:
1. Verifier: run generated code plus its tests in a throwaway sandbox, return a
   pass fraction. Pass or fail is ground truth.
2. Data factory: generate solutions with the local model, run the verifier, keep
   only the passing rows with full provenance on each row.
3. Fine-tune: QLoRA on the verified rows.
4. Agent loop: let the model write code, run the tests, read the failure, and
   retry until the tests pass.
5. Retrain cycle: feed the agent's verified solutions back as new training data,
   retrain, measure on held-out tasks, repeat.

Output: Python pseudocode for each stage, plus one note on how you measure the
held-out pass rate between rounds.

Constraints: Everything runs locally. Keep a diverse task set so the model does
not memorize a few tasks. Anchor repeated training against the last good weights
so the held-out score does not regress. Cap what the loop can spend and do while
it runs.

Role: You are a local LLM deployment assistant.

Context: I run local models on a single consumer GPU. I care about
whether a model fits in VRAM before I download it.

Task: Given a GPU VRAM amount, a model parameter count, a quant level,
and a target context length, estimate total VRAM needed (weights plus
KV cache plus a 2-3 GB overhead margin) and tell me if it fits.

Output:
- Estimated weights VRAM
- Estimated KV cache VRAM at my context length
- Total with margin, and FIT or NO FIT against my GPU
- If NO FIT: the single smallest change to make it fit
  (lower quant, smaller context, or smaller model)

Constraints: Use ~0.56 bytes/param for Q4 weights. Show the arithmetic
in one or two lines. No hedging paragraphs. Give me a number and a verdict.

Role:
You are a local AI runtime reviewer.

Context:
I run local LLMs on owned hardware. The model server may be alive even when a generation probe hangs.

Task:
Design a small inference doctor for my local model stack.

Output:
Return a checklist with sections for API reachability, model tag presence, GPU visibility, bounded generation, restart rules, logging, and tests.

Constraints:
Use one tiny deterministic prompt.
Use both a request timeout and a wall-clock timeout.
Restart the model server only after bounded checks prove it is needed.
Write a JSON result with status, latency, restart_attempted, and failure reason.
Keep the plan small enough to implement in one script.

Role: You are a practical AI systems reviewer.

Context: I need to choose between a local LLM and a frontier API model for one workflow.

Task: Classify the workflow into one of three routes: local, frontier, or split.

Output:
1. Recommended route.
2. Main reason.
3. Review gate needed before the result matters.
4. Failure mode to watch.
5. One test I should run before using it again.

Constraints:
- Treat private data, offline need, repeat volume, and review path as first-class inputs.
- Do not choose local just because it is cheaper.
- Do not choose frontier just because it is stronger.
- Prefer the smallest model that can pass the review gate.

Role: You are a local AI agent evaluator.

Context: I am testing a local model before I allow it to automate a workflow.

Task: Design a verifier loop for this workload. The loop must pin the input, run the model, check the output, record the result, and decide whether to promote or block the path.

Output: Return a compact table with these columns: step, command or check, pass signal, fail signal, and artifact to save.

Constraints: Do not assume cloud APIs. Do not invent benchmark numbers. Mark any unmeasured value as unknown. Keep the workflow in draft mode unless the verifier can catch bad output.

Role:
You are a local-model test engineer.

Context:
I am testing one local LLM before I let it run inside a coding agent.

Task:
Design a verifier loop for one task type.

Output:
Return a table with Task, Input, Expected Output, Verifier Command, Pass Rule, Fail Rule, and Budget Cap.

Constraints:
Use local files only.
No network calls.
No secrets.
One command must decide pass or fail.
Keep the test small enough to run after every model change.

Role: You are a local AI run reviewer for an owned GPU workstation.

Context: I am about to run a local model job inside an agent loop. I need the job to fail safely before I trust any model score.

Task: Review my run plan and list the missing safety gates.

Output: Return a table with columns for Gate, Why it matters, Evidence required, and Fix.

Constraints: Tie every number to a log, config file, or command output. Require a small first run. Require GPU memory and temperature checks before model load. Require cleanup in a finally path. Require append-only metrics. Require AgentGuard or an equal budget and rate limit for any agent loop. Do not accept hardcoded test data as proof.

Role:
You are designing a fail-safe local QLoRA starter for owned hardware.

Context:
Hardware:
[GPU, VRAM, cooling notes]

Dataset:
[path, row count, provenance, privacy limits]

Current goal:
[what the first run should prove]

Task:
1. Define the smallest direct run that proves the data path and writes an exact metric count.
2. Add resource checks before model load and before each training iteration.
3. Define the fallback behavior if model load or training fails.
4. Write the verifier checks that must pass before the run can claim progress.
5. List the blockers that should be published or recorded if the real train is not complete.

Output:
- A one-command starter run.
- A metrics schema with required fields.
- A test checklist tied to the claim.
- A blocker list with owner, next action, and proof needed.

Constraints:
- Keep the first run small.
- Use exact file paths and row counts when available.
- Label any stub or fallback metric clearly.
- Do not claim model improvement without a verifier result.

Role:
You are designing a local LLM verifier loop for a single agent task.

Context:
The model runs on owned hardware. The task may touch private files, local repos, or local reports. The result is not accepted until an independent proof step passes.

Task:
Design the smallest useful verifier loop for this workflow:
[paste workflow, target files, model, and command surface]

Output:
1. Task scope: one job the local model is allowed to do.
2. Inputs: files, prompts, and commands the model can read.
3. Proof check: the command, file readback, URL fetch, or report diff that proves completion.
4. Retry rule: what to do after the first failed proof and when to stop.
5. Runtime limits: AgentGuard budget, token, rate, and retry ceilings.
6. Blocked packet: the exact note to write when the loop cannot pass.

Constraints:
- Keep the loop small enough to run today.
- Do not trust model confidence as proof.
- Prefer deterministic checks over judgment.
- Do not expose secrets or private data to hosted tools.
- End with either a passed proof or a written block.

Role:
You are giving a fast GGUF quant pick, not a lecture.

Inputs:
- GPU and VRAM: [e.g. 24GB 4090]
- Model: [e.g. 32B]
- Context length: [e.g. 8k]
- One priority: [quality / speed / fit]

Task:
1. In one line, tell me which quant to run: Q4_K_M, Q5_K_M, Q6_K, or Q8_0.
2. Give the VRAM it needs including KV cache at my context.
3. Give the one-line reason and what I trade off versus the next step up.
4. Only if it does not fit, name the fallback: smaller model or shorter context.

Constraints:
- Lead with the answer, then the numbers.
- Account for context, not just weights.
- Do not hedge across all four; pick one.

Role:
You are fixing an out-of-memory or under-offloaded llama.cpp run.

My setup:
- GPU and VRAM: [e.g. 12GB 3060]
- Model and quant: [e.g. 14B Q4_K_M]
- Context length: [e.g. 8k]
- Current command: [paste your llama.cpp flags]
- Symptom: [OOM at load / OOM mid-run / falls back to CPU / too slow]

Task:
1. Estimate VRAM used by weights, KV cache at my context, and overhead.
2. Compute the highest --n-gpu-layers that fits, with headroom.
3. If it still will not fit, rank the fixes: lower quant, shorter context, smaller model, split.
4. Give the corrected command line.
5. Tell me exactly which load-log lines confirm the fix worked.

Constraints:
- Account for KV cache growth with context length.
- Prefer a change that runs now over a hardware upgrade.
- Do not silently drop layers to CPU without telling me the speed cost.

Role:
You are tuning llama.cpp offload for a single machine.

Context:
I want to run a GGUF model with llama.cpp and set --n-gpu-layers correctly.

My setup:
- GPU and VRAM: [e.g. RTX 4090, 24GB]
- Model and quant: [e.g. Llama-3.1-70B Q4_K_M]
- Other VRAM users: [display, other models, none]

Task:
1. Estimate how much VRAM one layer of this model costs at this quant.
2. Tell me the highest --n-gpu-layers value that fits my VRAM with headroom for context.
3. Explain what -1 and 0 do here and why I would pick a specific N instead.
4. Give the exact llama.cpp command line to start with.
5. List the load-log lines I should check to confirm the offload actually happened.

Constraints:
- Leave headroom for the KV cache at my context length.
- Do not assume every layer costs the same if the model has a large embedding or output layer.
- Prefer a value that runs today over a theoretical maximum.

Role:
You are designing a local LLM inference service on consumer GPUs.

My setup:
- GPUs and VRAM: [e.g. 2x 4090]
- Model and quant: [e.g. 70B Q4_K_M]
- Target load: [e.g. 50 requests/sec, prompt and response sizes]
- Serving stack I can use: [llama.cpp, vLLM, other]

Task:
1. Say whether this hardware can hit my target load and where the ceiling is.
2. Recommend a serving stack and the key settings: batching, concurrency, context.
3. Estimate tokens/sec and requests/sec I should expect, with the limiting factor.
4. List what to change first if I need more throughput: quant, batching, a second GPU.
5. Give the metrics to watch in production and their warning thresholds.

Constraints:
- Base numbers on the specific GPU and quant above.
- Separate prompt processing from token generation limits.
- Prefer settings that hold up under concurrent load, not single-request benchmarks.

Role: platform engineer hardening an AI agent workflow.
Context: my agents log every action, but nothing verifies claimed outcomes against real state. The workflow description follows this prompt.
Task:
1. List each material outcome the workflow produces (deploys, file changes, published artifacts).
2. For each outcome, state what the action log proves and what it cannot prove.
3. Design a deterministic receipt for each gap: check type (file content, command exit code, path move), the exact check, and where the append-only record should live.
4. Name the one outcome whose false "done" would hurt most, and gate that one first.
Output: a gap table plus an ordered rollout plan for the receipt layer.
Constraints: checks must be deterministic and runnable today. No model-graded evidence.

Role: senior engineer auditing an AI agent's completion report.
Context: an agent reported finishing a task in my repository. I have the report and repo access.
Task:
1. Extract every material outcome the report asserts (files changed, configs set, tests passing).
2. For each outcome, write one falsifiable claim with a deterministic check: a file path plus regex, a command with expected exit code, or a path that must exist or be absent.
3. Flag any outcome that cannot be reduced to a deterministic check and name the evidence needed instead.
Output: a table with claim, check type, exact check, and what a failure would mean.
Constraints: no LLM-judged checks. Every check runs from the repo root and can fail.

You are helping me design owner gates and AgentGuard cost rails for an AI agent workflow.

Goal: keep the agent moving on safe mechanical work while stopping for true owner decisions and bounding spend.

Review this workflow:
[paste workflow, agent prompt, or task list]

Return:
1. Owner gates: decisions the agent must stop for.
2. Safe default actions: work the agent can do without asking.
3. Request packet: the exact fields the agent should write when blocked.
4. AgentGuard limits: budget, token, and rate ceilings for the run.
5. Proof checks: commands, files, URLs, or fields that prove completion.
6. Red lines: actions the agent must never take.

Constraints:
- Keep the policy short.
- Prefer files, commands, and runtime checks over trust.
- Do not add new tools unless the existing workflow cannot prove completion.
- Use plain language a builder can maintain later.

You are auditing the memory layer for an AI agent workflow.

Your job is to replace vague "the agent remembers" claims with durable state that a human can inspect and a script can verify.

Work in five passes:

1. List every place the agent currently stores state. Separate durable files, append-only ledgers, databases, caches, prompts, and scratch output.
2. For each surface, answer: who writes it, who reads it, what proves it is current, and what happens if two agents write at once.
3. Find any completion claim that is not backed by a file, ledger row, API readback, test result, or live URL.
4. Propose the smallest durable memory system that would survive a cold restart: plain files first, append-only events second, database rows only where they are already part of the product path.
5. Write the exact checks that should run before an agent is allowed to say "done."

Return:

- A table of current memory surfaces and their risk.
- A short list of state that should be deleted, archived, or ignored.
- The proposed durable memory contract.
- The verification commands or scripts that prove the contract.
- One example "done" claim rewritten as a falsifiable claim.

Constraints:

- Prefer files a senior engineer can open and read.
- Do not add a vector database unless the workflow has a specific retrieval failure that plain files cannot solve.
- Do not trust model output as evidence.
- Every important claim needs a deterministic readback.

Role:
You are adding spend controls to an AI agent before it runs unattended.

My setup:
- Agent and model: [e.g. Claude Code or a GPT-4-class model]
- What it does unattended: [tasks]
- Who pays and the ceiling: [e.g. 50/day hard cap]
- Current controls: [none / soft warnings]

Task:
1. List every way this agent can spend money: tokens, retries, tool calls, sub-agents.
2. Set a hard daily budget and a per-run token ceiling with specific numbers.
3. Add a retry ceiling and a rate limit so one loop cannot spiral.
4. Define the kill condition: what trips it and what happens when it does.
5. Give me the check that runs before each agent run to enforce the caps.

Constraints:
- Caps must be hard stops, not logged warnings.
- Assume the agent will hit an infinite loop at least once.
- Prefer controls outside the model that the model cannot override.

Role:
You are estimating the real cost of building and running an AI agent.

My use case:
- What the agent should do: [tasks]
- Volume: [runs per day, users]
- Build path: [DIY / contractor / platform]
- Must-haves: [integrations, uptime, compliance]

Task:
1. Place this in a tier: DIY weekend, small custom build, or enterprise rollout.
2. Break down build cost: engineering hours, tools, one-time setup.
3. Break down run cost: model tokens, infra, monitoring, maintenance per month.
4. List the hidden costs that vendor quotes usually leave out.
5. Give a low, likely, and high total, and the biggest cost driver to control.

Constraints:
- Separate one-time build from recurring run cost.
- Treat token spend as variable and show how volume moves it.
- Do not accept a single quote without a range.

Role:
You are diagnosing why llama.cpp runs on the CPU despite -ngl 99.

My setup:
- GPU, VRAM, driver: [e.g. 8GB 3070, driver 55x]
- Build: [CUDA / Metal / ROCm / CPU-only?]
- Model and quant: [e.g. 8B Q4_K_M]
- Command: [paste flags]
- What the load log shows: [paste the offload and backend lines]

Task:
1. Confirm from the log whether llama.cpp was even built with GPU support.
2. Check, in order, the five usual causes: CPU-only build, no VRAM headroom, wrong device, layer count too low, driver mismatch.
3. Tell me which cause my log points to and the one command that proves it.
4. Give the corrected build or command.
5. Show the exact log line that will confirm the GPU is now in use.

Constraints:
- Read the load log before guessing.
- Do not assume the flag is the problem; usually it is the build or VRAM.
- Give one fix at a time with a check after each.

Role:
You are choosing a GGUF quantization level for local inference.

My setup:
- GPU and VRAM: [e.g. 16GB 5070 Ti]
- Model: [e.g. Qwen2.5-32B]
- Priority: [max quality / max speed / just fit in VRAM]
- Context length I need: [e.g. 8k]

Task:
1. Estimate the on-disk and in-VRAM size of this model at Q4_K_M, Q5_K_M, Q6_K, and Q8_0.
2. Tell me which of those fit my VRAM with room for the KV cache at my context length.
3. Recommend one quant and say what I give up versus the next step up.
4. Note any case where a smaller model at higher quant beats this model at low quant.

Constraints:
- Be specific about numbers, not vibes.
- Account for context and KV cache, not just weights.
- Do not recommend a quant that will not load on my card.

Take today's private BMD HODL devlog. Redact absolute paths, secrets, private dollar amounts, and Requests/ledger paths. Keep first-person builder voice. Publish as a public daily build note with sections for what shipped, machine overnight work, and tomorrow. Link 5090 Reports.

Role:
You are helping me decide whether a paid AI tool tier is worth it.

The tool:
- Name and tiers: [e.g. Aymo free vs 39/mo]
- What the paid tier adds: [features, higher limits]

My usage:
- What I actually use it for: [tasks]
- How often: [per day or week]
- The limits I hit on free: [rate caps, missing features, none yet]

Task:
1. List which paid features map to a real limit I actually hit.
2. Estimate my monthly value from the paid tier in hours or dollars saved.
3. Compare that to the price and to one cheaper or free alternative.
4. Give a clear verdict: stay free, upgrade, or switch, with the single deciding reason.

Constraints:
- Ignore features I will not use.
- Do not accept marketing claims without a usage-based reason.
- If the data is thin, say what to measure for two weeks before deciding.

Role:
You are designing an offline voice assistant on a Raspberry Pi 5.

Constraints of my build:
- Hardware: Raspberry Pi 5 [RAM: e.g. 8GB], [mic/speaker], no cloud.
- Target: wake word to spoken reply under [e.g. 2 seconds].
- Everything runs locally, no internet calls.

Task:
1. Pick a stack for wake word, speech-to-text, the local LLM, and text-to-speech that fits a Pi 5.
2. Give a rough latency budget per stage that adds up under my target.
3. Name specific model sizes and quant levels that run on this hardware.
4. Flag the stage most likely to blow the latency budget and how to cut it.
5. List the first three things to build and test, in order.

Constraints:
- Prefer components that install and run on ARM today.
- Do not assume a GPU.
- Keep memory use inside the Pi RAM budget above.