DeepSeek Harness Review: Alla tre körningar rapporterades klara. Endast en sida fungerade faktiskt.

154 302 stjärnor. Varje recension jag läste sa samma tre saker: allt är ett plugin, sessionsloggen är append-only, och det är en utvecklareförhandsvisning.

Inte en enda berättade hur mycket disk det äter. Eller hur mycket RAM en inaktiv session håller. Eller vad som händer när du pekar det mot en endpoint som inte är DeepSeeks egen.

Så jag installerade det och gav det ett jobb, tre gånger: bygg en live ISS-spårare i en enda fristående HTML-fil. Tre olika provider-konfigurationer, samma prompt, samma modell. Alla tre slutfördes. Alla tre skrev ut ett självsäkert "Klar" med en punktlista över allt de påstås ha verifierat.

Sedan öppnade jag de tre sidorna i en webbläsare. Två av dem var trasiga.

Viktiga slutsatser

• npm install @deepseek-ai/dsh drog 531 paket och 306 MB på macOS. Inte 1,5 GB, men inte heller litet, och själva dsh-paketet är 172 KB av det.
• dsh-webbservern vilade på 35 till 40 MB RSS med en aktiv session öppen, efter att ha toppat runt 212 MB vid start. Siffran på 500 MB som folk nämner är inte serverprocessen.
• Trajectory-vyn är det verkliga i denna utgåva. Det är en ren append-only JSONL-händelseström på disk, och det är vad som gjorde att jag kunde diagnostisera konfigurationsproblemet på minuter istället för timmar.
• Två YAML-rader (compat.thinkingFormat och en riktig maxTokens) ändrade samma uppgift från en 36-stegs, 422-sekunders körning till en 15-stegs, 152-sekunders sådan. Ingen av raderna finns på dokumentsajten.
• Varje körning rapporterade framgång. Endast en producerade en sida med noll konsolfel. Läs utdata, inte sammanfattningen.
• Det är en utvecklareförhandsvisning, och README säger det med versaler. Innesluten pilot, ja. Produktionskontrollplan, nej.

Här är hela artikeln i en bild. Två ISS-spårarsidor, samma prompt, samma modell, en konfigurationsskillnad. Vänster är körningen jag justerade. Höger är körningen jag inte gjorde.

Sida vid sida jämförelse av två ISS-spårarsidor byggda av DeepSeek Harness, den vänstra med en förvrängd världskarta och ett föråldrat märke fastnat, den högra renderar korrekt med en levande markör

Vänster: den justerade körningen, 152 sekunder, femton felaktiga SVG-sökvägar och ett märke fruset på "Föråldrad". Höger: den naiva körningen, 422 sekunder, noll konsolfel. Båda rapporterade klara.

Varför varje DeepSeek Harness-recension säger samma tre saker

Repo:t lades upp den 13 augusti och när jag började skriva hade det 154 302 stjärnor och 15 960 forks under en MIT-licens (GitHub, augusti 2026). I den hastigheten är det mesta av bevakningen en läsning av README, eftersom det inte har funnits tid till något annat.

Så det befintliga DeepSeek Harness-recensionslandskapet delas upp i tre läger, och alla tre har samma hål. Källgranskningsartiklarna plockar isär plugin-sömmarna och kör aldrig ett riktmärke. Dataartiklarna jämför tokenantal och hoppar explicit över installationsstorlek och minne. Enterprise-upphandlingsartiklarna når en slutsats med nästan inga uppmätta siffror alls.

Ingen installerade det, körde en uppgift från början till slut och öppnade sedan resultatet.

Under tiden fanns den skarpaste kritiken inte i någon recension. Det var två kommentarer i lanserings-tråden, som drog 737 poäng och 309 kommentarer på fyra dagar.

Två ordagranna Hacker News-kommentarer om DeepSeek Harness installationsstorlek och inaktiv minnesanvändning

De två klagomålen som denna recension faktiskt försöker kontrollera, citerade ordagrant från lanserings-tråden.

Användare Kuyawa: "47mb downloaded, 1.5gb after build, wtf?" och, i en redigering, "35 dependencies make up for 1.4gb, what they are for?" Användare eglintondust, i en under-tråd om CPU-belastning: "Memory usage definitely is out of hand, have an idle session right now eating 500MB" (Hacker News, augusti 2026).

Det är de två siffrorna jag ville kontrollera först, eftersom de är de två som avgör om den här saken bor på din bärbara dator. Båda visade sig vara mer komplicerade än citaten antyder, och en av dem mäter något annat än vad folk antar. Om du behöver arkitekturprimeraren innan något av detta är meningsfullt, det är en annan artikel: vad DeepSeek Harness faktiskt är.

Hur jag satte upp denna DeepSeek Harness-recension: En uppgift, en endpoint

Uppsättningen är avsiktligt tråkig så att variabeln är konfigurationen, inte uppgiften.

Uppgiften. Bygg en live ISS-spårare i en självständig index.html. Den behöver ett externt API, en kartrendering, en pollningsloop och felhantering, så den tvingar fram en riktig multi-steg verktygsloop istället för en engångs-koddump. Och avgörande nog, jag kan öppna resultatet och se omedelbart om det fungerar.

Modellen. deepseek-ai/deepseek-v4-flash-0731, samma modell i alla tre körningar, så inget i jämförelsen är en modells skillnad.

Endpointen. Det här är delen folk hoppar över. Harness levereras utan modell. Den behöver en OpenAI-kompatibel bas-URL och en nyckel, punkt slut, och konfigurationsytan för det är där alla mina tre problem kom ifrån. Jag körde den mot en värdbaserad OpenAI-kompatibel endpoint med fast DeepSeek-prissättning och ingen topptimmesavgift, vilket är viktigt när du är på väg att köra samma uppgift upprepade gånger och vill att räkningen ska vara jämförbar mellan körningar. Alla kompatibla endpoints fungerar på samma sätt.

En ärlig notering om den mittersta raden, eftersom den bet mig senare: den returnerar {"code":200,"msg":"succeed","data":[...]} snarare än standard OpenAI {"object":"list","data":[...]} -kuvertet. data-arrayen finns där, så en tolerant klient är okej, men anta inte att varje "OpenAI-kompatibel" endpoint är byte-identisk med specifikationen.

Priser lästes från V4 Flash-modellsidan den 18 augusti 2026. Ingen rabattmärkning på någon DeepSeek-modell just nu, så inget här är en tidsbegränsad taxa.

Steg 1: Installera DeepSeek Harness och mät vad det faktiskt kostar

Allt härifrån är reproducerbart på macOS med Node 22.19+ eller 24+ (det finns inget stöd för 23.x, och många guider får detta fel). Jag körde Node v24.15.0 och @deepseek-ai/[email protected].

Börja med snabbstarten, som är ett kommando:

bashCopy
1node -v                        # ^22.19.0 || >=24, inte 23.x
2npx @deepseek-ai/dsh web       # Webb-UI på http://127.0.0.1:3080
3

För att få en siffra du faktiskt kan jämföra med påståendet 1,5 GB, installera istället i en ren katalog och mät:

bashCopy
1mkdir dsh-size && cd dsh-size && npm init -y
2npm install @deepseek-ai/dsh
3du -sh node_modules
4du -sh node_modules/* | sort -h | tail -8      # där vikten bor
5

Här är vad som producerades på min maskin:

textCopy
1added 531 packages in 2m
2306M    node_modules
3255     top-level entries in node_modules
4172K    node_modules/@deepseek-ai/dsh          <- själva paketet
5
6 13M    node_modules/@shikijs
7 13M    node_modules/openai
8 14M    node_modules/@google/genai
9 17M    node_modules/@img/sharp-libvips-darwin-arm64
10 24M    node_modules/@mistralai/mistralai
11 26M    node_modules/node-pty
12 27M    node_modules/@deepseek-ai
13 34M    node_modules/@opentelemetry
14

Så: 306 MB, inte 1,5 GB. Siffran 1,5 GB i den Hacker News-kommentaren är en fullständig källbyggnad, som drar in utvecklingsberoenden och byggutdata över hela monorepot. Runtime-installationen är en femtedel av det.

Det sagt, 306 MB för en kodningsagent är fortfarande mycket, och uppdelningen förklarar exakt varför folk är irriterade. Du installerar tre leverantörs-SDK:er du kanske aldrig anropar (openai, @google/genai, @mistralai/mistralai kommer till 51 MB mellan dem), ett fullt OpenTelemetry-träd, en native sharp-binär och en syntax-highlighter. "Allt är ett plugin" har en fraktkostnad, och just nu betalar du allt på förhand oavsett om du använder dessa vägar eller inte.

För inaktivt minne, starta webbprofilen, öppna en session, lämna den ifred och läs RSS:

bashCopy
1npx @deepseek-ai/dsh web --port 3099
2# sedan, i ett annat skal:
3ps -o pid,rss,command -p $(pgrep -f "dsh web")
4

Samplade en gång per minut i fem minuter med en aktiv session öppen och ingen uppgift som kördes:

textCopy
1t+0s     101.8 MB     (direkt efter att sessionen öppnades)
2t+60s     37.0 MB
3t+120s    39.8 MB
4t+180s    38.8 MB
5t+240s    35.8 MB
6t+300s    35.0 MB
7

Den nådde cirka 212 MB under start, sjönk till ~102 MB när UI:et anslöt, sedan tog sopsamlaren ner den till 35 till 40 MB-bandet och den stannade där. Det är inte "ur kontroll".

Men eglintondust har inte nödvändigtvis fel, och det här är delen värd att förstå: dsh webbprofil är en lokal server plus en webbläsarflik. De 35 MB är servern. UI:et är en full webbapp i din webbläsare, och det minnet debiteras Chrome, inte dsh. Om du tittar på en 500 MB inaktiv session i Aktivitetsövervakaren, kontrollera vilken process det tillskrivs innan du rapporterar en bugg. Full installationsdetalj finns i 10-minuters installationsgenomgången.

Verklig terminalutdata som visar DeepSeek Harness installationsfotavtryck och inaktiva minnesmätningar

De faktiska mätningarna, med kommandona synliga. 306 MB installerat, 35 MB inaktivt.

Steg 2: Peka DeepSeek Harness mot din egen endpoint

I UI:et är detta Inställningar sedan Modeller sedan Lägg till en anpassad leverantör: leverantörs-ID, bas-URL, protokoll, nyckel, modellista. Du kan också skriva det direkt i $DSH_HOME/settings.yaml (standard ~/.dsh/settings.yaml), vilket är vad jag gjorde, eftersom filversionen är vad du kan diffa mellan körningar.

Sektioner i den filen är nycklade efter plugin-ID, vilket inte är uppenbart första gången. Leverantörsdikten tillhör llm-pi-ai, och standardmodellvalet tillhör agent-default-model:

yamlCopy
1llm-pi-ai:
2  providers:
3    atlas:
4      displayName: Atlas Cloud
5      api: openai-completions
6      baseURL: https://api.atlascloud.ai/v1
7      apiKeyEnv: ATLAS_API_KEY
8      models:
9        - id: deepseek-ai/deepseek-v4-flash-0731
10
11agent-default-model:
12  provider: atlas
13  model: deepseek-ai/deepseek-v4-flash-0731
14

Det är den naiva konfigurationen, och det är den jag började med. Den fungerar. Hämta en nyckel från Atlas-konsolen, export ATLAS_API_KEY=..., och körningen går igenom. Notera att apiKeyEnv är en referens, inte hemligheten, så ingen nyckel hamnar någonsin i denna fil.

En detalj från UI:et som är lätt att missa och genuint bra: när nyckeln kommer från miljön renderas API-nyckelfältet som Tillhandahålls av startmiljön (skrivskyddat). Den gröna punkten bredvid leverantören betyder att vägen löstes. Den röda punkten bredvid den inbyggda DeepSeek-leverantören betyder att den inte har några inloggningsuppgifter. Det är en tvåsekunders hälsokontroll du inte behöver leta efter.

Två saker med denna konfiguration är dock tyst felaktiga, och jag upptäckte det inte förrän jag jämförde trajectories. Håll den tanken tills Steg 4.

DeepSeek Harness Inställningar Modeller-sida som visar en anpassad OpenAI-kompatibel leverantör med namnet Atlas Cloud med en grön statuspunkt och dess API-nyckel tillhandahållen skrivskyddad av startmiljön

Inställningar, Modeller, anpassad leverantör. Grön punkt betyder att vägen löstes; den inbyggda DeepSeek-leverantören ovanför är röd eftersom den inte har någon nyckel.

Steg 3: DeepSeek Harness-recensionens tre körningar, sida vid sida

Samma prompt varje gång. Klistra in detta ordagrant om du vill reproducera det:

textCopy
1Bygg en ensidig ISS-spårare i en självständig index.html.
2
3Krav:
4- Hämta ISS-positionen från https://api.wheretheiss.at/v1/satellites/25544 var 5:e sekund.
5- Rendera en världskarta med en markör på aktuell lat/lon, plus ett avtagande spår av de senaste 60 positionerna.
6- Visa höjd (km), hastighet (km/h) och aktuell lat/lon i en läsbar panel.
7- Inget byggsteg, ingen npm-installation, ingen API-nyckel. Vanilla JS + inline CSS endast.
8- Hantera hämtningsfel utan att sidan kraschar: behåll den senaste kända positionen och visa en föråldrad märke.
9- Skriv filen, rapportera sedan klar.
10

Kör den headless så att utskriften är ren:

bashCopy
1export DSH_HOME=$PWD/dsh-home
2export ATLAS_API_KEY=<din nyckel>
3dsh --profile headless "<prompten ovan>"
4

Tre konfigurationer:

• Körning A, den justerade: compat.thinkingFormat: deepseek, contextWindow: 1048576, maxTokens: 131072.
• Körning B, den naiva från Steg 2: modellposten är inget annat än id.
• Körning C, det troliga misstaget: samma som A men med maxTokens: 4096, en siffra jag lyfte direkt från adapterns egen README-exempel.

Alla tre avslutades med 0. Alla tre skrev en index.html. Alla tre skrev ut en sammanfattning som påstod verifiering. Körning C:s sammanfattning skröt till och med om självreparation: "Ett par buggar jag fångade och fixade under bygget: en odefinierad variabel i spårfadern, felaktig N/S-E/W-suffixlogik..."

Sedan öppnade jag alla tre filer i en riktig webbläsare med konsolen öppen, och lät dem polla i två cykler.

Läs den tabellen igen. Den snabbaste körningen och körningen jag noggrant hade justerat levererade båda trasiga sidor. Den långsamma, naiva, dyraste körningen är den enda som fungerade.

Körning A:s misslyckande är det lärorika. Telemetripanelet var perfekt: 431 km höjd, 27 547 km/h, korrekt lat/lon, uppdateras live. Kartan under den var en grön klump, eftersom alla femton kontinentbanor slutade med en förvirrad L utan koordinater ("... L48.0 624.0 L Z"). Och märket sa "Föråldrad, behåller senaste position" med "Senaste uppdatering: -" medan tre framgångsrika hämtningar satt i nätverksfliken. Den fick den svåra delen rätt och den synliga delen fel.

Anledningen finns i dess egen resonemangslogg, vid steg 12, med dess egna ord: den hade raderat en variabel som dess kartbyggare fortfarande använde, märkte det och gick vidare ändå. Den typen av självförvållad regression sent i en körning är precis vad en append-only trajectory är bra för, vilket är nästa steg.

Körning C är roligare och värre. Den påstod sig ha fixat spårfaderbuggen och N/S-suffixlogiken. Spåret är precis vad som är trasigt (tolv NaN-cirklar, inget spår renderas alls), och latitudetiketten läser -34,76° S, vilket är dubbeltecknat. Den fixade inget av de två saker den sa att den fixade, och den verifierade sitt arbete med node --check, som tolkar JavaScript-syntax och vet ingenting om huruvida en SVG-bana är laglig.

Den tredje körningens ISS-spårarsida med ett NaN-positionerat spår, en markör fast i det övre vänstra hörnet och en dubbeltecknad latitud-etikett

Körning C, den 50-sekunders körningen: snygg, live och tyst trasig på de två ställen den påstod sig ha fixat.

Inget av detta är egentligen en Harness-bugg. Det är en kodningsagent-bugg som Harness troget utförde och sedan troget rapporterade som framgång. Vilket leder oss till den enda delen av denna release som verkligen imponerade på mig.

Steg 4: Två-raders fixen, och DeepSeek Harness Trajectory-vyn som hittade den

Körning B som tog 2,8x längre tid än Körning A var inte meningsfullt för mig. Samma modell, samma uppgift, och den enda skillnaden var några rader YAML. Så jag gick till Trajectory.

Den officiella beskrivningen är korrekt, vilket är sällsyntare än det borde vara: "Allt som modellen ser spelas in i en append-only sessionslogg: systemprompter, resonemang, verktygsanrop och resultat, underagentplanering och varje kontextinjektion... I Trajectory-vyn kan du inspektera dessa poster efter källa. Återuppta, förgrena, sök och spela upp alla arbetar på samma händelseström" (DeepSeek Harness, augusti 2026).

Det är inte marknadsföring. Strömmen är en riktig fil:

bashCopy
1ls $DSH_HOME/sessions/<workspace>/session-<uuid>/session.jsonl.zstd
2

En JSON-händelse per rad, zstd-ramad, append-only. Körning A producerade 606 händelser; Körning B producerade 1 709. Filtrera efter källa i UI:et, eller bara greppa den avkodade filen. Händelsetyperna är exakt vad meningen ovan lovar: turn/start, step/start, request/header, request/context, assistant/chunk, reasoning-chunks, tool-call-chunks, tool/call, tool/result, step/end, turn/end.

Händelsen request/header är vad som löste det. Den registrerar konfigurationen som faktiskt lades på tråden:

jsoncCopy
1// Körning A
2{"config":{"provider":"atlas","model":"deepseek-ai/deepseek-v4-flash-0731","maxTokens":131072},
3 "adapterDefaults":{"maxTokens":true}}
4
5// Körning B
6{"config":{"provider":"atlas","model":"deepseek-ai/deepseek-v4-flash-0731"}}
7

Körning B skickade ingen utgångsgräns alls, och dess resonemang svällde till 72 420 tecken över 33 block mot Körning A:s 6 094 över 9. Det är vart de extra 270 sekunderna och de extra 44 170 utgångstokenen gick.

Orsaken är dokumenterad, men inte på dokumentsajten. Den är begravd i packages/llm/llm-pi-ai/README.md: resonemangsdialekten gissas från endpoint-URL:en. Med underhållarnas egna ord, compat.thinkingFormat är något "pi-ai gissar från endpoint-URL:en; en privat gateway-URL säger inget, så en DeepSeek-dialekt gateway skulle talas till i OpenAI-dialekten utan möjlighet att korrigera det."

Min endpoint returnerar reasoning_content, DeepSeek-stavningen. Dess värdnamn säger inget om det. Så på Körning B föll adaptern tillbaka på OpenAI-dialekten, kunde inte skicka en resonemangsnivå, och modellen resonerade på sin egen standard vid varje av 36 anrop. Separat, en modellpost som bara deklarerar id ärver väg-fallbackarna defaultContextWindow: 262144 och defaultMaxTokens: 32768, så en 1 048 576-token modell förlorar tyst tre fjärdedelar av sitt fönster.

Båda är två rader:

yamlCopy
1llm-pi-ai:
2  providers:
3    atlas:
4      api: openai-completions             # compat.* finns ENDAST under detta protokoll
5      baseURL: https://api.atlascloud.ai/v1
6      apiKeyEnv: ATLAS_API_KEY
7      compat:
8        thinkingFormat: deepseek          # sluta gissa från URL:en
9        supportsReasoningEffort: true
10      models:
11        - id: deepseek-ai/deepseek-v4-flash-0731
12          contextWindow: 1048576          # åsidosätt 262 144-fallbacken
13          maxTokens: 131072               # lämna resonemang reellt utrymme
14

Två saker att ha i huvudet. Upplösningsordningen är modell, sedan väg, sedan den installerade katalogposten, sedan pi-ai:s URL-gissning, så ett modellnivåvärde vinner. Och compat.* finns endast under api: openai-completions; placera den någon annanstans och upplösningen misslyckas helt. Adaptern stöder också avsiktligt inte Bedrock, Vertex, Azure eller Codex, eftersom deras autentisering kräver mer än en nyckel, en endpoint och headers.

Ställ in det, och Körning A:s trådkonfiguration är rätt, dess tokenräkning sjunker 3,5x, och den levererar fortfarande en trasig karta. Vilket är den ärliga sammanfattningen av hela denna övning: konfigurationsfixen är verklig, och den fixar räkningen, inte kodgranskningen du fortfarande måste göra själv.

Den append-only sessionshändelseströmmen från en verklig DeepSeek Harness-körning, med händelseantal och förfrågningshuvudet som avslöjade konfigurationsproblemet

Trajectory-händelseströmmen från Körning A: 606 händelser, och den som avslöjade den saknade utgångsgränsen.

Vad denna DeepSeek Harness-recension kostade, och om den är produktionsklar

Tre fulla agentkörningar av en icke-trivial uppgift, direkt från trajectories, till den fasta $0,14 in / $0,28 ut per 1M taxa:

Två saker värda att dra ut ur det. För det första, cachesiffrorna är verkliga och endpointen rapporterar dem: 93,8% av alla prompt-token över de tre körningarna kom tillbaka som cache-läsningar, vilket är vad som gör en agentloop överkomlig överhuvudtaget. För det andra, den felkonfigurerade körningen kostade 3,5x den justerade för en uppgift av identisk storlek. Det är det faktiska priset för de två YAML-raderna.

Lägg märke till formen på det första anropet i varje körning: runt 11 000 indata-token innan agenten har gjort något. Det är systemprompten, verktygsschemana och färdighetskatalogen som "allt är ett plugin" innebär, och du betalar det vid varje ny session. Det är varför cache-träfffrekvensen spelar större roll på denna harness än på en tunnare, och varför en Minimal-läge körning (bash plus en filredigerare endast) är värd att prova om din uppgift inte behöver hela verktygsuppsättningen.

Så kan du lägga den i produktion? Nej, och projektet håller med dig. README:s egna ord: "DeepSeek Harness is currently in developer preview and is iterating rapidly. THERE WILL BE COMPATIBILITY-BREAKING CHANGES." Webb-UI:et öppnas med en modal som säger "DeepSeek Harness 0.1 remains in testing for Harness developers." MIT-licens innebär att du kan göra vad du vill med det; det betyder inte att API:et du bygger mot kommer att finnas nästa månad.

Resten av risklistan är kort och verklig. Det finns en anonym telemetri-UUID. Plugins och MCP-servrar exekveras utanför bash-sandlådan, så ett plugin är kod du väljer att lita på. Och som denna recension fann på det hårda sättet, dokumenteras inställningarna som styr kostnad och korrekthet i ett paket-README snarare än guiden, vilket innebär att din första räkning kan vara flera gånger vad den borde vara av skäl som inget felmeddelande kommer att berätta för dig.

DeepSeek Harness-recension: Vanliga frågor

Är DeepSeek Harness produktionsklart?

Nej. README anger det tydligt: "DeepSeek Harness is currently in developer preview and is iterating rapidly. THERE WILL BE COMPATIBILITY-BREAKING CHANGES." Webb-UI:et upprepar det i en startmodal. En innesluten pilot på en icke-kritisk arbetsbelastning är rimlig idag. En produktionskontrollplan som ditt team är beroende av är det inte, eftersom API-ytan du bygger mot är uttryckligen instabil.

Hur mycket disk och minne använder DeepSeek Harness faktiskt?

På macOS drog npm install @deepseek-ai/dsh 531 paket och 306 MB, varav själva dsh-paketet är 172 KB. Den vida citerade 1,5 GB är en fullständig källbyggnad, inte runtime-installationen. Webbserverprocessen vilade på 35 till 40 MB RSS med en aktiv session öppen, efter att ha toppat nära 212 MB under start. UI:ets eget minne debiteras din webbläsare, inte dsh.

Varför är min DeepSeek Harness-körning så mycket långsammare och dyrare än förväntat?

Mest troligt deklarerar din modellpost inget annat än id. Det ärver väg-fallbackarna defaultContextWindow: 262144 och defaultMaxTokens: 32768, och det låter adaptern gissa resonemangsdialekten från din endpoints värdnamn. I mitt test producerade den kombinationen 36 steg istället för 15 och 3,5x tokenkostnaden för samma uppgift. Ställ in compat.thinkingFormat, en riktig contextWindow och en riktig maxTokens.

Fungerar DeepSeek Harness med icke-DeepSeek endpoints?

Ja, alla OpenAI-kompatibla bas-URL:er fungerar, och det är så de flesta kommer att köra det. Haken är att resonemangsdialekten härleds från URL:en, så en DeepSeek-dialekt gateway på ett neutralt värdnamn talas till i OpenAI-dialekten. compat.thinkingFormat: deepseek är fixen, och den finns bara under api: openai-completions. Bedrock, Vertex, Azure och Codex stöds avsiktligt inte.

Är Trajectory-vyn faktiskt användbar, eller är det marknadsföring?

Den är användbar, och det är den starkaste delen av denna release. Sessionsloggen är en riktig append-only JSONL-fil du kan filtrera efter källa, återuppta, förgrena och spela upp, och händelsen request/header berättade exakt vilken konfiguration som nådde tråden, vilket är vad som löste mitt problem. Vad den inte gör är att förklara varför modellen valde något. Den registrerar vad modellen såg, inte varför den bestämde sig.

DeepSeek Harness vs Claude Code eller OpenCode, vilken ska jag använda dagligen?

Om du vill ha något som skriver kod pålitligt idag, inte denna, inte än. Välj Harness när agentruntime i sig är vad du vill ändra, eftersom att byta loop, verktyg eller UI är konfiguration här snarare än en fork. För en sifferbaserad jämförelse av tokenanvändning, se DeepSeek Harness vs OpenCode, och för förlängningslagret, vilka plugins som är värda att installera.

---

Körningar utförda 18 augusti 2026 på macOS, Node v24.15.0, @deepseek-ai/[email protected], modell deepseek-ai/deepseek-v4-flash-0731 serverad över en OpenAI-kompatibel endpoint på Atlas Cloud. Varje tokenantal, väggklocktid och konsolfel i denna artikel kom från sessionsloggarna och webbläsarkonsolerna för dessa körningar.