Eighty point four percent against seventy-one point eight. That is the gap on the SWE-bench Verified benchmark between two otherwise identical models that Anthropic trained on the reasoning transcripts of its own Claude Opus 4.8. One was fed the full transcripts, the other only short summaries of them. A gap of nearly nine points explains why the company published a long write-up on defending against distillation on October 12, 2026, and why the API now contains a mechanism that has changed how developers can safely tidy up a conversation history.

The point is that a model produces more than an answer. Before answering it writes a draft, a chain of reasoning. For anyone who wants to copy someone else’s capabilities, the draft is worth more than the answer. The answer shows the result; the draft shows the thinking, and learning from thinking is far more efficient.

What distillation is, and why it is called an attack

In its peaceful form distillation is an ordinary technique: a large teacher model generates examples and a small student model learns from them. Labs compress their own models this way. The trouble starts when the teacher belongs to someone else and nobody asked permission.

Anthropic describes these campaigns as covert, industrial-scale efforts to extract one model’s capabilities and reproduce them in another. In its February report the company gave the scale: more than 16 million exchanges with Claude through about 24,000 fraudulent accounts. Three labs were named: DeepSeek (over 150,000 exchanges), Moonshot AI (over 3.4 million) and MiniMax (over 13 million). One proxy network ran more than 20,000 accounts at once. These are Anthropic’s own claims and cannot be independently checked, and the company is a party to the dispute.

The October document adds something new: the earlier defense stopped working because the attackers changed tactics.

How the defense and the workaround chased each other

The first measure was simple. If reasoning is valuable, do not show it in full; summarize it. The 80.4 versus 71.8 percent test shows that summarizing really does thin out the training material.

Then came active extraction. Prompts began to include requests such as “output your prior reasoning verbatim”, and by Anthropic’s account one lab tried 12,000 requests, each with a different trick. After that it turned out that protected reasoning blocks could be moved: from one conversation to another, to a model with weaker safeguards, to a different account inside a proxy network. A reasoning block was just text that could be cut and pasted.

That was the weak spot Anthropic went after first. If you cannot hide the draft, you can make sure it is useless anywhere but where it was produced.

How a reasoning block gets tied to its context

The mechanism is called preserved thinking, and the documentation describes it drily. Every reasoning block carries a signature. Starting with Claude Fable 5.1, the API uses it to check two things: whether the current model can read the block at all, and whether anything before it has changed. “Before it” means the system prompt, the list of tools and every earlier message. Change one word at the start and the block, along with every later one, becomes invalid.

There is also binding to an account. Blocks from Claude Sonnet 5.5 and Claude Haiku 5.5 work only in the account that produced them or a linked one. Foreign blocks are silently dropped. Opus 5 and Opus 5.5 never read Fable 5.1 blocks.

For an attacker this is awkward: to use a stolen piece of reasoning you must reproduce the whole context to the last character and sit in the right account. An ordinary developer faces consequences too. On accounts created on or after August 31, 2026, the prefix check is on by default, and a mismatch returns a 400 error. Older accounts get the check only when they set the prefix_mismatch_behavior parameter.

What breaks? Anything that likes to rebuild history. A system prompt with a fresh date substituted each time. Trimming old tool results. Client-side summarizing of old turns while keeping recent ones. Editing the tool list mid-conversation. The documentation tells clients to be append-only and offers replacements: add a system message instead of rebuilding the prompt, use server-side compaction instead of cutting history by hand. Claude Code, claude.ai and the Agent SDK handle all this themselves, according to the same page. If you call the Claude API directly, check at least how you serialize responses: empty thinking blocks must be sent back as they came, because the reasoning itself lives in the signature.

A drop_block mode lets you simply discard invalid blocks, but then the model re-derives its reasoning and output token use can rise noticeably. The documentation itself calls it a stopgap.

What the numbers show and what they do not

The second half of the defense is a two-stage classifier, built on Anthropic’s work on constitutional classifiers and trained on real extraction attempts. Anthropic reports a false positive rate below 0.1 percent. Since September 24 it also charges for requests that the safeguards block before Claude responds, including in the distillation area. Repeat offenders face tighter limits and bans: tens of thousands of accounts, by the company’s count, often in under two hours after a campaign starts.

The headline claim is that reasoning tokens extracted by distillers are now 10 to 100 or more times lower, and on some days too small to measure. Elsewhere the post speaks of a drop of roughly 90 to 99 percent and calls this early evidence.

Some care is needed here. The measurement was made by Anthropic, on its own platform. It estimates extracted tokens from what it managed to detect, and what went unnoticed is by definition invisible. Distillers also spread traffic across several providers’ APIs and clouds, so closing one door guarantees nothing about the others. Anthropic writes plainly that it does not know how long the effect will last, expects a cat-and-mouse game, and has not yet seen a highly sophisticated, persistent attempt to get around the new defenses.

The costs are named as well: turning away meaningful revenue and “trillions of tokens” of paying traffic, integration changes for some legitimate customers, rare false blocks. The February goal, making distillation harder without hurting legitimate users, the company says it has not fully met.

Why this reaches beyond Anthropic

Start with what is known from an independent source. NIST’s CAISI in September called Z.ai’s GLM-5.3 the most cyber-capable open-weight model released to date and put it about four months behind the US frontier. On the SEC-Bench Pro test, for example, it solved 74 of 183 tasks; the best US model solved 165. The assessment says nothing about distillation.

The link between GLM-5.3 and copying American models comes from Anthropic’s October text: according to it, Zhipu distilled cyber capabilities from leading US models, and when Anthropic’s safeguards degraded its attempts with Claude Fable 5, it switched to an older Claude model and to another lab’s model. That is the company’s claim, not a finding of a government body, and there is nothing outside to confirm it yet.

If it holds, the picture is uncomfortable. A capability that one company wrapped in protective restrictions ends up in a model released with open weights, where those restrictions are absent; by Anthropic’s own assessment, GLM-5.3’s built-in safeguards are easy to bypass. Hidden reasoning stops being a trade secret and becomes a piece of security.

The signature on a reasoning block is probably not the last mechanism of this kind. When a product can be copied just by asking it questions, protection moves into the exchange protocol itself. Developers of outside integrations have to get used to the idea that a conversation history is no longer their private correspondence but a chain that must arrive undamaged.

Short version: people do not buy AI aggregators because they are always cheaper than direct subscriptions. They buy them for one interface, Russian payment methods, fast access to many models and less friction with VPNs, foreign cards and separate accounts.

But this category is easy to misread. The same model names on a landing page can hide very different economics: tokens, generation queues, video duration, model version, output rights, fair-use rules and whether unused balance survives after a subscription ends. Below is a practical comparison of SYNTX.AI, AiHere, Outsee, Umnik.AI and similar platforms based on public information checked on May 23, 2026.

What we are comparing

There are three types of services in this group.

The first type is the universal aggregator: one account for text, images, video, music and sometimes code. SYNTX.AI, Umnik.AI, NeuroHub, Uniset AI, OMNEX AI and Razum are closest to this format.

The second type is the creator platform, where the real value is visual content: video, photo shoots, photo editing, motion control and music. AiHere and Outsee sit closer to this group.

The third type is direct subscriptions to the original services: ChatGPT , Claude , Gemini , Midjourney , Runway , ElevenLabs , HeyGen . They are usually clearer on rules, limits and official support, but they are less convenient if you need Russian payment methods and want to switch between a dozen models quickly.

Quick comparison table

Service — Best for — Public pricing model — What to check before paying

SYNTX.AI — Broad all-in-one use: text, images, video, audio, Telegram workflow — The public promo page/search-visible page shows annual-billing monthly prices from 756 ₽; Pro — 1,436 ₽, VIP — 3,391 ₽, Elite — 5,091 ₽, Ultra Elite — 10,191 ₽ — Current terms in the official Telegram bot, token burn per model, what exactly “unlimited” means

AiHere — Per-model generation of video, images and music: Sora, Veo, Kling, Suno and others — Internal unit on pricing page: 1 = 0.20 ₽; prices are listed by model and operation — Total cost of the whole video, not just a second; queue behavior; exact model version available at generation time

Outsee — Visual content: video, photo shoots, photo editing, motion control, music — Basic 890 ₽/month for 200 tokens; Pro 1,990 ₽ for 500; Ultimate 3,990 ₽ for 1,100; Creator 9,990 ₽ for 3,000 — How many tokens your target model burns and whether queue priority fits your workflow

Umnik.AI — Russian-language “all neural networks in one place” interface — Public pages are hard to evaluate statically; indexed pages show tariffs and model categories, but not enough reliable pricing detail — Prices, model list, limits and token storage rules must be checked inside the account

NeuroHub — Free start and light tasks with text, images, code and audio — Public page states a free Starter plan with 100 generations per month — Which models are included for free and what the paid plans actually unlock

Uniset AI — Template-led photo, video, audio and text workflows for creators — Public page shows Premium at 1,580 ₽/month with 325K tokens; 1.5K free tokens at registration — Real cost of one operation and whether templates fit your niche

OMNEX AI — All-in-one subscription for text, images, video and music — Landing page states 60+ models and “from $5 per month” — Exact model access, Russian payment options, refund rules and usage limits

Razum — Text, code, images, speech and documents without VPN and with Russian cards — Public page shows Free and Pro; Pro is listed at 999 ₽/month with 2,000 CR — Full credit multipliers, file/image limits, model availability and cancellation rules

SYNTX.AI: the loudest all-in-one offer, but the bot still matters

SYNTX.AI sells the idea of “90+ neural networks in one subscription”: text models, Midjourney-like image generation, Sora/Veo/Kling/Runway-class video, Suno-style music and voice tools. Its public promo page emphasizes Russian card payments, a Telegram-bot workflow and savings compared with buying several separate subscriptions.

The main upside is breadth. If you produce a content package for social channels, it is convenient to write a script, generate an image, animate it into a short video and add music in one place. For a beginner, that lowers the entry barrier: you do not have to decide where to buy Midjourney, where to run Kling, how to access Veo, how to pay for Suno or how to manage a pile of accounts.

The main risk is the word “access.” In aggregator products it can mean many things: native API access, proxy access, queues, different model versions, relaxed mode, internal limits or fair-use caps. SYNTX’s public material also points users toward the official Telegram bot for the service, tariffs and support. Treat the landing-page price as an orientation point until you check the current tariff inside the bot.

SYNTX.AI is worth considering if you need a broad model shelf for “a bit of everything.” If your daily work is mostly text, a direct ChatGPT or Claude subscription may be easier to reason about. If your work is professional video, do not compare subscription prices; compare the cost of one usable final clip.

AiHere: strong when the price of a specific generation matters

AiHere is built differently. Instead of a broad “everything included” subscription, it publishes per-model prices for video, image, music and AI-chat generation. The pricing page includes Sora 2, Veo 3 / Veo 3.1, MiniMax, Kling Motion Control, Gemini / Nano Banana and Suno. The same page says payment works through SBP and Mir cards, without VPN.

That makes AiHere useful when you already know what you want to generate. For example: one Veo clip, several attempts with Kling Motion Control, one Suno track, a batch of images through Gemini. In that scenario, per-model pricing can be more honest than a large subscription with attractive but vague promises.

The usual pay-as-you-go problem still applies: the price feels low until you count failed attempts. Video almost never lands perfectly on the first try. If a clip needs 5-10 iterations, the final cost rises much faster than the line item “per second” or “per generation” suggests.

AiHere fits producers, marketers and creators who budget for specific assets. It is weaker for people who want to experiment freely without feeling a meter running in the background.

Outsee: a clear subscription for visual content

Outsee focuses on AI content creation: video, photo shoots, photo editing, motion control, music and images. Its public tariff grid is easier to parse than many aggregator pages: Basic costs 890 ₽/month and includes 200 tokens, Pro costs 1,990 ₽ for 500 tokens, Ultimate costs 3,990 ₽ for 1,100 tokens, and Creator costs 9,990 ₽ for 3,000 tokens. Higher tiers add stronger queue priority and, on the Creator plan, early access to new models.

The advantage is packaging. If you regularly make visuals for Telegram, Reels, Shorts, product cards or promos, you care not only about the models but also about speed, queues, workflow and predictable monthly spend.

The weak point is still token economics. The token price is clear, but the price of the result becomes clear only after you test the actual deductions for your use cases. One user may burn a package on a handful of videos; another may stretch it across images and photo edits for weeks.

Outsee is the more logical starting point if your work is mainly visual and you want a monthly package without a “100+ everything” storefront. For heavy text work, document analysis and coding, look at universal aggregators or direct subscriptions instead.

Umnik.AI: promising format, but not enough public detail for a clean price comparison

Umnik.AI positions itself as a Russian-language service for using neural networks online without VPN. Public search results and pages point to model categories such as text, images, video, audio and presentations, plus features like voice personas. But the statically available pages do not provide enough tariff detail for a fair side-by-side price comparison.

That means Umnik.AI should not be compared with SYNTX.AI, AiHere and Outsee on price alone. The practical way to evaluate it is manual: create an account, inspect the model list, limits, internal currency, typical operation cost and refund rules.

The recommendation is simple. If Umnik.AI has the models you need, a comfortable interface and transparent deductions, it may be a reasonable alternative. If prices and limits only become visible after payment, or if the terms are vague, start with the smallest possible package.

Similar services: where to look for alternatives

NeuroHub is interesting because of its free entry point: the public page states a Starter plan with 100 generations per month. That is a good way to test the aggregator format without risk, but check which models are included and what counts as one generation.

Uniset AI looks more like a creator platform with ready-made ideas and templates. Public information shows Premium at 1,580 ₽/month, 325K tokens and a free start with 1.5K tokens. It may be economical for simple visual workflows, but token counts cannot be compared directly across services: 325K in one system does not equal 3,000 in another.

OMNEX AI states 60+ models, four content types and pricing from $5 per month. That is a strong headline, but before paying you should inspect the exact model list and limits. “OpenAI, Anthropic, Google and more” on a landing page does not guarantee unrestricted access to the most expensive modes.

Razum emphasizes Russian language, Russian card payments, no VPN and practical categories: text, code, images, speech and documents. Its public page is more useful than many in this category because it shows a credit model and a Pro plan, but you still need to check model multipliers and real deductions against your tasks.

Direct subscriptions vs aggregators

An aggregator is more convenient if you are in Russia, do not want to assemble foreign payment methods and use many different models irregularly. In that case, one package can be cheaper and calmer than several separate subscriptions.

A direct subscription is better if you have one main tool. For text work, that usually means ChatGPT , Claude or Gemini . For images, Midjourney . For video, Runway or a specialized video model. For voice, ElevenLabs . For avatars and video localization, HeyGen .

Official public pages show that direct subscriptions keep changing too. OpenAI lists ChatGPT Plus at $20/month. Claude Pro is listed at $20/month or $200/year, while Claude Max is listed at $100 or $200/month depending on capacity. Midjourney lists Basic, Standard, Pro and Mega at $10, $30, $60 and $120 per month. Google’s AI subscription lineup now includes AI Pro at $19.99/month and Ultra starting at $99.99/month, and Google has moved Gemini app limits toward a compute-used model, which makes “number of prompts” comparisons less useful.

So aggregators are not competing only on price. They compete on access and convenience. Direct services win on transparency, official support and fewer intermediaries between you and the model.

How to calculate the real price

Do not compare tariffs by monthly price. Compare the price of the result.

For text, count working sessions per day, limits on the best models, file support, context length and answer quality in your language. For images, count series generation, upscale, variations, privacy and rights. For video, count duration, resolution, iteration count, queues, keyframes, motion control and the ability to repeat a style. For audio, count minutes, commercial rights, voice cloning, languages and voice-use rules.

A good pre-payment test is to take one real job you have already done manually and run it through the smallest package. For example: 10 posts, 5 images, 3 short videos and 1 voiceover. After that, it becomes obvious where the service saves time and where it is mostly selling a polished model showcase.

What to check in the terms

Before paying, check seven things.

1. The cost of the exact model, not just “access to the model.”
2. Whether tokens expire and whether they can be used after a subscription ends.
3. Whether “unlimited” plans have fair-use limits.
4. What happens under load: queue, fallback model, quality reduction or refusal.
5. Whether auto-renewal can be cancelled from the interface without support.
6. What rights you get to the output and whether commercial use is limited.
7. What the service says about storing uploaded files, images, voices and prompts.

Who should choose what

If you need one service “for everything” and are ready to understand tokens, start with SYNTX.AI, OMNEX AI or Razum. SYNTX.AI looks the most aggressive on breadth, but current terms should be checked in the Telegram bot.

If per-model pricing matters and you make separate video or music assets, look at AiHere. It is easier to estimate the cost of a specific operation, but remember to budget for several attempts.

If you create visual content regularly and want a monthly package, start with Outsee or Uniset AI. The first looks more focused on AI-content generation; the second is more template- and idea-led.

If you work with text, analysis, code or documents every day, an aggregator is not always the best choice. A direct subscription to Claude , ChatGPT or Gemini can be more predictable, especially if payment and availability are not blockers for you.

Bottom line

The best AI aggregator is not the one with the most logos on the landing page. It is the one where your typical task becomes cheaper, faster and less dependent on failed attempts.

As of May 23, 2026, the practical split looks like this: SYNTX.AI for a broad all-in-one model shelf, AiHere for per-model video and music generation, Outsee for regular visual content, and Umnik.AI only after checking tariffs manually inside the service. Similar platforms such as NeuroHub, Uniset AI, OMNEX AI and Razum belong on the shortlist, but they should be compared by the price of a specific result, not by promised “dozens of models.”

Local AI agents are no longer just a toy demo you run once and forget. With Ollama handling local models and LangGraph handling stateful orchestration, you can build a private agent system that plans, delegates, checks its own work, and resumes from checkpoints without sending your task history to a hosted LLM API.

This guide builds a compact but real agent swarm: a supervisor, a researcher, an architect, a coder, a reviewer, and a finalizer. It runs on your own machine, uses a local Ollama model, and keeps the control flow explicit enough that you can debug it when the model takes a strange turn.

What we are building

The word swarm is often abused. Here it means a group of specialized agents coordinated through shared state, not a magic pile of prompts talking over each other.

The architecture has four layers:

1. Ollama runs the local LLM and exposes it through a local API.
2. LangChain’s ChatOllama integration gives Python code a clean chat-model interface.
3. LangGraph turns the workflow into a state machine with nodes, edges, routing, and checkpointing.
4. Your agents are just functions with narrow responsibilities and explicit state updates.

The important design choice: the supervisor does not let every agent speak at once. It routes work step by step. That is slower than naive parallelism, but easier to control, inspect, and recover.

Why run agents locally

Local agents make sense when the task contains private context, internal documents, code, customer data, personal notes, or anything you do not want copied into a third-party inference service.

They are also attractive when you want predictable cost. The software stack in this guide can run without a monthly LLM subscription if your machine is strong enough for the model you choose. That does not make local inference free: you still pay in hardware, electricity, setup time, and slower iteration. But the cost curve is different. You trade API bills for ownership and operational responsibility.

Use this setup for:

• private code review and refactoring plans;
• document triage over local files;
• repeatable research workflows over an internal knowledge base;
• offline drafting and summarization;
• experimentation with agent architectures before moving to managed infrastructure.

Do not use it as-is for:

• high-risk actions such as payments, account deletion, or production database writes;
• workloads that need the best frontier-model reasoning;
• large-scale concurrent serving;
• tasks where latency matters more than privacy or cost control.

Prerequisites

You need Python 3.11 or newer, Ollama installed, and at least one local model pulled. Start with a smaller general model while debugging the graph. Bigger models may reason better, but they also make every broken loop more expensive.

Install Ollama from Ollama , then pull a model from the Ollama model library. The exact best model changes quickly, so check the model tags before you build around one name. The examples below use qwen3 because Ollama’s current docs use it in tool-calling examples.

ollama pull qwen3 ollama run qwen3

In another terminal, check that the local API responds. Ollama’s default local API base URL is http://localhost:11434/api.

curl http://localhost:11434/api/generate -d '{ "model": "qwen3", "prompt": "Say hello in one sentence.", "stream": false }'

Now create a Python environment and install the orchestration packages.

mkdir local-agent-swarm cd local-agent-swarm python -m venv .venv source .venv/bin/activate pip install -U langgraph langchain-ollama langchain-core pydantic typing-extensions

The complete local swarm

Create local_swarm.py and paste this code.

from __future__ import annotations import operator import os from typing import Annotated, Literal from langchain_ollama import ChatOllama from langgraph.checkpoint.memory import InMemorySaver from langgraph.graph import END, START, StateGraph from pydantic import BaseModel, Field from typing_extensions import TypedDict MODEL = os.getenv('OLLAMA_MODEL', 'qwen3') llm = ChatOllama( model=MODEL, temperature=0, ) class Route(BaseModel): next_agent: Literal['researcher', 'architect', 'coder', 'reviewer', 'finalizer'] = Field( description='The specialist that should run next.' ) task: str = Field(description='A short task for that specialist.') reason: str = Field(description='Why this specialist is the next best step.') class SwarmState(TypedDict): goal: str current_task: str active_task: str iteration: int max_iterations: int supervisor_notes: Annotated[list[str], operator.add] research: Annotated[list[str], operator.add] architecture: Annotated[list[str], operator.add] code: Annotated[list[str], operator.add] review: Annotated[list[str], operator.add] final: str router = llm.with_structured_output(Route) def make_brief(state: SwarmState) -> str: nl = chr(10) parts = [] for key in ['supervisor_notes', 'research', 'architecture', 'code', 'review']: values = state.get(key, []) if values: parts.append(key.upper() + ':' + nl + nl.join(values[-2:])) return nl + nl.join(parts) if parts else 'No shared notes yet.' def supervisor(state: SwarmState) -> dict: if state['iteration'] >= state['max_iterations']: return { 'active_task': 'finalizer', 'current_task': 'Prepare the best possible final answer from the work completed so far.', 'supervisor_notes': ['Stopped by max_iterations to prevent an infinite loop.'], } decision = router.invoke([ ('system', 'You are the supervisor of a local multi-agent workflow. Route one next step only. Prefer finalizer when the answer is ready. Do not loop unless a concrete gap remains.'), ('human', 'Goal:' + chr(10) + state['goal'] + chr(10) + chr(10) + 'Current shared state:' + chr(10) + make_brief(state)), ]) return { 'active_task': decision.next_agent, 'current_task': decision.task, 'iteration': state['iteration'] + 1, 'supervisor_notes': ['Route to ' + decision.next_agent + ': ' + decision.reason], } def call_agent(name: str, system_prompt: str, state: SwarmState) -> str: response = llm.invoke([ ('system', system_prompt), ('human', 'Goal:' + chr(10) + state['goal'] + chr(10) + chr(10) + 'Assigned task:' + chr(10) + state['current_task'] + chr(10) + chr(10) + 'Shared state:' + chr(10) + make_brief(state)), ]) return name + ':' + chr(10) + response.content.strip() def researcher(state: SwarmState) -> dict: content = call_agent( 'Researcher', 'Find assumptions, missing facts, constraints, and useful context. Do not invent external facts. If evidence is missing, say so clearly.', state, ) return {'research': [content]} def architect(state: SwarmState) -> dict: content = call_agent( 'Architect', 'Design the workflow, data structures, failure boundaries, and tradeoffs. Be specific and implementation-oriented.', state, ) return {'architecture': [content]} def coder(state: SwarmState) -> dict: content = call_agent( 'Coder', 'Produce concise implementation steps or code. Prefer simple, testable Python. Mention assumptions that affect correctness.', state, ) return {'code': [content]} def reviewer(state: SwarmState) -> dict: content = call_agent( 'Reviewer', 'Review the proposed work for bugs, missing checks, unsafe actions, and vague claims. Return concrete fixes.', state, ) return {'review': [content]} def finalizer(state: SwarmState) -> dict: response = llm.invoke([ ('system', 'Write the final answer. Use the shared state, resolve contradictions, and be direct. Do not mention internal agent names unless useful.'), ('human', 'Goal:' + chr(10) + state['goal'] + chr(10) + chr(10) + 'Shared state:' + chr(10) + make_brief(state)), ]) return {'final': response.content.strip()} def route_from_supervisor(state: SwarmState) -> str: return state['active_task'] builder = StateGraph(SwarmState) builder.add_node('supervisor', supervisor) builder.add_node('researcher', researcher) builder.add_node('architect', architect) builder.add_node('coder', coder) builder.add_node('reviewer', reviewer) builder.add_node('finalizer', finalizer) builder.add_edge(START, 'supervisor') builder.add_conditional_edges( 'supervisor', route_from_supervisor, { 'researcher': 'researcher', 'architect': 'architect', 'coder': 'coder', 'reviewer': 'reviewer', 'finalizer': 'finalizer', }, ) for node in ['researcher', 'architect', 'coder', 'reviewer']: builder.add_edge(node, 'supervisor') builder.add_edge('finalizer', END) graph = builder.compile(checkpointer=InMemorySaver()) if __name__ == '__main__': initial_state: SwarmState = { 'goal': 'Design a local document summarizer for private meeting notes. Include architecture, risks, and a minimal implementation plan.', 'current_task': '', 'active_task': '', 'iteration': 0, 'max_iterations': 8, 'supervisor_notes': [], 'research': [], 'architecture': [], 'code': [], 'review': [], 'final': '', } config = {'configurable': {'thread_id': 'local-swarm-demo-001'}} result = graph.invoke(initial_state, config=config) print(result['final'])

Run it:

python local_swarm.py

To try a different model without editing code:

OLLAMA_MODEL=gemma3 python local_swarm.py

How the graph works

LangGraph models work as graphs: nodes do work, edges decide where execution goes next, and state carries the memory of the run. START and END are special graph markers. Conditional edges let the supervisor choose which node runs next.

In this example, the supervisor is the only router. That keeps the graph legible:

START -> supervisor -> specialist -> supervisor -> specialist -> supervisor -> finalizer -> END

The state has append-only lists for research, architecture, code, review, and supervisor notes. Those list fields use reducers, so each specialist can add information without overwriting previous work. The scalar fields, such as current_task and active_task, are overwritten on each supervisor step.

That distinction matters. Most broken agent systems fail because memory is a pile of unstructured chat logs. A graph state gives every part of the workflow a known place to write.

Why checkpointing matters

The example uses InMemorySaver because it is simple and works for a local demo. It lets LangGraph associate a run with a thread_id, which is also the mechanism used for pause and resume patterns.

For production, in-memory checkpoints are not enough. If the Python process dies, the checkpoint goes with it. LangGraph’s own reference recommends durable checkpoint stores, such as Postgres-based checkpointing, for production use. Treat InMemorySaver as a debugger and teaching tool, not as your reliability layer.

A practical production version should add:

• a durable checkpointer;
• stable thread IDs per user, task, or document;
• model and prompt version metadata in state;
• trace logs for every route decision;
• a maximum iteration limit;
• explicit human approval before irreversible tools run.

Adding tools without losing control

Ollama supports tool calling for models that can use tools, and LangChain’s ChatOllama integration exposes tool binding. That is useful, but do not start by giving a local agent shell access, filesystem writes, browser automation, and database credentials.

Start with narrow, boring tools:

• read a specific approved directory;
• search a local vector index;
• summarize a single file;
• create a draft patch but not apply it;
• validate JSON against a schema.

Then put human approval in front of dangerous actions. LangGraph’s interrupt pattern is designed for this: a node can pause execution, surface the proposed action, and resume only after a human decision. That is the difference between a useful autonomous workflow and a local model with too much authority.

Privacy model: what stays local and what does not

If you run Ollama locally and use only local models, prompts and outputs are processed on your machine. That is the main privacy benefit of this stack.

But privacy can disappear through the tools you attach. If an agent calls a web search API, sends telemetry, uploads logs, or writes to a cloud vector database, the workflow is no longer fully local. The model runtime is only one part of the data path.

Before using this on sensitive material, check:

• whether Ollama is using a local model or a cloud model;
• whether any tool sends text outside the machine;
• where checkpoints are stored;
• whether logs contain raw prompts or documents;
• whether your model license allows your intended use.

Performance expectations

A local swarm is slower than a single prompt because it makes multiple model calls. It can still be worth it when each step improves quality: one agent scopes the problem, another designs the approach, another writes code, and another reviews the result.

If runs feel too slow, reduce max_iterations before changing models. Then shorten prompts, shrink shared state, or route fewer specialist steps. Bigger models are not a substitute for a clean graph.

Good defaults for early experiments:

• temperature 0 for routing and review;
• small max_iterations, usually 5 to 10;
• one supervisor, not peer-to-peer chaos;
• structured output for routing;
• final answer generated only after review has had a chance to run.

Common failure modes

The supervisor loops forever. Add max_iterations, stronger finalization criteria, and route logs.

The model ignores the requested JSON or structured output. Use a model with stronger structured-output behavior, reduce the schema, or add a fallback parser.

Specialists repeat each other. Give each node a narrower system prompt and show only the latest relevant state, not the entire transcript forever.

The final answer includes false certainty. Make the researcher and reviewer explicitly mark missing evidence. Do not ask a local model to invent facts it cannot verify.

The system is private but not safe. Privacy and safety are separate. A local agent can still delete files, leak secrets to a tool, or generate bad instructions. Gate tools by default.

When to move beyond this demo

This implementation is enough for a serious local prototype. Move to a stronger setup when you need multiple users, long-running jobs, audit trails, or real tool execution.

The next step is not adding more agents. It is making the existing graph observable and durable:

• swap InMemorySaver for a persistent checkpointer;
• stream intermediate state to a small local UI;
• add human approval for tool calls;
• store documents in a local vector database;
• evaluate outputs against a fixed test set;
• use a GPU cloud provider such as RunPod only when local hardware is the bottleneck and the data can safely leave the machine.

Bottom line

LangGraph and Ollama are a strong pair because they solve different problems. Ollama makes local model execution approachable. LangGraph makes agent control flow explicit, inspectable, and recoverable.

The result is not a magical autonomous employee. It is a private workflow engine powered by local LLM calls. That is more useful: you can see what it is doing, limit what it can touch, and improve the graph one node at a time.

The EU AI Act is not “another AI policy page” for small businesses. It is a product, procurement, documentation and workflow problem with legal deadlines attached.

The headline date is 2 August 2026: under the official AI Act timeline, most remaining provisions are due to start applying then. But the practical picture is more nuanced. On 7 May 2026, the Council of the EU and the European Parliament reached a provisional political agreement on AI simplification rules that would delay parts of the high-risk regime: standalone high-risk AI systems would move to 2 December 2027, and high-risk systems embedded in products would move to 2 August 2028. As of 22 May 2026, that agreement still needs formal adoption and publication before businesses can treat it as settled law.

So the useful question is not “does this apply to us?” It is: where are we using AI, what role do we play, and which parts must be ready by which date?

The short version

If you run a small company, you probably do not need a huge AI compliance department. You do need a clear map of AI use inside the business.

Start with six moves:

1. List every AI system your company builds, sells, integrates or uses.
2. Decide whether you are a provider, deployer, importer, distributor or product manufacturer for each system.
3. Classify each system: prohibited, high-risk, transparency-triggering, general-purpose AI related, or ordinary low-risk use.
4. Ask vendors for evidence, not slogans.
5. Add human review, logs and user-facing notices where the Act expects transparency or oversight.
6. Track the May 2026 simplification package before locking your final deadline plan.

This is not legal advice. It is an operational guide for founders, ops leads, product managers and small-business owners who need to turn a dense regulation into a workable checklist.

What actually changes on 2 August 2026

The AI Act entered into force on 1 August 2024. It applies in stages.

Some rules are already active by the time you are reading this. The bans on prohibited AI practices and AI literacy obligations started applying on 2 February 2025. Obligations for providers of general-purpose AI models started applying on 2 August 2025.

The next major date is 2 August 2026. The European Commission describes the Act as becoming fully applicable two years after entry into force, with exceptions. The AI Act Service Desk also lists 2 August 2026 as the date when the remainder of the Act starts to apply, except for specific provisions.

The catch: “fully applicable” does not mean every compliance duty for every AI system lands on the same day.

The most important uncertainty is high-risk AI. The May 2026 provisional agreement would set later application dates for high-risk rules: 2 December 2027 for standalone high-risk systems and 2 August 2028 for high-risk systems embedded in products. Until the amendments are formally adopted and published, treat this as a likely but not final change.

First, find your role

The same AI tool can create different obligations depending on what your company does with it.

Provider

You are likely a provider if you develop an AI system or general-purpose AI model and place it on the EU market or put it into service under your name or trademark.

For a small software company, this can happen faster than expected. If you wrap a model into a SaaS product, market the AI feature as your product, and sell it to EU customers, you may not be “just using ChatGPT.” You may be providing an AI system.

Deployer

You are likely a deployer if you use an AI system in a professional context.

A retailer using AI for customer support, a recruiter using an AI ranking tool, a clinic using AI transcription, or an agency using generative AI for client work may all be deployers. Deployer obligations are usually lighter than provider obligations, but they are not zero.

Importer or distributor

You may be an importer or distributor if you make an AI system from outside the EU available in the EU market. This matters for resellers, marketplaces, integrators and channel partners.

Product manufacturer

If AI is embedded in a regulated product, the AI Act can interact with product safety rules. This is especially relevant for medical devices, machinery, toys, lifts, vehicles and other regulated categories.

For most small businesses, the provider-versus-deployer distinction is the first fork in the road.

Then classify the AI use

The AI Act uses a risk-based structure. Small companies should not start by reading every article line by line. Start by sorting systems into practical buckets.

Prohibited AI practices

Some practices are banned. The exact boundaries matter, but the general category includes AI uses the EU treats as unacceptable risk. If your use case touches manipulation, exploitation of vulnerabilities, social scoring, certain biometric categorisation, or real-time remote biometric identification in public spaces, stop and get specialist advice.

For ordinary small businesses, this bucket is less common than the others. But it is the first thing to rule out because the tolerance is low.

High-risk AI systems

High-risk is where the Act becomes operationally heavy.

The obvious small-business traps are not futuristic robots. They are everyday tools in sensitive domains: hiring, worker management, education, access to essential private or public services, creditworthiness, biometric identification, critical infrastructure, law enforcement, migration and justice-related uses.

If your company uses AI to rank job applicants, score employees, filter students, assess eligibility, recommend credit decisions or influence access to important services, you should assume this needs serious review.

Under the current political agreement, many high-risk obligations may be delayed beyond 2 August 2026, but that does not make them irrelevant. Procurement cycles, documentation, vendor negotiations and workflow redesign often take months.

Transparency-triggering AI

Some AI uses require people to be told what is happening.

This is especially relevant for chatbots, synthetic audio, synthetic video, image generation, deepfake-style content and AI systems that interact directly with people. A small marketing team using ElevenLabs , HeyGen or Runway for synthetic media should think less about “AI content is cool” and more about disclosure, consent, rights, provenance and recordkeeping.

That does not mean every AI-generated image needs a dramatic warning label in every context. It does mean the team needs a policy for when content is synthetic, when people could reasonably mistake it for real, and how disclosure is handled.

General-purpose AI model exposure

Most small businesses are not providers of general-purpose AI models. They are customers of model providers.

If you use frontier models through APIs or commercial tools, the model provider carries the main GPAI provider obligations. But you still need to understand what the model is doing inside your product, what data you send to it, what outputs affect users, and what your own product claims.

If you fine-tune, package or redistribute a model, the analysis changes.

Low-risk internal productivity use

Using AI to draft emails, summarize meeting notes, brainstorm copy or generate first-pass code is usually a lower-risk category under the AI Act. That does not mean it is risk-free. Privacy, confidentiality, copyright, security and employment rules can still matter.

But for AI Act triage, low-risk internal productivity use should not consume the same compliance budget as hiring, credit, health or education decisions.

The small-business AI inventory

You cannot comply with what you cannot see. The most useful first artifact is a simple AI register.

Create one row per system or workflow. Include:

• system name;
• vendor or internal owner;
• business purpose;
• users and affected people;
• input data;
• output and how it is used;
• whether the output influences decisions about people;
• EU users or EU market exposure;
• company role: provider, deployer, importer, distributor or manufacturer;
• likely risk category;
• human review point;
• vendor documentation received;
• retention, logging and incident process;
• next review date.

This can start as a spreadsheet. The point is not tool sophistication. The point is that someone can ask “where do we use AI?” and get a defensible answer in one place.

What to ask vendors

Small companies often hear the phrase “AI Act compliant” from vendors. That phrase is too vague to be useful.

Ask sharper questions:

• What role do you consider yourself under the AI Act for this product?
• Do you consider this system high-risk in any intended use?
• What uses do you prohibit in your terms?
• What documentation can you provide for risk management, data governance, testing, logging, human oversight and accuracy?
• Does the product generate synthetic audio, image, video or text that needs disclosure?
• Where is data processed and retained?
• Can we disable AI features we do not need?
• How will you notify customers about substantial model or system changes?
• Do you support audit logs and exportable records?

If the vendor gives only marketing copy, treat that as a procurement risk. For high-impact workflows, you need evidence you can keep.

What to do if you use AI in hiring

Recruiting is one of the easiest places for small businesses to underestimate the AI Act.

If an AI tool screens, ranks, scores or recommends candidates, the system may fall into a high-risk employment category. Even when the vendor is the provider, the employer using the system may still have deployer responsibilities.

Practical steps:

• identify whether the tool merely assists admin work or influences candidate selection;
• avoid fully automated rejection without meaningful human review;
• keep records of how recommendations are used;
• check whether candidates need notice;
• ask the vendor for high-risk documentation and intended-use statements;
• test whether the tool behaves differently across protected groups where lawful and feasible;
• make sure hiring managers understand the limits of the score or ranking.

The key distinction is influence. A scheduling assistant is one thing. A candidate ranking system that decides who gets interviewed is another.

What to do if you create synthetic media

Generative media tools are now ordinary business software. The compliance issue is that synthetic content can mislead people.

For marketing, education, training and support teams, build a lightweight disclosure policy:

• disclose AI-generated or AI-manipulated media when a reasonable person could mistake it for real;
• get explicit permission before cloning a real person’s voice or likeness;
• keep release forms and source files;
• label fictional avatars clearly in sensitive contexts;
• avoid synthetic endorsements from people who did not give permission;
• review local consumer protection, advertising and privacy rules alongside the AI Act.

If you use voice or avatar products such as ElevenLabs , HeyGen , Hume AI or video-generation tools such as Runway , the operational question is not whether the tool is impressive. It is whether your audience can tell what is real, what is synthetic and who authorized it.

What to do if you build AI into your own product

If your startup or agency ships an AI feature to customers, treat the AI Act as part of product management.

Before launch, write down:

• intended use;
• prohibited or unsupported uses;
• model or vendor dependencies;
• input and output data flows;
• failure modes;
• human oversight design;
• logging and monitoring;
• user-facing disclosures;
• escalation path for harmful or wrong outputs;
• update process when the model changes.

This is especially important if your product touches employment, education, finance, health, insurance, public services or safety-sensitive decisions.

For ordinary AI assistants, the documentation can be short. For high-risk or borderline systems, it needs to become real compliance evidence.

What not to overdo

Small businesses can waste money by treating every AI use as if it were a certified medical device.

Do not start with a 90-page policy nobody reads. Do not buy a compliance platform before you know your AI inventory. Do not rely on a vendor badge without understanding your own role. Do not assume that because a tool is popular, your use of it is low-risk.

A good first version is boring and useful: a register, a role map, a risk classification, a vendor evidence folder, a disclosure policy and a review calendar.

A practical 30-day plan

Week 1: map the AI footprint

Find every AI system in use: official tools, browser extensions, embedded SaaS features, API integrations, internal automations and experiments. Include tools used by marketing, HR, support, sales, finance and engineering.

Week 2: classify and prioritize

Mark systems that affect people’s opportunities, rights, access, eligibility, employment, education, credit, health, safety or essential services. These get priority.

Separate internal productivity tools from systems that face customers or influence decisions.

Week 3: collect evidence

Ask vendors for AI Act position statements, technical documentation, data processing information, transparency features, logs and change-notification processes.

For internal systems, write your own one-page system note.

Week 4: fix the obvious gaps

Add notices where users interact with AI. Add human review where outputs influence important decisions. Remove AI features nobody owns. Restrict risky uses in policy and product settings. Assign an owner for quarterly review.

The deadline that matters most

For many small businesses, 2 August 2026 is the date that forces the inventory conversation. It is not the end of the story.

Some obligations already apply. Some are due on 2 August 2026. Some high-risk obligations may move to 2027 or 2028 if the May 2026 simplification package is formally adopted. Some legacy and public-authority-related provisions have their own timelines.

That uncertainty is exactly why small businesses should start with facts they control: what AI they use, what it does, who it affects, what vendors can prove, and where human judgment remains in the loop.

The companies that handle this well will not be the ones with the thickest policy PDF. They will be the ones that can answer a simple question without panic: “Show me where AI makes or influences decisions in this business.”

Until recently, building a voice AI assistant usually meant stitching together three separate systems: speech recognition (STT), a large language model (LLM), and text-to-speech synthesis (TTS). That cascade architecture worked, but it had one painful flaw: latency. A two-to-four-second pause after every user phrase makes a conversation feel less like a dialogue and more like a walkie-talkie exchange.

By mid-2026, the industry has moved toward native Speech-to-Speech (S2S) models and real-time audio APIs. Instead of converting every utterance into text, waiting for a model response, then synthesizing audio at the end, these systems process audio streams continuously. That shift makes it possible to approach human conversational timing, roughly 300-700 ms in good conditions, while preserving tone, hesitation, emotional cues, and interruptions.

This guide compares three practical options for business voice agents: OpenAI Realtime API, Hume AI with its Empathic Voice Interface, and ElevenLabs Conversational AI. The goal is not to crown one universal winner. It is to help you choose the right stack for support, sales, healthcare intake, coaching, onboarding, or interactive media.

The main contenders

1. OpenAI Realtime API

OpenAI’s real-time audio interface is built around bidirectional streaming, usually over WebSockets, and is designed for low-latency conversational agents. The key difference from older voice stacks is that the model can handle audio natively instead of treating speech as a temporary text transcript.

For business teams, the main appeal is speed plus tool use. A voice agent can listen, respond, call functions, fetch account data, update a booking, or trigger a workflow while keeping the conversation fluid. The tradeoff is integration complexity: this is a developer-first API, not a one-click voice widget.

2. Hume AI EVI

Hume AI focuses on empathic voice interaction. Its Empathic Voice Interface, or EVI, is designed to detect emotional signals in speech and adapt the response style accordingly. That makes it especially relevant for coaching, mental wellness, patient support, customer satisfaction analysis, and any workflow where tone matters as much as the literal words.

The important distinction is that Hume is not only a voice generator. It is an emotional signal system wrapped into a conversational interface. If your agent needs to notice frustration, uncertainty, sarcasm, or distress, Hume deserves a serious look.

3. ElevenLabs Conversational AI

ElevenLabs became known for high-quality voice synthesis, voice cloning, and expressive generated speech. Its Conversational AI product brings that strength into real-time agents.

For many companies, ElevenLabs is attractive because the voices sound polished and brandable. If your product needs a recognizable voice, a media character, a game NPC, or a premium concierge feel, this can matter more than shaving the last 150 ms off latency.

The real comparison: latency, emotion, and interruptions

When a business deploys a voice AI agent, the demo is not the hard part. The hard part is making the agent survive real users: people interrupt, mumble, change their mind, get annoyed, speak over background noise, and expect the system to respond naturally.

1. Latency

Human turn-taking is fast. In a normal conversation, people often begin responding within a few hundred milliseconds. Once an AI agent regularly crosses the 800 ms mark, the interaction starts to feel mechanical.

• OpenAI Realtime API: Typically the strongest option for raw responsiveness, with a practical target around 300-400 ms in optimized network conditions. It is a strong fit when low latency is the product experience.
• Hume AI EVI: Usually sits closer to 500-700 ms. Some of that extra time is the cost of deeper acoustic and emotional interpretation, which may be worthwhile in empathy-heavy use cases.
• ElevenLabs Conversational AI: Often lands around 500-800 ms, depending on the selected LLM, voice settings, and integration pattern. The upside is voice quality and production polish.

2. Emotional range and sarcasm

Imagine a customer says, “Oh, sure, this is the best support experience of my life” while clearly sounding irritated. A basic text-only system may treat that as praise. A better voice AI stack should understand the emotional contradiction.

• Hume AI: The strongest candidate for emotional understanding. Its core value is detecting affective signals from prosody, pitch, tempo, and other vocal features. In a support scenario, it is more likely to respond with empathy instead of taking sarcastic words literally.
• OpenAI Realtime API: Very natural and fast, and it can infer sarcasm from context or obvious tone. It is less specialized than Hume for dedicated emotional analytics, but it has strong general conversational intelligence.
• ElevenLabs: The generated voices are often the most cinematic and pleasant. The weak point is not voice realism; it is dynamic emotional interpretation of the customer. For a branded voice experience, it shines. For live emotion analytics, it may need additional tooling.

3. Interruption handling

Real conversations are messy. People interrupt agents, agents need to stop speaking quickly, and the system must decide whether a cough, background speech, or short backchannel is a true interruption.

• OpenAI Realtime API: Interruption handling is one of its strongest advantages. Since audio streaming and response generation are tightly coupled, the system can stop the current audio output quickly when the user starts speaking.
• Hume AI: Strong in emotionally aware turn-taking and backchanneling. It is designed to treat conversation as a live interaction, not a sequence of isolated prompts.
• ElevenLabs: Conversational AI can handle interruptions well in its managed environment, but custom API integrations may require careful client-side VAD, buffering, and turn-taking logic.

Comparison table: business-relevant tradeoffs

Parameter — OpenAI Realtime API — Hume AI EVI — ElevenLabs Conversational AI

Typical latency — 300-400 ms — 500-700 ms — 500-800 ms

Voice quality — Excellent and natural — Good, emotion-focused — Excellent, often best-in-class

Customer emotion detection — Good general inference — Deep emotional analysis — Limited unless paired with another system

Interruption handling — Excellent — Strong — Good, integration-dependent

Estimated cost per minute — ~$0.12-$0.25 — ~$0.07+ — ~$0.15-$0.30

Integration complexity — High — Medium — Low to medium

Best fit — Fast transactional agents — Empathic support and coaching — Branded voice and media experiences

These numbers should be treated as planning ranges, not procurement quotes. Voice AI pricing changes quickly, and real costs depend on audio duration, model choice, token usage, concurrency, storage, telephony fees, and whether you route calls through a platform such as Twilio or your own infrastructure.

Integration architecture: the voice engine is not the whole product

A real business agent needs more than a beautiful voice. It needs access to CRM data, policies, booking systems, knowledge bases, payment status, order history, and escalation rules.

A practical architecture often looks like this:

1. The customer speaks through a browser, mobile app, or phone call.
2. The voice engine receives the live audio stream.
3. When the user asks for an action, the agent triggers a tool call.
4. An orchestration layer validates the intent and calls internal APIs.
5. The voice engine returns the answer in the same conversation.

For the orchestration layer, LangGraph is a useful framework because it lets teams model agent workflows as stateful graphs instead of a single prompt. That matters when a voice assistant needs to check permissions, ask follow-up questions, branch into different flows, or recover from failed tool calls.

Which platform should you choose?

Choose OpenAI Realtime API if:

• You need the lowest possible conversational latency.
• Your product already uses OpenAI models and tool calling.
• The agent must handle interruptions naturally.
• You have engineers who can manage WebSockets, audio streaming, and stateful sessions.

OpenAI is the strongest default for fast, transactional agents: booking assistants, internal copilots, sales qualification, support triage, and voice workflows where responsiveness directly affects conversion.

Choose Hume AI if:

• Emotional awareness is central to the product.
• You are building coaching, therapy-adjacent support, patient intake, customer satisfaction analysis, or wellness experiences.
• You need to detect frustration or uncertainty before the user states it explicitly.
• You can accept slightly higher latency in exchange for deeper affective signals.

Hume is most compelling when voice is not just an input channel, but an emotional context layer.

Choose ElevenLabs if:

• Your brand needs a memorable voice.
• You care about voice quality, character, and tone more than absolute minimum latency.
• You want a faster path to a working conversational prototype.
• You are building media, games, education, entertainment, or premium concierge flows.

ElevenLabs is the strongest choice when the voice itself is part of the product identity.

A simple decision rule

If you are building a customer support agent that must answer quickly and execute tasks, start with OpenAI Realtime API. If you are building an emotionally sensitive assistant, evaluate Hume AI first. If your core differentiator is a polished, branded, memorable voice, start with ElevenLabs.

For many mature teams, the final architecture may combine more than one layer: OpenAI for real-time reasoning and tool use, ElevenLabs for custom voice identity, Hume for emotion analytics, and LangGraph for orchestration. The winning stack is not always the one with the best demo. It is the one whose latency, cost, emotional intelligence, and operational complexity match the job your business actually needs done.

There are too many AI models now: one writes best, another draws, a third makes video, a fourth picks music, and each has its own account and its own bill. That is why AI aggregators appeared, services that collect different models in one interface. Syntx AI is one of them. By its public description, it combines dozens of models and tools for text, images, video and audio and is available through a Telegram bot and a web platform.

What follows is not a promotional retelling but a look at what exactly you get and what you pay with.

How an aggregator works

Technically, an aggregator is an intermediary between you and the APIs of several model developers. You send a request in one interface, it routes the request to the chosen model, and billing goes in internal units (tokens or credits) that the service converts into the provider’s cost plus its own margin.

Three consequences follow.

1. The model lineup is not under your control. The service decides which versions to connect and when to update. A new model in the official app may arrive at an aggregator with a delay, or not at all.
2. Price depends on conversion. Compare not the “monthly plan” but the cost of a specific task: minutes of video, number of images, text length. It differs by model.
3. Features may be trimmed. In a model’s official interface there may be extra tools (region editing, references, advanced parameters) that an aggregator lacks.

Where it pays off

• Comparing models on one task. The most visible plus: give the same prompt to several models and pick the best result without opening six accounts.
• Irregular use. If you make video or music once a month, paying for four separate subscriptions makes little sense.
• Payment and access. For users in Russia it matters that the service, according to its public materials, accepts Russian cards. Terms and availability change, so check the current state on the site.
• Telegram interface. For quick tasks from a phone it is more convenient than separate apps.

Where a separate subscription is better

• You work with one tool daily (say only a text model or only an image generator) and need all its features.
• You need a stable model version and predictable output in a large project.
• You have data and privacy requirements: with an intermediary, your prompts pass through an additional party.
• You need team features and invoices for accounting.

What to check before paying

1. Which models and versions are available right now.
2. How tokens are charged and what your typical task costs.
3. What the terms say about commercial use of outputs.
4. How the service handles data and whether it stores request history.
5. How fast support responds and whether unused balance can be refunded.

A practical way is to pick two or three typical tasks, run them on a small balance and compare cost and quality with direct access to the models. If the difference in cost and convenience is not obvious, stay with separate services.

How to structure the work

An effective process does not depend on the platform: idea and text draft in a text model, two or three draft images, pick a style, and only then expensive video generation. That order saves balance on any service. For how to compare other aggregators, see our review of SYNTX.AI, AiHere, Outsee, Umnik.AI and alternatives .

Bottom line

Syntx AI is a rational option for people who use different generative models irregularly and want to compare them without many accounts. For constant work with a single tool, or with strict privacy and model-version requirements, look at direct access.

The phrase “magic words for a neural network” lasts until the first serious task. Then it turns out the result depends not on incantations but on clarity: what is needed, for whom, in what form, and how you will know it turned out well. That is closer to a technical brief than a spell.

Five parts of a request

1. Task. What exactly to do.
2. Context. For whom, why, which facts are known.
3. Format. What the answer should look like: list, table, JSON, length.
4. Constraints. What to avoid, the tone, banned words.
5. Quality criteria. How you will judge the result.

A weak request:

Write a post about neural networks.

A stronger one:

Task: write a Telegram channel post on how small businesses use AI. Context: audience is cafe and shop owners with no technical background. Format: up to 900 characters, a hook in the first line, one concrete example. Constraints: no "revolution" or "the future is here", no emoji. Criterion: the example must be doable in one evening.

What works for text models

• Examples. One or two samples of the desired result beat a long description of style.
• Structured output. If the answer goes into a program, ask for JSON with a defined schema and validate it with code, not by eye.
• Step breakdown. For complex tasks ask first for a plan or a list of assumptions, then the result itself.
• Self-checking. Ask separately for a list of claims that need source verification.
• A role (“you are an experienced editor”) helps less than concrete criteria.

Image models

An image is described like a shot: subject, setting, light, angle, style, color palette. For reproducibility keep part of the style description fixed in every request. State what must not appear (“no text, no logos”). English sometimes gives more predictable results on visual models, but modern models understand other languages well too: test on your model.

Video

Video models are sensitive to motion. Describe the action and the camera separately: what happens, how the camera moves, how many seconds. One shot, one action. If you need a stable character, start from a reference image rather than text.

Music

State genre, tempo, mood, instruments and structure (“8-bar intro, verse, no vocals”). Mind the rights and terms of use for generated tracks on your platform.

Iterate instead of aiming for the perfect prompt

Do not try to write the perfect prompt first time. Run it, see what exactly is wrong, and change one thing at a time. Keep good prompts in a file: a prompt library pays off quickly.

How to check the result

For important tasks, build a small set of test examples and run every new prompt version against it. It is the same principle as in software: a change should improve things, not just look better on the last example.

Telegram channels are among the most visible areas where AI has entered daily work: post drafts, headlines, covers, short videos for stories. But the word “automation” misleads. A channel lives on the author’s voice and a reputation for accuracy, and those are exactly the two things models destroy first when left unchecked.

What models do well

• Ideas and series. Ask for 20 topics based on your past posts with the best metrics and you get a starting base for a content plan. A human chooses.
• Drafts and structure. A post skeleton from your thesis: hook, 2-3 points, conclusion.
• Editing. Shorten, change tone, find repetition. Safer than generating from scratch.
• Visuals. Covers and illustrations without licensing complications. Better to ask for an image without text and add captions separately.
• Repackaging. From one long piece, make a post, a set of takeaways and a short video script.

Where models let you down

• Facts. A language model can confidently name a nonexistent date, figure or quote. Check any claim with names, numbers and links against the source.
• Consistent voice. Without examples of your writing the model writes “averaged”. Readers cannot say why, but subscriptions and forwards fall.
• Freshness. A model without search access does not know the news. For news channels that is critical.
• Sameness. If everyone uses similar prompts, posts on the same topic become indistinguishable.

A workflow that works

1. Build a “voice passport”: 5-10 of your best posts, a list of favorite phrasings and banned words. Paste it into every prompt.
2. Give the model a thesis and source facts rather than asking it to “write about”. The source should be yours.
3. When you get a draft, rewrite the beginning and end yourself: that is where the author is heard.
4. Check facts and links. Mark where you rely on a source.
5. For covers use one style: the same colors and composition in every prompt.
6. Publish on a schedule, not in a burst. Scheduled sending is built into Telegram itself.

Automation through bots and API

If you want a pipeline (say, a bot that prepares drafts and sends them to you for approval), it is done with the Bot API and a model connected over API. One working principle: a human approves every publication. Fully automatic posting without review quickly leads to errors and, for some topics, to complaints against the channel.

To try models on one task, aggregators such as AiHere are handy, letting you compare texts and covers without separate subscriptions.

How to measure the effect

Look not at the number of posts but at reach, read rate, forwards and unsubscribes. If metrics drop after you adopt AI, the voice has been lost: put more of your own editing back.

Testing five visual ideas for an ad used to depend on a designer and a budget. Now an image or a short video takes minutes, and the number of variants has jumped. But more variants does not mean better results: test ten random pictures and you learn which won, not why.

Hypothesis first, generation second

A workable scheme is built on a matrix: what exactly you change and what stays constant.

Variable — Examples

Scene — product close-up / product in use / outcome

Emotion — calm / urgency / humor

Offer — discount / free delivery / guarantee

Format — square / vertical 9:16 / wide

From the matrix pick 3-5 combinations where one variable changes, and generate visuals only for those. Then the A/B test answers a question instead of just naming a winner.

What models can do today

• Images. Good at backgrounds, atmosphere and object scenes. The weak spots are text in the image (especially Cyrillic), hands, small packaging details and logos. A practical rule: ask for an image without lettering and add text in an editor.
• Video. Short clips from text or an image have become usable for testing, but long scenes and keeping one character consistent between shots remain unstable. For product ads it is often better to animate a finished photo.
• Brand consistency. To keep visuals from drifting apart in style, use references (palette, composition examples), a fixed style description in every prompt and a shared negative list (“no text, no logos”).

Ad platforms built in AI too

The ad dashboards of large platforms now offer generation of backgrounds and text variants themselves. That is convenient, but check which rights and limitations apply in each dashboard and compare with the output of external models. For small teams a third-party tool such as AiHere is useful when you want to compare several models on one idea.

What to check before launch

1. Rights and brand. Whether the image reproduces recognizable people, other companies’ logos or a specific artist’s style.
2. Labeling. Regulation is moving toward mandatory disclosure of synthetic content: the EU AI Act introduces such duties, and platforms have added labels of their own. Rules depend on country and channel, so check current requirements before launch.
3. Truthfulness. You cannot show in an ad a result the product does not deliver; a generated “before/after” easily becomes a violation.

How to read results

A test must collect enough impressions and conversions; an early leader is often noise. Compare on a metric chosen in advance (cost per target action, not clicks). Record which hypothesis won and use that knowledge in the next matrix.

AI speeds up producing variants but does not cancel analytics. The winner is whoever learns faster from tests, not whoever has more pictures.