DeepSeek V4.1 Flash has made longer coding sessions more useful for me. It works surprisingly well around 200K context, and on OpenCode Go I can push it to 1M. For a bigger repository, that means more room to work with the code and the conversation that led to the current change.
I still prefer Claude or Sol when the job is to work out what to build. Architecture and messy requirements call for decisions before they call for code. Once the direction is clear, DeepSeek becomes much easier to put to work.
Hallucinations are the part I still do not fully trust. A compiler and a test suite give me something concrete to check. For important work without those checks, I want a second model to review the output and its evidence.
Those three observations lead to a practical way to use Offloop: give planning, implementation and review to separate Agents. This guide walks through that setup, then follows an example checkout bug from the first request to the final review.
1. Decide what each model is responsible for
Before choosing models, define the three results you need: a plan you can inspect, a patch you can test, and a review that examines both. A model’s ability to hold more context does not tell you whether it has chosen the right change.
Claude or Sol takes the Planner role here. This is where my preference matters most: deciding where a change belongs, breaking down an ambiguous request and identifying the questions that would change the implementation. I use either for this work; these observations do not establish a winner between them.
DeepSeek V4.1 Flash takes the Builder role. Its long-context behavior is the useful part of my experience: there is more room for a larger codebase and a longer working session. Give it the agreed direction, the relevant code and a clear definition of done. There is less ambiguity to carry into the patch.
For the Reviewer, choose a different model from the Builder. In the example below, Claude plans, DeepSeek implements and Sol reviews. A different model gives the work another inspection, but the review still needs evidence. Two models can agree on the same mistake.
Open Agents → New agent and describe the job you want the new Agent to do. Repeat this for three roles: planning the change, writing the code, and reviewing the result. Name them Planner, Builder and Reviewer so you can tell them apart.
2. Set the models in Offloop
Open Settings → Agents. Under All agents, choose a model beside each Agent and save the changes. You can also manage the model from the Agent’s own settings. Use the models available in your workspace.
Set the Planner to Claude or Sol, the Builder to DeepSeek V4.1 Flash, and the Reviewer to another model. Use an individual selection for each role; choosing Inherit default follows the workspace default instead.
My 1M context observation comes from OpenCode Go. It is not a promise of a 1M context window in Offloop. Keep the model and the environment in view when comparing your own results, particularly if you move the same task between tools.
Once the model choices are set, bring the Agents into one Channel. That gives you a place to follow the request, the accepted plan and the returned work.
Try the team in an Offloop workspace
Open Agents in the sidebar, choose an Agent, and change its model under Model. Save, then choose Back to checkout-fix. Open the member panel or send the example task to follow the team’s conversation. This is a sample workspace; the Offloop button below takes you to your own work.
3. Give the Planner a problem it can resolve
Create a Channel for the task. Open its member panel, choose Add, and select your three Agents. Provide access to the repository and the tools they will need. Put the request and relevant files in the Channel, then mention the Planner.
Consider a checkout bug: a discount expires after the customer sees the total but before payment. “Fix expired discounts” leaves several decisions open. Should the order be rejected? Should the customer see a revised total? What happens if the payment request is retried?
For this example, the intended behavior is to recalculate the total, ask the customer to confirm the new price and preserve payment idempotency. Supply the reproduction, the affected checkout code and any existing tests. These are example requirements, not a report of a fix I have shipped.
Have the Planner identify the code that owns the behavior, describe the smallest change and name the checks that would demonstrate it works. Read that plan before moving on. If the plan assumes that an expired discount can be silently removed, resolve the pricing decision now.
This is why I keep planning separate. A patch can compile while implementing the wrong product decision. Agreeing on the behavior gives the Builder a target and gives the Reviewer something more precise than “does this look reasonable?”
4. Hand DeepSeek the plan and the relevant code
Once the plan is agreed, direct the Builder to implement it. Include the original request, the accepted plan and the relevant code. Ask it to return the diff, the checks it ran and anything it could not verify to the Channel.
A larger context window gives you room to include the path around the change: the caller, the shared types, existing tests and earlier decisions. That is where the long-session behavior I described becomes useful. The Builder can work with more of the surrounding problem.
Keep the handoff deliberate. Mark which plan is current and which questions remain unresolved. If the requirements change halfway through, update the accepted plan before asking for more code. Extra context is useful only if the Agent can tell what still applies.
Agents can communicate through their own direct chats. Those internal conversations are not a transcript you browse, so have the decisions, deliverables and unresolved questions returned to your Channel. At the end of implementation, you should be able to inspect the actual change and the evidence behind it.
5. Review the patch against the original request
Mention the Reviewer and give it the original request, the accepted plan, the diff and the check results. A review based only on the Builder’s summary can inherit the Builder’s omissions. The code and the requested behavior need to be available for comparison.
For the checkout example, inspect the moment the discount expires, the revised-price confirmation and a repeated payment request. Passing the successful-payment test alone would leave the most important parts of this change unexamined.
Keep three outcomes distinct: checks that passed, checks that failed and checks that did not run. A typecheck supports a claim about types. A retry test supports a claim about the retry behavior it exercises. Neither establishes that every checkout path is correct.
Send confirmed findings back to the Builder. After the revision, rerun the affected checks and have the Reviewer inspect the updated diff. Accept the work when the evidence addresses the requested behavior and any remaining uncertainty is clear.
For open-ended work, the same review habit needs different evidence. If an Agent writes an architecture recommendation, have the Reviewer inspect the source code, constraints and assumptions behind it. For research, follow the cited sources. A second model is useful because it can question the answer; agreement by itself cannot verify it.
This is the workflow I would build from my three observations: use DeepSeek’s room for context on a well-defined implementation, keep planning with a model you trust for that job, and make review answer to evidence. Start with one bounded change so you can judge the result yourself.
References
The model preferences and context observations come from my original post. The Anthropic articles provide further reading on agent workflows and context; they do not independently verify those observations.
