Dev.to WebDev 🛠 Dev 👁 0 📖 5 min read

Introducing ZixcAI: An Agentic AI Chat Interface Powered by a 770B Parameter Model (80B Active)

Today I'm launching ZixcAI — an agentic AI chat interface built on top of a custom 770 billion parameter mixture-of-experts model with 80 billion active parameters per token. Most "AI chat" products you see in 2026 are

Today I'm launching ZixcAI — an agentic AI chat interface built on top of a custom 770 billion parameter mixture-of-experts model with 80 billion active parameters per token.

Most "AI chat" products you see in 2026 are wrappers around an existing API. ZixcAI is not. The interface is mine, the agent runtime is mine, and the model routing is mine. This article is a walkthrough of what it is, how the model architecture works, and why the 80B-active design is the right call for an agentic product.

What Is ZixcAI?

ZixcAI is an agentic AI assistant — meaning it doesn't just chat, it acts.

When you send a message, the model can decide to:

  • Execute code in a per-user sandbox (Python, shell)
  • Read and write files in an isolated workspace
  • Fetch URLs from the public web
  • Search the web through a browsing backend
  • Analyze images via a dedicated vision sub-agent
  • Remember you across sessions with persistent long-term memory
  • Quote, bookmark, and branch conversations — so you can fork a thread, explore a tangent, then return

The interface is a chat app — dark, minimal, keyboard-first. But the backend is an agent loop: a multi-round, tool-calling execution engine with retries, circuit breakers, and per-turn audit logs.

If that sounds like a lot, it's because it is. ZixcAI is not a small project.

The Model: 770B Total, 80B Active

The core of ZixcAI is a mixture-of-experts (MoE) transformer with:

  • 770B total parameters across all experts
  • 80B active parameters per token — only a subset of experts fire for each token
  • Sparse routing — the router picks the top-K experts for each position

Why MoE Instead of a Dense Model?

A dense 770B model would be brutal:

Approach Total Params Active/Token Compute per Token Memory Footprint
Dense 770B 770B 770B Very high Very high
MoE 770B/80B 770B 80B ~10% of dense High but manageable

MoE gives you the capacity of a giant model with the compute cost of a much smaller one. You pay for memory (all experts must be loaded), but you don't pay for compute on every token.

This is the same principle behind models like Mixtral, DeepSeek-MoE, and GPT-4-class systems. It's the dominant architecture for frontier models in 2026 for a reason.

Why 80B Active Is Enough

80B active parameters is roughly the same compute footprint as a dense 80B model per token. That's a serious amount of reasoning capacity — comparable to or exceeding most "70B" models that people run for serious work.

But because it's MoE, ZixcAI has 10x the total knowledge of a dense 80B model. Different experts specialize in different things — code, math, prose, tool use — and the router picks the right ones per token.

For an agentic product where the model needs to reason about tools, plan multi-step actions, and write code, this combination is ideal.

What It Feels Like to Use

Streamed Responses, Not Chunks

Every response streams token-by-token via SSE. Reasoning is displayed in a separate "thinking" panel you can expand. Tool calls appear inline as animated cards with status indicators.

Real Tools, Not Simulated

When ZixcAI runs code, it actually runs code — inside a sandboxed environment on the backend. You can see the stdout, stderr, exit code, and execution time. Files it creates stay in your workspace.

Multi-Modal by Design

Send an image, ZixcAI routes it to a vision sub-agent. The main reasoning model stays text-only (for speed and cost), but you get image understanding where it matters. This is a deliberate architecture choice — see below for why.

Persistent Memory

ZixcAI remembers facts about you across conversations. Tell it your name, your stack, your preferences — next session, it knows. Memory is user-visible and user-editable.

Conversation Branching

Every message has a "fork" button. Fork creates a new conversation starting from that message. You can explore tangents without polluting your main thread.

Syntax Highlighting, Math Rendering, Code Download

Code blocks get full syntax highlighting, one-click copy, and download. Math renders via KaTeX — inline and block, matrices, aligned equations, piecewise functions, all supported.

The Architecture, In Short

A ZixcAI turn looks like this:
User message
↓
[PHP API] → creates turn record → returns SSE meta event
↓
[Agent loop]
├─ Build history (system prompt + memory + recent turns)
├─ Call MoE model with tool schemas
├─ If tool call: execute → append result → loop
├─ If no tool call: stream final text to client
↓
[Persistence] → save turn, tool calls, usage, memory updates

text

Every layer is instrumented. Tool calls have circuit breakers. Streaming has watchdog timers. Every turn has a full audit trail.

The backend is native PHP with SQLite. I wrote about that choice here — it's an unorthodox stack for AI, but it works.

Why the 2-Agent Split for Vision

One thing that surprises people: ZixcAI's main model is text-only.

But ZixcAI understands images. How?

When you attach an image, ZixcAI:

  1. Routes the image to a vision sub-agent (a separate, smaller model tuned for image description)
  2. Gets back a detailed text description
  3. Feeds that description into the main reasoning model
  4. Responds to you using the combined context

Why this architecture instead of a single multimodal model?

Cost. Multimodal inference is expensive. If 95% of your traffic is text, paying multimodal cost on every request is wasteful.

Latency. The main model stays fast. Vision runs in parallel when needed, then gets injected as text.

Flexibility. You can swap the vision model without touching the main model. You can route specific image types to specific vision models. The main model never needs retraining when vision upgrades.

This is a pattern I expect to see more of as agentic products get more serious about unit economics.

What It's Not

ZixcAI is not:

  • A wrapper. The model, runtime, and interface are custom.
  • A general-purpose LLM. It's tuned for agentic tasks — tool use, code, multi-step reasoning.
  • Free. There are usage limits. I won't pretend otherwise.
  • Perfect. Memory extraction is heuristic. Vision routing is coarse. Tool retries are naive. It's a v1.

But it's a real product built by one developer, running real tools, on a real MoE backend.

Try It

ZixcAI is live. Sign up, send a message, ask it to write code, upload an image, ask it to remember something. It's free to try.

If you're building agentic products, I'm curious what your stack looks like:

  • What model are you running?
  • How do you handle tool calls and streaming?
  • Do you split vision from reasoning, or use a multimodal model?

Drop a comment. I read every one.

ZixcAI is built by @N4tzzOfficial. Follow for updates as I ship new features — memory improvements, faster streaming, and more tool primitives.

📰 Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.