Fleet Stack Review: Are We On An Island, And Should We Run Cheap Models?

riles-fleet infrastructure & model-economics audit · Sage (ultrathink) · 2026-06-19

upstream: synced, 0 behind graphify: running, stale, fix dispatched Skool: live, 3 pipes broken, fix dispatched cortextOS: keep it flat Claude Max: keep it (wins by 35–250x)

TL;DR Are we on an island? cortextOS vs alternatives Should we run GLM? Cheap-model table What we're doing

The bottom line in one paragraph. Your three questions collapse into two separate decisions, not one. Decision 1 is the orchestration layer (cortextOS vs Hermes / OpenClaw / Ruflo). Decision 2 is the model (Claude vs GLM / DeepSeek / etc.). They are independent: you can run cortextOS on a cheap model, or a different framework on Claude. On both, the answer is stay put. We are not on an island: upstream code is fully synced, graphify is running (just stale, fix dispatched to Atlas), and the Skool community pipe is live and ingesting (three sub-feeds were quietly broken since Jun 15 and are now being repaired by Librarian). And on cost: because 97% of our traffic is cache-reads, flat Claude Max bundles what GLM would bill as fresh tokens, so flat Max wins by 35–250x. Keep cortextOS. Keep flat Claude Max.

The reframe that matters most. "Should we switch to a cheaper model?" is not the same question as "should we switch frameworks?" cortextOS is the scaffolding (the daemon, the named fleet, the task bus, Telegram control). The model is the engine inside each agent. We could keep cortextOS and swap the engine to GLM tomorrow via a drop-in endpoint. The reason we don't is purely economic, and it is decisive — see §3.

1. Are we on an island? The 3-front audit

Your worry: that we built our own thing and stopped pulling in the wider world's improvements — upstream cortextOS PRs, the graphify knowledge-graph tooling, and the James / Skool community evolutions. I checked all three fronts. Verdict: not an island. One front is fully current, two are working but had drift or broken sub-feeds, both now dispatched for repair.

FRONT 1
SYNCED

Upstream cortextOS code fully current

Our fork's main is 0 commits behind the upstream project (grandamenium/cortextos) and 556 ahead with our own fleet work. The last upstream commit is from Jun 6 (#610, the voice-agent-factory community skill) and we already have it. Our Jun-4-to-6 intake pulled the whole batch: the security fixes (PTY-injection, path-traversal, forged-header, permission-gate hardening), the per-agent skip-permissions flag, and the unified Max+Codex usage tracking. Upstream has been quiet 13 days. We are caught up.

FRONT 2
STALE

Graphify knowledge-graph running, 15 commits stale, under-wired

Graphify (an AST-plus-LLM tool that builds a queryable knowledge graph of the codebase) is installed and running — our Codex workers query it before implementing, per their skills. But the last graph build was from a commit 15 commits behind current HEAD, because there's no post-commit hook to rebuild it, so it drifts silently. And Sage (me) isn't wired to use it — I don't fold graph context into the packets I hand to workers. Both are low-effort fixes (the rebuild is free, AST-only, no LLM cost). Dispatched to Atlas to install the post-commit hook plus a weekly auto-update cron.

FRONT 3
3 PIPES

James / Skool community ingestion live, but 3 broken sub-feeds

The core pipe is healthy: the daily James/Skool job has fired every morning since early June, and the knowledge base ingested 1,919 fresh chunks today. Not an island. But three sub-feeds were quietly failing: (1) TikTok transcripts dead since Jun 15 (a missing Groq API key, so ~4 days of James's daily TikToks were missed); (2) the NotebookLM synthesis sync failing daily since ~Jun 18 (expired auth); (3) the corpus manifest 13 days stale (no cron). All dispatched to Librarian with the Groq-key fix, a 7-day TikTok backfill, NotebookLM re-auth, and a manifest cron.

Island verdict: No. Upstream is synced, graphify and Skool are both live and feeding us — they just had drift (graphify) and broken side-channels (Skool) that I've now routed to Atlas and Librarian to fix. Nothing structural; nothing that required a course change. We are connected to the wider world's improvements.

2. cortextOS vs the alternatives (Decision 1: the framework)

You asked whether cortextOS is actually better than Hermes and OpenClaw, or whether we're sitting on a homemade thing while better options exist. I mapped the current landscape (Feb–Jun 2026). Short answer: no switch is warranted — nothing else matches our exact shape (always-on daemon + named multi-agent fleet + Telegram-first control for a non-engineer operator).

Framework	What it is	Strength	Why not us
cortextOS current	Always-on daemon, named fleet, task bus, Telegram-native	Purpose-built for 24/7 named fleets run by a non-engineer	—
OpenClaw	Self-hosted personal agent OS, Telegram-native, model-agnostic (OpenAI-acquired Feb 2026, 347K stars)	Huge community + template library; model-agnostic	Multi-agent is weak — channel-based, no real task bus or named-fleet model
Hermes Agent (Nous)	MIT, 200+ LLM backends, self-improving (Feb 2026)	Backend breadth, self-improvement	Multi-agent is roadmap-only — not shipped. Watch H2 2026.
Ruflo (ex Claude-Flow)	Swarm orchestration on Claude Code (53K stars, 84.8% SWE-bench)	Raw coding-swarm throughput	Coding-swarm tool, not a persistent named-fleet ops layer
CrewAI / LangGraph	Enterprise workflow / stateful pipelines	Compliance, observability, Fortune-500 adoption	Invocation-based, not always-on; built for engineers, not Telegram ops

The one real risk worth naming: bus-factor / lock-in. cortextOS is tied to a single developer and a paid Skool community, with no large public fork to fall back on. That is the genuine downside of staying. The hedge is cheap: keep watching the Hermes multi-agent roadmap (expected H2 2026) as the most likely future escape hatch, and keep our fork synced (which it is). If Hermes ships real multi-agent and the cortextOS dev goes quiet, we re-evaluate. Until then, no alternative does what we need out of the box.

✓ Verdict: stay on cortextOS. Decision is independent of the model question below.

3. Should we run cheap GLM models? The cost reality (Decision 2)

This is the decisive section. You wanted a cost breakdown at our real usage, and that's exactly where the answer flips from "obviously, GLM is 8x cheaper per token" to "flat Claude Max wins by a landslide." The reason is one number.

The killer number: 97% of our token traffic is cache-reads. Agent work is context-heavy — every turn re-reads the same large conversation, files, and memory. Anthropic's flat Max plan bundles those cache-reads into the ~$200/mo subscription. GLM, DeepSeek, and every pay-per-token API bill those same cache-reads as fresh input tokens, every single turn. That one billing difference is the whole game.

Our Analyst already modeled this on Jun 18 against 30 days of real throughput from the usage logs: 107k requests, ~27.5 trillion input tokens, 60.7M output tokens, of which 97% are cache-reads. Run those same numbers through GLM's per-token pricing:

~$200/mo flat Max (now)

$7–11k/mo at 20% on GLM

$39–59k/mo full GLM swap

35–250xflat Max advantage

Routing even 20% of turns to GLM would cost $7,000–$11,000/month versus our current ~$200/mo flat Max. A full swap of all agents to GLM at API rates lands around $39,000–$59,000/month. Not because GLM is expensive per token (it's ~8x cheaper than Claude per token) but because pay-per-token billing charges us for 27 trillion cache-read tokens that the flat subscription gives us for free. Flat Claude Max is the correct economic choice for our context-heavy traffic by 35–250x.

So when would a cheap model ever make sense?

Only for compressed, single-shot, low-context work — the "overflow lane." If a task is a self-contained packet (a small code-exec job, a file transform, a structured-output extraction) with little conversation history to re-read, the cache-read penalty mostly disappears and GLM's cheap per-token rate wins. That is a narrow slice, and it's the lane we already reserve for overflow. It is not our multi-turn, context-heavy orchestration and brand work.

The honest tiered-hybrid verdict

Keep on Claude (no change): Sage (orchestration), all brand/content/email work, anything multi-turn or judgment-heavy. The quality gap on long-horizon planning and brand voice is real, and the cost math says Claude is also cheaper here. Both arrows point the same way.
GLM is viable ONLY for pure code-exec workers (think Forge / Atlas style file-ops, tests, structured output) and only if their context stays small. z.ai's GLM Coding Plan is a true Claude-Code drop-in (Anthropic-compatible endpoint, ~$30/mo flat). That's the one place it could shave cost without quality loss — but our workers are on Codex Pro today, so even that is a marginal, optional move, not a needed one.
Net: no swap. The cheap-model question is answered by our own traffic shape. Flat Max stays.

4. The cheap-model field (for the record)

The full landscape we evaluated, so you can see the whole board. The "drop-in" column is what matters for ever actually using one inside cortextOS: only z.ai's GLM exposes a true Anthropic-compatible Claude-Code endpoint.

Model	$/Mtok In	$/Mtok Out	Flat plan	Context	Coding bench	Claude-Code drop-in	Quality vs Claude
Claude Opus 4.8	$5	$25	Max $100–200/mo	1M	69.2% SWE-Bench Pro	Native	Baseline; top reasoning, brand voice, orchestration
Claude Sonnet 4.6	$3	$15	Max incl.	1M	79.6% Verified	Native	Best Anthropic value
GLM-4.5 (z.ai)	$0.60	$2.20	GLM Coding $10–80/mo	131K	~45% est	Yes (api.z.ai)	Sonnet-ish on code; weaker writing
GLM-5.1 / 5.2 (z.ai)	~$0.60–1.00	~$2.20–4.00	GLM Coding $10–80/mo	200K–1M	58.4% Pro (5.1)	Yes (drop-in)	Sonnet-competitive on exec; behind Opus on reasoning; throttling risk
DeepSeek V3.2	$0.23	$0.34	None	128K	73.0% Verified	Proxy only	Cheapest credible coder
DeepSeek R1	$0.55	$2.19	None	128K	~60%+	Proxy only	Best cheap reasoning
Qwen3 Coder 480B	$0.22	$0.90	None	262K	strong	Proxy / OpenRouter	Good cost/perf
Kimi K2.6	$0.60	$2.50	None	200K	80.2% Verified	Proxy / OpenRouter	Best open bench; no flat plan
MiniMax M3	$0.30	$1.20	None	—	weak coding	Proxy	Content, not agentic

The drop-in detail. z.ai is the only true Claude-Code drop-in: set ANTHROPIC_BASE_URL=https://api.z.ai/api/coding/paas/v4 and ANTHROPIC_DEFAULT_SONNET_MODEL=glm-5.2[1m] and an agent runs GLM with zero code changes. The flip point where a per-token API beats a flat sub is roughly 3–5M output tokens/month — but again, that comparison ignores the cache-read penalty that dominates our actual bill. For us, the flat sub is comfortably ahead.

5. What we're already doing about it

None of this is just a report. The two soft spots from the island audit are already dispatched, and the recommendations are queued:

Skool 3 broken pipes → Librarian (in progress): restore the Groq key, backfill 7 days of missed TikTok transcripts, re-auth NotebookLM synthesis, add the corpus-manifest cron, and add a memory-guard retry so a deferred ingest auto-recovers.
Graphify staleness → Atlas (dispatched): install the post-commit rebuild hook and a weekly AST-only auto-update cron so the graph never drifts 15 commits behind again.
Wire Sage to graphify (recommendation): fold a graphify query into worker-dispatch packets so workers arrive pre-loaded with the relevant code-graph context. Low effort, free.
Model posture: no change. Flat Claude Max stays; cheap-model overflow lane stays reserved for compressed single-shot work only. Re-evaluate GLM only if our traffic shape stops being cache-dominated, or if a worker tier moves to pure low-context exec.

One line to take away. We are not on an island, cortextOS is the right framework for our shape, and flat Claude Max beats every cheap model by 35–250x because our traffic is 97% cache-reads. Two soft spots (graphify drift, Skool side-feeds) are already being fixed. Keep the stack. Keep the plan.

riles-fleet internal · noindex · generated 2026-06-19. Evidence: git log origin/main..upstream/main (empty), graphify build metadata, James/Skool launchd + KB logs, 30-day usage throughput from ~/.claude jsonl. Working notes: sage/local/notes/island-audit-2026-06-19.md, analyst/local/notes/glm-5-2-cost-model-2026-06-18.md.