DEV Community: N4tzzOfficial

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

N4tzzOfficial — Sat, 26 Sep 2026 03:53:21 +0000

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:

Routes the image to a vision sub-agent (a separate, smaller model tuned for image description)
Gets back a detailed text description
Feeds that description into the main reasoning model
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.

Why I Built an AI Agent in Native PHP in 2026 (And Not Python/Node)

N4tzzOfficial — Sat, 26 Sep 2026 03:51:18 +0000

Every time I tell another developer that I built an AI agent in PHP, the reaction is almost always the same: raised eyebrows, a thin smile, then the question — "seriously?"

Yes, seriously.

I built ZixcAI — an AI agent that can execute code in a sandbox, read files, fetch the web, analyze images, and maintain long-term memory — entirely in native PHP, no framework. Not Laravel, not Symfony, not Node.js, not Python. PHP 8.3, SQLite, a single process.

This is not a "PHP is better than X" post. This is a post about why, for this specific use case, PHP turned out to be the right call — and what I learned while shipping 2000+ lines of AI agent code in a language most people consider "ancient" for AI work.

Context: What Am I Actually Building?

ZixcAI is an agentic AI product. When I say "agentic", I don't mean a chatbot that returns greetings. I mean an LLM that can:

Execute code — Python scripts, shell commands, in a per-user sandbox
Read and write files — in an isolated workspace
Fetch web content — with host validation and response size limits
Search the web — via a bridge to Serper/Tavily
Analyze images — routed to a vision sub-agent
Remember you — persistent memory across sessions
Orchestrate multiple tools — in a single turn, with retries and circuit breakers

The chat interface streams responses via Server-Sent Events (SSE). Every tool call is logged, cached, and auditable. There is a full user system, session management, CSRF protection, attachment storage, and a subscription model.

This is not a weekend project. It's a production system.

The Reflex: "Shouldn't This Be Python?"

The standard argument goes: AI = Python. LangChain, LlamaIndex, CrewAI, Autogen — everything in the ecosystem is Python. If you're building an AI product, you should be in Python.

Here's the thing though — PHP is not competing with Python here. PHP is competing with the framework layer.

The actual work of an AI agent is:

Receiving HTTP requests — a chat message, a tool result, a stream.
Managing state — user sessions, conversation history, permissions.
Orchestrating API calls — sending prompts to an LLM, parsing responses, handling tool calls.
Streaming output — pushing deltas to the browser in real-time.
Persisting data — messages, turns, tool calls, memories.

Python does #3 well. But #1, #2, #4, and #5? PHP was literally designed for this. The entire web runs on request-response cycles that PHP has been optimizing for two decades.

When I stripped away the "should be Python" reflex and looked at what the agent actually does, PHP wasn't just adequate — it was faster to ship, easier to deploy, and cheaper to run.

Why PHP Actually Made Sense

1. Deployment Is Trivial

Python deployment is a small war: virtual environments, dependency pinning, WSGI servers, process managers, reverse proxies. Multiply that by every environment (dev, staging, prod) and you've got hours of ops work before writing a single line.

PHP deployment: copy files, point a web server at them, done. Every shared host in the world runs PHP. My entire production deploy is git pull and a cache clear.

For a solo developer shipping fast, this is not a nice-to-have. It's the difference between launching this month or this quarter.

2. The Request Lifecycle Fits the Agent Workflow

An AI agent turn is: request comes in → orchestrate a bunch of sub-requests → stream the response back → persist state → done. There's no persistent "agent daemon" that stays alive between turns.

This is exactly what PHP's shared-nothing request model was designed for. No memory leaks across requests. No concurrency primitives to fight. No event loop to debug. Each turn is a fresh, isolated, stateless execution.

Python's async model is powerful, but for this specific shape of work, it's also overkill and easier to get wrong.

3. SQLite + WAL = Zero-Ops Persistence

I chose SQLite with Write-Ahead Logging for storage. No Postgres to manage, no separate cache layer, no Docker compose stack. On a single-node agent, SQLite with WAL handles more than enough concurrent reads and writes.

The full-text search feature? SQLite has FTS5. Conversation search, message search, all indexed. No Elasticsearch. No Meilisearch.

Combined with PHP's stable PDO layer, persistence is a solved problem in ~30 lines of code.

4. SSE Streaming Is Actually Clean in PHP

Real-time streaming responses usually mean WebSockets or SSE, and both feel awkward in traditional web stacks. In PHP, they're just... responses that keep echoing.


php
header('Content-Type: text/event-stream');
header('Cache-Control: no-cache');
header('X-Accel-Buffering: no');

while (ob_get_level() > 0) ob_end_clean();
@ob_implicit_flush(true);

echo "event: delta\n";
echo "data: " . json_encode(['text' => $chunk]) . "\n\n";
@ob_flush();
flush();
That's the entire streaming contract. No framework, no library, no adapter. The main gotcha is output buffering — you have to disable it aggressively or the browser will buffer your entire stream before rendering. Once you know that, SSE in PHP is 20 lines of boilerplate.

5. The Framework Tax Is Real
I built this in native PHP, not Laravel. Here's why: frameworks are great when you need to solve 50 problems at once. When you need to solve 5 specific problems well, frameworks add more abstraction than value.

Every agent turn passes through the same 4-5 functions. My tool execution layer is ~200 lines. My memory system is ~150 lines. My SSE handler is ~80 lines. If I had used Laravel, half my debugging time would be understanding the framework, not my own code.

This is not a critique of Laravel. It's an observation that for a small, well-understood domain, a framework is sometimes the wrong abstraction.

The Trade-Offs (Because Nothing Is Free)
Let me not pretend this was all rosy. PHP has real limitations for this use case:

Concurrency. PHP-FPM spawns processes. If you need 100 concurrent long-running requests, you need 100 processes. For a chat product this is fine because most requests are short-lived streams, but if you were building a real-time collaboration tool, this would hurt.

Long-running background jobs. PHP doesn't have a natural "worker daemon" story without extra infrastructure (Supervisor, PM2, etc.). For ZixcAI, background work is minimal — title generation and memory extraction run inline after each turn. If I needed serious async processing, I'd probably add a small worker process in Node or Python.

Python ecosystem. There are Python libraries for AI that have no PHP equivalent. The OpenAI SDK for Python is richer than any PHP option. But the OpenAI API is just HTTP + JSON — you don't need an SDK. A curl_init() and a json_decode() cover 99% of what the SDK does.

Hiring. If I ever need to hire, "PHP developer with AI experience" is a smaller pool than "Python developer with AI experience." But for a solo project, this is a hypothetical.

What I Learned Building This
1. Streaming Is a Debugging Nightmare Until You Understand Buffering
The first version of my SSE stream didn't work. The browser received nothing until the entire response completed, then dumped everything at once. Three days later I found out that output_buffering in php.ini was silently holding every chunk.

Lesson: In PHP, for streaming, ob_end_clean() + ob_implicit_flush(true) + flush() after every chunk is non-negotiable.

2. Upstream Timeouts Kill Chat Products
LLM APIs are slow. A single turn can take 30+ seconds if the model is reasoning heavily. If your HTTP timeout to upstream is 15 seconds, you'll get random "chat failed" errors that only happen sometimes.

Lesson: Set CURLOPT_TIMEOUT to 0 (infinite) for streaming, and set a hard wall-clock limit at the product level (e.g., "if no token received for 45 seconds, abort the turn"). Distinguish between transport timeout and product timeout.

3. Tools Are Just Functions With a Contract
I spent a week designing an elaborate tool-call protocol before realizing: the LLM only sees a JSON schema and returns a JSON call. Your job is to route the call, sanitize arguments, execute safely, and return a text result.

php
if ($tool === 'shell.exec') {
    $cmd = (string)($args['command'] ?? '');
    if (!self::isSafeShellCommand($cmd)) {
        return ['exit_code' => 400, 'stdout' => '', 'stderr' => 'blocked'];
    }
    // ... execute via bridge
}
That's the whole tool layer. Everything else is bookkeeping.

4. Memory Is Harder Than Tools
Reading files and running code is easy — the LLM tells you what to do, you do it. But knowing what to remember across sessions is a genuinely hard problem. My current system extracts 0-3 memory items per turn via a secondary LLM call, deduplicates with similarity matching, and injects the top-30 into the system prompt.

It works. It's not perfect. But it taught me that "memory" in agentic systems is 20% storage and 80% extraction policy.

5. Circuit Breakers Save You From Cascading Failures
If your sandbox bridge goes down, every tool call will hang for 30 seconds and then fail. That's a bad user experience and it exhausts your process pool.

Adding a simple circuit breaker (5 consecutive failures → short-circuit for 30 seconds) made the product dramatically more resilient:

php
if (self::$bridgeFailures >= self::BRIDGE_FAILURE_THRESHOLD) {
    if (time() - self::$lastBridgeFailure < self::BRIDGE_CIRCUIT_RESET_SECONDS) {
        return ['ok' => false, 'status' => 503, 'body' => [
            'violation_code' => 'bridge_circuit_open',
        ]];
    }
}
This is 6 lines of code and it's the difference between "the product degrades gracefully" and "the product crashes when one dependency hiccups".

So, Should You Use PHP for Your AI Agent?
If you're building a research project, a training pipeline, or heavy ML work — no. Use Python. The ecosystem is unmatched.

If you're building an agentic product where the LLM does the reasoning and your job is orchestration, streaming, and persistence — PHP is a perfectly defensible choice. It's fast to ship, cheap to deploy, and boring in the best way.

The "AI must be Python" rule is a community convention, not a technical constraint. The technical constraint is: can your language make HTTP requests, handle JSON, and stream output? If yes, you can build an AI agent in it.

The real question isn't "is PHP good for AI" — it's "is this stack right for this product". For ZixcAI, it was.

What's Next
I'm continuing to ship ZixcAI features: better memory, multi-modal inputs, and more tool primitives. If you want to see what an agentic AI built on PHP actually looks like in practice, check it out.

If you're building something similar — in PHP, Python, or anything else — I'd love to hear about it. Drop a comment with your stack and what surprised you the most.

And if you made it this far: yes, PHP is fine. Really.

Thanks for reading. If you found this useful, I write occasionally about AI engineering, unorthodox stack choices, and building products solo.

Why I'm Building N4Kit Instead of Another AI Tool

N4tzzOfficial — Tue, 16 Jun 2026 09:06:15 +0000

Why I'm Building N4Kit Instead of Another AI Tool

Artificial intelligence is everywhere.

Every day, new AI tools, AI assistants, AI agents, and AI startups appear online.

While AI is exciting, I noticed something interesting during my own development workflow.

Most of the tasks I perform daily don't actually require AI.

What I use most often are simple tools:

JSON formatters
JWT decoders
UUID generators
Password generators
QR code generators

Small utilities that save time and help me work more efficiently.

The problem is that these tools are often spread across many different websites.

So instead of building another AI project, I decided to build something practical.

Introducing N4Kit

N4Kit is an open-source developer toolkit focused on productivity and simplicity.

The goal is not to replace existing tools.

The goal is to provide a better experience by bringing useful utilities together in one place.

Building for Developers

N4Kit is designed around a simple philosophy:

Fast.
Useful.
Open Source.

No unnecessary complexity.

No bloated interfaces.

Just tools that help developers get things done.

What's Next?

The project is still in active development.

Future plans include:

More developer utilities
Snippet collections
Productivity features
Workflow enhancements

I'm building N4Kit publicly and sharing the journey along the way.

Sometimes the best projects aren't the most complex ones.

They're the ones people actually use every day.

🌐 Live Demo:
https://n4kit.n4tzzofficial.my.id/
💻 Source Code:
https://github.com/N4tzzOfficial/N4Kit

Built by N4tzzOfficial under N4tzzNetwork.

Who is N4tzzOfficial?

N4tzzOfficial — Mon, 15 Jun 2026 06:29:40 +0000

In today's rapidly evolving digital world, innovation, automation, and artificial intelligence continue to transform the way people interact with technology. Behind several growing technology projects stands N4tzzOfficial, an independent software developer, digital creator, and technology enthusiast dedicated to building intelligent, scalable, and practical digital solutions.

N4tzzOfficial is the founder of the N4tzzNetwork / N4tzzTeam, a connected network of projects focused on artificial intelligence, automation, software development, network infrastructure, and digital innovation.

The goal is simple: to create useful technology that empowers users, developers, and communities through innovation and reliability.

The N4tzzNetwork / N4tzzTeam

The N4tzzNetwork / N4tzzTeam consists of multiple projects working together to create a modern and connected technology environment.

N4lyx

N4lyx is a WhatsApp automation library designed to help developers create messaging systems, bots, and automation workflows.

Key Features
WhatsApp Automation
Messaging Workflows
Bot Development
API Integration
Event Handling
Developer Tools

N4lyx focuses on simplifying communication automation while providing flexibility for developers to build custom solutions.

Nexa AI

Nexa AI is an intelligent desktop assistant inspired by the concept of advanced AI companions such as JARVIS.

Unlike traditional chatbots, Nexa AI is designed to integrate directly with a user's computer environment, helping manage tasks, automate workflows, and improve productivity through natural language interaction and intelligent automation.

Key Features
Natural Language Conversations
Desktop Automation
Voice Assistant Capabilities
Smart Productivity Tools
Application Integration
Task Management
AI-Powered Assistance
System Interaction

The long-term vision of Nexa AI is to become a powerful personal desktop companion capable of assisting users in everyday computing activities.

N4tzzNetwork

N4tzzNetwork is the infrastructure, networking, and security division of the N4tzz Ecosystem.

It is responsible for maintaining the technological foundation that supports projects, services, and future innovations developed under N4tzzOfficial.

Core Responsibilities
Network Infrastructure
Cloud Systems
Server Management
Infrastructure Monitoring
Digital Security
System Reliability
Performance Optimization
Technology Operations

N4tzzNetwork ensures that services remain secure, stable, and scalable while supporting the long-term growth of the ecosystem.

N4tzzTeam

N4tzzTeam is the primary development organization behind projects within the N4tzz Ecosystem.

The team focuses on designing, building, and maintaining software solutions across multiple technology sectors.

Areas of Expertise
Software Engineering
Artificial Intelligence
Automation Systems
Web Development
API Development
Infrastructure Solutions
Digital Innovation

N4tzzTeam transforms ideas into practical products and services that contribute to the ecosystem.

Technology Areas

N4tzzOfficial actively works across several fields:

Artificial Intelligence
Automation Systems
Software Development
Cloud Infrastructure
Networking
Cybersecurity
Desktop Applications
Web Technologies
API Development
Productivity Solutions
Vision

The vision of N4tzzOfficial is to build a connected digital ecosystem where software, artificial intelligence, automation, infrastructure, and security work together seamlessly.

By combining innovation with practical solutions, N4tzzOfficial aims to create technology that remains useful, scalable, and future-ready.

Looking Ahead

The journey of N4tzzOfficial is only beginning.

Future plans include expanding N4lyx, advancing Nexa AI, strengthening N4tzzNetwork, and developing new technologies that contribute to a smarter and more connected digital future.