All Things AI · Season 2 · The Models · Episode 1
Grok is the one to reach for when you need a lot of output quickly from material you already have. It is fast, it handles a large amount of context at once, and it is cheap enough to run in batches, which matters more than it sounds once you are producing at volume.
What it is
A large general-purpose model from xAI, accessible through a chat interface and through a programming interface for anyone building something on top of it.
It sits in the same broad category as the other major services: you give it text, it gives you text back, and it is capable across writing, analysis, summarising, and reasoning. The interesting question is never whether a model can do a task. It is what it is comparatively good at, and where it earns its place next to the others.
What it is comparatively good at
Three things, and the third is the one that changes how you work rather than just how fast you work.
Speed
It returns quickly, and the difference is noticeable rather than marginal when you are doing something twenty times. A model that takes half as long changes a task from a session into a break, and that changes how often you are willing to do it.
Holding a lot at once
It works comfortably with a large amount of material in a single request, which means you can give it a great deal of context rather than summarising first. Summarising before you ask is where accuracy quietly leaks out of the whole process.
Cost at volume
Per unit of output it is inexpensive relative to the largest models, which makes running something across fifty items a reasonable thing to do rather than a decision you have to justify. Batch work is where this becomes the obvious choice.
Where it is weaker
It is not the model to reach for on the hardest reasoning, where the largest and most expensive options still have an edge. If a task genuinely requires careful multi-step thinking with high stakes attached, that is not where the cheapest fast option belongs.
It is also a hosted service, which means anything you send it leaves your machine. For client documents, that alone decides the question, and the local options exist for exactly this reason.
And like every model, it will produce a confident answer when it does not know something. Speed makes this slightly more dangerous rather than less, because fast wrong answers arrive before you have thought about whether to trust them.
What it is genuinely useful for as an agent
The pattern is high volume, low individual stakes, and material you are supplying.
- Drafting many pieces at once from notes you already have, where the register matters more than any individual sentence.
- First-pass processing of a lot of items, where you will review the output anyway.
- Anything you want to try several ways to see which approach works, because cheap and fast means you can afford to run it four times.
- Working through a large body of text in one request rather than chopping it into pieces.
The workflow it fits into
The reason this model became a default for a lot of production work is not that it is the best model at anything in particular. It is that it is fast and cheap enough to change the shape of the work.
A long careful session with the most capable available model produces one excellent thing and takes an afternoon. That is the right approach for something that genuinely warrants it, and it is the wrong approach for the thirty ordinary things that also need doing.
Running the ordinary thirty through something fast, then spending your attention on correcting rather than producing, gets more done at a higher average standard than doing four of them beautifully and leaving twenty-six undone.
How you get started
Nothing unusual. There is a chat interface for ordinary use and an interface for anything you build, and the second is where the batch work happens.
- Use the chat version for a week on real work before deciding anything about it.
- Give it more context than feels necessary. This is where it is strong and most people underuse it.
- For anything repetitive, move to the programming interface, because that is where the batch economics actually apply.
- Keep client documents out of it and run those locally instead.
Where this goes wrong
Three failures.
Using it for the hardest thing on your list because it is the one you have open. Match the model to the task rather than to habit, which is the entire argument for knowing what each one is for.
Sending it material that should not leave your machine. Fast and cheap is not a reason to relax about where a client file goes, and the local options handle document work well.
Trusting output that arrived quickly. There is a genuine psychological effect here where speed reads as confidence. The review standard should not move because the answer came back sooner.
How it sits next to the others
Against the largest paid services it trades some capability on the hardest problems for speed and cost, which is a good trade for most of what an agent does and a bad one for the small number of things that genuinely need the best available reasoning.
Against the open models you run yourself it trades privacy and permanence for capability and convenience. It is more capable than what runs on your laptop, and it is a service that can change.
The sensible position is not loyalty to one. It is knowing that the fast hosted one handles volume, the local one handles anything private, and the most capable one is reserved for the small number of things that warrant it.
What to try in the first week
Three exercises, chosen because each one demonstrates something the model is specifically good at rather than something any model can do.
Take the largest pile of text you have that relates to one thing and put all of it in a single request, then ask a question that requires having read all of it. Do not summarise first. The point is to feel the difference between a model you have to prepare material for and one you can simply hand everything to.
Take a task you would normally do once and do it eight ways. Eight different angles on the same piece, eight different openings, eight versions aimed at different people. On an expensive slow model this is not a reasonable thing to do. Here it costs almost nothing, and comparing eight attempts teaches you more about what you actually wanted than a single careful attempt does.
Then take something you would genuinely have spent an hour on and give it four minutes of this instead, and compare honestly. Sometimes the hour was necessary. Frequently it was not, and knowing which is which is the actual skill.
A note on how quickly this changes
Everything in this episode is about the shape of the model rather than a specific version, deliberately, because specific comparisons go stale within months.
What is stable is the category: there will always be a fast, capable, inexpensive option, and it will always be the right choice for volume work. Which product occupies that position changes, and the workflow you build around it does not have to.
That is the useful way to hold all of this. Build around what a model is for, not around which one is currently winning, and switching costs you an afternoon rather than a rebuild.
What it costs
A subscription for the chat interface in the usual range, and usage-based pricing for anything you build on top of it, which is where it is notably inexpensive. For batch work the cost per item is small enough that the constraint becomes your review time rather than the bill.
Questions agents actually type
What is Grok good for in real estate?
High-volume drafting and first-pass processing from material you already have, where speed and cost matter more than winning the hardest reasoning problem. It handles a large amount of context in one request, so you can give it everything rather than summarising first.
Is Grok better than ChatGPT or Claude for agents?
Not better, different. It trades some capability on the hardest problems for speed and low cost, which is the right trade for volume work and the wrong one for a small number of high-stakes tasks. Matching the model to the job beats picking a favourite.
Can I use Grok with client documents?
It is a hosted service, so anything you send leaves your machine. For client documents the better answer is an open model running locally, which handles reading and extraction well and keeps the file where it is.
Why would I use a cheaper model instead of the best one?
Because cost and speed change what work is worth doing at all. One excellent output produced over an afternoon leaves the other twenty-six tasks undone, and a fast pass on all of them plus your review time produces more at a higher average standard.
Season 1 is Claude Code for Real Estate Agents, filmed and on its own hub. All three seasons: AI for real estate agents.