Guides

You write a vague prompt ("do me an analysis of X") and it hands back something generic that you end up rewriting anyway.

Give the model: (1) a concrete role/context, (2) the exact output format you want, (3) 1–2 examples of what to do and what not to do. All three models respond better to structured instructions than to loose prose.

Instead of "summarize this contract": "You're a lawyer reviewing this lease agreement. Give me a list of at most 5 risky clauses, each on one line: [clause] — [why it's risky] — [what to ask for instead]."

You have access to several models and don't know which one to use for what — you end up always using the same one out of habit, not by judgment.

Ask yourself three things in order: (1) Is the data sensitive? → if yes, local first. (2) Is the task long-format/agentic code? → Claude Opus/GPT-5.3-Codex. (3) Do you need huge context (long documents)? → Gemini. Everything else (chat, summaries, short tasks) → the cheapest local model that handles it well.

Reviewing a contract with a client's personal data: local model (never leaves your server). Large refactor of a repo: Claude Opus or GPT-5.3-Codex-Max. Summarizing a 300-page report: Gemini for the context window.

You want to try a local model but you don't know what hardware you need or where to start.

For Qwen3.6 27B (dense, the sweet spot right now): at minimum a 16-24GB VRAM GPU at Q4. Install llama.cpp or Ollama, download the quantized GGUF (Q4_K_M is the standard quality/size balance), run the local server, and point any OpenAI-compatible client at `http://127.0.0.1:8080/v1`.

`ollama pull qwen3.6:27b` → `ollama run qwen3.6:27b "explain what RAG is in 3 lines"`. First output in minutes, not hours.

Both are chat gateways (WhatsApp/Telegram/etc.) to AI agents — which one do you pick and why?

The real question isn't 'which is better' but 'where do you want the model to live'. OpenClaw is open-source but BYO-API-key — by default your messages go through a third party's cloud (Claude/GPT/Gemini) even if the gateway runs on your machine. Imaginclaw runs on local models (Hera) by default, cloud only as an explicit fallback.

If it matters to you that no message leaves your infrastructure (legal, health, client data): Imaginclaw or an OpenClaw configured exclusively with local Ollama. If you want frontier capability without running your own infrastructure: OpenClaw with Claude/GPT API.

It's not obvious when the difference between 'local' and 'cloud' is just a technical preference and when it's a real risk decision.

Ask yourself: if this conversation leaked tomorrow, who would it hurt? Third parties' personal data (clients, patients, employees), trade secrets, or anything with a legal obligation of confidentiality → local is the right answer, not a preference. For everything else, the cloud is simpler and usually enough.

A law firm processing client case files: local, no debate (and in Colombia, with real implications under Law 1581 of 2012 on data protection). Writing a draft blog post: either one works.

Every new release says 'outperforms X on benchmarks' — and almost never is that information useful for deciding whether it's worth it for you.

Ignore the vendor's benchmark. Build 5-10 REAL tasks from your own work (not generic ones), run them against the current model and the new one, and compare them blind. If you don't see a real difference on your tasks, don't migrate just for the benchmark number.

Before migrating from one model to another for contract review: take 10 contracts already reviewed by a human, run both models, count how many real errors (not style ones) each one makes.

AI jargon is full of terms that sound important but that nobody explains to you in a useful sentence.

20 terms, one line each: **Token** — the smallest unit of text a model processes (not exactly a word). **Context** — how much text the model can "see" at once. **Quantization (Q4/Q8)** — compressing a model so it uses less VRAM, with a small loss in quality. **VRAM** — the GPU's memory, the real bottleneck for running local models. **MoE (Mixture of Experts)** — a large model that only activates part of itself per token (faster than a dense model of the same total size). **Fine-tuning** — retraining a model with your own data. **RAG** — looking up real information before answering, instead of trusting what the model "remembers". **Agent** — a model that can use tools (search, run code, browse) in a loop, not just answer with text. **Hallucination** — the model invents a fact with total confidence. **Temperature** — how much randomness the response has (0 = deterministic, higher = more varied). **System prompt** — the invisible instruction that sets the model's behavior before your message. **Context window** — the total token limit (your prompt + the response) the model can handle in a turn. **Embedding** — turning text into numbers so it can be compared by similarity. **Zero-shot / few-shot** — asking for a task with no examples vs. with 1–2 examples in the prompt. **Open-weight** — the model's weights are downloadable (doesn't mean it's lightweight or easy to run). **API** — how your code talks to a model running on another server. **Latency** — how long it takes to respond. **Throughput** — how many requests it can handle in parallel. **Prompt injection** — an attack where malicious text inside the content the model processes makes it deviate from its instructions. **Guardrail** — a rule external to the model that blocks or corrects its output.

This model has 262K of context — it can see ~200,000 words in one sitting, not that it's "smarter."

The model "forgets" something you told it earlier in the same conversation, or cuts your response off mid-sentence.

Everything that goes in and out of a model is measured in tokens (approx. ¾ of a word in Spanish/English). The context window is a TOTAL shared limit across your prompt + the history + the response — they are not separate quotas. As you get close to the limit, the model starts losing detail on what came earlier.

A model with 128K of context and a conversation with 100K tokens of history only has 28K free for your next message + the response — if you ask for a long document there, it will cut it off or over-summarize it.

You want the model to "know" something specific about your business and it's not obvious which of the three techniques to use.

**Prompting** (put the info directly in the prompt) — for small data that changes often, with no infrastructure. **RAG** (search and retrieve relevant info before answering) — for large knowledge bases that change frequently (documents, policies, catalogs). **Fine-tuning** (retrain the model) — only when you need to change the model's STYLE/behavior, not to add data — it's more expensive and not the right way to "teach it facts".

A bot that answers about 500 products in a catalog that changes every week: RAG, not fine-tuning. A bot that must always respond in a specific legal tone regardless of the topic: there fine-tuning does make sense.

All three are "open-weight" but have completely different hardware requirements — the label does not tell you whether you can run them yourself.

Qwen3.6 27B dense: runs on 1-2 consumer GPUs (16-24GB VRAM at Q4) — the only one of the three truly accessible for individual self-hosting today. Kimi K3 (2.8T params) and DeepSeek V4 (up to 1.6T): open weights, but datacenter scale — hundreds of GB of VRAM even quantized, designed to be served via a provider's API or a private cluster, not on your desktop.

If you have 1-2 GPUs and want to run something NOW: Qwen3.6 27B. If you want maximum open-weight capability and don't mind paying a provider to host it: Kimi K3 or DeepSeek V4 via API.