How to Make Claude Think Harder on Difficult Tasks

To make Claude think harder, define the difficult parts of the task, use the reasoning controls available for your model, and require checks against explicit success criteria. Asking for more effort helps most when you also explain what a correct answer must satisfy.

A long response can still miss a constraint or reuse a bad assumption. Tools like fenbs keep your project brief and accepted review criteria outside a single chat, so the next attempt starts with the same problem. The goal is a better tested answer, not a more impressive performance of thinking.

What should you try before asking for deeper analysis?

1. State the outcome: the decision, calculation, explanation, or working change you actually need.
2. List the constraints and source material. Mark which requirements are mandatory and which are preferences.
3. Ask Claude to identify missing information that could materially change the answer before it proceeds.
4. Choose an appropriate effort or thinking setting if your model offers one, then request a concise result with supporting checks.
5. Verify the most consequential claim through a calculation, source, test, or qualified person outside the response.

Say you are choosing how to move a small customer database. The difficult parts may be preventing lost changes, limiting downtime, and proving the transfer is complete. Tell Claude those are the review criteria. A generic request to think deeply does not tell it whether a clever migration plan that exceeds your downtime allowance is unacceptable.

Name the information you do not have. If the database size is unknown, an estimate based on an imaginary size can make the recommendation look more precise than it is. Ask for a conditional answer or a focused question instead. This advice also applies to planning a workshop or comparing two proposals.

Which controls can change how carefully Claude works?

In the Claude app, check the model menu for the available effort and thinking options. Anthropic explains the controls in its model, effort, and thinking settings guide↗ (opens in a new tab). Availability depends on the selected model; a prompt cannot create a missing setting.

For developers, the API effort documentation↗ (opens in a new tab) describes how supported effort settings trade thoroughness against token use. Tokens are the small pieces of text the model processes. Use the documentation for your selected model rather than copying an old configuration from a different one.

Treat a setting change as an experiment. Save the original question and answer, change one control, and compare the results on the same requirements. If the second attempt catches a real conflict, keep that observation. If it only adds background and extra headings, you have not established that it solved the problem better.

The Claude overview explains the app and model distinction, while the Claude API guide covers the developer route. For controlling duration and reducing unnecessary reasoning, see making Claude think longer.

What does a useful difficult-task prompt look like?

Use a problem statement that separates the goal from the evidence. Give the assistant permission to return an unresolved issue when the evidence does not support a confident recommendation. Ask for the reasoning you need to assess the result, such as assumptions, calculations, and tradeoffs, rather than an exhaustive private thought process.

Help me evaluate this plan.
Goal: move our customer database with no lost updates.
Constraints: one planned maintenance window; rollback must be possible.
Evidence: [paste the current design and measured system details].
Unknowns: [list missing facts].
First identify any missing fact that blocks a responsible recommendation.
Compare two feasible approaches against the constraints.
Return your recommendation, key assumptions, failure cases, and specific checks.
If a requirement cannot be met, say which one and why.
Keep the final explanation focused on what I need to review.

Replace the example with your actual facts. Leaving the brackets empty invites an answer about a generic project. If you provide conflicting requirements, ask Claude to expose the conflict rather than quietly relaxing one. A plan that needs your approval to change a requirement should say so.

Save the stable prompt separately from temporary details. The reusable part is the review method; the database size and maintenance date belong to the current task. fenbs can keep that method in Skills and prompts and the project-specific requirements with the work.

How do you check whether the answer improved?

Write the pass conditions before reading the answer. For the migration example, the plan should explain how writes are handled, how copied records are checked, what triggers rollback, and who authorizes the final switch. These are review questions you can inspect directly rather than vague impressions of intelligence.

Anthropic recommends specific, measurable criteria in its evaluation guide↗ (opens in a new tab). For your own work, a short checklist is enough to begin. Include a case that should fail, because an answer that approves every scenario is not demonstrating useful discrimination.

• For arithmetic, recompute the result with a calculator and check units.
• For a recommendation, open the source that supports its decisive factual claim.
• For software, run a test that would fail if the reported fix were absent.
• For a plan, walk through an interrupted or unsuccessful run and check the recovery steps.

Ask for a brief account of what was checked and what remains untested. Self-review can suggest problems, but repeating the same answer more confidently is not independent verification. The Claude Code introduction explains the coding tool if your task needs repository work and executable checks.

Why can more effort still produce a weak answer?

Extra analysis cannot supply a missing document, resolve an undefined goal, or turn an unsupported assumption into a fact. A detailed answer may optimize the wrong objective because the request never explained the real constraint. Check the input before increasing the effort again.

Also watch for repeated attempts that all inherit the same mistake. Start a clean comparison using the original evidence, or ask a person to review the disputed premise. If a result changes, identify the new evidence that justifies the change. Do not choose whichever response sounds most certain.

How to do this with fenbs

1. Create a free account, then add the project and the difficult task you want to solve.
2. Put the problem, known evidence, constraints, and acceptance criteria in the task note and plan. Keep unanswered questions explicit.
3. Save the reusable review instructions in Skills and prompts. Record requirements a person has approved in Decisions and rules where appropriate.
4. Follow the integration guide to connect your supported AI app over MCP, a standard way for an AI app to use an outside tool. Ask it to read the project context before working.
5. Save progress before stopping: the chosen approach, actual checks, unresolved concerns, and next step. A person decides whether the result is acceptable.

fenbs is free for one person, no credit card. It is useful when the same problem spans sessions or assistants; it does not provide Claude reasoning controls or run an independent correctness test for you. For a single isolated puzzle, a clear prompt and an external check may be sufficient.

After the next attempt, compare the recorded pass conditions with the evidence. Keep the prompt if it helps expose mistakes you care about, and revise it if it encourages unnecessary work. The AI prompts hub has more ways to make requests specific to the job.