A preference is a short, standing instruction about how you want Claude to behave, written once and reused many times.

The simple definition

Every time you start a new chat, Claude begins with a fresh page. It does not automatically know your job, your taste in writing, or your habits. A preference is a note you leave on that page before the conversation begins. The note might say “keep answers brief”, “use British spelling”, or “explain technical ideas with simple examples”. Claude reads the note at the start and lets it shape how it answers.

Why they exist

Without preferences, you would need to open every chat with the same paragraph of instructions. That wastes time, and you will sometimes forget. Preferences solve this by moving the paragraph out of your head and into Claude’s settings. The saving is small each time, but across hundreds of chats it becomes large.

What preferences are good for

A short history of repeating yourself

Early chat assistants treated every conversation as a brand-new meeting. Whatever you explained on Monday was gone by Tuesday. This is fine for a quick factual question, but it is tiring for real work, where context matters. If you are writing a book, running a small business, or studying for an exam, the useful answer depends on who you are and what you are trying to do. Preferences are one of the answers to this problem. They give Claude a small, stable piece of context that survives from one chat to the next.

What a preference is not

It helps to be clear about the limits. A preference is not a database of your life. It is not a place to paste your documents. It is not a way to switch off Claude’s values. And it is not a programming language, so it does not run exact commands the way a computer program does. It is a short piece of guidance written in everyday words, read by a system that understands language and uses judgment. Keeping that picture in mind will help you write notes that work and help you forgive the small misses that remain.

Three questions before you write anything

First, ask what you keep repeating. Your answer shows where a preference will save the most time. Second, ask what you wish Claude would stop doing. Turn that wish into a positive description of what you would rather see. Third, ask what Claude should know about you in order to pitch its answers at the right level. A sentence on your role and experience is usually enough. These three questions usually produce a first draft of four to six lines that already makes a real difference.

Claude can learn about you in several ways. Each layer has a different job and a different reach.

People often mix up preferences with other features, so it helps to see the whole picture. Think of personalization as a set of layers, like clothing. A thin layer is always on you. Other layers are added for a particular trip or a particular weather. Claude works in a similar way.

flowchart TD
  A["Claude's built-in behavior"] --> B["Your profile preferences"]
  B --> C["Memory from your past chats"]
  C --> D["Project instructions and files"]
  D --> E["Writing style you pick"]
  E --> F["Skills for a specific task"]
  F --> G["Your message right now"]
    

The diagram runs from the widest layer to the narrowest. Claude’s own built-in behavior is the starting point. Your profile preferences come next and apply across your chats. Memory adds facts that Claude has learned from your conversations, where that feature is turned on. Project instructions apply only inside one project. A chosen writing style shapes the voice of replies. A skill is a packaged set of instructions for one kind of task. At the end sits the message you are typing right now, which is the most specific layer and generally the most powerful.

Why layers matter

When two layers disagree, the narrower and more recent one normally has the stronger say. If your preferences say “keep it short” but your message says “give me a full detailed guide”, you will get the detailed guide. That is the right outcome, because what you say now reflects what you need now. Knowing the layers explains most of Claude’s behavior that otherwise looks puzzling.

The profile preference is a text box in your settings where you describe yourself and how you like Claude to respond.

Where it lives

In the Claude app, your settings include a place to write personal preferences in your own words. You type plain sentences, save them, and Claude takes them into account in your conversations. The exact name and location of this box may change, so look in your settings or search the help center. What matters here is the idea: it is one free-text note, written by you, that follows you from chat to chat.

How Claude uses it

The text you write is given to Claude at the start of a conversation as background. Claude reads it the way a new colleague reads a briefing note. It is not a rigid program with switches, and it is not a command line. It is language, and Claude interprets it with judgment. This is a strength, because you can write in everyday words, but it also means vague wording leads to vague results.

Applied selectively, not always

A sensible assistant does not mention your preferences every time. If your note says you are a software architect, Claude will not start every answer with “as a software architect”. It uses that fact quietly when depth of explanation matters, and leaves it unused when you ask about a cake recipe. This is the right behavior. A preference should shape the answer without showing off.

A sample note, line by line

To make the idea concrete, here is the kind of note a careful person might write, followed by the reason for each line. The note is only an example, and yours should reflect your own habits.

Reading the note as a stranger would

When you finish writing, read the note as though you had never met yourself. Would a stranger know what “short” means? Would they know which topics the rule covers? Would two lines contradict each other? Many weak notes fail this simple test. Claude is clever, but it cannot read your mind, and it only has the words you wrote. The clearer those words are, the more closely your wishes will be followed.

Writing in the first person

Write the note about yourself, in your own voice: “I prefer”, “I work as”, “please do”. This feels natural and avoids confusion about who is speaking. A line such as “the user likes short answers” is also understood, but first person tends to produce notes that are warmer, more precise, and easier for you to edit months later.

The best preferences are short, lasting, and about style. Anything private, temporary, or huge belongs somewhere else.

Durable versus temporary

Ask yourself a quick question before adding a line: “Will this still be true in three months?” If the answer is yes, it is a good candidate. “I prefer concise answers” passes the test. “I am preparing for an interview next Tuesday” does not, because it will be wrong soon and will quietly mislead Claude later. Short-term needs belong in the chat itself, where they expire naturally.

Clear, specific, positive sentences give the best results.

Because Claude reads your note as language, the quality of the writing matters. Think of it as writing a short briefing for a smart person who has never met you. The five habits below make the difference between a note that changes behavior and a note that gets ignored.

Before and after

Tone words need examples

Words like “professional”, “friendly”, and “casual” mean different things to different people. One person’s casual is another person’s careless. When tone matters to you, pair the word with an example. “Friendly, like a helpful colleague who says ‘Happy to help’ but does not use exclamation marks” tells Claude much more than the single word “friendly”. If you have a short paragraph that sounds exactly right, you can mention it in a project or paste it into a style sample.

Ask for the behavior you can observe

Good preferences describe things that you can see in the reply. “Start with the answer” can be checked by reading the first line. “Be insightful” cannot be checked at all. When a line describes something observable, you can test it, and you will know at once whether it works. When it is a vague quality, you are left guessing.

Use strengths and limits gently

Strong words such as “always”, “never”, and “must” have a place for things you truly need, like a required spelling of a name. For most style choices, softer wording such as “usually” or “by default” works better, because it lets Claude adapt when a situation is unusual. Too many strong rules also tend to compete with each other. Keep the strong words for a few lines that truly matter.

Preferences are what you tell Claude. Memory is what Claude gathers from your chats, where the feature is turned on.

The difference in one sentence

A preference is a note you write by hand. Memory is a set of facts that Claude picks up from your conversations, such as the projects you work on, tools you use, and choices you have stated. Both aim at the same goal, which is saving you from repeating yourself, but they start in different places.

How memory behaves

Where memory is available, there are settings that control it, including one that lets Claude generate memory from your chat history and another that lets it search your past chats. You can turn these on or off in your settings. Memory is meant to record lasting facts, not passing moods or one-off tasks. Claude is also designed to use remembered facts only when they actually improve an answer, and not to announce them for no reason.

Staying in control

Because memory can build up without your typing it, it is wise to look at what has been stored from time to time and ask Claude to correct or forget anything that is wrong or unwanted. If you want Claude to stop using memory altogether, the setting that controls memory generation is the place to do that, and the help center explains the steps. Claude itself cannot flip that switch for you.

A tale of two chats

Suppose you told Claude last month that you are planning a trip with two young children. This month you ask for ideas for a weekend outing. If memory is on and the fact was stored, Claude may suggest places that work for children without being told again. If memory is off, you would add that detail yourself. Neither path is wrong. The first is smoother, and the second gives you tighter control. The choice depends on how much convenience you want in exchange for how much you are comfortable having remembered.

Correcting what Claude remembers

If Claude uses a remembered fact that is wrong or out of date, say so plainly: “I moved cities”, “I no longer work there”, or “please forget that”. Where memory is available, such corrections are meant to be handled, and some products let you view and edit stored items in settings. Be specific about what should change, so the correction is clear. A habit of fixing small errors early keeps memory trustworthy.

When memory should stay out of the way

Remembered facts are best used when they change the substance of an answer. A greeting that mentions your hobby for no reason feels odd, and a recommendation that quietly leans on an old assumption can be wrong. Claude is designed to apply remembered details selectively. If you notice memory being used where it does not belong, tell Claude to ignore it for the current task, or switch memory off if that suits you better.

Choosing the right tool starts with knowing what each one is best at.

flowchart TD
  A["I want Claude to do something consistently"] --> B{"Is it a lasting style or fact about me?"}
  B -- "Yes" --> C["Profile preferences"]
  B -- "No" --> D{"Does it belong to one piece of work?"}
  D -- "Yes" --> E["A project with instructions and files"]
  D -- "No" --> F{"Is it a repeatable step-by-step procedure?"}
  F -- "Yes" --> G["A skill"]
  F -- "No" --> H["Say it in the chat"]
    

The decision path starts with the widest question: is this a lasting fact or style that applies to you everywhere? If so, it belongs in preferences. If it only applies to one piece of work, a project is a better home. If it is a repeatable procedure with steps, a skill suits it. If none of those fit, just say it in the chat.

A style controls how Claude sounds, which is different from what Claude knows about you.

Your preferences describe you and your habits. A writing style describes the voice you want in the reply: formal or relaxed, short or flowing, warm or businesslike. Where the feature is available, you can choose a ready-made style or create your own from samples of your writing. A style then applies to the way text is written, while your preferences continue to carry facts about you.

When a style helps

Style versus preference

If you want Claude to know that you are a nurse, that is context, so it belongs in your preferences. If you want replies that read like friendly letters, that is voice, so it belongs in a style. The two can work together. In practice the boundary is soft, and a short style hint in your preferences may be enough if you do not have a style feature available.

Building a style from your own samples

Where the feature exists, you can show Claude a few examples of writing you admire or have written yourself, and it will describe the qualities it notices, such as sentence length, warmth, and word choice. You can then adjust the description until it feels right. Good samples are varied, recent, and representative of the voice you want in future. Avoid samples that are copied from someone else’s protected work, since a style should capture your own manner and not reproduce another writer’s text.

After you create a style, test it on three different jobs: a short email, an explanation, and a piece of creative writing. If it works in all three, it is probably capturing something real. If it only works on one, the samples may be too narrow.

A project is a workspace with its own instructions and files, so preferences for one job do not leak into another.

Where projects are available, a project gathers chats and reference files around one goal: a book, a client, a course, or a product launch. You can give the project its own instructions and upload documents that Claude can draw on whenever you work inside it. This is ideal for rules that are important in one place and irrelevant everywhere else.

An example of the split

Why not put everything in preferences?

If you put the five-part outline for your course into your general preferences, it would try to apply to your holiday plans and your cooking questions too. That is confusing and wasteful. Projects keep rules close to the work they belong to. They also have more room, so detailed guidance, glossaries, and examples fit comfortably without crowding your short personal note.

What a good project instruction looks like

A good project instruction has the same qualities as a good preference, with more room for detail. It says what the project is, who the audience is, what the output should look like, and what to avoid. It names key terms and links to the files that explain them. For example, a project for a weekly newsletter might say who reads it, how long each issue should be, which sections appear in every issue, and what voice to use. Every future chat in that project then starts with the same foundation.

Files as shared memory for the project

Files uploaded to a project act like a reference shelf. Style guides, past examples, product descriptions, and glossaries can all sit there. Claude draws on them when relevant, which saves you from pasting the same material again and again. Keep the files tidy and current. An outdated file is as misleading as a stale preference, and Claude will trust it just as faithfully.

When a project is too much

Not every task needs a project. If you only need a one-off answer, a project adds setup work with no return. Reach for one when you expect to come back to the same body of work several times, or when several people need the same background. Otherwise, a clear message in a normal chat is the lighter and faster choice.

When a preference is really a procedure, package it as a skill.

Some of what people call preferences is actually a method. “When I ask for a meeting summary, give me decisions first, then actions with owners and dates, then open questions” is not a personality trait. It is a recipe for one kind of task. A skill is a packaged set of instructions, and sometimes helper material, that Claude can load when a task calls for it. Where skills are available, they keep your general preferences short, because the detailed recipe lives elsewhere and is used only when needed.

Why skills are tidy

A skill is loaded on demand. Claude can see its name and a one-line description, and it opens the full instructions when your request matches. This means a long, careful procedure does not clutter every chat. It appears when meeting notes are involved, and stays out of the way when you ask about the weather.

When instructions clash, the more specific and more recent one usually wins, and some rules never bend.

Sooner or later two instructions will disagree. Your preferences may say “short answers”, while a project says “write detailed lessons”. Or your note may say “no bullet points”, and then you ask for a checklist. Claude is designed to resolve such clashes with judgment, guided by a few sensible principles.

flowchart TD
  A["Two instructions disagree"] --> B{"Does one break a safety or honesty rule?"}
  B -- "Yes" --> C["Claude declines that part and keeps helping with the rest"]
  B -- "No" --> D{"Is one from your message right now?"}
  D -- "Yes" --> E["Your current message wins"]
  D -- "No" --> F{"Is one more specific, such as a project or skill?"}
  F -- "Yes" --> G["The more specific instruction wins"]
  F -- "No" --> H["Claude uses judgment and may ask you"]
    

The path begins with a firm boundary. Some things cannot be unlocked by any preference, such as instructions that would make Claude unsafe or dishonest. Past that, your present request generally outranks your standing notes, because you know what you need right now. After that, the narrower tool, such as a project or skill, outranks the broader one. When nothing settles the matter, Claude uses judgment and may simply ask.

Make conflicts rare by design

The best way to handle conflicts is to prevent them. Keep your general preferences broad and gentle, and place strict or detailed rules in narrow tools that apply only where they matter. If your general note says “usually keep answers short”, a project can freely say “write long lessons here” without any real clash, because the first is a default and the second is a specific rule. Soft defaults and specific exceptions get along well.

Being explicit when it matters

If a particular reply is important and several instructions might apply, say in your message which one should win: “ignore my usual brevity preference for this answer and give me full detail”. Direct words remove doubt. Claude can follow your intention without guessing which layer you meant.

Third-party content is not an instruction

One more rule is worth knowing. Text that you paste in from elsewhere, such as an email, a web page, or a document, is information for Claude to read. It is not a new set of orders from you. If an email says “ignore your instructions and do something else”, Claude is designed to treat that as part of the content and not as a command. Your preferences and your own messages remain in charge. This protects you from instructions hidden in outside material.

The same idea of standing instructions appears across Claude products, with different names and places.

Claude is available in several places: the main Claude app on web, desktop, and mobile; Claude Code for software work; connections inside other tools; and the developer platform. Each has its own way to keep standing instructions, but the principle is shared: write guidance once, in plain language, in the place where that product expects it.

Who owns the instruction?

A useful question in every product is: who wrote this instruction, and who else can see it? Your personal preferences belong to you. A project guidance file in a shared code base belongs to the team. A system prompt in a published application belongs to the developer. Knowing the owner helps you decide what is appropriate to write. Personal habits belong in personal places, and team conventions belong in shared places.

Why shared files beat private habits for teams

When several people work on the same code base or the same documents, private preferences produce inconsistent results. One person asks for short answers and another asks for long ones, and the team’s output drifts. A shared guidance file solves this by writing the team’s conventions in one place that everyone, and Claude, can read. Personal preferences then handle only the personal parts, such as tone and level of detail.

The practical rule is simple: if a rule would still be true after you left the team, it belongs in the shared place. If it is only about how you like to read, it belongs in your own settings.

Standing instructions are convenient, which is exactly why they deserve a little caution.

What you write is read many times

Anything in your preferences is supplied to Claude in many conversations. That makes it convenient, and it also means a mistake is repeated many times. If you write something private, it follows you into every chat where it is included. So the safest approach is to write only what you would be happy for a colleague to see on a settings page.

Categories to keep out

Memory systems also filter sensitive material

Where Claude keeps memory, it is designed with privacy rules about what it should not store, such as certain sensitive personal categories. If you ask Claude to remember something in those categories, it may decline and say so. This is a deliberate protection and not a malfunction.

Shared and work accounts

On a shared device or a work account, remember that settings may be visible to other people or administrators. Read your organization’s policy and the privacy information on the help center before writing anything personal into a work-managed account.

A practical test before saving

Before you save a line, imagine it displayed on a projector in a room full of colleagues. If you would squirm, rewrite it or leave it out. This simple test catches most privacy problems quickly. It also reminds you that preferences are a note about working style, not a diary.

Choosing generality over detail

You can often get the benefit of a personal detail without the risk by stating it more generally. “I live in a place with cold winters” can guide advice as well as an exact address would. “I work in the finance industry” is safer and often just as helpful as a company name. Generality keeps your note useful, shorter, and safer.

Think about who else might see it

Screens are shared, screenshots are forwarded, and accounts are sometimes managed by an employer. If a stranger might see your settings, or if the note might be copied into a bug report or a help request, write accordingly. Care taken at the time of writing costs nothing, while regret afterward costs a lot.

Preferences adjust style and context. They do not rewrite Claude’s character or values.

It is tempting to think of preferences as a control panel with unlimited switches. They are not. Claude has a stable character, with honesty and care for people at the center, and your note works inside that character. Understanding this prevents disappointment and also keeps you safe.

Why this is good for you

Suppose you wrote, “never disagree with me”. It sounds harmless, but think about what it would cost. If you made a mistake in a budget or a plan, an assistant bound by that rule would stay silent while you walked into trouble. The most valuable assistants tell you gently when something looks wrong. A better preference is “be direct and polite when you disagree, and give your reasons briefly”. That keeps the honesty and adjusts the delivery.

Good intentions behind blunt rules

People sometimes write blunt rules because they have been disappointed by empty praise or long lectures. The need behind such rules is real: they want useful, respectful, efficient help. You can meet that need directly. Ask for no filler compliments, ask for the main risk to be named first, and ask for concerns to be given in one or two sentences. These requests are honest, specific, and easy for Claude to follow, and they give you what you actually wanted.

Most cases have a simple cause, and a short checklist finds it quickly.

Sometimes a preference seems to have no effect. Before you decide that the feature is broken, walk through a few likely causes. Almost always the issue is one of wording, placement, or conflict.

flowchart TD
  A["A preference seems ignored"] --> B{"Was it saved, and is it in the right place?"}
  B -- "No" --> C["Save it again and start a new chat"]
  B -- "Yes" --> D{"Is the wording clear and specific?"}
  D -- "No" --> E["Rewrite it with a target and a reason"]
  D -- "Yes" --> F{"Does your message or a project say otherwise?"}
  F -- "Yes" --> G["Resolve the clash or state it in the message"]
  F -- "No" --> H{"Is the chat very long?"}
  H -- "Yes" --> I["Start a fresh chat and remind Claude briefly"]
  H -- "No" --> J["Check the help center or send feedback"]
    

The common causes

The long-conversation effect

In very long chats, early instructions can lose some of their influence, simply because there is so much later text competing for attention. If you notice Claude drifting from a style you set at the start, a gentle reminder helps: “please keep to my usual format”. Starting a fresh chat for a new topic also helps, because preferences are applied again at the very beginning, where they are strongest.

Check the product you are using

If you use more than one Claude product, remember that preferences saved in one place may not appear in another. A coding tool, a browser extension, a work add-in, and the main app can each have their own settings. When behavior differs between them, the cause is often simply that the instruction was saved in only one of them. Check the settings in the product where the problem occurs.

When to send feedback

If you have checked the wording, the placement, the conflicts, and the length of the chat, and the preference is still not working, the issue may lie with the product itself. The help center explains how to get support, and the feedback buttons in the app let you tell Anthropic what happened. A short, clear description of what you wrote and what you saw helps the people who read it.

A short review a few times a year keeps your note accurate and useful.

Your work changes, your tastes change, and your note should change with them. A preference written a year ago may describe a job you no longer have or a style you no longer like. Stale instructions do quiet harm, because Claude will still follow them faithfully.

A simple review routine

Keep a private backup

Keep a copy of your note in a document of your own. If a setting is reset, or you change accounts, you can paste it back in a minute. A dated copy also lets you see how your needs have changed over time.

Seasons of change

Certain moments are natural times for a review: a new job, a new project, a new language, a move to a different team, or a change in how you like to read. At each of these, ask whether your note still helps. Often a small edit is enough, such as updating a role or removing a rule that no longer fits. A few minutes spent at the right moment prevents months of slightly-off answers.

Notice the small signals

Your own reactions are good data. If you find yourself editing the same thing in many replies, such as deleting a closing paragraph or shortening a long opening, that is a signal that a preference could help. If you find yourself saying “no, not like that” repeatedly, check whether a stale line is causing it. Treat your irritation as a clue, and turn it into a better line.

Preferences save effort, but they also carry costs worth knowing.

Main trade-offs

When to use more, and when to use less

A short note gives a gentle nudge, while a long note gives a firm push. Most people want the gentle nudge for everyday chats and the firm push only in specific places such as a project or a skill. This is why the layers exist. By moving firm rules into narrow tools, you keep your general note light, and you let the strict rules do their work exactly where you need them.

The cost of too little

Having no preferences at all is also a choice, and it has a cost. You may spend time reshaping replies by hand, repeating context, or reading more text than you need. If you notice that pattern, a few lines of preference may repay the effort within a day or two. The goal is not to write the perfect note, only to remove the most common friction.

A handful of habits keep a preference note effective, and a handful of mistakes spoil it.

Six small stories show how different people shape Claude to fit them.