Manus-Bot Lite Now Runs on DeepSeek-V4-Flash High: From Brain Teasers to Executable Workflows

Today, we are announcing that Manus-Bot Lite now runs on the latest DeepSeek-V4-Flash High.

This upgrade is not just about producing a smarter answer. It is about giving the model more room to break down a complex task, check its constraints, and deliver a result you can keep working with. Use it to solve a deceptively simple logic puzzle, or give it a product brief, a few tables, and a long list of requirements. Manus-Bot can take on the right Agent role, use the right Skills, and turn the request into a practical next step.

Why Lite × DeepSeek-V4-Flash High

DeepSeek describes V4-Flash as an efficient Mixture-of-Experts model with 284B total parameters and 13B activated parameters. It supports a 1M-token context, while the official API supports Thinking / Non-Thinking modes, tool calls, and structured output. Read the DeepSeek release notes and models and pricing documentation.

The Lite tier uses DeepSeek-V4-Flash with High reasoning effort. It will not be correct on every problem, but it is a strong fit for tasks that involve:

• many conditions where one missed detail can change the result
• planning, analysis, and writing that need multiple stages
• long documents, tables, and cross-referenced context
• turning conclusions into plans, code, test cases, or other deliverables

The official model card reports reference results for different reasoning efforts. For V4-Flash High, it reports 86.4 on MMLU-Pro, 87.4 on GPQA Diamond, and 88.4 on LiveCodeBench. These figures come from the model card’s evaluation setup; they are not an internal Manus-Bot benchmark or a guarantee for every real-world task. See the DeepSeek-V4-Flash model card.

Four tests to see whether it really thinks things through

These are not trivia questions. They are designed to expose reasoning, constraint tracking, and delivery quality. Copy any of the prompts below into Manus-Bot and try them yourself.

1. Four cards: conditional reasoning and counterexamples

Four cards are on a table. The visible faces show 3, 8, blue, and red. Each card has either a number or a color on its other side. To test the rule “if one side shows an even number, the other side must be blue,” which cards must you turn over at minimum? First describe the cases that could disprove the rule, then give the answer.

This classic Wason selection task tests whether the model looks for cards that could violate the rule instead of turning over everything. The standard answer is the 8 card and the red card: the 8 checks for a non-blue reverse side, and the red card checks for an even number on the reverse side. See the Wason selection task.

In Manus-Bot, follow up with: “Explain using counterexamples, not intuition, why the 3 and blue cards do not need to be turned over.” A strong answer should distinguish necessity from sufficiency rather than only naming two cards.

2. Decimals and letters: precision across turns

First question: which is greater, 9.11 or 9.8? Explain using place value.
Second question: how many r letters are in strawberry? Mark each position.
Third question: compress both answers into a two-column table and explain why the second answer should not be estimated from the word’s appearance.

This looks simple, but it tests decimal comparison, character counting, multi-turn context, and formatted output at the same time. DeepSeek’s official Thinking Mode documentation uses a similar decimal-comparison and strawberry counting example to demonstrate multi-turn reasoning and output handling. Read the Thinking Mode documentation.

The reference answer is that 9.8 is greater and strawberry contains three r letters. What matters is whether the model separates its answer from its verification process and keeps the second count independent from the first turn.

3. Zebra Puzzle: preserving a full set of constraints

Solve the classic Zebra Puzzle: there are five neighboring houses, each with a different color, nationality, drink, cigarette brand, and pet. Build a full logic grid from the clues, mark the elimination relationships one by one, answer “who owns the fish,” and check whether a second solution satisfies all the clues. Do not give only the final answer.

The Zebra Puzzle is a constraint-satisfaction problem and has long been used to test computer programs and large language models on logical reasoning. Read the Zebra Puzzle overview.

The acceptance criteria are not just whether the model guesses who owns the fish. Check three things: whether it kept every clue, whether each elimination can be reviewed, and whether the final solution is unique. For reliable work, High reasoning and structured output are often more valuable than a polished one-line conclusion.

4. From a question to a deliverable: testing Agent + Skill collaboration

Now replace the puzzle with a real piece of work:

I am planning to evolve an existing chat product into a multi-Agent architecture. Work as an IT Architect and attach the Product Planning, Technical Design, Code Implementation, and Code Review Skills. Produce: 1) target users and core scenarios; 2) boundaries between Agents, Skills, models, and tools; 3) the flow from request to deliverable; 4) the smallest viable interfaces and data structures; 5) migration steps; and 6) risks, rollback, and acceptance criteria. Label every item as a known fact, design assumption, or open question.

There is no single correct answer, which makes this closer to real work. The Agent provides the working perspective; the Skills add methods for the current turn. Product Planning clarifies goals and acceptance, Technical Design defines boundaries, Code Implementation turns requirements into changes, and Code Review looks for defects and testing gaps. You can combine multiple Skills in one message and move the output from a suggestion toward an executable next step.

The real upgrade: organizing model capability into a workflow

A stronger model can still produce only a longer answer when it is used on its own. Manus-Bot’s design puts model capability inside a selectable, reusable workspace:

1. Choose a role for the task, such as Writing, Product Manager, Data Analyst, IT Architect, or Test Engineer.
2. Choose the Skills needed for the current turn, such as Technical Design, Writing Polish, Code Implementation, or Product Planning.
3. Use High reasoning for complex constraints, and specify the output format, acceptance criteria, and open questions.
4. Continue the result into a follow-up conversation, document, code change, table, or other deliverable.

That is how we think about an Agent: not a system that claims to think of everything for you, but one that helps move an ambiguous goal forward inside the right role, method, and boundaries.

Try it now

Open Manus-Bot, choose the Lite tier, and start with one of the four tests above. Then replace the puzzle with your own work: a product brief, meeting notes, a data table, or code that needs refactoring.

Give it a clear goal, attach the right Skills, and ask it to list assumptions, verification methods, and the expected deliverable format. That is where this upgrade becomes tangible: the model is not only answering a question, but helping turn a problem into a path you can keep moving along.

Visit manus.kim to learn more.