Skip to content
all longreads
Longread#AI4SDLC#PlatformEngineering

AI Development as a Co-Evolving Stack: Hardware, Models, Harnesses, Tools, and Traces

While we compare models, the real advantage increasingly emerges between layers: hardware changes architectural economics, post-training creates a familiar action environment, the harness assembles the model’s world, tools grant authority, and traces plus verifiable outcomes start the next cycle. The winner is not the strongest component but the system that turns a real failure into a safe improvement fastest.

23 July 2026≈ 19 min

This article is based on a research dossier checked on 23 July 2026. Specifications for new systems, benchmarks, and effects published by the companies themselves are treated as vendor claims. Public open-source harness history shows code changes but does not always disclose rollout or production status.

01

Not Model + Harness, but a production system over time

The formula Agent = Model + Harness is useful as a first approximation and dangerous as a stopping point. It hides inference economics, the actual action environment, identity, outcome verification, and the feedback loop. Two teams can buy the same checkpoint and build very different products: one supplies a familiar patch primitive, a bounded shell, and compact tool results; the other exposes a hundred novel JSON schemas, noisy context, and approval prompts for every safe step.

diagram 01 · the closed loop of a co-evolving stack
The co-evolving AI development stackHARDWAREmemory · fabricMODELpost-trainingHARNESScontext · policyTOOLS + ENVactions · outcomesEVALSreplay · gatesTRACESfailures · signalsMOATcycle timeA snapshot score ages quickly; the durable capability is learning across layers

The system has at least six layers, each answering a different question. A model score describes capability in a particular benchmark. The harness defines available context and recovery. The execution environment turns intent into a verifiable change. Evals show whether quality survived a release. Traces provide diagnostic material—but not permission to train.

Layer
Hardware + serving
What it includes
Precision, memory, interconnect, kernels, cache, scheduler
What it determines
The cost and latency of economically reachable behavior
Layer
Model + post-training
What it includes
Weights, SFT/RL, tool-use trajectories, familiar action formats
What it determines
Capability and behavioral priors
Layer
Harness
What it includes
Context, planning, compaction, persistence, sandbox, approvals
What it determines
How long the model can act and what world it sees
Layer
Tools + environment
What it includes
Shell, edit primitives, APIs, MCP, VM, identity, secrets
What it determines
Which real-world consequences are available
Layer
Evals + outcomes
What it includes
Replayable episodes, graders, repeated runs, release gates
What it determines
Whether a change can be compared safely
Layer
Traces + governance
What it includes
Calls, errors, latency, permissions, result state, retention
What it determines
How a failure becomes evidence
diagram 02 · fast and slow loops share the same evidence
Two clocks inside one improvement loopFROM SIGNAL TO RELEASE · TWO CHANGE PATHS1 · PROD SIGNALtrace · failureoutcome2 · WHERE TO FIX?localor structural3 · SLOW · MONTHS / YEARSpost-training · servingaccelerator · memory · fabric3 · FAST · DAYS / WEEKStools · prompts · contextpolicy · routing · release gates4 · RELEASEevals · canarynew evidenceESCALATE WHEN THE FAILURE CLASSREPEATS ACROSS MANY EPISODESNEW TRACES AND OUTCOMES START THE NEXT CYCLERead left to right: most signals take the fast path; repeated failure classes escalate upstream

The inner loop runs in days and weeks: teams change tool descriptions, context packaging, budgets, routing, and release gates. The outer loop runs in months and years: post-training, serving architecture, accelerators, and network fabric. A local failure does not always require a new model. When the same failure class repeats across thousands of episodes, however, the signal can move upstream into training, runtime, or the next hardware generation.

02

Hardware defines the economically reachable model space

An accelerator is more than a FLOPS count. In Hopper, Transformer Engine links FP8/FP16 to transformer workloads while NVLink changes the price of inter-GPU communication. Blackwell extends the idea to a rack-scale system, and the Vera Rubin announcement explicitly uses the term extreme codesign: CPU, GPU, interconnect, storage, and networking are presented as one system. Acceleration and TCO figures on those pages are vendor claims; the direction of design is directly observable.

The clearest shift is the divergence of training and inference. Google’s TPU 8t and TPU 8i are two systems: one optimized for large-scale pretraining, the other for serving, sampling, and long reasoning workloads. Memory, on-chip SRAM, networking, and collectives change with MoE and agentic workloads. For a CTO, this means the “per token” price hides provider decisions about batch, cache, latency, and available capacity.

diagram 03 · precision, memory, and fabric change the relative price of architectures
Hardware shapes the economically reachable model spacePRECISIONHBM / SRAMINTERCONNECTSTORAGEECONOMICALLYREACHABLEMODEL SPACEDENSE ↔ MoEexpert trafficCONTEXTKV cacheBATCHlatencyTRAIN ↔ SERVEdifferent systemsHardware does not dictate one model; it changes the relative price of architectural choices

A full vertical stack is not the only route. DeepSeek-V3 demonstrates reverse co-design: the team adapted FP8, MoE, expert balancing, and its training framework to available H800 hardware. The GPU-hours remain self-reported, but the architectural response to the constraint is documented. Anthropic and Annapurna Labs show another configuration: a dense partner loop without owning the hyperscaler.

03

A model learns to act in a particular environment

Function calling tests whether a model can form a call. A real agent must also select the tool, interpret errors, continue after a large result, verify effects, and stay within its authority. These habits emerge from the distribution of action spaces seen during post-training.

Cursor describes spending weeks adapting its harness to each new model: a familiar patch-based edit for OpenAI models and string replacement for Anthropic models. In a separate Codex write-up, the team changed tool names, the preamble, lint feedback, and reasoning-trace handling because the model had shell-first behavior. These are company observations rather than an open A/B dataset, but they align with the nature of post-training.

diagram 04 · API compatibility does not guarantee behavioral compatibility
The same checkpoint behaves differently across action spacesSAME MODELcheckpointFAMILIAR ACTION SPACEpatch · shell · known errorsUNFAMILIAR SCHEMAnew names · noisy outputSHORTER PATHclean recoveryMORE REASONINGmore failuresAPI compatibility ≠ behavioral compatibilityTool familiarity is part of post-training behavior, not a property of JSON Schema alone

A harness is necessary not because the model is “not smart enough,” but because autonomous work requires a protocol. The Codex App Server includes lifecycle and persistent threads, config/auth, sandboxing, MCP, and skills under one policy model. In Anthropic’s long-running agent experiments, a high-level prompt plus compaction was insufficient: the agent needed an initializer, a feature list, progress artifacts, git history, and small iterations.

diagram 05 · procedural logic moves while new scaffolding appears
Harness responsibility moves rather than disappearsEARLIERHARDCODED HARNESSverify after every taskforce commit / pushfetch CI logsmodel improvesNOWMODEL-CONTROLLED TOOLSgit · CI · files · branch / PRNEW SCAFFOLDINGcomputer use · multi-agent · policyless procedure here · more scaffolding thereA good harness is a temporary theory of the current model’s weaknesses

Responsibility moves as reliability improves. Cursor once rechecked every task, forced commit/push, and fetched CI logs through hardcoded harness logic. Those actions later became tools controlled by the model. At the same time, weaker computer-use capability still required dedicated routing, a subagent, and screen recording. The harness does not “end”: it stops constraining a mature capability and starts protecting a new one.

04

Tools must be designed for behavior, not merely connected

MCP solves an important but narrower problem. The tools specification standardizes discovery, schemas, and call semantics. It does not promise that a model saw a similar schema in post-training, will choose correctly among dozens of tools, receive a compact response, or act under the right identity.

A large catalog can be worse than a small set of familiar primitives. In the code execution with MCP case, Anthropic shows two costs of direct connection: schemas occupy context and intermediate results repeatedly pass through the model. A meeting-transcript example added roughly 50,000 tokens. Progressive discovery and code execution keep large data inside a sandbox and return only the necessary result. That does not make shell safe by default: composability adds package, network, and secrets-policy risk.

diagram 06 · a good action contract is larger than its JSON Schema
The tool contract is a behavioral productDISCOVERYclear boundaryOUTPUTcompact · boundedERRORSmachine-readableIDENTITYscope · OBOEFFECTidempotent?PROVENANCEreplay · evalACTIONCONTRACTMCP standardizes discovery and calls; it does not supply these product decisions
Facet
Boundary
What to specify
One action and a clear distinction from adjacent tools
Failure prevented
Wrong tool selection
Facet
Output
What to specify
Compact, structured, and bounded
Failure prevented
Context overflow and lost provenance
Facet
Errors
What to specify
Stable code, cause, and permitted next action
Failure prevented
Blind retries and loops
Facet
Authority
What to specify
Identity, scope, delegated on-behalf-of (OBO), and no prompt-based privilege expansion
Failure prevented
Action by the wrong principal or in the wrong environment
Facet
Effect
What to specify
Idempotency or explicit irreversibility
Failure prevented
Repeated destructive action
Facet
Verifiability
What to specify
Provenance, replay, and eval cases
Failure prevented
An outcome that cannot be demonstrated

An internal tool gateway is therefore not a plumbing project. It is a behavioral product for the platform team. Its moat is not the number of connected servers, but the quality of contracts and the evidence about how agents fail in selection, arguments, refusal, and recovery.

05

Traces close the loop—but do not grant an automatic right to train

“Trace” is often used as shorthand for magical self-improvement. It is better to separate four modes. Infrastructure telemetry improves serving and timeouts. Product telemetry surfaces tool-selection errors, permission stops, and compaction failures. Outcome evals connect episodes to tests, merges, reverts, or user corrections. A training trajectory is a deliberately selected and permitted rollout with a reward or verifier.

diagram 07 · one trace branches into four data modes
One trace can feed four different governance pathsPRODUCTIONTRACEINFRA TELEMETRYlatency · cache · retriesPRODUCT TELEMETRYtool errors · stopsOUTCOME EVALtests · merge · revertTRAINING TRAJECTORYselected rollout + rewardSEPARATE BASISconsent · policyredaction · retentionObservability, evaluation, and model training are different data modes

The distinction between trajectory and outcome is essential. In Anthropic’s eval methodology, a transcript is the sequence of steps while the outcome is the state of the environment afterward. τ-bench adds reliability across repeated runs: a single success is not evidence of stability. GitHub separately evaluates tool selection and arguments for its MCP Server, while Databricks connects production-like scenarios, traces, and regression gates. All of these can improve a system without changing model weights.

Even when a provider trains a model in a realistic environment, it is wrong to attribute training to all customer sessions. Cursor Privacy Mode excludes customer data from training; Anthropic separates commercial sessions from opt-in programs (policies as reviewed in July 2026); and OpenAI does not train on business/API inputs and outputs by default. Observability, eval use, and model training require separate policies, retention rules, and legal bases.

production failure → trace + end state → reproducible eval → harness/tool/model change → repeated gate → controlled rollout

A common telemetry schema, such as the evolving OpenTelemetry GenAI conventions, lowers export cost. Field names still do not decide retention, redaction, or training rights. Those remain the system owner’s responsibility.

06

Harness half-life: a strong metaphor and a weak metric

The original hypothesis was intentionally provocative: within 180 ± 60 days, half of a meaningful harness becomes unnecessary, replaced, or removed. Line churn cannot test it: a large UI diff may leave agent behavior unchanged. The research therefore fixed ten mechanisms—context, compaction, planning, edit, policy, discovery, sandbox, persistence, orchestration, and telemetry/evals—and inspected the public histories of Codex, Gemini CLI, and OpenCode.

diagram 08 · 7+ mechanisms changed substantially, but only 3–4 were clearly replaced
What a six-month public history actually supportsAUDIT FRAME · 10 MECHANISMScontextcompactionplanningeditpolicydiscoverysandboxpersistenceorchestrationevalsFREQUENT RETUNINGvisible across public historiesdirectional evidenceRETUNING ≠ REPLACEMENTa commit ledger is requiredfor numerical claimsHALF-LIFE · NOT ESTABLISHEDCodex · Gemini CLI · OpenCode, public history through 23 July 2026

At least seven mechanisms changed substantially in every project over six months. Under a strict criterion—the old behavioral path is actually retired rather than coexisting behind a feature flag—clear replacement appears in roughly three to four out of ten. The research did not find two independent projects with proven ≥ 5/10.

The uncertainty is epistemic rather than statistical. Git history does not always reveal rollout percentage, deployment status, or the role of feature flags. Young projects also inflate visible change. The strategic conclusion is still robust: a proprietary generic harness is not a one-off build but an indefinite compatibility program.

07

Concentration creates several loops, not one universal winner

Integration accelerates feedback. A team that can see model behavior, product traces, and outcomes can connect a regression to the right layer faster. The fixed cost of frontier training, multi-OS sandboxing, eval farms, and enterprise governance strengthens scale effects. That increases concentration inside individual loops, but it still does not imply that one company must own and win every layer.

diagram 09 · durable ways to close adjacent layers
Three viable integration archetypesFULL VERTICALGoogle patternsiliconruntimemodelproductLAB + CLOUDAnthropic + AWS patternpartner computemodelharnessdistributionPRODUCT-FIRSTCursor patterndistributiontracesharnesspost-trainingControl of adjacent layers matters more than owning every layer

Four ways to close the short loop

  • Google connects TPU, networking, compiler, model, Cloud, and distribution—a full upstream vertical.
  • Anthropic owns the model and harness while building hardware co-design as a partnership with AWS.
  • Cursor started with developer workflow and distribution, accumulated traces and evals, then added post-training and a model layer.
  • OpenAI is building a hybrid partner-led vertical: Stargate connects the lab to clouds, data centers, energy, and capital, while its work with Broadcom adds OpenAI-designed accelerators and networking systems. It does not own every physical layer, but it shapes the loop’s architecture and carries model and product knowledge into hardware.

The China path: a national loop built on domestic hardware

China’s shift toward domestic hardware moves the short loop to the scale of a national technology ecosystem. The authors of Pangu Ultra report pretraining a dense 135-billion-parameter model on 13.2 trillion tokens using 8,192 Ascend NPUs. In Huawei’s roadmap, Ascend 950PR targets prefill and recommendation while Ascend 950DT targets decode and training. Interconnect, low-precision formats, CANN, tooling, and openPangu evolve around them. This is a verifiable example of training a large model on a Chinese stack, not proof that the entire Chinese market has moved away from NVIDIA.

The evidence boundary around DeepSeek V4 is narrower. In its official release, DeepSeek lists V4-Pro at 1.6 trillion total and 49 billion active parameters, and V4-Flash at 284 billion total and 13 billion active parameters, but does not disclose the hardware used for base pretraining. The SLAI T-Rex study does document full-parameter post-training of the V4 family on an Ascend NPU SuperPOD: the authors report 34.22% MFU and a 2.93× improvement over the open baseline recipe, and describe continued pretraining and SFT for V4-Flash. That is verified trillion-parameter-scale training on Ascend, but it is not evidence that the base V4 model was pretrained from scratch on those accelerators.

The position of Chinese big labs in 2026 is neither an absolute ban on NVIDIA nor a simple refusal to buy it. BIS moved H200 applications to case-by-case review, but NVIDIA itself reported authorization for only small volumes to specific customers, no H200 program revenue, and effective foreclosure from China’s data-center compute market. At the same time, some labs are making a strategic choice: Reuters reported that DeepSeek gave domestic chipmakers several weeks of early V4 access for optimization while withholding it from NVIDIA and AMD. After the release, Reuters also reported new Ascend 950 inquiries from ByteDance, Tencent, and Alibaba amid constrained supply until shipments scale in the second half of 2026. The companies did not publicly confirm those procurement talks, so this is an agency-sourced market snapshot, not an official industry-wide rejection of NVIDIA.

Counterforces: open models and routing

Vertical integration is not the only force. Open weights from DeepSeek, Qwen, and GLM lower switching barriers. Qwen Code and OpenCode move session UX, permissions, and some tools outside a single lab’s control. MCP and compatible APIs reduce integration cost. RouteLLM formalizes the choice between a strong expensive model and a cheaper one, while OpenRouter Auto Router turns the same principle into a product: it classifies the task, selects from an allowed model pool, applies a cost-quality trade-off, and preserves fallback routes. It does not reproduce RouteLLM’s specific learning algorithm; it implements the same architectural idea across models from different providers. A corporate environment may still be so specific that a generic provider sees neither authority nor the final outcome.

Several ecosystems with specialized fast paths are therefore more likely than one universal runtime. The moat forms where an organization controls several adjacent layers and has an evidence channel between them. Owning everything is only one configuration.

08

The CTO boundary: rent, adapt, and own

It is more useful to draw the boundary by rate of change and organizational uniqueness than by provider logo. Frontier capability changes quickly and is rarely company-specific. Identity, policy, domain action contracts, and accepted outcomes age more slowly and determine what the system is even allowed to count as success.

diagram 10 · rent fast-changing capability and own unique, verifiable evidence
Where the enterprise boundary should sitmore specific · more authorityfaster changeАРЕНДОВАТЬfrontier modelsgeneric agent loopcommodity executionADAPTmodel / tool adapterscontext + routingbudgets + compactionВЛАДЕТЬidentity + policytool contractsevals + outcomes + tracesRent generic capability · adapt the seam · own authority and evidence
Mode
Rent
What belongs here
Frontier models, generic loop, commodity execution
Why
Rarely unique; changes quickly and requires scale
Mode
Adapt
What belongs here
Model/tool adapters, context packaging, routing, budgets, compaction
Why
The seam where provider behavior meets the local environment
Mode
Own
What belongs here
Identity, policy, tool contracts, eval corpus, outcomes, trace governance
Why
Unique knowledge, authority, and the basis of portability

What not to build by default

  • another general coding-agent loop merely to swap an API endpoint;
  • custom compaction or orchestration without a regression suite built from real episodes;
  • a catalog of hundreds of MCP tools without owners, response limits, or selection telemetry;
  • a “self-learning” system that automatically treats operational logs as permitted training data;
  • a gateway that normalizes every provider to the lowest common denominator and hides their strengths;
  • a fork of an open-source harness without a team responsible for upstream merges, security, and model compatibility.
diagram 11 · when a proprietary harness has a real business case
Decision gate for building a proprietary harness1. ANSWER YES OR NOYESNO1Is the action space genuinely unique?2Are key constraints non-delegable?3Does scale fund continuous adaptation?4Do evals and controlled experiments exist?5Is the agent loop part of the product?2. FIND THE PATTERNGENERIC NEEDRENTmanaged core · owned policy and dataUNIQUE SEAMADAPTproprietary seam · managed harnessNON-DELEGABLE + PRODUCTBUILDstrategic role · mature evalsEval maturity and strategic role are gatesDecision aid, not a formula · conditions are not equally weighted

A proprietary harness is justified when several conditions coincide: a unique action environment, sovereignty or extreme latency constraints, enough volume, mature evals, and willingness to maintain model-specific fast paths. The strongest condition is that agent capability is part of the external product and the strategic moat. A talented platform team alone is not enough.

09

The operating loop: from failure to controlled release

An enterprise can implement co-design without owning an accelerator or a foundation model. It needs to close the part of the cycle it actually controls: its tasks, authority, tools, end states, and rollout decision.

A minimum one-quarter program

  1. 01Select 20–30 real episodes. Freeze a clean start state, task contract, permitted tools, and a verifiable outcome.
  2. 02Separate trace modes. Define operational telemetry, human review, eval use, and permitted training trajectories independently.
  3. 03Inventory action contracts. For each critical tool, record identity, scope, idempotency, response limit, provenance, and owner.
  4. 04Build provider-neutral replay. Store the episode, environment version, model/harness/tool versions, and end-state evidence in a portable format.
  5. 05Introduce repeated release gates. Compare quality, variance, cost, safety, and human acceptance rather than one successful run.
  6. 06Test the layer, not the brand. Change a tool description, context, policy, routing, or model only through a controlled experiment.

In this loop, the provider supplies rapidly changing capability while the enterprise retains release authority. A new model may be cheaper and stronger on public benchmarks; production rollout still passes internal episodes, policy checks, and comparison of accepted outcomes. That is the practical defense against both technical and evidentiary lock-in.

Takeaways

What to carry into practice

  1. 01AI-agent quality is a property of a particular model × harness × tools × environment configuration over time, not a permanent score attached to one model.
  2. 02MCP and compatible APIs lower connection costs, but they do not guarantee familiar model behavior, effective recovery, or rich session semantics.
  3. 03Public history supports a fast harness-reconfiguration cycle, but not the literal claim that half of the harness is replaced every six months.
  4. 04A production trace, an eval episode, and a training trajectory are different data modes; permission to observe does not automatically grant permission to train.
  5. 05Enterprises should rent fast-changing generic capability, adapt the seam, and own authority, contracts, outcomes, evals, and an exit plan.
Sources

Primary materials, research, and documentation

Other sources

  1. NVIDIA · Hopper ArchitectureTransformer Engine, FP8/FP16, and NVLink; performance figures are vendor-reported
  2. NVIDIA · Blackwell Architecturerack-scale co-design, precision, and interconnect
  3. NVIDIA · Vera Rubin platformthe extreme-codesign announcement; relative economics are company claims
  4. Google Cloud · TPU 8t and TPU 8i technical deep divethe split between pretraining and inference/reasoning systems
  5. Google Cloud · Ironwood TPUs and Axion VMsco-design across silicon, systems, and software
  6. THUDM / Z.ai · slimean open RL framework with rollouts, tools, sandbox feedback, and verifier rewards
  7. Model Context Protocol · Tools specificationthe normative contract for discovery, schemas, and calls
  8. GitHub · Offline evaluation of GitHub MCP Serverpre-release evaluation of tool selection and arguments
  9. Databricks · coSTARproduction-like scenarios, traces, and regression gates; results are self-reported
  10. OpenTelemetry · GenAI semantic conventionsagent/tool/evaluation telemetry fields and warnings about sensitive data
  11. Google · Gemini CLI repositorypublic history of context, policy, persistence, and subagent mechanisms
  12. Anomaly · OpenCode repositorypublic history of a model-agnostic harness and its v2 migrations
  13. Huawei · Ascend and SuperPoD roadmapAscend 950PR/950DT specialization and CANN/openPangu plans; figures and dates are vendor claims
  14. U.S. BIS · H200 export licensing policy for Chinacase-by-case H200 export-license review since January 2026
  15. NVIDIA · FY2026 Form 10-Ksmall-volume H200 authorization, no program revenue, and effective foreclosure from the China market
  16. OpenRouter · Auto Routerproduction routing by task type, cost, and quality with fallbacks

Harnesses and models

  1. DeepSeek · DeepSeek-V3 repository and reportFP8, MoE, and adapting the training framework to H800; cost is self-reported
  2. Anthropic · Expanding our use of AWS Trainiuman example of partner-based hardware/model co-design
  3. OpenAI · Unlocking the Codex harnesscore loop, persistence, sandbox, MCP, and the limits of session semantics
  4. OpenAI · Harness engineeringagent-readable scaffolding and feedback loops; productivity is self-reported
  5. Anthropic · Effective harnesses for long-running agentsinitializer, progress artifacts, a feature list, and small iterations
  6. Anthropic · Harness design for long-running appsplanning, verification, and state transfer across context windows
  7. Anthropic · Effective context engineering for AI agentscompaction, structured notes, subagents, and just-in-time retrieval
  8. Anthropic · Claude Code sandboxingthe link between isolation and autonomy; approval-prompt reduction is internally measured
  9. Cursor · Continually improving our agent harnessmulti-week model adaptation and differences in edit primitives
  10. Cursor · Improving the harness for OpenAI Codex modelsshell-first behavior, tool naming, and lint feedback
  11. Cursor · What we’ve learned building cloud agentsmoving procedural logic from the harness into model-controlled tools
  12. Cursor · Composer 2 technical reportRL in production-like sessions and an internal eval loop; benchmarks are company claims
  13. Cursor · Self-summarizationtraining a model to work with compaction inside the training loop
  14. Cursor · Data Use & Privacy OverviewPrivacy Mode, ZDR, and boundaries on permitted data use
  15. Alibaba Qwen · Qwen3-Coderlong-horizon RL and 20,000 environments, as reported by the team
  16. Alibaba Qwen · Qwen Codean open multi-provider harness with a preferred fast path for Qwen
  17. Anthropic · Code execution with MCPprogressive discovery and handling large intermediate data outside model context
  18. Anthropic · Writing tools for agentshow names, descriptions, schemas, and response shape affect agent behavior
  19. Anthropic · Demystifying evals for AI agentsthe distinction between transcript/trace and outcome, plus graders and eval harnesses
  20. Anthropic Privacy Center · Model training data policyboundaries on using commercial chats and coding sessions
  21. OpenAI Help Center · How data is used to improve model performancethe distinction between consumer controls and business/API no-training defaults
  22. OpenAI · Codex repositorypublic harness history used to inspect change cadence
  23. OpenAI · Building the compute infrastructure for the Intelligence AgeStargate as a partner-led infrastructure ecosystem and reinvestment loop
  24. OpenAI and Broadcom · OpenAI-designed AI acceleratorsplans to co-develop accelerators and networking systems; schedule and scale are company claims
  25. DeepSeek · DeepSeek V4 Preview Releaseofficial V4-Pro and V4-Flash sizes; base-pretraining hardware is not disclosed
  26. Reuters · DeepSeek V4 early access for domestic chipmakersan Investing.com reprint of a Reuters report on Huawei’s early access and NVIDIA/AMD being left out of prerelease optimization, attributed to unnamed sources
  27. Reuters · Demand for Ascend 950 after DeepSeek V4an Investing.com reprint of a Reuters report: ByteDance, Tencent, and Alibaba inquiries and constrained supply until the second half of 2026, attributed to unnamed sources

Research

  1. Cottier et al. · The rising costs of training frontier AI modelshistorical estimates and scenarios for frontier-training cost
  2. Wang et al. · Executable Code Actions Elicit Better LLM Agentsresearch on code as a compositional action space
  3. Yao et al. · τ-benchtool-agent reliability across repeated runs and end states
  4. Yin et al. · Pangu Ultra on Ascend NPUspretraining a dense 135-billion-parameter model on 13.2 trillion tokens and 8,192 Ascend NPUs
  5. Li et al. · SLAI T-Rex on Ascend SuperPODfull-parameter DeepSeek V4 post-training, MFU, and a CPT/SFT workflow on Ascend
  6. Ong et al. · RouteLLMrouting between stronger and cheaper models as a counterexample to a single-provider design
Share