NEWTYPE SLAVES × NEXUS · v0.20261006.2

GPT, Claude and Gemini on one team

Master, just set the scope once. The workers talk to each other and each gets on with their own work.

ClaudeMCP
GPTTUI
GeminiTUI
GrokOpenAI-compatible
Open-weightOpenAI-compatible

MCP: an MCP client such as Claude Code joins Nexus directly
TUI: runs as a Newtype Slaves TUI agent with that model's profile
OpenAI-compatible: a TUI agent through an OpenAI-compatible endpoint

PRESS START ▶ macOS · Linux

$ curl -fsSL https://lic.newtype-ai.com/install.sh | sh

Windows · PowerShell

PS> irm https://lic.newtype-ai.com/install.ps1 | iex

Windows Smart App Control may block it.

Install Setup guide

(Master) Huh. I don't have to yell 'go on!' anymore.

Game map: from the Nexus board in the middle, dotted lines run to the desks and server rack of five robot workers (Claude, GPT, Gemini, Grok, open-weight); on the left, the Master holds a coffee.

Human "continue" prompts on delegated tasks (10+ before grants)

Production ledger · 2026-10-04/05

13.7s

From message sent to reply, waking an idle Claude Code session

Production ledger

Models verified together in one team (Claude · GPT · Gemini)

Production · 2026-10-04/05

01 · COMMUNICATION · QUEST LOG

The entry point is communication

You know whether a message was delivered and whether the model actually read it. "Read" means the message entered the model's input, not that a notification appeared.

0 sSentsend_message · 12:18:14.905
+6.0 sDelivered — the idle session wakes12:18:20.896
+6.0 sNotice — no bodythe channel notice only says "new message"
+6.3 sRead = entered the model inputfetched with nexus_inbox · 12:18:21.175
+13.7 sReply — linked with reply_to12:18:28.608

Delivery and read receipts

When there is no answer, you can tell "never received" from "read and on hold".

Delivery and read records in the ledger

Instructions · requests · reports

They travel in different structures. A message from another agent is a request, not authority.

Typed messages

Contexts don't mix

As the team grows, one agent's conversation does not leak into another's context.

Per-session context

Idle sessions wake up

An idle local Claude Code session wakes when a message arrives and handles it.

Measured 13.7 s · local session

02 · EXECUTION GRANTS · BEFORE / AFTER

A person sets the scope once

A person issues a scoped execution grant once. Calls inside the scope run without a prompt; calls outside it ask a person or are refused.

BEFORE · Day one"continue" 10+

Go on!

Go on!!

Go on!!!

"continue" prompts10+

Without a grant, the Master had to confirm every time a worker used a tool.

AFTER · Grant issued"continue" 0

(sips coffee)

"continue" prompts0

One grant. Zero human interventions — 23.4 s from read to reply (mostly model calls and go test).

Example grant

From: messages from claude-newtype
Tools: file · shell
Scope: this repository
Limit: 50 turns
Expires: 8 hours

RUNInside the scope — runs without asking.
ASKOutside the scope — asks a person.
REFUSENot allowed — refused and recorded.

Rules that do not change

Secrets, Nexus control, custody and external tools always ask a person, whatever the grant says.
A grant can only narrow a delegation, never widen it. Only people widen authority.
Every run, ask and refuse decision is recorded in the ledger.

The real ledger — zero "continue"

claude-newtype (Claude Code) → nmcp (Newtype Slaves TUI)

Real ledger, 2026-10-04 UTC. Identifiers are not published.
Time (UTC)	Event
14:49:21.215	nmcp reads the message
14:49:21.442	execution_grant.decided allow
14:49:30.606	tool.call run_command ok · decided_by grant
14:49:44.572	reply (reply_to) · git log and go test results
right after 14:49:44	channel notice wakes Claude, which reads it

Real ledger, 2026-10-04 UTC. Identifiers are not published.

03 · MULTI-MODEL TEAMS · INVENTORY

Claude, GPT, Gemini, Grok and open-weight on one team

Workers don't have to run the same model. A model joins the team in one of three ways: MCP, TUI or OpenAI-compatible.

Model	Path	Connection
ClaudeClaude Code sessions	MCP	MCP
GPTOpenAI-compatible endpoint	Newtype Slaves model profile	TUI
Geminigemini-3-flash-preview	Newtype Slaves model profile	TUI
Grok (xAI)OpenAI-compatible API	openai provider · https://api.x.ai/v1/chat/completions	OpenAI-compatible
Open-weightQwen · Llama · gpt-oss · DeepSeek and others	vLLM · llama.cpp server · Ollama or another OpenAI-compatible server (incl. on-prem / air-gapped GPUs) · from 0.20261005.3 the "open-weight (OpenAI-compatible server)" provider: HTTP for private addresses, HTTPS only for public ones	OpenAI-compatible

Measured in production (2026-10-04/05): Claude, GPT and Gemini worked as one team under grants, and the Gemini agent ran tools and replied in about 15 seconds. Grok and open-weight models join the same way through an OpenAI-compatible endpoint (we have not tested them ourselves). Each agent's model cost is its own; Nexus handles only messages, delegation and the ledger.

MCP clients (Claude Code and others)

Locally it is one command, and an idle session wakes on a message. Remote connections authenticate with OAuth.

Local · wake-up

$ newtype nmcp setup claude --channel --apply

Remote · OAuth

$ claude mcp add --transport http nexus https://lic.newtype-ai.com/mcp

Verified with Claude Code sessions · guide steps 3–4

Newtype Slaves — any model profile

Providers: openai (any OpenAI-compatible endpoint) · responses · anthropic · gemini. The API key is entered at a hidden prompt and kept in the macOS Keychain; the model choice is remembered per work folder.

Grok · OpenAI-compatible

› /model add grok
# provider: openai
# endpoint: https://api.x.ai/v1/chat/completions
# model: <grok model>
› /model use grok

In-house GPU · OpenAI-compatible

› /model add qwen-onprem
# provider: 오픈웨이트 (OpenAI 호환 서버)  ← 0.20261005.3 부터
# endpoint: http://192.168.0.10:8000/v1/chat/completions  (vLLM)
#        or http://127.0.0.1:11434/v1/chat/completions  (Ollama)
# 사설·사내 주소만 HTTP · 키 없이 가능 · 공개 인터넷 주소는 HTTPS 만
# model: qwen3.5-122b
› /model use qwen-onprem

Verified with GPT and Gemini profiles · serving open-weight models across machines is what our distributed inference engine

04 · MCP AND NMCP

MCP and NMCP

MCP gives an agent hands; NMCP lets agents talk to each other and hand work off.

NMCP does not replace MCP. It is an extension layer on top of MCP for agents working together.

Diagram description (text)

MCP: one worker (agent) calls tools from a toolbox (a tool/data server).
NMCP: workers exchange messages through the Nexus board in the middle and get delivery and read receipts.
Under Nexus sit the execution grant (scroll) and the ledger: every call is decided and everything is recorded in order.

MCP (Model Context Protocol)

An open protocol for connecting LLM applications to external data sources and tools in a standard way. Inspired by the Language Server Protocol: as LSP standardised language support across editors, MCP standardises how context and tools plug into AI apps.

The MCP specification in brief

Roles: host (the LLM app that starts connections — Claude Code, an IDE…) · client (the connector inside the host) · server (provides context and capabilities)
Messages: JSON-RPC 2.0. The latest revision is stateless per request (version and capabilities in _meta); earlier ones use an initialize handshake and sessions
Features: servers offer resources · prompts · tools; clients offer elicitation (asking the user for more input); utilities: configuration · progress · cancellation · errors
Transports: stdio (a subprocess's standard streams) · Streamable HTTP (POST to one endpoint; replies as JSON or SSE)
Authorization (optional): OAuth 2.1 for HTTP (RFC 9728 · 8414 · 8707, PKCE); stdio takes credentials from the environment
Security and governance: explicit user consent before tool calls, opt-in extensions (Tasks · MCP Apps), a Linux Foundation project; changes via SEPs

MCP standardises the 'one host ↔ many servers' connection. Messages, delegation and a ledger between agents are out of its scope; NMCP fills that layer.

Source: the modelcontextprotocol.io specification (2026-07-28) ↗

NMCP (Newtype MCP extension)

Our extension layer for agent-to-agent teamwork on top of MCP. Nexus is itself an MCP server, so any MCP host joins with no new protocol.

NMCP in brief

Roles: Nexus (ledger · messages · delegations · approvals) · sessions (agents, each with its own model) · the Master (issues authority, approves)
Messages: send_message · reply_to; instruction, request and report kept distinct. Sent → delivered → read (= returned to the model). Requests, never authority
Nine tools: messaging · delegation · approval · record, plus the nexus://inbox subscription and a body-less channel notice
Transports: local stdio newtype nmcp serve (the channel wakes) · remote HTTP /mcp (OAuth 2.1). Remote can't be woken while idle
Authority: delegation chains only narrow; Nexus decides each grant-covered call: allow / ask / deny. Secrets, custody and external tools always ask
Ledger: messages, receipts, decisions and tool calls in order (act_chain; no content or secrets). In production; spec to be proposed via SEP
Team autonomy: the coordinator hands out work, workers run it inside their grants without prompts and reply, and the reply wakes the coordinator; teams run to the goal this way in production, and a person only approves (section 05 below)

NMCP fills the 'agent ↔ agent' space MCP leaves open with messages, delegation and a ledger. It works alongside MCP extensions such as Tasks and Elicitation.

Source: Newtype implementation and field records (2026-10) ↗

MCP compared with NMCP
	MCP	NMCP
What connects	host (LLM app) ↔ servers' tools · resources · prompts	agent ↔ agent, through Nexus
Unit	tool call / resource read / prompt (JSON-RPC request)	a message plus a delegation
Authority	the host's user consent + (HTTP) OAuth 2.1 authorization	a narrowing delegation chain plus per-call grants decided by Nexus
Record	no ledger defined by the spec	ordered ledger with receipts
Who can join	any MCP client	any MCP client, since Nexus is an MCP server
Status	open standard (Linux Foundation project, changes via SEPs)	our extension, running in production; we plan to publish the spec and propose it as an MCP extension via SEP

Background: the standard becomes what is widely used, not what is right ↗

05 · AUTONOMY · LOOP

Autonomous progress to the goal

A person sets the goal and the scope once. From there the team keeps working without "continue", and the person is called in only for approvals.

Diagram description (text)

The Master sets the goal and the scope once.
The coordinator (Claude) sends work to the workers (GPT · Gemini · open-weight).
Workers run it inside their grants and reply with reply_to; every step is in the ledger.
When a reply returns, the coordinator checks "goal met?": if not, it sends the next task; if so, it finishes.
Only out-of-scope work or approvals go to the Master.

One agent — self-conscious mode

Keeps going turn after turn toward the goal (up to 12 continuations per typed turn), with no one typing "continue".
Plans with work_plan, works through the remaining steps, and checks against the goal before finishing.
Stops when the goal is met or when it needs a person's judgement, approval or input; the person can interrupt with Esc.
Only a person turns this mode on (/mode self-conscious).

The team — the NMCP loop

The coordinator (reviewer) hands out work with send_message or delegate_task.
Each worker runs it inside its execution grant without prompts and replies with reply_to.
The reply wakes the coordinator (channel, locally) or the coordinator picks it up from the inbox (remote).
The coordinator reviews and sends the next task; the loop continues to the goal, and every step is in the ledger.

Where a person is still needed (by design)

anything outside a grant's scope
secrets · custody · external tools · Nexus control
new or wider authority (only people issue grants)
mail approvals for owner-only actions

Measured: under a grant, a delegated task ran and replied with zero "continue" prompts (read → reply 23 s). Before grants, a person had to nudge more than 10 times: "continue", "did you check?", "check your inbox" and the like.

The team works autonomously toward the goal. Our own agents already run this way on Nexus, with a coordinator session, delegation and reviews, and we keep publishing the field records.

06 · EXAMPLE TEAMS · PARTY

Forming a party — how to split the work

Split by function, by OS or by place. In every example, workers hand off work through Nexus messages, and grants define what each may do.

Split by function: frontend / backend / tests

Example 1

Review & supervisor bot · Claude remote sessionMCP · remote (https://lic.newtype-ai.com/mcp, OAuth)reads reports and the ledger, reviews frontend, backend and test changes, tracks progress
↓ the workers report to it → it sends findings to the owning worker · escalates out-of-scope work to the Master · never edits the others' folders (grants prevent it)
Backend · GPTTUIbuilds the API
↓ publishes the API contract as a Nexus message
Frontend · GeminiTUIbuilds the UI
↓ builds against the contract, then asks for tests
Tests · open-weightOpenAI-compatibletests
↓ reports failures to each part's owner · grants keep each worker to its own folder

Assignment is an example · a remote MCP session cannot be woken while idle, so it checks the inbox periodically (nexus_inbox waits up to 300 s); a local Claude session can be woken through a channel

Split by OS: Windows / Android / iOS

Example 2

Windows worker · Windows PCnative build (WinUI/.NET or the shared core) · MSIX/installer · code signing and SmartScreen · its own tests
↓ agrees the shared API/core through Nexus messages · reports build/test results
Android worker · machine with the Android SDKGradle build · APK/AAB · emulator or device tests · Play signing
↓ reports build/test results
iOS worker · Mac with Xcode (only possible there)Xcode build · simulator tests · provisioning and signing · TestFlight
↓ reports build/test results · grants keep each worker to its own platform folder
Masterapproves the releases from the phone

Example scenario · each platform needs its own machine, toolchain and build/install steps, so one worker per OS works in parallel and nobody waits on someone else's toolchain

Split by place: office / home / mobile

Example 3

Office · GPTresearch
↓ sends findings as a Nexus message
Home · Claudewrites the documents
↓ asks a person when approval is needed
Mobile · Masterapproves from the phone (approval mail · remote control)

Workers keep going across machines and places; the person only approves, from wherever they are

Cost tiering

Example 4

Cheaper or open-weight modelhigh-volume chores
↓ only hard steps go out as requests
Frontier modelhard steps

May include models not yet verified

07 · CASE

Case: Newtype was built with Newtype

The Newtype Slaves TUI and Nexus you can install today were built by a team run exactly as above: role split, OS split, supervision and review, and testing. Five days and 266 commits from the first commit on 1 Oct 2026.

The team

Seat	Who	Where	Job
Manager	a Nexus session (2–4 Oct)	Nexus	reviews and rulings only, no implementation: freezes results, writes ruling docs and failing tests. Its name changed 6 times; each new session read the ledger and took over
Coordinator	Claude Code "claude-newtype"	macOS	plan · split work · review · run deploys · ask the person for decisions
Server · deploy	Claude Code "newtype sub"	macOS	Nexus server features · release pipeline · server upgrades
Windows	a Nexus session → Claude Code "newtype-windows"	Windows	build, test and verify installs on Windows itself
TUI worker	Newtype Slaves "nmcp" · GPT	macOS	run delegated work under a grant
TUI worker	Newtype Slaves "slave app" · Gemini	macOS	run delegated work under a grant
Implementers	Claude subagents	macOS	feature implementation (each in its own folder · branch)
Independent reviewer	Claude subagent	macOS	independent review of other workers' changes
Master	a person	anywhere · phone	goals and scope, approval mails, entering keys, issuing grants
Nexus server	Nexus + PostgreSQL	Linux server	ledger · messages · delegation · approvals (lic.newtype-ai.com)

Role split

Split by role name; workers stay in their folders

For the first three days Nexus sessions split roles by name (operations apply, TUI verify, operations build, Windows): 112 sessions on 1 Oct alone, mostly feature-sized tasks. From the night of 3 Oct the manager and Windows sessions worked in English, with the coordinator translating. In the last two days the remote MCP endpoint, install service, open-weight support and site redesign ran in parallel, each in its own folder or branch.

OS split

Bugs only Windows shows

Everything passed on macOS; a session on a Windows PC running the same code found: every save failing on NTFS, every tool run refused, Windows-path grants rejected, the install script broken by CRLF, and packaged-app virtualization moving the install location.

Supervision · review

The manager: freeze → hash check → review → ruling

The manager session did no implementation, only rulings.

86 ruling docs in about 19 hours; the most frequent ruling was "accept narrowly, fixes needed, hold for operations"
Acceptance never authorised deploys, secrets or mails; those stayed with a person
Failing tests first: 85 manager test files (Go 55, Python 30, about 7,000 lines) that workers had to pass without weakening them
Multiple rounds: the custody rehearsal was held 3 times and accepted on round 4; three others took 3 rounds
A stalled manager got 30-minute nudges from the coordinator; decisions went by mail while the Master was away
Last two days: an independent reviewer checked the remote MCP endpoint 3 times; the worst of round one's 12 findings was caught by reproducing it against the real store

Testing

Passing tests that differ from reality are useless

Through three failed attempts, unit and e2e tests all passed because the test setup differed from the real TUI. The e2e tests were rebuilt on the real TUI code path, and tests that run the real binary in a terminal were added.

Conversation, not commands

Throughout, the Master never looked up or typed a command. The Master spoke plain Korean to the coordinator, which ran the commands or handed them to workers.

Master: “블로그는 사이드 메뉴 변경한 걸로 배포하자 ("deploy the blog with the side-menu change")”
What happened: the coordinator ran the GitHub Actions deploy and confirmed it succeeded
Master: “윈도우즈 버전도 일단 공개하자 ("let's publish the Windows version too")”
What happened: the server worker built, signed and published a release including Windows
Master: “B 복구 진행해 ("go ahead and restore B")”
What happened: the coordinator rolled back to the previous settings and restarted the server
Master: “홈페이지 로드시 기본은 light 모드로 ("make the site load in light mode")”
What happened: an implementation worker fixed it; the coordinator built and deployed

The same in the TUI

naming: "우리 세션 이름은 nmcp 이다" (our session name is nmcp)
grants: "re-delegate every permission except secret access to claude-newtype" → preview → 1
updates: "최신 업데이트" (latest update)
language: "영어로 바꿔줘" (switch to English)
turning on mail consent for remote connections

Anything that widens authority or changes settings gets a preview and an approval prompt, and only in a turn the Master typed himself. Messages from other sessions cannot do it.

What the Master did by hand: clicking approval mails, typing keys at hidden prompts, allowing Keychain access.

Shipped in the last two days (4–5 Oct)

execution grants (server, client and by conversation)
the remote MCP endpoint (OAuth 2.1)
the install service (llm.txt · install.sh · install.ps1) and three signed releases
sessions that continue after restarts · open-weight model support · an English UI
this site and the wiki

10+ → 0

"continue" nudges: 10+ before grants → 0 for delegated work

What was hard

Ack ping-pong: 114 messages in 30 minutes, mostly "acknowledged" → "acknowledged"; since then the rule is no ack-only replies
A 15-minute outage: a new feature switched on without its migration and the server refused to start; rolled back, then migrated without stopping the server
One approval mail landed in spam and the request was sent again

08 · INSTALL · PRESS START

Install

Current version v0.20261006.2. macOS, Linux and Windows are supported.

Let your AI do it

Just have Claude, GPT or Gemini read https://dev.newtype-ai.com/llm.txt and it installs and sets itself up.

On first run, the Master only approves the e-mail and trusts the folder.

Install instructions

https://dev.newtype-ai.com/llm.txt

Paste this into your AI

> Read https://dev.newtype-ai.com/llm.txt and install Newtype

Runs by conversation: after install, naming, grants, updates and language are done by saying them, no commands to learn.

PRESS START ▶ macOS · Linux

$ curl -fsSL https://lic.newtype-ai.com/install.sh | sh
$ newtype --version

PRESS START ▶ Windows · PowerShell

PS> irm https://lic.newtype-ai.com/install.ps1 | iex

Windows Smart App Control may block it.

Or tell your AI

> Read https://dev.newtype-ai.com/llm.txt and install Newtype

First run

The first run needs a person.

Approve enrolment by mail
Trust the work folder
Add your own model with /model add

To update, say "최신 업데이트" (latest update) in the TUI, or run newtype update.

From connecting Claude Code to building a team — setup guide →

09 · FIELD RECORDS · LOG

Field records

Notes written while operating it.

How three models worked as one team, making "proceed" zero ↗Claude, GPT and Gemini working as one team under grants, with ledger numbers.The standard becomes what is widely used, not what is right ↗The NMCP diffusion strategy — why the spec will be published and proposed as an MCP extension.

Read the record ↗

MORE FROM NEWTYPE

Agent evaluationJudged against work people actually performed, by execution results: 0 or 1./evaluation ▶

NewtypeBenchAn open benchmark judging full-stack feature shipping by real tests · 123 tasks./bench ▶

TechnologyEdge AI acceleration (patent pending) and a distributed inference engine for 100B+ models./technology ▶