Common questions

Picture a stand-in handed the whole email thread before every reply, and allowed to read only the last twenty pages. Nothing is remembered here. The thread is re-read from scratch each turn, and whatever stops fitting drops off the top — so the earliest instructions die first, which is exactly where people put the important ones. Two cheap fixes: restate the constraint at the moment it matters, and carry a five-line recap forward yourself — goal, decisions, constraints, current draft, next step.

By default each conversation starts blank — that is the design, not a fault. Memory features exist, vary by product and plan, and usually store a summary rather than the transcript. Assume nothing carries over unless you can point at the setting that carries it.

Put them where they get re-read, not where they were said once. Anything mentioned only at the start competes with everything since. Restating the constraint at the point of work, or keeping it in a standing file the tool reads each time, beats trusting a message from an hour ago.

When what you want has changed — not when the chat got long. A thread carries every rejected idea, and those keep pulling the answers backwards. Planning and doing are the classic split: decide in one place, carry the decision out, execute somewhere clean.

A chat is not a document the model owns. Each turn, the visible history is re-sent, and only what fits inside that limit gets read. Long fiction outgrows that limit fastest because prose is dense. Keep a running summary of characters and plot, and paste the summary forward yourself.

There is no memory. The transcript is re-sent as fresh input every time, so what looks like recall is just re-reading. That explains the failure too: once the transcript outgrows that limit, the earliest part is dropped before the model ever sees the question.

Two different mechanisms get confused. Ordinary chats begin blank, remembering nothing. Some products add a separate saved-notes feature that carries facts across sessions, and it can be viewed and edited. Recall across sessions is a feature that is switched on, not something the model does naturally.

Nothing was deleted. Yesterday's summary sat near the top of the transcript, and the transcript is re-read whole each turn. As today's talk grew, the top scrolled past the reach and fell off. The oldest material always goes first, which is exactly where yesterday lived.

The signal is not an error message. Watch for the model losing early instructions, contradicting facts set at the start, or repeating questions already answered. Bad answers early in a fresh chat are a prompting problem. The same faults deep in a huge thread are usually a length problem.

There is no transfer button, and none is needed. Ask the first assistant for a handover note: the goal, the decisions made, the constraints, the current draft. Paste that into the second. History is only text being re-sent, so a good summary carries as much weight as the full transcript.

Ask for the source, then open it. A fabricated citation collapses the second it is clicked, which makes clicking the cheapest test anyone owns. Run three checks in order: open one link and read the paragraph it points at; ask the same question in a clean chat and see whether the answer survives; hand the claim to one person who does know. Where nothing can be opened, treat the answer as a draft to verify, never a fact to repeat. Practice: take an answer you accepted last week and click every source in it.

Confidence is a property of the writing, not of the knowledge. It produces the most plausible continuation, and a plausible sentence and a true one look identical on the page. Fluency is what makes the error dangerous — a hesitant wrong answer would be easier to catch.

Anything narrow, recent or countable: a specific citation, a current price, somebody's exact job title, a figure from last quarter. Broad explanation is where it is strongest. The rule of thumb — the more precise the fact, the more it needs checking.

Only if the links get opened. A citation is a claim about a source, not proof of one, and the sentence beside it may not be what the source actually says. A citation sitting beside a sentence is not support. Two minutes of clicking separates the two.

Confidence is not a signal, because the model writes fluently whether or not it knows. Check the parts that can be checked: names, dates, figures, quotes, citations. Those are where invention shows. Smooth reasoning around a false name still fails, so test the anchors rather than the prose.

A language model predicts likely next words, not verified statements. Nothing inside it separates remembering from inventing, so a plausible-sounding gap gets filled the same way a known fact does. Saying nothing is not the default behaviour. Asking directly whether the model is certain does not repair the mechanism.

Not by tone, which is identical in both cases. Advice that reflects a real practice usually names something outside the chat: a standard, a document, a common method you can look up. Invention stays vague and self-contained. Ask what the claim rests on, then go look at that thing.

The frame is wrong. On an opinion question there is nothing to be false about, so the model is not hallucinating - it is generating a reasonable-sounding position with no stake in it. Treat the output as one argument to react against, not as a recommendation from someone who cares.

Trust the wrong unit and the answer is no. Trust it as a drafter, summariser and explainer, with a human checking anything that leaves the building, and the answer is yes. The unreliability is real and stable, so build the check into the workflow instead of hoping for a better week.

Anything where a wrong answer costs more than checking would. Live prices, current law, medical dosing, whether a person exists, what happened last week. A model has no access to the present point and no way to know a gap in its own knowledge. Use search for those.

Start with what this is not: not a forum post, not a public page. Closer to emailing a document to a supplier — one company holds it, under a contract. The real question is retention: whether your text is kept and used to train the model, and the answer differs between a personal account and a company one. Go and look before you paste — settings, then data controls, on whichever tool you use. Read what it says rather than what you assume. The setting takes two minutes; undoing a paste takes a lawyer.

Other users cannot see your chat. What people mean by stolen is usually training — the fear that your work resurfaces inside someone else's answer. Business terms generally exclude that; consumer terms may not. It is a contract question rather than a technology one, which is why the terms are the answer.

The fear imagines a library another user can search. Models do not retrieve stored chats for strangers on request. The realer exposure is mundane: your draft sitting in an account with a weak password, or a colleague reading over a shared login. Guard the account, not the plot.

Rarely a hacker. Usually a contract. Many client agreements forbid sending their material to any third party, and an AI vendor is a third party regardless of how safe it is. The breach is of the promise you made, discovered later, and safety settings do not cure it.

The connection is not the risk people picture. It reads your mail because you told it to, and it reads whatever is in there, including things you forgot were in there. Old password resets, contracts, medical notes. Ask what a decade of inbox contains before granting the key.

No, and the two are separate things. Opting out of training stops your text improving the model. Deletion is a retention period, often weeks, because copies are kept briefly for abuse review. Both matter, they are different switches, and only one is about permanence.

Paying buys speed and capacity, not automatically privacy. The protection people want comes from business and enterprise terms, which are a different product from a personal upgrade. Check whether your plan says your data trains the model. A card on file does not answer that.

Count the re-reading, not the messages. Every turn re-sends the whole conversation, so a long thread costs more each time you speak, and an attached file is re-read on every single turn rather than once at upload. One short chat carrying a forty-page PDF can outspend fifty ordinary ones. Two habits fix most of it: start a fresh chat when the subject changes, and paste the five paragraphs you actually need instead of the whole document. Watch your own limit for one week and you will see where it was going.

Free is enough to learn what it is. It is not enough to learn what it does. The free tier tends to run out at exactly the point where the work gets interesting — the long document, the real task. Learn on free, and pay when the ceiling starts interrupting work you care about.

A coding assistant does not read your question alone. It reads the files it needs to answer, and a codebase is enormous compared to a chat message. Each search, each file opened, each retry adds to the same bill. Pointing it at one file instead of a whole repository is the real saving.

No fixed number exists to memorise. Free capacity flexes with how busy the service is and how heavy each conversation runs, so the same account gets different mileage on different days. The reliable lever is conversation weight: short threads, small attachments, fresh starts. Treat the limit as weather, not a wall.

Occasional light use is exactly the case where a free tier holds. Paid plans buy headroom, not intelligence - longer documents, fewer interruptions, steadier access at busy hours. The question to answer first is whether hitting a limit mid-task actually costs you anything. If nothing breaks, wait.

Aggregators sell the model list, but daily work happens in the surrounding features - memory, file handling, project folders, the mobile app that actually syncs. Those live with the original provider and rarely travel. Buy an aggregator to compare models. Buy direct to build a habit.

Cost tracks how much the assistant has to read, not how much it writes. Narrow the scope: name the files, close finished conversations, stop attaching whole folders when one function is the problem. A clear instruction beats three vague attempts, and three attempts cost triple.

The limit is usually about total material held open, not the count of files. So splitting a document into more pieces does not help. Extract the pages that matter, convert images of text into text, and start a new conversation once a document is finished with.

There is deliberate randomness in how the next word gets chosen, so identical input does not guarantee identical output. That is a feature when writing and a nuisance when checking facts. If two answers disagree on something that matters, the disagreement is worth chasing.

Look at what the request left out. “Write a product description” names a task, not the product, not the buyer, not the objection, not where the words will sit — and a generic request has exactly one honest answer. Put back four things: who it is for, what it must do, one thing to avoid, one example you already like. Run the same job twice, the bare line then the four, and keep both outputs side by side. That comparison teaches more about asking than any guide, because the difference is yours and you can see it.

The tricks dated fast; the habits did not. Give context, hand over material, say what finished looks like, check what comes back. That is most of it. Anyone selling a list of secret phrases is selling last year's workaround for a limitation that has since been fixed.

Specific to you is not specific on the page. The model cannot see your industry, your reader, or last quarter's numbers unless the words are there. Most requests that feel detailed are missing the audience and the material. Paste the actual thing you are working from, and the reply narrows immediately.

Do not rewrite from scratch. Tell it what is wrong with the reply it just gave, in the same thread. The wrong assumption is that prompting is one shot at a vending machine. It is a conversation, and correction is cheaper than reinvention.

Stop tuning wording and start reusing structure. Once a request works, save it and swap the contents next time. The gains people chase through clever phrasing mostly come from consistent context: same role, same reader, same standard. Keep a short file of the requests that worked.

Pick one recurring task, not a tool tour. Something you do weekly and dislike - meeting notes into actions, drafts into plain language. Run it there until the output beats doing it by hand. Random questions produce random value, and that is why the habit never forms.

A system prompt is a job description, not a spell. Say who the assistant is speaking to, what it must never do, what format the answer takes, and where it should ask instead of guess. Long lists of adjectives like expert and world-class change very little.

Two questions, and they get collapsed into one. Detection is unreliable in both directions — it clears real machine text and accuses real people. Whether it is permitted is a rule someone has written down, or has not. Go and find the rule. Do not calibrate to the odds of being caught.

Assume a policy is coming, and behave now as you would want to be judged later. No client data pasted without checking, your name on the output, and the ability to explain any line you handed over. People rarely get into trouble for using it. They get into trouble for hiding it.

Firing is rarely the first step, and treating the rule as a tripwire misreads why the rule exists. Most policies exist to protect client data and legal exposure, not to punish curiosity. What matters is what left the building. Someone who pasted a customer contract sits in a different place from someone who fixed grammar.

Recruiters are not running scanners; they notice the letter says nothing about the company. Generic praise, tidy rhythm, no specific detail. The fix is not disguise but substance. Bring the real reason you want the job and the tool becomes a helper for phrasing rather than a source of content.

Plagiarism means presenting someone else's work as your own without credit. Most institutions treat undisclosed AI use as a separate offence with its own name and its own penalty. So the question is not whether it matches plagiarism, but what your department's written policy says about disclosure.

Detectors guess, and they guess badly in both directions. Teachers who catch it usually do so another way: the essay does not sound like your earlier work, or it cites sources that do not exist. Voice mismatch across a term is far more convincing than any percentage score.

Copyright in many countries needs a human author, so purely machine-written lines may hold no protection for anyone rather than belonging to the AI company. Your own edits, structure and selection are yours. The practical risk is not ownership but licence contamination if the output resembles copied training material.

With one task you already do and dislike. Not a course, not a tour of the features. The people who get somewhere start from work they own, because they can tell whether the output is any good — and that judgement is the part no tool supplies.

No, and the premise deserves questioning. What is scarce is not tool familiarity — it is knowing what a good result looks like in a real job, which takes years to acquire. That judgement is what makes the tool worth anything. It is the part you already have.

A first real win takes about an hour. Comfort takes a few weeks of ordinary use. What takes longer is the judgement of when not to use it, and that only arrives from being wrong a few times and noticing that you were.

The confusion is that learning AI means learning to build AI. For almost everyone it means learning to use it well, which is a writing and judgement skill, not an engineering one. Open a chat tool and bring real work to it. The building side is a separate career, and you can ignore it.

Age is not the obstacle. Having no task is. The people who stall are the ones practising on toy prompts with nothing at stake. Pick the dullest recurring part of your week, do it with the tool badly for a fortnight, and skill arrives as a side effect of finishing real work.

Yes, and the wrong assumption is that a course would fill a gap in knowledge. The gap is in reps. A course gives structure, which helps some people finish, but nothing in it is unavailable to someone who works with the tool daily and pays attention to what fails.

Skip the feature tour. Bring one document you already know well and ask for something you could grade yourself - a summary, a critique, a rewrite for a named reader. Judging the output teaches faster than any lesson, because you can see exactly where it went wrong.

The trap is collecting material instead of building habits. One tool, one real task, used every working day for a month beats twenty hours of video. Return to explanations only when something specific breaks. Curiosity aimed at a stuck problem sticks; curiosity aimed at a playlist does not.

Three ways into the same thing, built for different jobs. Chat is for thinking with it. The coding tool sits on your machine and works on your real files. The API is for wiring it into something that runs without you. Most people need the first two.

No, and the name puts off the people who would gain most. It works on files — renaming hundreds of them, reading a folder of PDFs, turning a spreadsheet into a report. If your work lives in folders rather than in a chat box, that is the more useful one.

When something has to run without a person present. A subscription covers you sitting there working. A key covers a program doing it on a schedule, with its own billing and its own limits. If nobody is watching the screen, that is the line.

The wall is the terminal, not the coding. Claude Code writes the code; you describe the outcome in ordinary language. What stops most non-coders is not knowing how to open a command line or move between folders. Learn those two things and the rest is conversation.

Chat sees only what gets pasted in. Claude Code sees a folder on your machine, and can open, edit and create files there. The difference is not intelligence but reach. Same model, standing inside your work instead of outside asking to be handed things.

The API is not a better chat. It exists so software can call the model without a human typing, which is what makes scheduled and repeated jobs possible. If nothing is being built or automated, the subscription is the right tool and the API adds only complexity.

Anything that is repetitive and lives in files: renaming, reformatting, pulling numbers out of many spreadsheets, turning notes into a structured document. The wrong assumption is that automation means software. Mostly it means describing a boring chore precisely enough that a machine can repeat it.

Yes, and the shape matters more than the amount. A subscription is a flat fee with a ceiling on use. An API key bills per unit of text processed, with no ceiling unless you set one. Set a spending cap the day you create the key.

Rarely the model. It is that code and files leaving a laptop touches security review, and that giving a tool write access to real repositories needs someone accountable for what it changes. The blockers are approval and audit, not capability. Expect procurement conversations, not technical ones.

Less than the internet suggests. They differ at the edges — tone, file handling, behaviour over long documents — and those differences move every few months. Fluency in one transfers almost entirely to the others. Pick one, get good, stay curious rather than loyal.

Rarely at the start. Two subscriptions usually buy two shallow habits instead of one deep one. The case for a second appears when you can name the specific thing the first does badly — and until you can name it, the money is buying reassurance.

Most comparisons are a snapshot of one week, written to be published. Test on your own work instead: same real task, same material, both tools, one afternoon. Your task is the only benchmark that reflects what you consider a good answer.

The difference people report is tone and stamina on long text, not capability. Both draft, edit, summarise and answer questions at a similar standard. Judge them on your own real document, side by side, once. That test takes an afternoon and beats every comparison article, because it uses your work.

It matters slightly more, because coding rewards long context and careful instruction-following, and models differ there. But the wrong assumption is that the model does the work. The programmer who reads the output, tests it, and rejects the bad parts outperforms the one on the fashionable model.

The prompt matters more, by a wide margin. A named audience, a stated job and a sample of your own past writing will change the draft far beyond any gap between the two tools. Blandness comes from thin instructions, not from picking the wrong brand.

Ask a different question first: does the tool have the book, or only its memory of the book? A summary written from training data drifts and invents. Upload the actual file, or paste the actual chapters. Then the models perform close enough that source access decides quality.

Barely. Benchmarks measure exam-style tasks under lab conditions, and the leaderboard reorders with every release. Nobody's job is on the benchmark. The useful test is your three most common tasks, run in each tool, judged by whether the output needed less fixing.

One tool, learned properly, beats three tools sampled. Switching costs are real: different habits, different file handling, different settings to check. Standardise so people can help each other, and let one curious person track the alternatives. Fluency compounds; browsing does not.

An upload is a photocopy: it sees that version, once. A connection is a key: it can look at the live thing whenever it needs to. The photocopy is safer and simpler. The key is what makes it useful daily. Start with photocopies and earn your way to keys.

With a connection it can read, search and change what you point it at — and only what you point it at. It does not wander. The limit worth knowing is that it cannot open what you cannot find yourself, which is why getting your own folders in order comes first.

The common mistake is ranking them. They answer different questions. A project holds context you reuse. A skill packages instructions you repeat. MCP reaches outside the chat. A subagent hands off work so one thread stays clean. Pick by the problem in front of you, not by which sounds most advanced.

The setup names one folder, not the whole machine. Point it at a working directory holding copies, never at your home folder or anything under version control you care about. Read access first, editing later. The safety comes from the boundary you draw, not from the tool being careful on your behalf.

For repeated work, yes; for one document, rarely. Copy and paste stays faster when the answer is needed once. The integration earns itself when the same files are revisited daily and manual pasting becomes the bottleneck. Convenience is the point, not capability - a pasted draft gets read exactly as well.

The failure was not autonomy, it was scope. An account with full access to mail, drive and calendar lets one loose instruction touch everything. Create a separate account holding only what the task needs. Agents do not know which actions are irreversible, so the account must not be able to take them.

The file staying local is a comfortable illusion. Whatever the model reads is sent to the model to be read, so the contents travel either way. The real difference is scope and permanence: an upload ends, a connection keeps looking. Choose it for convenience, and treat confidentiality exactly as strictly.

Because training teaches the tool, and people need a task. Nobody returns to their desk thinking "now I will apply feature four" — they think about the report due Friday. The rollouts that land start from one job everybody already hates, and teach the tool inside it.

Say the quiet thing first. Half the room is doing arithmetic about their own job, and no productivity slide competes with that. Name what changes, name what does not, and let them shape how it is used. Fear that goes unspoken does not fade — it goes underground and becomes non-adoption.

Regular use does not come from training; it comes from a task that repeats. A weekly report, a recurring email, a standing summary. Attach the tool to something already on the calendar and use follows the calendar. Teach features in isolation and the tool becomes something people once attended a session about.

Start with the work, not the software. Pick one task the team dislikes and does often, do it together with the tool in the room, then let people finish it themselves. Curriculum comes later. A first session that produces one finished piece of real work beats a full overview nobody applies.

Fear is usually specific, not general. Someone worries about being replaced, someone about being blamed for a mistake, someone about looking slow. Ask which one it is. Then give a task where being wrong costs nothing - a rough draft, a summary of something already read - and let the fear meet reality.

The blocker is rarely willingness. It is not knowing what to type, and not wanting to look foolish trying in front of colleagues. Willingness was never the missing part. Share actual prompts that worked on actual company work, and the blank box stops being the obstacle.

The common mistake is writing a policy about the technology. Write it about the material instead: which kinds of information may leave the building, which may not, and who to ask when unsure. Name the approved tools. Say what must be disclosed. Everything else ages badly.

Technical skill is the wrong qualification. The person needs credibility with the team and daily contact with the actual work, because the job is spotting which tasks are worth automating. That is domain knowledge. Someone respected in the department will move a rollout further than an expert imported from outside it.