Choosing Your AI Stack — Chat, Vision, Reasoning and Local Models

The market presents these as a ladder — cheap, better, best, and then a private option for the paranoid. That framing is wrong and it is the source of the mismatch. They are not rungs. They are different instruments, and the expensive one is genuinely worse than the cheap one at several jobs you will do every week.

The distinction that matters is what each type is doing to your input. A chat model takes text and returns transformed text: extracted, restructured, compared, drafted. A vision model takes pixels and returns a description of what is in them. A reasoning model takes a problem that has intermediate steps and works through them before answering, at the cost of time and money. A local model is any of the above, running on your machine instead of somebody else's server, which changes nothing about capability and everything about confidentiality.

Notice that only one of those four differences is about intelligence. The other three are about input type, working style and where the data physically goes. Those are the axes you should be choosing on, and the reason people choose badly is that the marketing is all on the intelligence axis.

Read the table below by its last column first. That column is the one that will actually change how you work, because it names the specific way each type quietly costs you when it is the wrong pick.

A general chat model is where roughly nine out of ten research jobs belong, and it earns that position by being good at exactly one thing: transforming text that is already in front of it. Paste a section of a filing and ask for the seven items on your extraction checklist with a page reference on each. Paste two quarters of your own notes and ask for the differences. Paste a concall transcript and ask which analyst questions were answered without a figure. All of these work well, quickly and cheaply.

They work because nothing is being recalled. The material is in the prompt, the job is rearrangement, and rearrangement is what the underlying machinery does. That is also why the quality drops off a cliff the moment you step outside the supplied text — and the drop is silent. Ask what a company announced last week without pasting the announcement and you will get a fluent answer in the same register as the correct ones.

The specific waste with a chat model is therefore not slowness or cost. It is verification time spent on answers that had no source in the first place. You ask a convenient question, get a paragraph, and then spend twenty minutes trying to confirm something the model constructed from the general shape of how companies announce things. That twenty minutes was avoidable at the moment you typed the question.

The second waste is images. A pure text model cannot see, and if you describe a chart to it in words you are just getting your own description reflected back with more adjectives. If the material is a picture — a scanned page from an older annual report, a screenshot of a table, a chart — this is not the tool, and no amount of prompting changes that.

A vision model takes an image as input. In Indian market work that matters more than it first sounds, because a large amount of what you need to read is not text at all. Older annual reports on exchange websites are frequently scans. Investor presentations put their most useful numbers inside charts. Regulatory circulars circulate as photographed pages. A screenshot of a broker statement, a table you can see but not select — all of this is image work, and a text model is blind to every bit of it.

What a vision model does well is transcription and description of what is visibly there. Give it a screenshot of a segment-revenue table and ask for it back as rows and columns, and that is a real, checkable job — you can look at the picture and confirm every cell. Give it a scanned page and ask what the text says. Give it a chart and ask what is labelled on the axes, what the last plotted value appears to be, and whether the series is rising or falling. Each of those is a claim about the image that you can verify by looking at the image.

The waste begins the moment you ask it to judge. Upload a chart of an NSE stock and ask whether the pattern is a breakout, whether the setup looks good, or where it goes from here, and you will get an answer with levels and conditions in it. That answer is generated from the visual shape plus the enormous quantity of market commentary in its training. It is not analysis of the instrument, it has no volume context, no idea what the index did that session, and no knowledge of the company. It is chart-shaped prose.

This is the single most common expensive mismatch in the whole module, because the output is so persuasive. Keep the boundary mechanical: ask a vision model only questions whose answer you could confirm by pointing at part of the picture. What is the axis label. What does this cell read. Is the last bar higher than the previous one. The moment the answer requires something outside the frame — volume, context, the future — you have left what the tool does.

A reasoning model is one that works a problem through in explicit intermediate steps before it answers, rather than producing the reply in one pass. It generally takes longer and costs more per question. Both of those costs are worth paying when the problem genuinely has steps, and are pure waste when it does not.

The jobs it earns its keep on are the ones where the answer depends on a chain rather than a lookup. Working out what a conditional clause in a scheme document actually implies once three other clauses are applied. Reconciling why a figure in an investor presentation differs from the filed statement, when the difference comes from basis, comparative period and an adjustment stacked together. Checking whether a set of screening rules you have written contradict each other. Tracing a logical error in a backtest specification. In each case the value is that you can read the intermediate steps and find the exact point where it went wrong.

The waste is everything else, and everything else is most of your week. Pulling a stated revenue figure off a page has no steps in it. Extracting seven checklist items has no steps in it. Restructuring notes into a table has no steps in it. Routed to a reasoning model, those jobs come back later, cost more, and are no more accurate — because the accuracy was never limited by reasoning. It was limited by whether the number was in the text you pasted.

There is a subtler waste too. A model that shows working invites you to grade the working, and a well-constructed chain of steps is persuasive in a way a bare answer is not. Plausible reasoning towards a wrong conclusion is harder to reject than a bare wrong answer, because you have just watched it be built. The visible steps are a debugging aid, not evidence. Verification still happens against the source document, exactly as it does everywhere else.

A local model runs on hardware you own. Nothing you type crosses a network, nothing sits in somebody else's log, and nothing is subject to another company's retention policy. That is the entire proposition, and for one category of work it is the only thing that matters.

That category is anything whose disclosure would be a genuine problem: your live positions and sizing, client information if you handle any, unpublished research, and internal notes. This is a real constraint in Indian market work rather than a theoretical one. A SEBI Registered Research Analyst has confidentiality obligations to clients and rules around unpublished research; a screenshot of a client portfolio pasted into a hosted chat box is a compliance question, not a preference. The separate article on data privacy in this module covers what must never enter a prompt at all — some of it should not go into a local model either.

Set against that, be honest about the trade. A model you can run on a personal machine is typically smaller than what a hosted service runs on server hardware, and smaller shows up specifically in long-document synthesis: holding a hundred pages coherently, tracking a subtle inconsistency across widely separated sections, producing genuinely tight prose. For short, structured, well-specified jobs the gap is often small enough not to matter. For heavy reading it is not.

The waste with a local model is therefore twofold. Setup and maintenance time is real and recurring, and it is wasted if you then use it for public documents that carry no confidentiality question at all — an exchange filing anyone can download does not need to be processed privately. And on the other side, forcing a long, demanding synthesis job through a smaller local model produces thinner output that you then treat as though it came from the stronger tool.

The practical resolution is a split rather than a choice. Public documents go to whichever hosted model suits the job. Anything private stays local. The routing rule is not about the task at all — it is about the data, and it should be decided before you open anything.

You do not need a decision tree with twelve branches. Three questions in a fixed order resolve nearly every real task, and they are in this order deliberately, because privacy overrides convenience and input type overrides everything else about the task.

Ask them before you open a tool rather than after you have started typing into whichever one is already on screen. That is where most misrouting happens — not through a considered wrong choice, but through no choice being made at all.

The result is usually a very small stack. Most working researchers need one general chat model for the bulk of the reading, occasional access to a vision model for scans and slide tables, a reasoning model kept for the handful of genuinely multi-step problems, and a local model for anything private. That is a routing habit, not a subscription list.

It is worth stating plainly what changing model type does not buy you, because a lot of money is spent discovering this individually. None of these four types has a live market data feed. None of them knows what NSE or BSE did today unless you paste it in. None can tell you where a stock or the index trades tomorrow, and none has any mechanism by which it could. Upgrading from a chat model to a reasoning model does not move that boundary by a millimetre; it just means the answer you cannot use arrives more slowly and with visible working attached.

None of them has an internal measure of its own confidence either. That is a property of how these systems produce text, not a limitation of a particular tier, so a wrong figure from the most capable model available arrives in exactly the same assured tone as a correct one. The article on hallucination and the audit trail in this module deals with what to do about that, and the answer is procedural rather than technological.

What changing type genuinely buys you is narrow and worth having: the ability to read an image, the ability to work a multi-step problem where you can inspect the steps, and the ability to keep confidential material off somebody else's servers. Three real capabilities. None of them is prediction, and none of them removes a single verification step.

One last practical note, since this is a page that will still be here in two years. Model names, pricing, context limits and which type can do what are all moving quickly, and several of the boundaries described here are already blurring as tools combine capabilities. Check the current documentation of whatever you use before assuming a limit. The routing logic — private first, image second, steps third, otherwise the default — outlasts the products, because it is about the job and not about the tool.