Claude Certification Guides
CCAO-F/Domain 79 min read

Lesson 7.2

Refusals, Limits and Long Conversations

Why Claude sometimes declines, how to respond legitimately, how usage and conversation limits behave, and how to keep long pieces of work productive.

Three kinds of interruption frustrate business users: Claude declines a request, a usage limit stops you mid-task, or a long conversation starts behaving oddly or hits its length limit. None of these is a malfunction. Each has a cause and a right response, and the exam expects you to know both. It also expects you to recognise the wrong responses: trying to trick Claude past a refusal, or using a second account to dodge limits.

Refusals

Claude declines when a request appears to fall into a prohibited or high-risk area of the Usage Policy, when it lacks the context to tell a legitimate purpose from a harmful one, or occasionally when it misreads a benign request. Refusals vary from a full decline to a partial answer with caveats, or a request for clarification.

When the refusal is a misread, the fix is context, not pressure. Explain who you are, what the output is for, and why it is legitimate.

I am the compliance officer for a retail bank. I need a plain-English
explanation of the common signs of invoice fraud so I can train our
accounts payable team to spot them. This is for defensive training;
please include the warning signs and the controls that catch them.

That framing usually unlocks a careful, useful answer, where "explain how invoice fraud works" alone might not.

When the refusal is correct, accept it. Attempts to disguise the request, split it into innocent-looking parts, role-play around it or insist that "it's just hypothetical" are attempts to circumvent safety features, which the Usage Policy prohibits and which can lead to account action. If a legitimate task keeps being declined after honest reframing, the task may need a different tool, a human specialist, or a conversation with your organisation about whether it should be done at all.

Partial refusals (Claude answers but omits a step or adds caveats) are often appropriate, particularly in high-risk domains.

Usage limits

Consumer plans meter usage in rolling windows, with higher tiers also carrying weekly ceilings. What counts is work, not messages: long conversations, big attachments, Opus-tier models, extended thinking and agentic tasks consume more. When you reach a limit, the app tells you when it resets. Nothing is lost; your conversation remains and you can continue after the reset.

Managing limits well:

  • Start a fresh chat for each new topic; every message in a long chat re-reads everything before it.
  • Use Sonnet or Haiku for routine work and reserve Opus for the steps that need it.
  • Turn extended thinking off for simple tasks.
  • Attach only the pages or sheets you need rather than whole archives.
  • If limits bind regularly, that is a signal to move up a plan tier, not to open a second account; account sharing and multiple accounts to evade limits breach the terms.

Business plans have their own allowance model with administrator visibility. Current figures are at support.claude.com. Separately, when the service itself is under heavy load, you may see capacity messages; those are not your limit, and the status page shows whether there is a wider issue.

Long conversations and the context window

Every conversation lives inside the model's context window. As the conversation grows (your messages, Claude's replies, attachments), two things happen. Responses get slower and consume more allowance, and eventually the app warns that the conversation is approaching its length limit. Well before that, quality can degrade through drift, because Claude is weighing a long history of instructions, some obsolete.

Habits for long work:

  1. Work in chapters. When you finish a phase, ask Claude for a handover summary: decisions made, current state, open items, the rules in force. Start a new chat and paste it in.
  2. Use a Project. Put the standing material in knowledge and instructions so each chat starts light and the context is spent on the task.
  3. Keep attachments lean. Extract the relevant section rather than attaching the full document repeatedly.
  4. Restate the rules when you notice drift, or move to a fresh chat.
  5. Save outputs externally. Artifacts, generated files and Project knowledge persist; a conversation that hits its limit should not be the only copy of anything.

Other limits worth knowing

File size and count limits per conversation; Project knowledge capacity (with retrieval mode extending it); Artifact publishing restrictions on some business plans; connector action confirmations. All are documented in the help centre and change over time; the exam tests that you know they exist and where to look, not the numbers.

Scenario: the all-day analysis

An analyst spends a morning in one conversation analysing a survey, hits a usage limit at midday, and after the reset notices answers have become muddled. Diagnosis: a very long thread consuming allowance quickly and drifting. Fix: ask for a handover summary, open a Project with the survey file and the agreed analysis plan as knowledge, start a fresh chat for each section of the report, and use Sonnet for the routine tabulations with Opus reserved for the final interpretation.

Exam focus

  • Refusals come from policy boundaries, missing context or misreads; respond with honest context and purpose, never with circumvention.
  • Repeated declines after honest reframing mean the task, not the phrasing, needs reconsidering.
  • Usage limits meter work done (length, attachments, model tier, thinking, agentic tasks) in rolling windows; fresh chats and lighter models conserve allowance; multiple accounts to evade limits breach the terms.
  • Long conversations slow down, cost more and drift; work in chapters with handover summaries, use Projects, and keep attachments lean.
  • Capacity messages and status-page incidents are service conditions, not personal limits; specific limits live at support.claude.com.

Check yourself

5 questions

  1. 1.Claude declines a request that the user considers perfectly legitimate. What is the most likely explanation and sensible first response?

  2. 2.A security awareness trainer asks Claude to 'write a phishing email' and is declined. What is the best way to proceed?

  3. 3.A user sees a message that the conversation has reached its maximum length and no more messages can be sent. What has happened and what should they do?

  4. 4.A user is told they have reached their usage limit for now. Which response is correct?

  5. 5.A team of analysts complains that they exhaust their usage quickly. Investigation shows each analyst keeps a single conversation running for weeks, re-pasting the same 30-page brief whenever Claude seems to forget it. What is the best explanation and fix?