So You Want to Use AI: The Field Manual

You're reading this because someone at work dropped "we need to use AI" in a meeting and everyone nodded like they knew what that meant. Or maybe you're the one who said it, and you're hoping nobody asks you to define it.

Either way, you're here because there's a gap between the hype and the practical. This guide is not about prompt engineering courses or AGI philosophy. It is the landscape, what things cost, how to pick a tool, and where to actually start. I use this stuff every day. I'm cheap with tokens because they're mine. This is what I would hand someone before they spend a dime.

What It Actually Is

Here's the mental model that changes everything: AI is a next-word prediction engine, not a brain. It doesn't "know" anything. It is really, really good at completing patterns.

When you ask it a question, it is not retrieving a fact from a database. It is calculating the most statistically likely sequence of words that follows your prompt. The fact that those sequences are often correct is remarkable. The fact that they are sometimes confidently wrong is inevitable.

This isn't philosophy. It changes how you prompt, how you trust the output, and how you design around it. You stop asking it "truth" questions and start asking it "plausible completion" questions. You stop treating it like an oracle and start treating it like a very fast, very confident intern who needs supervision.

Bucket Zero: The Browser Tab

Before you install anything, before you set up an API key, before you spend a dime, there is the browser tab. ChatGPT.com, Claude.ai, Gemini. Type in a box, get an answer. No files, no code, no setup.

This is how most people meet AI. And it's genuinely useful at this level for a lot of things. Draft an email. Brainstorm a name. Summarize a wall of text. Explain a concept you're struggling with. Argue with it about something. The barrier is zero and the utility is real.

The catch: You're using somebody else's interface, somebody else's model, and you get what they decide to give you. No customization. No privacy beyond their policy. No way to swap models when one isn't cutting it. You can't show it your internal documents unless you paste them in every time. The context window is whatever they set it to.

But that is fine for starting. The skill you build at this level is the one that transfers everywhere: learning how to talk to these things. How to give context. How to push back when the output is generic. How to know when it is confidently wrong. That skill doesn't change whether you're in a browser tab or hitting an API.

To get specific: the difference between a bad prompt and a good one is context, constraint, and format.

Bad: "Write an email to my team about the new process."

Good: "Write a 120-word email to my five-person sales team announcing that demo requests now go through the shared calendar link instead of email. Tone: direct, no corporate fluff. End with the one action they need to take."

The model can't read your head. Everything it needs has to be in the prompt. Bad prompts produce generic output. Good prompts produce usable output on the first try. That skill is what transfers when you move from a browser tab to something more powerful.

When this is enough: You need help with occasional tasks. You don't handle sensitive data in the chat. You want to figure out what these things can actually do before you invest in a setup.

When it's not enough: You're doing this daily. You need consistency. You want control over which model you use. You're working with anything you wouldn't post on a billboard. Any of those, and you graduate to the buckets below.

Bucket 0.5: The Subscription

Before you install a local model or wire up an API key, there is an obvious middle ground: pay a flat monthly fee for a better chat experience.

ChatGPT Plus, Claude Pro, Gemini Advanced. Same chat interface you used in Bucket Zero. Higher limits, better models, priority access. Some add features like file uploads, image generation, or voice. No thinking about tokens, no API keys, no setup.

Good for: Heavy daily chat use. Predictable billing. Anyone who doesn't want to learn what a token is but needs more than the free tier offers. This is where most people who actually use AI end up.

Bad for: Automation, scripting, anything programmatic. You're locked into one provider's interface. No model switching. No building workflows. You're paying for a better chair at the same table, not a different table.

The graduation signal: The moment you want the model inside a workflow instead of a chat window, move to Bucket 2.

The Tool Landscape

Once the browser tab stops being enough, you have three real options. Pick the one that matches your situation.

Bucket 1: Local (CLI)

Run models on your own machine. Ollama, llama.cpp. No subscription, no data leaving your network, no API calls. You download a model and run it locally.

Good for: Privacy, no recurring cost, offline use, testing, sensitive data. If you're working with anything you wouldn't post on a billboard, this is your bucket.

Bad for: Big models require hardware. You need a decent GPU to run the good ones. Smaller models run on laptops but they are, well, smaller. There's setup friction. You're installing software, pulling models, and figuring out the command line.

Real talk: You need a decent GPU or you're running small models. That is fine for learning. A 7B or 8B parameter model handles most everyday tasks. You don't need the 70B behemoth to write an email.

Bucket 2: Cloud Pay-As-You-Go

API access to models like OpenRouter, OpenAI, Anthropic, Google. You pay per token, fractions of a cent per request. No subscription, no commitment, just usage.

Good for: Access to the best models without a monthly subscription. You pick the cheapest model that does the job. Need Claude Opus level reasoning? Use it. Writing a tweet? Use a model that costs 1/100th as much.

Bad for: You can burn money fast if you're not paying attention. On heavy use it adds up quick. My monthly API spend averages about $80 across Claude, OpenAI, and OpenRouter, running agents most days. I've seen people burn that in a day by sending everything to the most expensive model.

Why I use it: When it's your money, you optimize hard. You learn really fast which models are overkill for which tasks. That optimization muscle is one of the most valuable skills you can develop.

Bucket 3: Local GUI

A nice graphical interface for running local models. LM Studio, Open WebUI, Msty, GPT4All. Less technical than the command line. You download it, pick a model, and hit run.

Good for: Testing models visually. People who want to play without touching the command line. Quick experimentation.

Bad for: Same hardware constraints as the CLI option. Less scriptable. More of a playground than a production tool.

Where to Start

CLI tools (Ollama, llama.cpp) if you're technical. GUI apps (LM Studio, Open WebUI, Msty, GPT4All) if you want a visual interface. Cloud providers (OpenRouter, OpenAI, Anthropic, Google) if you just want results and don't care about setup.

A Note on Fine-Tuning

Everyone asks about fine-tuning. 99% of the time, RAG (retrieval-augmented generation) is simpler, cheaper, and more effective. Fine-tuning is for when you need the model to learn a new skill or adopt a very specific behavior that prompting alone can't achieve. You'll know when you need it. Until then, don't.

RAG is the real superpower. Take your documents, break them into chunks, embed them into a vector database, and let the model retrieve relevant context at query time. This is how you get a model that "knows" your business without training it. And it's easier than it sounds. There are off-the-shelf tools that do the heavy lifting.

The Economics (What Nobody Tells You)

AI pricing is confusing because nobody explains the unit of measurement. So here it is:

One token is about three-quarters of a word. A paragraph is roughly 100 tokens. Shakespeare's entire Hamlet is about 40,000 tokens. A typical business email is 50 to 100 tokens. A 100-page PDF is about 30,000 to 50,000 tokens.

Input vs. output tokens are priced differently. Providers charge separately for what you send in (your prompt, documents, context) versus what the model generates (the response). Per token, input is cheaper. Per conversation, input usually dominates the bill because you send far more than you get back. This matters when deciding whether to paste the whole document or just the relevant excerpt.

Which model you use for which direction matters too. You might use a cheap model to process input (summarize, extract) and a smart model to generate the final response. Or the reverse. The point is you don't have to use the same model for both halves of the conversation. This is where the real savings live.

Why model choice matters: The most expensive model isn't always the right one. A small model can write a tweet just as well as Claude Opus. A big model is wasted on "summarize this email." The difference between the cheapest and most expensive model can be 100x per token. Pick the one that fits the job.

Cache hits are the hidden savings. If you send the same system prompt or context repeatedly (same instructions every query, same document prepended every time), many providers cache the repeated portion and charge less for it. Sometimes significantly less. Across my own usage, cache hits cut the bill by nearly half. This is why keeping a consistent system prompt matters beyond just output quality - it saves you money every time that cached context gets reused. Some providers cache automatically. Others make you mark what to cache. Check your provider's docs before you count on the savings.

The psychology of spending: When it's your money, you pick the cheapest model that works. When someone else is paying, people default to the biggest model. Be honest about which situation you're in. It changes your behavior more than you would think.

Real costs from the field:

Costs as of July 2026. These fall fast. Check the provider's pricing page before you budget.

• OpenRouter lets you shop model pricing in real time and set hard spending caps.
• OpenAI and Anthropic publish per-token rates on their pricing pages.
• A simple Q&A with a cheap model: pennies
• Processing a 100-page PDF with a smart model: under a dollar for one pass, a few dollars if you spend the afternoon interrogating it
• Running a full codebase through an agent for a day: $5 to $20
• Training or fine-tuning: don't do this yet, you don't need it

Learning and experimenting for a month: $5 to $15. Building a real workflow: $20 to $50 per month. Production deployment: depends entirely on volume, but start small.

How to Pick a Model (When There Are 200 Choices)

You don't need to know all 200. You need to know three tiers:

• Small models like Gemini 3.5 Flash, GPT-5 Mini, Claude Haiku 4.5, DeepSeek V4 Flash. Use for summarization, classification, simple Q&A, anything that doesn't need deep reasoning. These cost pennies per thousand uses.
• Mid-range (for most work): Models like Claude Sonnet 4.6, GPT-5.5, Gemini 3.1 Pro, DeepSeek V4 Pro. Handle complex reasoning, code generation, multi-step instructions. This is your daily driver.
• Heavy (when you really need it): Claude Opus 4.8, Claude Fable 5, GPT-5.5 Pro. Use for architecture decisions, detailed analysis, the task where quality matters more than cost. Use these like power tools, not everyday hammers.

Names current as of July 2026. The names rotate. The tiers do not.

Start with cheap and fast. If the output is bad, move up a tier. Most of the time, the mid-range does the job for a fraction of the heavy cost.

The Language (Terms Explained Like We're at a Bar)

Pull up a stool. I've got something in hand and the jukebox is playing something good. AI people use words that sound like jargon but are actually just precise descriptions of simple things. Here's the translation, bar edition:

• Token: The atomic unit AI thinks in. Not letters, not words. Tokens. About three-quarters of a word on average. Everything is measured in tokens.
• Context window: How much the model can "see" at once. Think of it as working memory. Small window means the model forgets what you said three paragraphs ago. Big window means more expensive but the model can handle entire documents.
• Temperature: The randomness dial. 0 means the same answer every time (good for factual things). 1 means creative (good for brainstorming). Above 1 means word salad. Don't go above 1 unless you're writing fiction.
• System prompt: The instructions you give the model before you start talking. Like telling a temp worker: here's the job, here's the rules, here's how I want you to answer. This is the most important thing you'll write.
• Hallucination: When the model is so confident about something wrong that you would bet your paycheck on it being right. It's not "lying." It's doing exactly what it was trained to do (complete a pattern). The pattern just happened to be wrong. Every model does this. The best ones do it less often, but none are immune.
• API: Application Programming Interface. The way one piece of software talks to another. When you use an AI model through a service, you're calling an API. It is just a fancy way of saying "send a request, get a response."
• RAG: Retrieval-Augmented Generation. Give the model relevant context at query time instead of training it to remember everything. The model searches your documents, finds what's relevant, and uses that to answer. It's how you get a model that "knows" your business without retraining.
• Embedding: Converting text into a numerical representation that captures meaning. Think of it as giving each piece of text coordinates in a meaning space. Similar things end up close together. This is what makes search and RAG work.
• Cache hit: When you send the same context repeatedly (like the same system prompt or document every time), the provider may charge less for the repeated part. Some cache automatically. Others make you mark what to cache. Check your provider's docs. Think of it like the bartender who remembers your usual order, but only if you showed them the bottle first.
• ZDR: Zero Data Retention. Some providers promise not to log your prompts or responses. It's better than the default, but it's still not local. Know where your privacy threshold is.

Vibe Coding and When to Use an Agent

AI coding agents are not magic. They are models that can read files, write files, and run commands. They automate the boring parts of coding. Here's how to use them without getting burned.

Good for: Boilerplate, refactoring, debugging, "write me a script that does X." Anything that is well-defined and repetitive.

Bad for: Architecture decisions, security-critical code, anything you don't understand well enough to review. If you can't review the code the AI wrote, don't ship it. Period.

Vibe Coding: Who You Plumb It To Matters

The same principle applies to coding agents. You can point Claude Code at OpenAI, Anthropic, or any OpenRouter model. You can point a local agent setup at Ollama. The tool stays the same, the engine changes. Ollama has spoken the Anthropic Messages API natively since v0.14.0 (January 2026), so Claude Code can talk to a local model with no translation layer. OpenRouter exposes the Anthropic format natively too, no proxy needed. If you're plumbing into an OpenAI-format endpoint or a self-hosted model, you'll need a gateway like LiteLLM or claude-code-router in between. A quick prototype on a cheap cloud model, a deep reasoning session on a stronger one, private code analysis on a local model. Your workflow shouldn't change, just the endpoint.

When to Go Local vs. Cloud for Coding

• Private code or personal projects: local (Ollama, Qwen)
• Complex tasks, need the best model: cloud (Claude, GPT-5.5)
• Prototyping and vibe coding: whatever is cheapest that gets the job done

The Rewrite Trap

AI loves to rewrite everything. Every session, it wants to restructure your whole project. Don't let it. The goal is not "perfect code." It's your code that works. If you let AI rewrite your project every time you open it, you never build momentum. You end up with a cleaner codebase and zero shipping. Prefer small, targeted changes. Add one feature. Fix one bug. Ship it. Repeat.

GitHub Is Non-Negotiable

AI writes code fast. You need version control to track what changed, revert when it breaks, and iterate without fear. AI doesn't replace good engineering practices. It amplifies the need for them. If you're not using source control, start before you touch AI.

Test-First Workflow

When I write code with AI, I have it write the tests first. Then I pipe in fake data to verify UI interactions and system integration. The AI generates the scaffolding; I verify the behavior. Slow iteration, one change at a time.

Markdown as the Universal Bridge

Here's a pattern nobody talks about: Claude, Gemini, ChatGPT. They can all read and write Markdown files. If you structure your project around Markdown docs (specs, prompts, notes, task lists), you can switch tools freely. Write a spec in Markdown. Feed it to Claude for code. Feed the same spec to Gemini for a different angle. Keep your context in a file, not in a chat window. The tools come and go, but the docs stay.

The Unix Philosophy for AI

One tool, one job. Don't look for the AI that does everything. Use Claude for deep-dive tasks, Gemini for broad research, a local model for private work. Pipe the results between them. Just like grep | sort | uniq. Each tool does one thing well, and you chain them. Watch people who are good at this. Steal their patterns. The AI community shares workflows openly. You don't need to invent everything from scratch.

Your First Real Project

Don't start with "revolutionize my business." Start with something boring. The best first project is the one that saves you 15 minutes a week.

Good First Projects

• Summarize your emails every morning. One prompt, model picks the important ones.
• Write a script that formats a CSV the way you need it. Saves 20 minutes a week.
• Build a chatbot that knows your company's FAQ. Simple RAG, copy-paste your docs in.
• Draft replies to common customer questions. Template generation, not autonomous.

Bad First Projects

• Replace your customer support team. You're not ready.
• Build an autonomous agent that runs your business. Nobody is ready.
• Anything involving fine-tuning. You don't need this yet.

When Not to Use AI

Some things are better done by hand. A shell script you understand beats an AI-generated one you don't. A manual process that works beats an automated one that hallucinates 5% of the time. Learning to recognize when the tool is the wrong tool is as important as learning which AI to use.

How to Not Get Burned

AI is useful. It's also a minefield if you're not paying attention. Here are the traps I've seen people walk into.

• Privacy: Assume anything you send to a cloud model is visible to someone. If it's sensitive, run it locally. OpenRouter offers zero-data-retention (ZDR) endpoints. They don't log your prompts or responses. I use them. I still don't love sending my data to someone else's server. Trust is earned in degrees, not absolutes. ZDR is better than nothing, but local is better than ZDR. Know where your threshold is.
• Hallucinations: Every model hallucinates. The best ones hallucinate less. Always verify anything that matters. Always. The model will sound confident even when it's making things up. That confidence is not a signal of correctness.
• Vendor lock-in: Don't build your whole workflow around one model provider. Aggregators like OpenRouter help by letting you switch models without changing your code. Same logic applies to local tools: if you build around Ollama's API format today, the skills transfer if you switch to something else tomorrow. Design your systems to be model-agnostic from day one.
• Account balances and auto-top-up: This is the one nobody warns you about. You set a $20 budget on a provider's billing page and think you're safe. The API keeps running. The provider processes billing in batches. You wake up to a $50 charge because the "stop at $20" alert was an email that arrived three hours late. This is exactly why I use aggregators with hard spending limits and billing failure alerts rather than wiring a credit card to a single provider. If the payment fails, the requests stop. That's a feature, not a bug. Whatever provider you choose, understand their billing model before you set up the auto-top-up. Treat anything over your limit as a surprise you don't want.
• The hype filter: If someone says "AI can do X perfectly," they're selling something. If they say "AI can help with X but you need to check its work," they're being honest. The difference is usually obvious once you know to look for it.
• Prompt injection: An agent that reads files and web pages can be steered by instructions hidden inside them. Do not wire an agent to your inbox, your customer data, or production systems until you understand this. The agent does what the text tells it, and not all the text is yours.

The Advanced Path: Open Source and Self-Training

Everything above covers how to use AI. But there is another layer if you want to go deeper.

Open source models are the floor, not the ceiling. And the floor keeps rising. Llama, Qwen, Mistral, DeepSeek. These models are freely available, you can run them anywhere, and they're catching up to the closed-source leaders fast. The ecosystem around them (Hugging Face, Ollama library, OpenRouter) means you can experiment without asking permission.

Self-training on your own machine: Training a model on your own data is no longer a hyperscaler-only game. Tools like Hugging Face's TRL, Axolotl, and Unsloth make it possible to fine-tune or even train small models on consumer hardware. I've been doing this on a Mac Studio. It's real, it works, and the barrier keeps dropping.

Why you'd do this: Off-the-shelf models are generalists. If you need a model that speaks your company's internal language, or writes in a very specific style, or knows your codebase's conventions, training a model (even a small one) can beat any general-purpose API.

The honest caveat: This is not a weekend project. But knowing it exists changes how you think about the landscape. The API-based approach is the on-ramp. Owning your model is the destination, if you need it.

If You're Rolling This Out to a Team

The guide so far addresses one person making their own choices. If you're the one who has to figure this out for an organization, the calculus changes.

Start with a pilot, not a mandate. Pick two or three people who are already curious. Let them run an experiment for two weeks. Measure what changes. A mandate before you know what works guarantees expensive chaos.

Write a one-page data policy. What can go into which tools. What cannot. Where customer data lives. The policy doesn't need to be perfect, it needs to exist so nobody says "nobody told me."

Assume shadow AI is already happening. Your staff is already pasting company data into free chat tools. They have been for months. A policy that pretends otherwise just makes people hide it better. Acknowledge it, set boundaries, and give them a better option.

Measure one workflow before scaling. Don't ask "where can AI help us?" That's too vague. Pick one specific workflow your team hates, automate part of it, and measure the time saved. That number is what you use to justify the next one.

The Challenge

This whole guide is meant to get you past the paralysis of "there are too many options." So here's a self-assessment.

If you're in Bucket 0 (browser tabs only): Spend a week using a chat interface for one task a day. Draft a message. Summarize an article. Ask it to teach you something. The goal isn't productivity, it's building the skill of talking to these things.

If you're comfortable with that, wade into Bucket 1 or 2: Install something local or get a pay-as-you-go account. Pick one boring task this week and automate it with the cheapest model that works. See what happens.

If you're already in the tool landscape: Look at what you're sending to the most expensive model and ask if a cheaper one could handle it. The savings are probably hiding in plain sight.

You don't need a strategy. You need one workflow that saves you 15 minutes a day. The next level is just doing that again.

The goal isn't to replace yourself. It's to free yourself up for the work that actually needs a human.