DEV Community: Aditi Gupta

DeepSeek Harness Explained: What It Is, When to Use It, and When Not To

Aditi Gupta — Fri, 21 Aug 2026 08:44:36 +0000

AI models can generate code, explain repositories, and suggest fixes. But a model alone cannot safely inspect your project, execute commands, remember a long-running task, or coordinate multiple tools.

That surrounding infrastructure is called an agent harness.

DeepSeek Harness also called dsh is DeepSeek’s open-source implementation of that infrastructure. It provides the runtime that connects a model to files, tools, sessions, sandboxes, approval policies, workflows, and a user interface.

Here is the breakdown:

This article explains what DeepSeek Harness is, what makes it interesting, how to try it, and—just as importantly—when it may be the wrong tool.

DeepSeek Harness is currently a developer preview. Expect breaking changes, unfinished edges, and rapidly evolving APIs.

The short version

DeepSeek Harness is not:

A new DeepSeek model
A model-training framework
A replacement for Node.js, Python, or your IDE
A guarantee that an AI-generated change is correct or safe

It is an agent runtime.

A useful mental model is:

AI agent = model + harness

The model provides reasoning and language capabilities. The harness gives that model a controlled way to interact with the outside world.

Your request
    ↓
DeepSeek Harness
    ├── builds the model context
    ├── exposes approved tools
    ├── manages the workspace
    ├── executes tool calls
    ├── records the session
    ├── applies approval and sandbox policies
    └── returns results through the UI
    ↓
Configured AI model

The model decides what it wants to do. The harness decides how that action is represented, executed, recorded, and controlled.

Why do agents need a harness?

Suppose you ask a regular chat model:

Find the authentication bug in this repository, fix it, and run the tests.

The model needs more than intelligence to complete that request. It needs a way to:

Discover the repository structure
Read the relevant files
Search for related code
Edit the implementation
Execute the test suite
Inspect failures
Make another change
Preserve a record of what happened

A harness supplies these capabilities.

Without one, you have a model that can tell you what code might work. With one, you have an agent that can potentially inspect and modify a real environment subject to the permissions you give it.

That last part matters. A harness makes a model more useful, but it also makes the model more capable of causing damage. Workspace boundaries, approvals, sandboxes, and human review remain essential.

What makes DeepSeek Harness different?

The main design principle is:

Everything is a plugin.

Models, tools, skills, sessions, storage, sandboxes, agent loops, scheduling, and even the UI are provided through plugins.

At the center is Cordis, a plugin kernel responsible for mounting plugins, resolving their dependencies, and letting them communicate through services and events.

This has an important practical consequence: capabilities can be replaced or recomposed without maintaining a permanent fork of the harness.

For example, a developer could theoretically swap:

One model provider for another
A local shell backend for a remote sandbox
The default storage implementation for a custom store
One approval policy for a stricter policy
The standard agent loop for a specialized workflow
The browser UI for another client

This architecture is most valuable when you want to build or study agent infrastructure, not merely chat with an AI model.

DeepSeek Harness does not require a DeepSeek model

The name can be misleading.

DeepSeek Harness includes direct support for configuring DeepSeek, but it can also work with other catalog providers and custom OpenAI-compatible endpoints. The model and the harness are separate layers.

That means you can evaluate questions such as:

How does the same model behave with different tools?
How do two models perform inside the same agent environment?
What happens when the sandbox or approval policy changes?
Can an internal model endpoint be connected to a reusable agent runtime?

For custom providers, you supply details such as the provider ID, base URL, API protocol, credentials, and model list.

Be aware that “OpenAI-compatible” does not always mean perfectly compatible. Different gateways may use different roles, token-limit fields, reasoning formats, or image capabilities. DeepSeek Harness exposes compatibility settings for these cases, but connecting an unusual endpoint may require experimentation.

Every run is traceable

DeepSeek Harness uses an append-only session log.

The log records the model-visible history of a run, including prompts, messages, tool calls, tool results, context injections, and agent activity. Features such as resuming, forking, searching, replaying, and inspecting a trajectory are built from this event stream.

This is useful for debugging questions like:

Why did the agent edit this file?
Which tool result changed its direction?
What context did the model receive?
Where did a multi-step task begin to fail?
Did the problem come from the model, a tool, or the harness configuration?

Traceability is especially helpful when developing an agent system. Looking only at the final answer often hides the real failure.

It also has a privacy implication: session logs may contain code, prompts, tool output, file contents, or other sensitive context. Treat stored trajectories as potentially sensitive data.

The four runtime modes

DeepSeek Harness provides several modes for different kinds of work.

Mode	What it provides	Best suited for
Standard	File editing, shell access, search, skills, planning, goals, subagents, and workflows	General agent-assisted development
Code	Standard capabilities exposed through a code-based orchestration SDK	Multi-step tool orchestration
Minimal	A persistent shell and file editor	Benchmarking models with minimal harness influence
Creator	Runtime inspection and plugin experimentation in addition to standard capabilities	Building presets and extending the harness

Standard mode

Start here if you want to understand the normal user experience.

It provides the familiar capabilities expected from a coding agent: reading files, editing code, searching, running commands, planning work, and delegating subtasks.

Code mode

Code mode lets the model combine several tool operations in a generated TypeScript program.

This can reduce the overhead of repeatedly moving between the model and individual tools. It is useful for complex orchestration, but it also increases the importance of execution controls and careful review.

Minimal mode

Minimal mode intentionally removes most of the surrounding machinery.

It is useful when comparing models or studying how much the harness itself influences performance. It is less convenient for everyday development because many higher-level capabilities are absent by design.

Creator mode

Creator mode is for developers experimenting with the harness itself.

Use it to inspect the runtime, test plugins, and compose custom presets. If your goal is simply to fix an application bug, Creator mode is probably unnecessary.

When should you use DeepSeek Harness?

DeepSeek Harness is a strong candidate in the following situations.

1. You are building an agent platform

If your product needs interchangeable tools, model providers, storage systems, sandboxes, or agent loops, the plugin architecture gives you an existing composition model to study or extend.

2. You need inspectable agent runs

The session event stream and trajectory view make it easier to reconstruct what an agent saw and did. This is valuable for debugging, evaluations, and failure analysis.

3. You want to compare models inside the same environment

Model comparisons are difficult when each model uses a different set of prompts, tools, and execution rules. A configurable harness helps keep more of the environment consistent.

4. You are experimenting with custom tools or policies

Because tools and execution policies are extension points, the project is relevant when testing a custom capability, approval flow, sandbox backend, or internal integration.

5. You want an open-source base you can inspect

DeepSeek Harness is released under the MIT license. You can examine the implementation, modify it, and build on it within the terms of that license.

Remember that MIT-licensed does not mean zero operating cost. A configured model provider may charge for API usage, and remote infrastructure can introduce additional costs.

When should you not use it?

A new open-source agent system can be exciting, but it is not automatically the right choice.

1. You only need a simple model call

If your application sends a prompt and receives an answer, a model SDK may be enough. Adding a full harness introduces plugins, sessions, configuration, storage, and operational complexity you may not need.

2. You need a stable production API today

The project is explicitly marked as a developer preview and warns that compatibility-breaking changes will occur.

That makes it suitable for learning, prototyping, and experimentation. Production adoption requires version pinning, migration planning, testing, and a willingness to follow upstream changes.

3. You cannot isolate the working environment

An agent that can edit files and execute commands should not receive unrestricted access to a sensitive machine.

If you cannot provide a narrow workspace, suitable approval policies, secret isolation, and preferably a disposable environment, do not use it for autonomous changes.

4. Your workflow requires deterministic results

An agent loop combines model decisions with changing context and tool output. Even with the same request, the exact path may vary.

Use conventional scripts, tests, and workflow engines when deterministic execution is the primary requirement.

5. Your team does not need harness customization

If a mature coding assistant already meets your needs, adopting an extensible agent runtime may create maintenance work without delivering meaningful value.

6. You plan to trust the output without review

A traceable agent can still make incorrect changes. Logs help explain a decision; they do not make that decision correct.

Treat generated code like a contribution from an unfamiliar developer: review the diff, run tests, inspect security-sensitive changes, and verify the behavior.

How to try DeepSeek Harness

The fastest path is through its local Web UI.

Step 1: Check Node.js

The repository currently declares support for Node.js ^22.19.0 or >=24.0.0.

node --version

Because the project is changing quickly, verify the current requirement in the repository before installing.

Step 2: Start the Web UI

npx @deepseek-ai/dsh web

By default, this starts a local server at:

http://127.0.0.1:3080

Run the command from the project directory you want to work with. The process uses its starting directory as the default filesystem location, although you still need to select a workspace in the UI.

Step 3: Configure a model

Open:

Settings → Models

You can enter a DeepSeek API key, add another supported provider, or configure a custom provider.

Credentials are stored separately from normal settings, and the UI receives a redacted credential descriptor after saving rather than the literal key.

You still need to protect the machine and the harness home directory. Never commit credential files to a repository.

Step 4: Choose a workspace

Select Choose workspace, add the relevant project directory, and select it.

Use the smallest practical directory. Do not select an entire home folder or a directory containing unrelated secrets and projects.

Step 5: Begin with a read-only task

A good first request is:

Summarize this repository. Identify its main packages, test commands,
and likely entry points. Do not modify any files.

This lets you evaluate how the agent explores the project before allowing it to make changes.

A reasonable next task is:

Find one small, well-contained issue in this repository.
Explain the proposed fix and wait for approval before editing files.

Only after you understand the permission flow should you try a full implementation task.

Step 6: Inspect the trajectory

Do not judge the harness only by the final response.

Inspect:

What context was sent to the model
Which tools were called
Which files were accessed
Whether commands required approval
How tool output affected later decisions
Whether the agent repeated unnecessary work

This is where a traceable harness becomes more useful than a simple chat interface.

A safer evaluation workflow

For early experiments, use a disposable branch, worktree, container, or test repository.

A practical workflow looks like this:

Create an isolated copy of a small project.
Remove production credentials and customer data.
Start DeepSeek Harness from that directory.
Select only that directory as the workspace.
Use a read-only repository-summary task first.
Ask for a plan before permitting edits.
Review every requested command.
Inspect the resulting diff manually.
Run the project’s tests yourself.
Review the trajectory for surprising behavior.

Do not let a successful demo convince you to skip these controls on the next run.

Building from source

If your goal is to inspect or modify the harness itself, clone the repository and build it with its configured package manager:

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

Use this route when you want to:

Read the architecture alongside the implementation
Develop or modify plugins
Test changes to the runtime
Contribute upstream
Pin your work to a specific commit

For a first evaluation, the npx command is simpler.

What to evaluate before adopting it

A successful installation only proves that the harness starts. Before using it for real work, evaluate the following.

Model quality

Does your chosen model use tools reliably? Can it recover from failed commands? Does it stop when it lacks information?

Permission behavior

Which actions require approval? Are writes and command execution constrained appropriately?

Workspace isolation

Can the agent access files outside the intended project? Are secrets, SSH keys, cloud credentials, and production configuration isolated?

Trace quality

Can you reconstruct why a change happened? Does the log contain enough information to debug failures without exposing more sensitive data than necessary?

Plugin trust

A plugin can add substantial capabilities. Review its source, dependencies, permissions, maintenance status, and network behavior before installing it.

Upgrade cost

Since the project is in preview, test upgrades against pinned configurations and plugins. Do not assume a newer release will preserve every API or behavior.

Cost

The harness is open source, but model requests, hosted sandboxes, storage, and other providers may not be free. Measure token usage and infrastructure costs with realistic tasks.

Final perspective

DeepSeek Harness is best understood as infrastructure for constructing and studying agents.

Its value does not come from making a model magically correct. It comes from giving developers a composable way to connect models with tools, sessions, workspaces, policies, storage, orchestration, and observability.

Use it when you need that control or want to experiment with agent architecture.

Avoid it when a simple API call is enough, when stability is more important than extensibility, or when you cannot safely isolate what the agent can access.

Most importantly, keep the model and the harness conceptually separate:

The model decides.
The harness enables, constrains, executes, and records.
The developer remains responsible for the system.

Official resources

Grokbot Honest Review: Is xAI and Cursor's Computer-Use Agent Worth $200 a Month?

Aditi Gupta — Mon, 17 Aug 2026 18:03:19 +0000

Grokbot is xAI and Cursor's attempt at an AI agent that doesn't just chat, it uses a computer. Each bot you create gets its own machine in the cloud, with Chrome, a file manager, and its own operating system, and it keeps working after you close your laptop. I spent a week building three bots to see whether that idea holds up in practice.

Prefer the quick version? I covered the three bots I built, the shared-login trap, and my full verdict in this video:

What Grokbot actually is
You download it from x.ai/bot as a desktop app, not a website. You make a bot with a name and a short description of its job, and it spins up its own virtual computer to get started. Because that computer lives in the cloud, the bot runs on its own, 24/7, without touching your machine.

Why I tested it
I wanted to know if computer-use is real yet or still a demo. So I built three bots with very different jobs: one to find startups that raised seed funding recently and pull the founder names and amounts, one to compare flight prices from Delhi to Tokyo, and one to check the price of a phone across five stores. Same setup each time.

Where it provides value
The genuinely new part is that Grokbot skips the API problem. A huge chunk of the internet has no API an AI can plug into, and even when there is one it rarely lets you do everything the website can. Grokbot gets around that by using the site directly, logging in, clicking through pages, and downloading files the way a person would. It ran with my laptop shut, and I could take over the virtual computer from the mobile app. The teach-a-task feature is the standout: you record yourself doing something fiddly once, it watches the recording frame by frame, and turns it into a reusable private skill.

The main catch
Two things stood out. First, reliability. It got stuck on simple clicks, brought back half the data, and sometimes just froze on easy tasks. Second, and more important, the virtual computer and its logins seem shared across all your bots. I signed into Google on one bot and the others could suddenly reach every site tied to that login. Convenient, but you should be deliberate about which accounts you hand it.

The settings and habits to change first
Always require approval before the bot sends an email, publishes anything, books a flight, buys a product, or deletes something. For anything complicated, record a demo with teach-a-task instead of hoping it figures the task out alone. And keep sensitive logins on bots you trust, given the shared-computer behavior.

How it compares to Claude Code and Codex
Claude Code and Codex can drive a browser too and do more flexible work, but they usually run on your machine, you kick them off yourself, and they stop when your computer is off. Grokbot's lane is different: watching web pages, checking prices on a schedule, moving data between apps, and grinding through repetitive screen work in software you already use. It is not a replacement for a coding agent.

Who should and shouldn't try it
The cheapest plan is $200 a month, and that does include Cursor Ultra. If you already burn through a lot of AI tokens and you're fine switching your subscription to Cursor Ultra, the price makes more sense. If you just want the bot, it's a lot to pay for something this early. Try it on the free week if you have one repetitive task nothing else can automate.

My verdict
Grokbot is a real step in the right direction. Instead of waiting for every website to build an API, it lets an AI use a computer the way we do, and if that gets reliable enough it could automate almost anything you can do on a screen. Right now the automation isn't consistent, the trial is tiny, and the price is steep, so I wouldn't tell most people to pay for it yet.

Have you tried Grokbot or another computer-use agent yet? Tell me in the comments. If you like quick, honest AI-tool reviews, follow my YouTube channel for the next one.

Links and sources

Grokbot (xAI + Cursor): https://x.ai/bot
Full video review: https://youtu.be/rUfvWFPYGMo
More AI tool breakdowns + weekly news: https://goventure.live https://youtu.be/rUfvWFPYGMo
My testing notes: the three bots, the shared-login behavior, and the reliability misses are all shown in the video above.

Tags: #ai #agents #cursor #aitools

I Tried Kimi K3 for Free in VS Code - Can It Replace Claude or GPT?

Aditi Gupta — Wed, 12 Aug 2026 17:35:03 +0000

My coding assistant subscription has one job: save me more time than it costs.

So when Moonshot AI released a 2.8-trillion-parameter model with a one-million-token context window—and I found a way to connect it to VS Code for free—I wanted to answer one practical question:

Is Kimi K3 good enough to replace a paid coding assistant?

After looking past the headline numbers, comparing the benchmark results, and testing it on a complete browser game, my short answer is:

Kimi K3 is good enough to become a serious coding workhorse for many developers. But it is not a universal replacement for every paid model, and the free access comes with an important catch.

Prefer the video walkthrough? I cover the test and both setup methods here:

First, what exactly is Kimi K3?

Kimi K3 is Moonshot AI's newest open-weight, native multimodal model. According to the official release, it has:

2.8 trillion total parameters
104 billion active parameters per token
A Mixture-of-Experts architecture that activates 16 of 896 experts
A 1,048,576-token context window
Native image and video understanding
Kimi Delta Attention and Attention Residuals
Built-in reasoning for coding, research, and agentic work

That “104 billion active” detail matters. Kimi K3 does not use all 2.8 trillion parameters for every token. Its sparse architecture routes each token through a small subset of experts, making inference more efficient than the headline size suggests.

Open-weight is not the same as free to run

You will see Kimi K3 called “open source,” but open-weight is the more precise description. Moonshot has released the model weights under its own Kimi K3 license, so developers can inspect, deploy, and build on the model within those terms.

However, downloading the weights does not make inference free. A 2.8T model is far beyond the practical local setup of most developers. Unless you have access to serious GPU infrastructure, you will use a hosted provider—and that provider pays the compute bill.

That distinction becomes important when we get to the free setup.

The benchmark results are genuinely competitive

Kimi K3's coding scores are the main reason I took it seriously.

Here are selected results from Moonshot's published evaluation:

Benchmark	Kimi K3	Claude Fable 5	GPT-5.6 Sol	Claude Opus 4.8
DeepSWE	67.5	70.0	73.0	59.0
ProgramBench	77.8	76.8	77.6	71.9
Terminal-Bench 2.1	88.3	88.0	88.8	84.6
FrontierSWE	81.2	86.6	71.3	66.7
SWE-Marathon	42.0	35.0	39.0	40.0
BrowseComp	91.2	88.0	90.4	84.3

The pattern is more interesting than a simple “Kimi wins” headline:

It nearly matches GPT-5.6 Sol on Terminal-Bench 2.1.
It beats GPT-5.6 Sol and Opus 4.8 on FrontierSWE, although Fable 5 scores higher.
It leads this comparison on ProgramBench, SWE-Marathon, and BrowseComp.
It falls behind both GPT-5.6 Sol and Fable 5 on DeepSWE.

That is not a clean sweep. It is something more useful: evidence that an open-weight model now belongs in the same coding conversation as the leading proprietary models.

One benchmark warning most reviews skip

These numbers come from Moonshot's evaluation, and some models were tested with different agent harnesses. Kimi used Kimi Code on several tests, GPT used Codex on some, and Claude used Claude Code or other harnesses on others. All Kimi results also used maximum reasoning effort.

In other words, treat the table as a strong signal—not a perfectly controlled, apples-to-apples contest. The technical report and repository document the methodology if you want to inspect it.

My practical test: build a browser game from one prompt

Benchmarks tell me whether a model deserves a test. They do not tell me whether I want it editing my project.

So I gave Kimi K3 a long, single prompt to generate a complete browser game. This forced it to plan the interface, write the game logic, connect the files, and keep the result coherent over a longer generation.

It produced a complete, playable first version in one pass.

What impressed me was not one clever function. It was the model's ability to sustain a multi-part implementation without losing the original goal.

But a one-shot demo has limits. A generated game can look impressive while still hiding brittle state management, accessibility problems, or code that becomes painful on the second revision. The better test is whether the model can explain its decisions, respond to bug reports, make targeted changes, and run verification without rewriting unrelated code.

That is how I would evaluate Kimi K3 on a real repository.

How to try Kimi K3 for free

I found two practical routes: one in the browser and one inside VS Code.

Availability note: The free Kimi K3 routes I tested are promotional and may be rate-limited, renamed, or removed. Check the provider's model page before following the steps.

Method 1: Use Kimi K3 in your browser

When I tested it, GenSpark included Kimi K3 in its model menu after a free signup.

Create a free GenSpark account.
Open the AI chat interface.
Select Kimi K3 from the model menu.
Start with a real task—not “write hello world.”

Try asking it to:

Explain an unfamiliar module and identify risky dependencies.
Build a small feature with clear acceptance criteria.
Review a pull request and separate bugs from style preferences.
Turn a screenshot into a working frontend component.

In my usage, Kimi consumed fewer GenSpark credits than the premium Claude and GPT options, so the free allowance lasted longer. Credit rules can change, so verify the current rate in the interface.

Method 2: Connect Kimi K3 to VS Code

For coding, this is the more useful setup because the model can work with your files through an agent extension.

You can use Kilo Code or Cline. Both support OpenAI-compatible providers, which means you normally need only three pieces of information:

A provider Base URL
An API key
The exact model ID

Step 1: Install the extension

Install Kilo Code from the VS Code Marketplace. If its provider setup gives you trouble, install Cline instead; Cline documents the same OpenAI-compatible fields.

Step 2: Create a provider API key

Use a current provider that lists a promotional Kimi K3 route. At the time of writing, the following OpenAI-compatible configuration works with ZenMux:

Provider: OpenAI Compatible
Base URL: https://zenmux.ai/api/v1
Model ID: moonshotai/kimi-k3-free
API key: <your provider key>
Reasoning: enabled

The free model is explicitly listed as a limited-time route, so confirm that the model ID still appears in the provider's catalog before setting up the extension.

Step 3: Configure Kilo Code or Cline

Open the extension's model settings and:

Choose OpenAI Compatible as the provider.
Paste the provider's Base URL.
Paste your API key.
Enter the exact Kimi K3 model ID.
Enable reasoning or thinking mode if the client exposes that setting.
Save and send a small test prompt.

If you receive “model not found,” do not keep changing random settings. Check the provider's live model list first. Promotional model IDs change frequently.

Step 4: Test it safely

Start with a disposable branch or a small personal project. Ask the agent to explain its plan before editing, review the diff after each task, and keep automatic command approval off until you trust the workflow.

Also remember that a hosted endpoint can receive the prompts and code you send through it. Do not upload credentials, private customer data, or proprietary source code until you have reviewed the provider's privacy and retention policies.

The real catch behind “free”

The free access is real, but “free” can mean three different things:

Free weights: You can download the model under its license, but you supply the hardware.
Free web access: A product absorbs the inference cost and applies its own limits.
Free promotional API access: A provider offers a zero-cost route temporarily, usually with rate limits and no service guarantee.

The VS Code method falls into the third category. It is excellent for testing and personal projects. I would not build a production workflow around the assumption that the endpoint will stay unlimited or free forever.

There is another practical catch: the official Kimi API expects clients to preserve reasoning content across multi-turn tool calls. If your coding extension drops that state, you may see weaker follow-up behavior even when the first response looks good.

Should you replace your paid coding assistant?

Here is my honest recommendation.

Kimi K3 could become your default if:

Most of your work is coding, browser automation, or agentic web tasks.
You regularly need to reason across a large repository.
You are a student, indie developer, or early-stage builder minimizing subscriptions.
You are comfortable switching providers if a free route disappears.
You review diffs and verify generated code instead of accepting it blindly.

Keep a paid model as your primary if:

Reliability and support matter more than saving the subscription fee.
You work with sensitive code and need clear enterprise data controls.
Your tasks are ambiguous, high-stakes, or difficult to verify.
You depend on stable throughput, predictable latency, or a service-level agreement.
You want one assistant for coding, writing, analysis, and specialized professional work.

For many developers, the best answer is not a dramatic switch. It is a two-model workflow: use Kimi K3 as the high-context coding workhorse and keep a paid model as the fallback for difficult or high-stakes tasks.

Final verdict

Kimi K3 does not make every paid coding assistant obsolete.

What it does is more significant: it narrows the gap enough that “open model” no longer automatically means “second-tier coding model.” Its benchmark performance is competitive, its million-token context is genuinely useful, and the hosted free routes make it easy to test inside a real coding workflow.

My verdict:

Do not cancel your paid assistant because of one leaderboard. But if you write code, Kimi K3 deserves a permanent slot in your model picker while the free access lasts.

Have you tried Kimi K3 on a real repository? Share the task, what it did well, and where it failed. That comparison is more useful than another benchmark screenshot.

If this walkthrough helped, follow my YouTube channel, GoVenture, for more practical and honest AI-tool tests.

Links and sources

Kimi K3 official repository and benchmark table
Kimi K3 technical report
Kimi API documentation
Cline: configuring an OpenAI-compatible provider
ZenMux OpenAI-compatible API quickstart
GenSpark (browser method): http://genspark.ai/
Free API provider Token Router (VS Code method) : https://www.tokenrouter.com/

Meta Muse Spark 1.2 Honest Review: Loses the Benchmarks, Wins as an Agent

Aditi Gupta — Sat, 08 Aug 2026 08:49:34 +0000

Meta just shipped two things at once: Muse Spark 1.2, the model, and Muse Code, an agentic harness that wraps around it. The interesting part is that they pull in opposite directions. On raw coding the model is a clear underdog. As an agent it is suddenly near the top. Here is what actually held up when I tested it.

Prefer the quick version? I covered the benchmark split, the broken games, the harness features, and a head to head against Qwen 3.8 in this video:

What Muse Spark and Muse Code are
Muse Spark 1.2 is Meta's new coding model. Muse Code is the harness you actually run it in. The harness keeps a local log of every tool call and every edit, so if a run crashes it picks up exactly where it left off instead of starting over. It ships with built-in skills too: /plan turns a task into an approval-gated plan, /grill stress-tests that plan before you run it, and /goal keeps the agent pushing toward the objective.

Where it loses
On the coding benchmarks it never comes first. Second on Terminal Bench behind Opus 5, third on DeepSWE, and behind Opus 5 on Meta's own internal benchmark. The games I had it build showed the same weakness. They were laggy and half-finished, one dragon bounced on the spot, one character's arms were missing, another spun around when you tried to walk backwards. On the same prompts, Qwen 3.8 and Fable 5 built noticeably cleaner, more playable versions.

Where it wins
Point the same model at tools inside Muse Code and the picture flips. On agent and tool-use benchmarks it jumps to first. The crash-resume log is the standout feature for anyone running long agent jobs. To test it properly I gave both Muse Spark and Qwen 3.8 the same task: read a guide and turn it into a reusable skill. Muse Spark replied faster and produced the sharper result. It analyzed the guide, built a proper table, and got specific instead of generic.

Who should run it
If you want the best raw coding model, Opus 5 still wins and Qwen 3.8 still builds cleaner. If you care about agent workflows, tool use, and not losing progress when a long run dies, Muse Code is worth a serious look even though the model underneath loses the benchmark race.

My verdict
The model is not the story. The harness is. Muse Spark 1.2 is a reminder that in 2026 the wrapper around a model can matter as much as the weights.

Have you tried Muse Spark or Muse Code yet? Tell me in the comments. If you like quick, honest AI-tool reviews, follow my YouTube channel for the next one.

Tags: #ai #metaai #musespark #aiagents #coding``

Qwen3.8-Max Beat Claude

Aditi Gupta — Tue, 04 Aug 2026 11:34:00 +0000

Alibaba has released Qwen3.8-Max, its largest and most capable AI model to date.

The headline specifications are absurd: 2.4 trillion total parameters, 95 billion activated per token, multimodal input, and a one-million-token context window.

But the specification sheet is not the most interesting part.

Alibaba says Qwen3.8-Max operated autonomously for roughly 16 days, starting with an empty repository and building a working software project through issues, code changes, testing, pull requests, and self-correction.

That sounds impressive. It also sounds suspiciously like the sort of claim that deserves more inspection than a celebratory repost.

So I examined Alibaba's announcement, the public repository, and its benchmark results to answer a more useful question:

Does Qwen3.8-Max actually beat Claude, or did the benchmark department simply have an excellent week?

Prefer the two-minute version?

TL;DR

Qwen3.8-Max is a mixture-of-experts model with 2.4 trillion total parameters and 95 billion active per token.
Alibaba reports a one-million-token context window and support for text, images, and agentic workflows.
It beats the Claude models in Alibaba's table on Terminal Bench 2.1, PaperBench, and OSWorld-Verified.
It trails Claude Fable 5 on demanding repository-level engineering benchmarks such as SWE-bench Pro and FrontierSWE.
Alibaba says the model weights will be released next week. At the time of writing, the API is available, but the weights are not yet downloadable.
The 16-day coding trace is public, but the results still come from Alibaba's own evaluation setup and need independent replication.

What is Qwen3.8-Max?

Qwen3.8-Max is Alibaba's new flagship mixture-of-experts model.

It contains 2.4 trillion parameters in total, with approximately 95 billion active during each forward pass. This architecture allows Alibaba to scale the model's capacity without paying the full inference cost of a dense 2.4-trillion-parameter model on every token.

The model also supports a one-million-token context window, making it suitable for large repositories, long documents, persistent agent sessions, and other tasks where context compression usually arrives carrying a shovel.

Alibaba calls it the first Qwen model at Max scale that will receive an open-weight release. However, there is an important distinction:

The API is available now. The model weights are scheduled for release next week.

So calling it an "open-weight model" is reasonable when discussing Alibaba's release plan, but saying the weights are already available would be inaccurate.

You can find the specifications and release details in the official Qwen3.8-Max announcement.

The 16-day autonomous coding run

Alibaba asked Qwen3.8-Max to create a project called oh-my-cli from an empty repository.

Instead of responding to a single prompt and stopping, the model worked through a continuous engineering loop:

Convert feedback and requirements into GitHub issues.
Claim and execute individual tasks.
Write and modify code.
Run builds, unit tests, end-to-end tests, and lifecycle checks.
Route failures back into the issue workflow.
Fix the problems and verify the result.
Merge completed pull requests.

According to Alibaba, the repository had accumulated 265 commits, 127 pull requests, and 151 issues after approximately 16 days of autonomous operation.

The complete project history is available in the public oh-my-cli GitHub repository.

That transparency matters. Most autonomous-agent demonstrations give us a polished video and ask us to believe that nothing caught fire outside the frame. Here, developers can inspect the issues, commits, pull requests, tests, and failures.

Still, this does not prove that the model can autonomously build any production system for 16 days. It proves that Qwen3.8-Max performed this particular task inside a structured environment with automated testing and feedback loops.

That is still meaningful, just narrower than the marketing headline.

Where Qwen3.8-Max beats Claude

Alibaba published a large benchmark table comparing Qwen3.8-Max with Claude Opus 4.8, Claude Fable 5, GPT-5.6 Sol, and Qwen3.7-Max.

Here are the most relevant results:

Benchmark	Qwen3.8-Max	Claude Opus 4.8	Claude Fable 5	Result
Terminal Bench 2.1	86.6	84.6	84.6	Qwen leads
PaperBench	93.0	80.3	88.8	Qwen leads
OSWorld-Verified	86.1	83.4	85.0	Qwen leads
SWE-bench Pro	67.7	69.2	80.0	Claude leads
FrontierSWE	73.5	70.0	88.8	Mixed; Fable 5 leads

These results suggest three areas where Qwen3.8-Max looks particularly strong.

1. Terminal-based agent work

Its 86.6 score on Terminal Bench 2.1 puts it ahead of both Claude models in Alibaba's comparison.

That makes Qwen especially interesting for command-line agents, environment setup, testing, deployment workflows, and tasks that require repeated tool use rather than a single code-generation response.

2. Research reproduction

Qwen3.8-Max scored 93.0 on PaperBench, ahead of Claude Fable 5's 88.8 and Opus 4.8's 80.3.

Alibaba also demonstrated a five-day research task in which the model reproduced a paper's experimental pipeline, ran 33 rounds of GPU training, and then searched for improvements to the original method.

This is potentially more useful than another model becoming marginally better at generating React components nobody requested.

3. Computer and visual interaction

On OSWorld-Verified, which evaluates an agent's ability to operate computer environments, Qwen3.8-Max scored 86.1.

The model uses visual output as part of its feedback loop. It can inspect an interface, identify errors, revise its plan, and try again. That matters for browser agents, desktop automation, document workflows, UI testing, and multimodal development.

Where Claude still wins

The "Qwen kills Claude" headline falls apart once we examine harder repository-level engineering tasks.

On SWE-bench Pro, Qwen3.8-Max scored 67.7. Claude Fable 5 scored 80.0.

On FrontierSWE, Qwen scored 73.5 while Fable 5 reached 88.8.

That is not a rounding error. It suggests Claude remains stronger when a task requires deep repository understanding, architectural judgment, and reliable changes across a complicated codebase.

The more honest conclusion is:

Qwen looks excellent at long-running, tool-heavy work.
It performs strongly on terminal, research, multimodal, and computer-use tasks.
Claude Fable 5 remains ahead on some of the hardest software-engineering benchmarks.
Neither model "wins" every category, because reality rudely refuses to fit inside one thumbnail.

There is another caveat: these scores come from Alibaba's evaluation table. Different benchmarks used different harnesses, time limits, context settings, and judging methods. The numbers are useful, but independent testing will matter more than launch-day charts.

How to use Qwen3.8-Max with Claude Code

QwenCloud provides an Anthropic-compatible API, allowing Claude Code to use Qwen3.8-Max without replacing the Claude Code interface.

First, install Claude Code:

npm install -g @anthropic-ai/claude-code

Then configure it to use Qwen:

export ANTHROPIC_MODEL="qwen3.8-max"
export ANTHROPIC_SMALL_FAST_MODEL="qwen3.8-max"
export ANTHROPIC_BASE_URL="https://dashscope-intl.aliyuncs.com/apps/anthropic"
export ANTHROPIC_AUTH_TOKEN="YOUR_QWEN_API_KEY"

claude

You will need a QwenCloud API key. The international endpoint may differ depending on your account or deployment region, so check the current QwenCloud documentation before configuring it.

And please do not paste your real API key into a public DEV article. Becoming an involuntary cloud-compute philanthropist is rarely part of the content strategy.

Can you run it locally?

Not casually.

Although only 95 billion parameters are active during each pass, the full model contains 2.4 trillion parameters. Open weights do not magically convert that into something your laptop can run between Chrome tabs.

Once the weights are released, practical deployment will likely require substantial multi-GPU infrastructure, aggressive quantization, or a hosted inference provider.

For most individual developers, QwenCloud will be the realistic way to use the full model.

The verdict

Qwen3.8-Max does not kill Claude.

It does something more consequential: it brings frontier-scale agent capabilities closer to the open-weight ecosystem.

Its strongest argument is not a single benchmark score. It is the combination of long-horizon execution, terminal performance, multimodal feedback, research reproduction, and a public 16-day development trace.

Based on the evidence available today:

I would consider Qwen3.8-Max for long-running agents, terminal workflows, research automation, visual tasks, and jobs that benefit from repeated feedback.
I would still prefer Claude Fable 5 for the hardest repository-level engineering work, especially when first-pass reliability matters.
I would wait for independent evaluations before treating Alibaba's benchmark table as the final verdict.

Qwen3.8-Max is not the model that makes Claude irrelevant.

It is the model that makes the frontier race significantly less comfortable, and that is far more interesting.

Have you tested Qwen3.8-Max in QwenCloud or Claude Code? Share the task, harness, and result in the comments. "It felt smarter" is emotionally valid, but logs are sexier.

Sources

Claude Opus 5 Is Better at Coding and Harder to Trust

Aditi Gupta — Wed, 29 Jul 2026 13:18:53 +0000

Claude Opus 5 completed one of my coding tasks considerably faster than Opus 4.8.

There was just one problem: it confidently reported that the issue was fixed when it wasn’t.

That experience captures the trade-off with Anthropic’s latest Opus model. It is faster and more capable on difficult, multi-step work, but polished output can make its mistakes harder to notice.

After testing it on coding and agent tasks, I changed three parts of my workflow.

1. Start with medium reasoning effort

More reasoning is not automatically better. For routine coding tasks, begin with medium effort and increase it only when the problem genuinely requires deeper investigation.

Higher effort can consume more tokens, expand the scope of the task, and produce a solution far more elaborate than the one you requested.

2. Verify outcomes, not explanations

A convincing explanation is not evidence that the task was completed correctly.

Ask for or independently run the relevant tests. Review the files that changed. Confirm the original bug no longer exists.

The dangerous failure mode is not nonsense. It is an incorrect result presented like finished work.

3. Control the scope

Define what the model may change before it begins:

Which files can be modified?
What behaviour must remain unchanged?
Which tests must pass?
Can it create subagents or expand the task?

Opus 5 is strongest when the job requires investigation across multiple steps. For a small, clearly defined change, that same initiative can become unnecessary complexity.

The quick version

I condensed my findings, the confidently wrong problem, and the three changes I recommend into this 90-second video:

My broader verdict is simple: Opus 5 is a meaningful upgrade for difficult coding and agent work, but only when verification is part of the workflow.

I published the complete review, including pricing, benchmark comparisons, use cases, and switching advice, on Hashnode:

hashnode.com

Have you tested Opus 5? Did it improve your workflow, or merely become more articulate while being wrong?

Fable 5 vs GPT 5.6 Sol Pro: Stop Asking Which Is Better

Aditi Gupta — Wed, 15 Jul 2026 11:42:47 +0000

Every new frontier model launch triggers the same debate: "Which one is better?" After using both Fable 5 and GPT 5.6 Sol Pro, and reading through hundreds of real-world experiences from developers, I think that's the wrong question. These models are optimized for different workflows, and understanding those differences is more useful than looking for a single winner.

GPT 5.6 Sol Pro is built for throughput. Across many developer reports, the common themes were speed, lower token usage, and cost efficiency. Developers consistently mentioned that Sol could complete large coding tasks using fewer subagents and significantly fewer tokens, making it ideal for repeated agent runs, verification passes, and high-volume development. When you're running AI-assisted workflows all day, economics becomes part of performance.

Fable 5 is optimized for judgment. While it's generally slower and more resource-intensive, many developers praised its ability to understand architecture, distinguish stale documentation from current context, and question assumptions before implementing changes. That becomes especially valuable in large, long-lived codebases where the biggest problems often come from misunderstanding the system rather than writing incorrect code.

The biggest takeaway is that many experienced developers are no longer choosing one model over the other. They're using GPT 5.6 Sol Pro for rapid implementation and iteration, and Fable 5 for architectural reviews and deeper reasoning. As AI coding tools continue to evolve, the real advantage may come from knowing which model to use at each stage of development rather than searching for a single "best" model.

What's your experience? If you've used both GPT 5.6 Sol Pro and Fable 5, I'd love to hear where each one has been most valuable in your workflow.