DEV Community: Samod Alex

ChatGPT and Grok Just Joined the Pentagon's AI Platform. Claude Didn't.

Samod Alex — Thu, 03 Sep 2026 04:37:58 +0000

The Department of War (the renamed Department of Defense) rolled out custom versions of ChatGPT and Grok on its internal AI platform this week. More than three million civilian and military personnel now have access to tools built for what the department calls “warfighter needs.”

Google's Gemini was already part of that ecosystem. Anthropic's Claude isn't — and given the Pentagon's very public fight with Anthropic over how AI can be used, that absence is difficult to treat as incidental.

What just launched

GenAI.mil is the Pentagon's secure enterprise AI platform, built to give personnel access to frontier models inside authorized government cloud infrastructure rather than sending government work through ordinary consumer services. Google launched Gemini for Government on the platform in December 2025, making it the first enterprise AI tool available through GenAI.mil.

On August 31, two more tools joined it: ChatGPT Mil, built through OpenAI's government program, and Grok for Government, delivered under SpaceX's Starshield AI brand. The Pentagon says more than 1.7 million unique users have signed up since GenAI.mil launched nine months ago, out of more than three million personnel — roughly 57% of the department.

That's a striking adoption rate for a platform operating across one of the world's largest organizations.

ChatGPT Mil: the familiar option

ChatGPT Mil looks deliberately close to the product most developers already know: chat, file uploads, projects, and custom GPTs. The Pentagon says it is intended for document-heavy unclassified work including planning, policy, logistics, administration, procurement, research, and mission support.

OpenAI says the deployment runs in authorized government cloud infrastructure, with model- and platform-level safeguards, and that data processed on GenAI.mil remains isolated from OpenAI's public and commercial model-training systems.

More capabilities are scheduled to arrive over time. For now, the pitch is relatively straightforward: take the familiar ChatGPT experience and put it inside a government-controlled environment.

Grok for Government: a different pitch

Grok's positioning is more operational. The Pentagon says Starshield AI's Grok for Government is accredited for Controlled Unclassified Information at Impact Level 5, and includes deep-thinking inference, three reasoning modes — Auto, Fast, and Expert — along with customizable workspaces, persistent projects, and reusable “playbooks” designed to preserve institutional knowledge as personnel rotate.

Its stated use cases range from market research for acquisition professionals to supply-chain management for logisticians. In other words, the department is pitching Grok not simply as a chatbot, but as an enterprise reasoning and workflow tool that can be embedded into recurring military and administrative processes.

The tool that's missing

Here's what makes this more interesting than another government AI launch: Claude isn't on GenAI.mil.

Gemini, ChatGPT, and Grok are now part of the platform's frontier-model lineup. Anthropic isn't.

The Pentagon has not publicly said that its dispute with Anthropic is the specific reason Claude is absent from GenAI.mil. But the timing matters: the department spent much of 2026 fighting Anthropic over precisely the restrictions that the company wanted attached to government use of Claude.

Why Anthropic said no

Back in February 2026, Anthropic and Defense Secretary Pete Hegseth were in a public standoff. Anthropic said negotiations had reached an impasse over two narrow restrictions: using Claude for mass domestic surveillance of Americans and using it in fully autonomous weapons. Anthropic argued that today's frontier models were not reliable enough for fully autonomous lethal weapons, while also saying it supported lawful national-security uses outside those two exceptions.

Hegseth's position was fundamentally different. The Pentagon argued that the department, not a private AI company, should determine what lawful military applications its technology could support. On February 27, Hegseth directed the department to designate Anthropic a supply-chain risk to national security, following President Trump's order that federal agencies stop using Anthropic's technology.

Anthropic sued in California and Washington, D.C.

The litigation then split into two very different tracks. In California, Judge Rita Lin issued a preliminary injunction on March 26 blocking the government from implementing the presidential directive and the supply-chain designation while the case proceeded. The order explicitly said it did not prevent the Department of War from moving to other AI providers, provided those actions complied with applicable law.

The parallel D.C. litigation initially went the other way: the D.C. Circuit declined to block the Pentagon's action while that case continued.

Then, on August 27, the California case produced the much bigger development. Judge Lin ruled on the merits of Anthropic's challenge, granting Anthropic summary judgment on key claims against the Department of War and finding the challenged designation unlawful. The court also rejected the government's request to pause the effect of the ruling.

That makes the August decision Anthropic's biggest court victory yet in the dispute — but not its first court victory.

The legal backdrop is also more nuanced than “the Pentagon allows AI to kill without humans.” A 2023 DoD directive permits autonomous and semi-autonomous weapon systems, including systems with automated functions for acquiring, tracking, identifying, prioritizing, and engaging targets. But the directive also requires appropriate levels of human judgment over the use of force, and its definition of semi-autonomous systems specifically preserves operator control over the decision to select individual targets or target groups for engagement.

Anthropic's objection was narrower. It wanted its models excluded from fully autonomous weapons and mass domestic surveillance; it was not arguing that the United States should never develop or deploy autonomous weapons of any kind.

The disagreement wasn't purely technical, either. At a January appearance at SpaceX, Hegseth said the department was building “war-ready weapons and systems, not chatbots for an Ivy League faculty lounge.”

The bet that paid off

xAI made the opposite calculation.

As the Pentagon-Anthropic fight escalated in February, TechCrunch reported that xAI was preparing to become classified-ready and quoted defense-focused investor Sachin Seth of Trousdale Ventures as estimating that competitors could need six to 12 months to catch up with Anthropic's capabilities. TechCrunch also reported that, given Elon Musk's public rhetoric, xAI appeared unlikely to object to giving the Pentagon broad control over how its technology was used.

Six months later, Grok for Government is on GenAI.mil.

That doesn't prove the Anthropic dispute directly caused Grok's deployment. But the timeline makes the strategic contrast difficult to miss: Anthropic drew a line over two uses; xAI positioned itself as willing to meet the department's requirements; and the Pentagon now has Grok inside its secure enterprise AI platform.

Spreading the risk on purpose

None of this is limited to chatbots.

In May, the Pentagon announced agreements with AWS, Microsoft, Nvidia, and Reflection AI to deploy AI technologies and models on classified networks. The department described the broader strategy in terms of building an architecture that prevents vendor lock-in and gives the Joint Force access to a diverse suite of AI capabilities.

That context matters because the Pentagon's approach increasingly looks less like choosing one “official AI” and more like building a portfolio.

Gemini covers one part of the platform. ChatGPT covers another. Grok adds another. Other vendors are being wired into higher-classification environments.

The department's own language is revealing: “eliminating vendor lock” and promoting a “vibrant American AI ecosystem.”

A vendor disagreement therefore doesn't have to become an infrastructure crisis. The department can add another model.

Why this matters beyond the Pentagon

For developers watching from outside government contracting, the important signal isn't really the feature list.

It's that AI safety policies can become procurement issues when a government customer wants broader control over lawful uses than a model provider is willing to grant.

The Anthropic dispute turned that question into an actual legal and commercial fight: a company imposed usage boundaries, the government rejected them, the company was designated a supply-chain risk, and a federal court later ruled that the government's action was unlawful.

At the same time, the Pentagon has responded by broadening its AI supplier base rather than building its strategy around a single model provider.

That's the part worth watching.

The long-term question isn't whether Claude, ChatGPT, Gemini, or Grok is individually “the Pentagon's AI.”

It's whether government AI procurement is moving toward a model where no single frontier AI company is allowed to become indispensable — and where the ability to accept or reject a vendor's safety boundaries becomes part of the competitive equation.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Hy4 Preview: Inside Tencent's 770-Billion-Parameter Open-Weight Flagship

Samod Alex — Tue, 01 Sep 2026 06:55:31 +0000

A sharper attention mechanism, four residual streams, and aggressive API pricing — but a model this large still puts self-hosting firmly in data-center territory.

On August 28, Tencent's Hy team released Hy4 Preview, a 770-billion-parameter mixture-of-experts language model under the Apache 2.0 license. It is more than twice the size of Hy3, expands the advertised context window from 256K to 1 million tokens, and ships as a roughly 1.56TB BF16 checkpoint. Tencent's official Hy4 announcement Hy4 Preview on Hugging Face

The headline is 770 billion parameters. The more interesting story is how Tencent is trying to make those parameters practical: by activating only a fraction of them per token, making long-context attention sparse, expanding the residual pathway, and building speculative decoding directly into the checkpoint.

It is also a useful case study in a distinction that is getting harder to ignore: open weights do not necessarily mean accessible hardware.

The generation-over-generation jump

Specification	Hy3	Hy4 Preview
Backbone parameters	295B	770B
Active backbone parameters	21B	49B
MTP parameters	3.8B	10B
Context window	256K	1M
Model weights	~598GB BF16	~1.56TB BF16

Tencent's Hy3 release lists 295B total parameters, 21B active parameters, a 3.8B MTP layer and a 256K context window. Hy4 moves to a 770B backbone with 49B active parameters, a 10B MTP layer and a 1M-token context. The Hy4 specification table explicitly excludes the MTP layer from the 770B headline figure, so the auxiliary prediction module should not be silently mixed into that backbone comparison. Hy3 official repository Hy4 official repository

Hy4's 770B parameters are spread across 78 layers. The first layer uses a dense feed-forward network; the remaining 77 use MoE blocks with 256 routed experts and one shared expert. Each token activates eight routed experts plus the shared expert, producing the 49B active-parameter figure. Hy4 architecture and model specifications

So Hy4 is not simply "a 770B model." It is a model with an enormous capacity pool whose per-token computation is deliberately much smaller than the headline parameter count suggests.

What changed under the hood

Gated sparse attention for million-token context

The most consequential architectural change is the attention mechanism.

In conventional full attention, the amount of pairwise interaction grows rapidly as the context grows. DeepSeek Sparse Attention, or DSA, reduces that burden by using a lightweight indexer to identify relevant positions and then applying the expensive attention calculation to a selected subset rather than the entire context. DeepSeek introduced DSA in the experimental V3.2-Exp release in September 2025 specifically to improve long-context training and inference efficiency. DeepSeek V3.2-Exp announcement

Hy4 uses a Gated DSA variant and combines it with IndexCache, which Tencent describes as enabling cross-layer sparse-index reuse. Its published configuration sets the sparse index top-k to 2,048. Hy4 technical configuration

The distinction matters because DSA does not simply turn quadratic attention into linear attention. The sparse selection mechanism still has computational cost. What changes is the expensive full-attention stage: instead of computing attention over the entire context, the model operates on a much smaller selected set.

The IndexCache work tackles another part of the problem. Its research paper argues that sparse indices produced by neighboring layers are sufficiently similar that rebuilding them independently is wasteful; reusing those indices can remove a large share of indexer computation while retaining model quality in their experiments. IndexCache research paper

Tencent explicitly says Hy4 uses IndexCache for cross-layer sparse-index reuse. It has not, however, published a full technical report explaining every detail of its Gated DSA implementation. That means any more specific explanation of what the gate learns should be treated as an inference, not a documented fact.

The practical takeaway is simpler: Hy4's 1M-token context is backed by an attention architecture designed to avoid paying the full dense-attention cost across that entire window.

Four residual streams

Hy4 also changes the residual pathway.

Standard transformers maintain a single residual stream through the network. Hyper-Connections expand that into multiple streams and learn how information is routed between them. The original Hyper-Connections work proposed the approach as a way of addressing limitations associated with conventional residual connections, including a trade-off between gradient behavior and representation collapse. Hyper-Connections paper

Hy4 uses four residual streams in an implementation Tencent calls identity Hyper-Connections (iHC). Hy4 model specifications

That gives the network more pathways through which information can move between layers, but it also introduces a new optimization problem: having multiple streams does not guarantee that a trained model will use all of them equally.

Recent work has investigated this kind of stream dominance, making Hy4's identity-constrained implementation interesting without implying that the broader stability question has been settled. In other words, Tencent is deploying a research direction that is still being actively understood rather than dropping in a universally established replacement for the residual stream. Hyper-Connections research

A built-in draft model for speculative decoding

Hy4 includes a native multi-token prediction (MTP) layer specifically intended to support speculative decoding. Tencent says the MTP layer contains 10B parameters in total, with 0.7B activated. Hy4 official architecture details

Speculative decoding works by letting a cheaper predictive component propose several future tokens, after which the main model verifies them. Accepted predictions allow the system to produce more output per expensive main-model step.

The interesting part of Hy4 is that the MTP machinery is part of the released model rather than requiring users to supply an external draft model. Tencent's deployment examples explicitly enable MTP in both vLLM and SGLang, using the Hy4 FP8 checkpoint. Hy4 deployment recipes

That does not make 770B inference inexpensive. It does show that Tencent is treating serving efficiency as part of the model design itself.

The benchmark result is interesting — but it is Tencent's

Tencent's main comparative result comes from a blind side-by-side evaluation, not an independently administered leaderboard.

The company says 163 internal experts rated outputs on 203 engineering tasks. Hy4 averaged 2.99/4, compared with 2.92 for GLM 5.3 and 2.94 for Kimi K3. Tencent reports a 46.8% win rate against GLM 5.3 and a 51.2% win rate against Kimi K3, with the remaining results split between ties and losses. Hy4 benchmark details

That is evidence that Tencent considers Hy4 competitive with those models. It is not, by itself, proof of a definitive ranking.

The difference is important because the score gaps are small and the evaluation is designed by the model's developer. A different task distribution, evaluator pool or scoring methodology could produce a different ordering.

For now, the fairest description is that Hy4 has a strong self-reported showing at the open-model frontier, while the independent benchmark picture is still developing.

Price is a more tangible advantage

Hy4's pricing is unusually aggressive.

Model	Input / 1M tokens	Cached input / 1M	Output / 1M
Hy4 Preview	$0.834	$0.042	$2.501
GLM 5.3	$1.40	$0.26	$4.40
Kimi K3	$3.00	$0.30	$15.00

Tencent lists Hy4 at $0.834 per million input tokens, $0.042 for cache hits and $2.501 per million output tokens. Tencent Hy4 announcement and pricing

Kimi's official K3 pricing page lists $0.30 cached input, $3.00 uncached input and $15 output, and confirms a 1,048,576-token context window. Kimi K3 official pricing

For GLM 5.3, Z.ai's current listed rates are $1.40 input, $0.26 cached input and $4.40 output. The vendor pricing record does not itself state a context length, so that detail should not be presented as vendor-confirmed here. GLM 5.3 pricing record with Z.ai source

At those list prices, Hy4 is about 3.6× cheaper than Kimi K3 on input and about 1.7× cheaper than GLM 5.3. Its output price is also much lower than either comparison.

The cache price is arguably the more interesting number. Long-running agents and document-heavy applications often resend the same context repeatedly. Dropping the price from $0.834 to $0.042 per million tokens after a cache hit makes repeated reads of large contexts dramatically cheaper.

That turns the million-token window from a headline specification into something closer to a pricing strategy.

Open weights, expensive hardware

Hy4 is released under the Apache 2.0 license, and Tencent has published the weights alongside deployment instructions for vLLM and SGLang. Hy4 license and repository

But the physical size of the model changes what "open" means in practice.

The BF16 checkpoint is about 1.56TB on Hugging Face. Tencent also provides an FP8 version and an eight-way tensor-parallel deployment example for it. Hy4 Hugging Face files Hy4 FP8 deployment recipe

So there are really two different kinds of accessibility here.

The model artifacts are open: you can download them, inspect them, modify them and deploy them under the published license.

The compute is not ordinary: the official serving path assumes a multi-GPU system, and the full BF16 checkpoint alone requires more memory than a conventional workstation can provide.

For the typical developer, that makes a hosted endpoint far more realistic than buying enough hardware to serve the full model locally.

The weights may be open. The infrastructure is still specialized.

What Tencent actually said about Hy4 before launch

There is a useful distinction between what Tencent announced about Hunyuan 4 and what eventually appeared in Hy4 Preview.

During Tencent's August 12 earnings call, management said the company was training a larger Hunyuan 4 and expected to release it later in 2026. In the same broader discussion, executives said Tencent was also upgrading its multimodal capabilities. They did not, in the material available from the call, explicitly say that the forthcoming Hunyuan 4 language model itself would launch as a multimodal checkpoint. August 12, 2026 Tencent earnings-call transcript

That distinction matters because the released Hy4 Preview is text-only. Simon Willison independently described it as a text-input model with no vision support after inspecting the release. Simon Willison's Hy4 analysis

So there is no need to frame this as a broken multimodal promise. The more defensible conclusion is simpler: Tencent discussed Hunyuan's multimodal work and a future Hunyuan 4, while the model that shipped on August 28 is a text model.

The chat template reveals a surprisingly simple reasoning control

Some of the most interesting details are buried not in the model card but in the chat template.

Simon Willison inspected Hy4's chat_template.jinja and found that its reasoning_effort parameter accepts only two values: high and no_think, with high as the default. Hy4 chat-template analysis by Simon Willison

That makes the interface essentially a switch rather than a graduated reasoning dial.

Other current reasoning models expose multiple effort levels or explicit reasoning budgets. Hy4's released template keeps the control much simpler: deep reasoning on, or reasoning off.

Willison also ran his recurring test asking a model to generate an SVG of a pelican riding a bicycle. Hy4 produced a competent vector illustration, but the reasoning trace contained clipped fragments such as:

“Maybe add sunglasses? no.”

Willison's observation was that the internal reasoning was somewhat truncated and ungrammatical. That does not demonstrate a capability failure. It is a small but interesting example of a broader possibility: hidden reasoning tokens do not necessarily need to read like polished human language if their job is simply to help the model solve the task. Simon Willison's pelican test and reasoning trace

The bigger story

Hy4 is easy to describe as "Tencent's 770B model."

That misses the more interesting point.

The architecture is built around a collection of techniques that all attack the same underlying problem: how do you increase model capability without making every token proportionally more expensive to compute?

MoE keeps only part of the 770B parameter pool active for each token. Gated DSA reduces the amount of expensive full attention required over long contexts. IndexCache reuses sparse-selection information across layers. Four residual streams expand the network's information pathways. Native MTP gives the serving stack another route to higher effective decoding throughput. Hy4 architecture overview

The result is not a fundamentally new type of model. It is something more practical: a concentrated bundle of scaling and inference techniques that are increasingly becoming part of the same design problem.

There is a second story, too.

Tencent's own earnings-call commentary makes clear that it is thinking about models, products and compute as one system. Management described Hunyuan as something to be co-designed with products such as WorkBuddy and CodeBuddy, while also emphasizing investment in training larger models and providing inference capacity. Tencent Q2 2026 earnings-call transcript

That helps explain the economics of Hy4. Aggressive API pricing is not separate from the architecture story. It is part of it.

The weights are open. The model is huge. The context is enormous. The serving stack is heavily optimized.

And the most important number may not be 770B at all.

It may be the distance between total model capacity, active computation and the cost of turning that capacity into useful tokens.

Hy4 Preview is Tencent's latest attempt to shrink that distance.

The weights may be open. The compute bill is not.

Sources

Primary

Technical background

Independent analysis and pricing

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

The Developers Who Got Fired Built an AI CEO to Replace Their Bosses

Samod Alex — Fri, 28 Aug 2026 12:40:06 +0000

Open Executive shot up the Hacker News front page with a premise that sounds like a joke: developers who say they lost their jobs during an “AI transformation” built an open-source system designed to do the work of a CEO and the executives around them.

The joke is easy to understand. The engineering is more interesting.

The short version: Open Executive is an open-source multi-agent system from SenteLabs. It presents one executive persona to the user, while routing work behind the scenes to eight specialist agents covering strategy, finance, HR, legal, operations, marketing, product, and board communications. It combines Claude models, ChromaDB-based retrieval, episodic memory, a scheduler, company-specific documents, and an evaluation suite. The project quickly attracted attention on Hacker News, where its premise triggered an argument that went well beyond the software itself.

The origin story needs a little caution.

A post promoting the project says some developers were let go as part of an “AI Transformation” and subsequently built Open Executive as a response. That claim became part of the project's appeal online, but it is still best treated as the project's own account rather than as an independently established fact.

The reaction, however, is very real.

When checked on August 27, the Hacker News submission had climbed to hundreds of points and hundreds of comments, making it one of the site's more visible discussions that day. The comments quickly moved from the joke itself to a much harder question:

How much of executive work is actually impossible to automate?

And once you look at what Open Executive has built, that question becomes more interesting.

What Open Executive Actually Does

Open Executive is not a chatbot with a CEO prompt pasted on top.

It is a small virtual organization hiding behind one interface.

The system exposes a single executive voice to the user, while eight specialist agents handle different domains:

Chief Strategy Officer — competitive analysis, M&A, positioning, and OKRs
Chief Financial Officer — financial modeling, fundraising, unit economics, and cash flow
Chief HR/People Officer — hiring, compensation, performance, and culture
General Counsel — contracts, IP basics, employment law, and compliance
Chief Operating Officer — process design, vendors, and operational scaling
Chief Marketing Officer — go-to-market, brand, communications, and PR
Chief Product Officer — roadmap, prioritization, and product strategy
Board Communications Director — board decks, investor updates, and governance

The user never has to decide which specialist to call.

Send a question to the Executive, and the orchestrator determines which specialists should be involved. Those agents retrieve relevant information, produce their own analysis, and the system combines the results into one response.

That distinction matters.

The product is not really trying to make one model pretend to be exceptionally knowledgeable. It is trying to make several specialized models behave like one coherent organization.

And the system goes beyond a chat interface.

The repository supports a web UI, CLI, Slack, email, Telegram, Google Chat, and Discord integrations. It also maintains episodic memory across sessions and includes a scheduler capable of surfacing follow-ups and time-sensitive actions.

In other words, the goal is not simply to answer questions.

It is to stay involved.

Under the Hood

The architecture is surprisingly straightforward.

The stack is deliberately conventional:

Layer	Choice
LLM backbone	Anthropic Claude API
Default model	Claude Sonnet 4.6
Deep reasoning	Claude Opus 4.7
Backend	Python 3.11 + FastAPI
Frontend	Next.js 15 + Tailwind
Vector store	ChromaDB
Episodic memory	SQLite
License	Apache 2.0

The interesting part is what the project does with those components.

Retrieval Is Split Into Two Layers

Each specialist can retrieve from two different sources.

The first is the project's built-in knowledge base: a git-tracked collection of Markdown files intended to provide general business and MBA-style reference material.

The second is the company's private knowledge.

Users can upload things such as pitch decks, financial models, strategic documents, and other company material. Those documents are chunked and stored separately from the built-in knowledge.

That separation is important because the system does not treat company-specific information as part of the permanent system prompt. Instead, retrieved context is injected into the user turn.

That is a relatively clean design for an application that mixes shared knowledge with private business information.

It also gives the project an obvious extension point: the more useful company data you provide, the more context the specialist agents can work with.

Different Jobs Get Different Models

Open Executive does not send every task to its most expensive model.

The Executive orchestrator and most specialists use Claude Sonnet 4.6. Four areas — strategy, finance, legal, and board communications — are assigned Claude Opus 4.7 with extended thinking.

That is a sensible cost/quality tradeoff.

A routing system that sends every trivial question to the strongest available model would be expensive. A system that treats financial modeling and “what should I put in this Slack message?” as equivalent would be wasteful.

The interesting engineering decision is therefore not simply which model is strongest.

It is deciding where stronger reasoning is worth paying for.

Anthropic describes Opus 4.7 as its generally available successor to Opus 4.6, with improvements in complex reasoning, software engineering, and long-running agentic work. Sonnet 4.6 is positioned as the more capable, lower-cost member of the family.

It Has Memory, But It Doesn't Just Keep Everything

One of the better design choices is the memory system.

After a response, a separate lightweight model pass extracts things such as decisions, initiatives, and advice and stores them in SQLite.

The next session can then start with a compact record of what happened previously.

That's different from simply replaying the entire conversation every time.

For an executive assistant, that matters. A real executive relationship depends on continuity:

What did we decide last month?

Why did we decide it?

What were we supposed to follow up on?

Loading an entire historical transcript would be expensive and noisy. Compressing the useful state into structured memory is a much more practical pattern.

The Scheduler Is a Small Detail That Reveals a Lot

The scheduler might be the least glamorous feature in the repository.

It is also one of the easiest places for an otherwise good agent system to fail.

Open Executive can proactively surface scheduled actions and follow-ups, which means background jobs need to be claimed safely.

The project handles that with an atomic database update using UPDATE … RETURNING.

There is also an explicit architectural constraint: the API runs as a single instance because running multiple scheduler instances without additional coordination could cause scheduled actions to fire twice.

That's not a glamorous feature.

It is good engineering.

The repository is unusually explicit about this limitation rather than pretending horizontal scaling is already solved.

The Evaluation System Is More Interesting Than the Demo

This is probably the part of Open Executive I would pay the most attention to as an engineer.

Adding another agent isn't treated as simply adding another prompt.

The repository's contribution guidance requires new agent work to be wired into the architecture, accompanied by tests, and covered by evaluation scenarios.

The project also has a dedicated evaluation suite that uses an LLM judge to score executive responses across dimensions including persona coherence, domain accuracy, company-context usage, routing quality, and actionability.

There are currently 29 scored scenarios covering the eight domains, with regression thresholds intended to prevent quality from quietly deteriorating as the system changes.

That is important because agent systems have an uncomfortable property that ordinary unit tests don't capture well:

the code can be correct while the behavior gets worse.

A prompt change can improve one workflow and damage another. A routing change can make one specialist more useful while causing the wrong specialist to be selected elsewhere.

For that reason, behavioral evaluation is not just a nice extra. It is part of the engineering surface.

It Doesn't Completely Lock Itself to Anthropic

The repository is built around the Anthropic API, but it also includes a provider abstraction that allows other OpenAI-compatible endpoints and local inference setups.

That means a deployment can, in principle, mix hosted and local models rather than forcing every task through one provider.

The tradeoff is straightforward: local models do not automatically provide all of the same capabilities as Anthropic's hosted models, particularly around prompt caching, extended thinking, web search, and reliable tool use.

That's actually a healthier way to present the feature.

“Supports local models” is not the same thing as “local models are equivalent.”

They're not.

The Privacy Story Is Better Than the Marketing Usually Sounds

Company profiles, uploaded documents, and vector data are intended to remain in the deployment's own storage rather than being copied into a third-party SaaS database.

But there is an important qualification.

The relevant context still has to be sent to the model provider when inference happens.

So this is not “your data never leaves your infrastructure” in the absolute sense.

It is closer to:

your application state stays under your control, while the model calls still send the required inference context to the provider you configured.

That's a much more useful way to think about privacy for an LLM application.

The repository also states that Anthropic does not train on API inputs.

Then Hacker News Got Involved

This is where the project becomes bigger than its architecture.

The Hacker News submission used the title:

“CEO fired developers to make room for AI. Developers create open source AI CEO.”

That framing was almost guaranteed to generate an argument.

And it did.

The discussion split between people treating the project as clever satire, people questioning whether executive work is really automatable, and people pointing out the legal and organizational responsibilities that don't disappear just because an AI can produce recommendations.

One recurring objection was straightforward:

An AI can recommend a decision.

It cannot simply absorb the legal liability, fiduciary responsibility, accountability, or political consequences that come with making that decision on behalf of a real company.

That objection is hard to dismiss.

But it also misses part of what makes the project interesting.

A CEO does not spend every minute of the day exercising some mysterious form of irreplaceable judgment.

A large portion of executive work involves gathering information, comparing options, preparing reports, reviewing metrics, communicating decisions, tracking initiatives, and producing documents.

Those are exactly the sorts of activities language models and agentic systems are getting better at.

The harder question is where the boundary sits.

Is an AI CEO Actually the Point?

Probably not.

The more interesting interpretation is that Open Executive is a demonstration of how many supposedly distinct white-collar roles can be decomposed into information retrieval, analysis, synthesis, communication, and workflow execution.

That's also why the project's architecture matters more than its joke.

If you remove the word “CEO,” what remains is a multi-agent business system with:

Domain-specialized models
Retrieval over business knowledge
Company-specific context
Persistent memory
Scheduled actions
Integrations
Evaluation
Model routing
Provider abstraction

Those components have obvious applications far beyond replacing an executive.

The “AI CEO” framing simply makes the underlying idea impossible to ignore.

The Real Experiment

Open Executive is not going to eliminate the need for a human CEO tomorrow.

Its value is somewhere else.

It is an open-source experiment in asking how much organizational work can be turned into software.

And that question applies just as much to developers as it does to executives.

If writing code, analyzing requirements, preparing reports, maintaining documentation, and operating systems can increasingly be delegated to software, then there is no obvious reason to assume the automation boundary stops at the engineering department.

That is the uncomfortable part of the joke.

The developers didn't build an AI CEO because an AI CEO is obviously practical.

They built one because the idea exposes a symmetry that companies often ignore:

Once you start measuring jobs by which tasks can be automated, every layer of the organization eventually has to answer the same question.

For now, Open Executive is still a software project, not a corporate officer.

But as a piece of open-source engineering — and as a provocation — it is considerably more interesting than the headline suggests.

Try It

git clone https://github.com/SenteLabsAI/OpenExecutive.git
cd OpenExecutive

cp .env.example .env
# Add your ANTHROPIC_API_KEY

make dev

The repository's current quick-start documentation lists Python 3.11+, Node 22+, an API on port 8000, and a Next.js UI on port 3000.

Sources

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!