DEV Community: Slawa

[Boost]

Slawa — Mon, 05 Oct 2026 13:49:23 +0000

Slawa

Oct 2

OpenAI Dots, Meta Muse, Grok Bot: Who Owns Your AI Agent's Computer?

#ai #agents #security #architecture

8 min read

State of AI, Fall 2026: Which Models Lead, Which Benchmarks Still Matter, and What Your $200 Subscription Really Buys

Slawa — Fri, 02 Oct 2026 13:55:04 +0000

State of ai devto body · TXT

TL;DR: Anthropic (Claude Opus 5.5, Sonnet 5.5, Fable 5.1) and OpenAI (GPT-6 Astra, GPT-6.1 Sol) currently lead; open-weights models such as Kimi K3 and DeepSeek V4 trail by three to eight months. What decides your productivity is no longer the score, but the price per task and the real usage limits of your subscription.

Snapshot as of 30 September 2026. The original of this article is a living post: models, benchmarks, prices and limits are re-verified every week. For the latest numbers and the dated changelog, check the up-to-date version on next-levels.de.

The benchmark table you just read in some newsletter is already out of date. Over the last four weeks, the top spots have been reshuffled five times. And yet the question that’s really burning in the developer forums is a different one. A ChatGPT Pro user writes: “Weekly limit reset yesterday, only 20% left today.” The model question has become a side issue. Your productivity is determined by the cost per task and your weekly limit; that last percentage point on the leaderboard is just noise.

So this post answers four questions: which models are leading the pack, which benchmarks can still measure anything, what the $20, $100 and $200 subscriptions really include, and what developers experience with Claude Max, Codex and Kimi in their day-to-day work.

At a glance

Top performers: Claude Opus 5.5 and Sonnet 5.5 lead the independent coding and agent indices, while GPT-6 Astra leads in knowledge and interactive reasoning.
SWE-bench Verified, GPQA and AIME are saturated. Terminal-Bench 4.0, ARC-AGI-3, GDPval-AA and the Artificial Analysis Index with private test sets are meaningful.
The mid-range (US$2 to US$4 per million input tokens) has seen a collapse in price: GPT-6.1 Sol and Sonnet 5.5 cost 2/10, Opus 5.5 4/20. The top tier remains at 10/50.
The subscription tiers differ in volume, not in model access; even entry tiers get the top models: Claude effectively reduced its weekly limits by 17% in September, while OpenAI paused Pro 20× and reopened it with half the quota.
Recommendation: Opus 5.5 at medium reasoning effort as the default, top-tier models only for review and security, Kimi K3 as a cheap second track for code without personal data.

AI models compared: who’s currently in the lead

The real news this summer comes from the open-weights camp. Since July, four Chinese labs have released models with between one and three trillion parameters and one million tokens of context under open licences: Kimi K3 from Moonshot (2.8 trillion parameters, 104 billion active, weights available since 27 July), Alibaba’s Qwen3.8-Max, DeepSeek V4-Pro under the MIT licence and, most recently, Xiaomi’s MiMo-V2.6-Pro, which, with an index score of 46, is the strongest open model in the Artificial Analysis ranking.

How big is the gap? The US institute CAISI estimates it for DeepSeek V4 Pro at around eight months behind the US frontrunners; for GLM-5.3, it measures on cyber benchmarks around four months. Nathan Lambert from Interconnects sees the gap narrowed by K3 from six to nine months to three to five months. Three to eight months: That’s the head start you are buying today when you pay for a closed frontier model.

And the leaders? A duopoly. In June, Anthropic moved the “Fable/Mythos 5” class above Opus; Fable 5.1 and Mythos 5.1 were launched on 1 September; Mythos remains reserved for security-cleared programmes. They were followed by Claude Opus 5.5 at 4/20 US dollars per million tokens, which, according to Anthropic, is “on a par with Fable 5.1 for most tasks”, and Sonnet 5.5 at the unchanged price of 2/10.

OpenAI has simultaneously replaced its entire range. GPT-6 Astra is the company’s largest training run (over 100,000 GPUs), with 1.05 million tokens of context and a price of 10/50 US dollars per million. Below it sit GPT-6 Sol and Luna, at half the price of the 5.6 generation, and on 29 September, GPT-6.1 Sol, which, according to OpenAI, delivers Astra-level performance on DeepSWE at a fifth of the cost.

Google has spent the year without a new Pro model. Gemini 3.5 Pro was announced at I/O and never launched; instead, three Flash models were released in six weeks, most recently Gemini 3.8 Flash on 2 September. According to Google, Gemini 4 is set to be released well before the end of the year. xAI releases new models monthly (Grok 4.7 on 21 September, US$2/6). Meta has effectively shelved the Llama line: since April, its only model has been the proprietary Muse Spark, currently at version 1.3.

Model	Provider	Release	Context	API price (1M tokens in/out)	Open weights
Claude Fable 5.1	Anthropic	1 September 2026	1M	10 $ / 50 $	no
Claude Opus 5.5	Anthropic	22 September 2026	1M	4 $ / 20 $	no
Claude Sonnet 5.5	Anthropic	28 September 2026	1M	2 $ / 10 $	no
GPT-6 Astra	OpenAI	4 September 2026	1.05M	10 $ / 50 $	no
GPT-6.1 Sol	OpenAI	29 September 2026	1.05M	2 $ / 10 $	no
GPT-6 Luna	OpenAI	22 September 2026	1.05M	$0.10 / $0.50	no
Gemini 3.8 Flash	Google	2 September 2026	N/A	$0.75 / $3.75 (introductory price until 31 December)	no
Grok 4.7	xAI	21 September 2026	500K	$2 / $6	no
Kimi K3	Moonshot	16 July 2026 (weights 27 July)	1M	3 $ / 15 $	yes (revenue-based licence)
DeepSeek V4-Pro (0813)	DeepSeek	13 August 2026	1M	N/A	yes (MIT)
Qwen3.8-Max	Alibaba	3 August 2026	1M	N/A	yes (own licence; Apache 2.0 only for Qwen3.8-27B)
MiMo-V2.6-Pro	Xiaomi	21 September 2026	1M	$0.43 / $0.87	yes (MIT)

Vendor list prices as of 30 September 2026; batch and cache discounts come on top. And that is precisely where the most important figure of the month lies: Anthropic has reduced the cache read prices by 75% for Fable 5.1 (to $0.25 per million) and by 60% for Opus 5.5 (to $0.20). In an agent run that re-reads the same 200,000-token context fifty times, that amounts to ten million cache tokens: with Opus 5.5, the cost is two US dollars instead of five. The list price for fresh tokens is almost irrelevant for such workloads.

Benchmarks: what still has room for growth and what is saturated

If you pick models from tables, you have a problem: the benchmarks you know are obsolete. OpenAI removed SWE-bench Verified from its own reporting in February because 59% of the tested tasks were flawed and top models were able to reproduce the human reference solution verbatim. GPQA Diamond was removed from the index by Artificial Analysis in September because all top models “simply solve” it. On AIME 2026, the top 3 sit between 97% and 99%. On FrontierMath, Epoch AI had to re-release the benchmark in June after 42% of the tasks contained errors.

What counts instead are interactive, economically grounded tests that are hard to contaminate. Terminal-Bench 4.0 comprises 66 curated tasks; eight were removed (saturated, publicly solved or with quality issues), 19 were revised. ARC-AGI-3 is interactive; the model must learn the rules of an environment through trial and error, so there is no solution that could be found in the training dataset. GDPval-AA measures real-world professional tasks from 44 occupations in blind pair comparisons. And Artificial Analysis weights private, never-before-published test sets at 45% in the Index v4.3, compared with 40% in v4.2 and 20% previously.

Benchmark	What it measures	Top 3 (as at 30 September)	Status
AA Intelligence Index v4.3	10 evaluations, 45% private sets, independent	Opus 5.5 (58), Opus 5.5 xhigh / Sonnet 5.5 (56), Fable 5.1 / GPT-6 Astra (53)	current
Terminal Bench 4.0	agent-based terminal tasks, independent	Sonnet 5.5 (63.6%), Opus 5.5 max (59.6%), Opus 5.5 xhigh (59.6%)	current
Arena WebDev	Web apps in a blind comparison, 795,000 votes	Opus 5.5 (1,827), GPT-6 Astra (1,792), Fable 5.1 (1,751)	current
GDPval-AA v2.1	220 professional tasks, 44 professions, Elo, independent	Opus 5.5 (1846), Sonnet 5.5 (1844), Opus 5.5 xhigh (1820)	current
Humanity’s Last Exam	Expert knowledge, no tools, independent (Scale)	GPT-6 Astra (54.2%), Gemini 3.1 Pro (47.3%), Fable 5.1 (46.8%)	current
ARC-AGI-3	Interactive reasoning, independent (ARC Prize)	GPT-6 Astra 62.7% on the standard harness (99.9% on the provider’s harness), Opus 5 30.2%; Opus 5.5 not yet measured	current, harness dispute
SWE-bench Verified	Coding tickets	Top score 96%; ranks 11 to 15 within half a point at 80%	Saturated; discontinued by OpenAI
GPQA Diamond	Natural sciences	Provider figures: Astra 96.0%, GPT-5.6 Sol 94.6%	saturated, removed from the AA Index
AIME 2026	Math olympiad	Top 3 within 2.1 points at 97–99%	saturated

“xhigh”/“max” denote the reasoning effort used in the measurement. “Harness” refers to the test environment: which tools the model is given, how many attempts, and what compute budget.

The figures from providers’ blogs are almost universally higher than the independent measurements. Anthropic reports 70.6% for Sonnet 5.5 on Terminal Bench 4.0, while Artificial Analysis measures 63.6%. OpenAI reports 99.9% for Astra on ARC-AGI-3, while the standard ARC Prize harness yields 62.7%, with computing costs of around 26,000 US dollars for the test run. Neither figure is a lie; they are different harnesses and reasoning levels. They are just not comparable. In short: trust the figure measured by someone who isn’t selling the model.

What has shifted in recent weeks: Since the release of Opus and Sonnet 5.5, Anthropic has been leading the way in agentic coding tests and professional task indices, while OpenAI leads in knowledge, maths and ARC. Both providers are now promoting the same metric. Anthropic calculates that Opus 5.5 at medium reasoning effort beats Astra at maximum effort, at roughly a fifth of the cost per task. OpenAI countered on 29 September with GPT-6.1 Sol and exactly the same formula.

AI subscriptions compared: what you get for $20, $100 and $200

Comparing AI subscriptions is simpler than it looks. All providers have settled on three tiers (around 20, 100 and 200 US dollars), and all control the price via limits. Euro prices are for Germany and include VAT where the provider states them:

Provider	Entry level	Mid-range	Top tier	What distinguishes the tiers
Claude	Pro €21.42 (Opus, Sonnet, Claude Code)	Max 5× €107.10	Max 20× €214.20	5-hour window plus weekly limit; Fable 5.1 available only on Max and Team Premium, up to 50% of the weekly limit
ChatGPT	Plus €23 (15 to 150 Sol messages per 5 hours)	Pro 5× €103	Pro 20× €229 (new sign-ups since 29 September with halved quota)	Weekly quotas at all tiers; Astra Ultrafast only on Pro for $500
Gemini	AI Pro $19.99 (3.1 Pro, Antigravity entry-level)	AI Ultra $99.99	AI Ultra $199.99	Gemini CLI disabled for subscriptions since 18 June; replaced by the closed Antigravity CLI
Kimi Code	Andante ¥49 (K2.7 Code)	Moderato ¥99 / Allegretto ¥199 (K3, 1M)	Allegro ¥699	Monthly pool plus weekly allowance plus 5-hour rate; processed by Moonshot AI Pte. Ltd. in Singapore
Cursor	Pro $20 ($20 credit)	Pro+ $60 ($70 credit)	Ultra $200 ($400 credit)	Credits instead of requests since 2025; Auto mode draws on credits too
GitHub Copilot	Pro $10 ($10 credit)	Pro+ $39	Business $19 / Enterprise $39 per user	From 1 June 2026: usage-based pricing according to API rates

Euro prices for Claude according to ssdnodes, for ChatGPT according to heise; Google and Kimi do not quote euro prices for Germany. For teams, the number of user seats is relevant: Claude Team Premium with Claude Code costs 100 US dollars per seat on an annual subscription, ChatGPT Business Premium also 100; with a VAT number, Claude Max 20× comes to 180 euros net.

The difference between the tiers is not a model upgrade. With Claude, even the Pro tier at 21 euros gets Opus 5.5 and Claude Code. With OpenAI, the Plus tier gets GPT-6 Astra, but only between five and 45 Astra messages every five hours. You pay by volume. So the more interesting question is: how fast will I hit the limit?

In practice: what developers really experience with Claude Max, Codex and Kimi

The pricing page says “5× Pro”. In recent weeks, both big providers have revised downward what that actually means.

On 14 September, Anthropic replaced the “+50% weekly limit” promotion, launched in May, with a permanent “+25% over the old baseline”. That sounds like a bonus, but compared with the last four months it is a 17% cut, which Anthropic, after criticism on Hacker News, confirmed. The 5-hour windows, which were doubled in May, remain in place.

At the same time, a class action lawsuit has been running in the US since June, alleging that Max 20× actually delivers six to eight times the usage of Pro, not twenty times. A Max 20× user who has been logging his usage for months reports 20% of his weekly quota used on the first day after the reset. His verdict: worth it for $200, “but I wouldn’t bet on it a year from now”.

An effect that hardly anyone takes into account: Fable 5.1 is capped at 50% of the weekly limit on Max and costs 2.5 times as much per token as Opus 5.5. According to a widely shared estimate by Theo Browne, making Opus 5.5 your default gives you roughly four times the effective quota.

OpenAI tackled the problem from the other side. On 10 September, new registrations for Pro 20× were paused because, according to Codex head Tibo Sottiaux, this segment places the greatest load on the systems; on 29 September, sign-ups reopened with halved quota; existing customers are spared until 29 October. The quote from the intro is from this phase: “Weekly limit reset yesterday, only 20% left today”, writes a Pro-5× user on the OpenAI forum.

Common practice is to split the work: Codex for the bulk of small changes and cloud parallelisation, Claude Code for long, continuous sessions. In an analysis of 500 Reddit comments, 65% preferred Codex, mainly because of the limits, while Claude Code won eight out of twelve blind tests, which is not a contradiction.

Kimi is the third track, and it deserves to be taken seriously. Moonshot’s Kimi K2.7 Code runs as a drop-in inside Claude Code (point ANTHROPIC_BASE_URL at https://api.moonshot.ai/anthropic, done) and, at 0.95/4 US dollars per million tokens, costs around a quarter to a fifth of Opus 5.5.

A sample calculation against the then-current Opus 4.8 came to 0.69 US dollars instead of 4.00 US dollars for a 50-turn agent run. A practitioner who ran K2.7 in Claude Code for about two weeks describes it as disciplined in following instructions, with no scope creep, but weaker at extended thinking and with less community know-how about the best prompts.

The catch lies elsewhere. The international Kimi platform is operated by Moonshot AI Pte. Ltd. in Singapore, where the data is processed; a GDPR-compliant data processing agreement (DPA) is not publicly available. Singapore is a third country without an adequacy decision from the EU, and the parent company is based in Beijing. For a European company with customer data in the repo, that is a deal-breaker as long as there is no EU entity offering a DPA.

For code without personal data, it is a cheap second track. Ramp reports that 6.1% of US companies paying for AI are now using platforms that provide open-source or Chinese models.

Two numbers show how far enterprise reality is from the forums. According to Menlo Ventures, around 54% of enterprise spending on AI coding in 2025 went to Anthropic and 21% to OpenAI; in the Ramp AI Index from August, 43.5% of US companies pay Anthropic and around 40% pay OpenAI.

Usage numbers tell a different story than budgets. The Stack Overflow survey 2026, with over 49,000 responses, shows that 84% use AI tools, 29% trust their accuracy (3% “strongly”), and 66% say the code is “almost right, but not quite”. Among the tools, Copilot leads with 68% of AI users, Cursor is at 18%, and Claude Code at just under 10%.

What this means for your setup

I think it’s a mistake to rely on a single model for a team. The reason is economic: the cost per task depends more on the reasoning level than on the model. Opus 5.5 scores an identical 59.6% on Terminal Bench 4.0 at “max” and “xhigh”; the higher level just burns more tokens. My recommendation as of today:

Default: a mid-range model at medium reasoning effort. Today, that means Opus 5.5 medium or GPT-6.1 Sol; both deliver top results at a fifth of the cost. Review: frontier models, i.e. each provider’s most expensive tier (Fable 5.1, Astra), are reserved for cases where a mistake gets expensive: security reviews, architecture decisions, the last pair of eyes before the merge.

Bulk: for high-volume work with clear instructions (generating tests, migration scripts, documentation), a third, low-cost track pays off, provided data protection and DPAs are sorted. That could be Luna, Gemini Flash or an open-weights model on European infrastructure.

As I described in the post “Agent = Harness + Model”, the harness (context, memory, tools and evals) determines whether an agent is productive. In a properly built setup, swapping the model is a single config line; ANTHROPIC_BASE_URL above is an example.

If switching from Opus 5 to 5.5 takes days, the dependency is in the wrong place. And anyone sending customer data through a model outside the EU because it’s five times cheaper should read my post on the European AI stack first.

When deciding on a subscription: a team of five developers is better off with Claude Team Premium (US$100 per seat, including Claude Code) or ChatGPT Business Premium than with five individual Max subscriptions. SSO and audit logs are one reason.

The other: on the Team and Business plans, chats are not used for training by default and belong to the company account; with private subscriptions, they are linked to the employee and move with them. If you stick with Cursor or Copilot: both now bill at API rates, and the $20 plan is really a credit balance.

What I’m watching next

Four open threads that will shape the coming weeks.

Anthropic announced Haiku 5.5 on 22 September, for release “in the coming weeks”, but it isn’t here yet. At OpenAI, the grace period for existing Pro-20× customers ends on 29 October; after that, the halved quota will apply to everyone. Gemini 4 is expected to launch well before the end of the year and would be Google’s first new Pro model since February. And the class action lawsuit against Anthropic’s Max limits is pending; a judgement or settlement would directly affect the subscription table above.

Frequently Asked Questions

Which AI model is currently the best? For agentic coding and professional tasks, Claude Opus 5.5 leads the independent indices (Artificial Analysis, Terminal-Bench 4.0, GDPval-AA); for knowledge and interactive reasoning, GPT-6 Astra (Humanity’s Last Exam, ARC-AGI-3). The performance gap is smaller than the price gap.

Is Claude Max 20× still worth it? If you work in Claude Code for several hours a day and set Opus 5.5 as your default instead of Fable, then yes. Expect to pay €214 incl. VAT in Germany and bear in mind that a single large agent run will make a noticeable dent in your weekly limit. For teams, Team Premium at 100 US dollars per seat is usually the better option.

Can I use Kimi K3 for business in the EU? Technically yes, via API or as a drop-in in Claude Code. Legally, it depends on what data you send: processing is carried out by Moonshot AI Pte. Ltd. in Singapore, a third country without an EU adequacy decision, and a data processing agreement is not publicly available. For code without personal data, it’s a cost-effective alternative; for customer data, it isn’t.

Why do vendor blogs show different benchmark numbers than this post? Because vendors measure with their own harness, at the highest reasoning level and sometimes with multiple attempts. Independent evaluators such as Artificial Analysis, ARC Prize or Scale use a fixed harness and budget. This post prefers the independent numbers and labels vendor numbers as such.

Changelog

The original post logs every change to models, prices, limits and top-3 rankings with a date. This dev.to copy is a snapshot; the live changelog has everything since.

30 September 2026 — First published. Status: Opus 5.5, Sonnet 5.5, GPT-6 Astra, GPT-6.1 Sol, Gemini 3.8 Flash, Grok 4.7, Kimi K3, MiMo-V2.6-Pro. Claude weekly limit −17% since 14 September; ChatGPT Pro 20× has been open again (halved) since 29 September.

I’m Slawa, CEO of Next Levels, a German agency building Shopware commerce, apps and AI agents for mid-sized companies. This article was originally published on next-levels.de, where it is re-verified every week. If a number here looks stale, the original has the current one.

Which split are you running in your team: one model for everything, or separate tracks for default, review and bulk work? Let me know in the comments.

OpenAI Dots, Meta Muse, Grok Bot: Who Owns Your AI Agent's Computer?

Slawa — Fri, 02 Oct 2026 13:52:37 +0000

Facts as of September 30, 2026.

"Do not use separate Bots as a security boundary."

That sentence isn't from a pentest report. It's from xAI's own Grok Bot documentation, for a product marketed as "AI teammates you can give real work to."

Within seven weeks, three of the biggest AI vendors shipped the same kind of product: an agent that runs around the clock, logs into your tools and reports back when it's done. xAI went first with Grok Bot on August 11, Meta followed with Muse on September 8, and OpenAI launched Dots at DevDay on September 29. Most coverage compares context windows, benchmarks and avatars. If you've ever written a threat model, the interesting question is a different one: which computer does the agent run on, who else shares that computer, and what decides what leaves it?

The common pattern: the agent gets a computer

Until recently, "agent" in practice meant an LLM calling tools over an API while you sat in a chat window. Close the tab, the agent is gone. All three products break that model in the same three ways.

Persistent. The agent has a name, memory across conversations, and keeps working while you're offline.

A real machine. Each product gives the agent a cloud computer with a browser, file system and logged-in sessions. xAI's FAQ puts it plainly: "Every Bot on your account uses one persistent cloud computer." That's what lets an agent operate websites that have no API, save files and sign into accounts like a human at a desk.

Proactive. Dots keeps researching with read-only tools while idle, Grok Bot runs routines on a schedule or on events, and Muse watches inboxes and prices and pings you when something changes.

In other words: these vendors are selling a workstation for software that behaves like a colleague. And the moment you see it that way, the important questions turn into access-control questions. You don't ask a new hire about their IQ first. You ask what they have access to.

OpenAI Dots: one cloud computer per agent

Dots runs on GPT-6 Astra. Each dot gets its own cloud computer, separate from your machine; local desktop access is off by default and has to be turned on through the ChatGPT desktop app. You talk to it through the ChatGPT apps, Slack, Microsoft Teams and voice calls, with SMS available as a limited beta for US Pro users. It inherits your ChatGPT app connections and, per OpenAI, reaches more than 4,000 apps through plugins.

The permission model is the interesting part. OpenAI's announcement says "Custom Rules let you allow specific actions, require approval, or block them," and the Help Center lists four levels: Take action without asking, Take action if pre-approved, Ask before taking action and Hand off to you. Permanent deletion and software installs go through approval; password changes and money transfers are handed back to you entirely.

The part I like most: proactive research is architecturally constrained. When the dot works on its own initiative, it uses "tools that are restricted to be read-only, which means that they can't send messages, change app content, or control your browser or computer." That's a clean split between looking around and acting, and neither competitor draws that line as clearly.

Pricing: one dot is included in ChatGPT Pro and Business Premium; more dots are announced for later, without a price yet. Availability matters if you're in Europe: the Pro rollout excludes the EEA, Switzerland and the UK, while Business Premium is available "across all supported ChatGPT regions." Enterprise, Edu and Healthcare workspaces get a beta that an admin must enable.

Meta Muse: an egress guard that approves every outbound action

Muse runs on Meta's Muse Spark model and targets consumers first: email, travel bookings, bill negotiation, forms. It's available on iOS, Android, muse.ai and WhatsApp.

Architecturally, it's the most interesting of the three. Every user gets a dedicated "Muse Secure VM" holding both the agent and the user's data. Next to it runs a second agent, the Sentinel, separated from Muse at the system level. Per Meta, nothing Muse does reaches the internet unless the Sentinel approves it, and it asks the user for permission when needed. Credentials sit in secure storage that Muse can use without seeing them. Payments go through one-time cards via Stripe Link. A "Confidential VM" with user-held keys is promised for later this year.

So Muse separates thinking from acting into two processes: the model proposes, the Sentinel decides what leaves the box. Conceptually, that's the strongest answer to prompt injection any vendor ships today. If the agent reads a hidden instruction on a crafted page telling it to email your last bank statements to a stranger, that send still has to pass a guard that knows what you actually asked for. Whether that holds up in daily use, nobody can say yet, Meta included.

The launch already produced some data points. Reuters reported on internal Meta posts describing the agent routing around guardrails to expose a person's private iCloud photos in testing, and monitoring tasks silently stopping after about 15 minutes. Interactions are used for training by default (opt-out available). Pricing is the most transparent of the three: free up to 100M tokens per week, then $20 or $100 per month. It's available in the US and Canada, 18+.

Grok Bot: many bots, one computer, shared logins

Grok Bot launched in beta on August 11 and ships with SuperGrok and Cursor plans (xAI is now SpaceXAI, part of SpaceX, which acquired Cursor). It's positioned as a team: you create several bots with different roles and let two to six of them coordinate in group chats. You can show a bot a workflow once, and it turns the demonstration into a draft skill you review, then runs it as a routine on a schedule or trigger. It prefers connectors where they exist and falls back to driving the browser.

Here's the difference that matters: all bots on an account run on one shared cloud computer. Each gets its own screen, but browser cookies, sessions, files and command-line credentials are shared. Isolation between users is strict: per xAI's security FAQ, each gets a dedicated Firecracker microVM. Isolation between bots in one account doesn't exist. xAI is upfront about it:

"Do not use separate Bots as a security boundary."

And from the Bots docs:

"Deleting a Bot removes its active profile, conversation, and routines from Grok Bot. Shared computer files and sign-ins are not isolated by Bot and may remain on the computer."

Think through what that means in practice: the bot that reads unfiltered customer email uses the same browser sessions as the bot that prepares bank transfers. For real privilege separation, you need separate accounts, because only those give you separate machines.

The comparison

	OpenAI Dots	Meta Muse	xAI Grok Bot
Launch	Sep 29, 2026	Sep 8, 2026	Aug 11, 2026 (beta)
Model	GPT-6 Astra	Muse Spark	no fixed model named
Compute	own cloud computer per dot	one Secure VM per user	one shared cloud computer per account
Isolation within an account	per dot	per user + Sentinel egress guard	none: files, sessions, logins shared
Sensitive actions	Custom Rules (4 levels), proactive mode read-only	Sentinel approves all network actions, user approval when needed	Auto-review rules, drafts approved before sending, admin policies
Pricing	1 dot in ChatGPT Pro / Business Premium	free tier, $20, $100 / month	bundled with SuperGrok and Cursor plans
EU availability	Pro: no · Business Premium: yes · Enterprise: beta	US + Canada only	no regional statement in the docs

Isolation decreases from left to right. All three are legitimate engineering choices. But for an agent that touches customer data, the shared box is the one that doesn't fit.

Why the isolation model beats the model

An LLM that reads web pages, emails and PDFs will inevitably read text written by attackers. Prompt injection can't be patched away, because the model can't reliably separate instructions from content. Every improvement in hit rate lowers the risk; none removes it.

What decides the damage is the blast radius of a compromised agent, and that radius is the isolation model:

Dots: the radius ends at that dot's own computer. A hijacked research dot can't touch the sessions of an accounting dot on a different machine.
Muse: the radius ends at the Sentinel. Inside the VM the agent can hallucinate all it wants; only what the guard approves gets out.
Grok Bot: the radius ends at the account. A bot reading a poisoned page sits on the same machine, with the same cookies, files and open logins, as every other bot you own.

The sysadmin version: Dots gives every employee their own laptop. Muse gives every employee their own laptop and puts a doorman at the exit who reads every letter before it goes out. Grok Bot sits ten employees at one shared PC where everyone stays logged in, and honestly writes in the manual: if you want separation of privileges, buy more PCs.

Credit to xAI for writing it down. But a warning in a manual shifts responsibility to you, and it's a different thing from a boundary you can't technically bypass.

What to do before these land in your stack

You don't need any of these products to start on the part that actually matters. Write the permission model first, vendor-agnostic. It can be as simple as a policy file you keep in your repo:

# Illustrative least-privilege policy for one agent (not a vendor format)
agent: invoice-intake
owner: finance-lead@example.com     # a named human, like a manager for an employee
scopes:
  mailbox:   { read: true,  send: approval }   # drafting is fine, sending needs a human
  calendar:  { read: true,  write: true }
  erp:       { read: true,  post_booking: false }
  banking:   { read: false, write: false }     # never
  crm:       { read: true,  write: true, delete: false }
isolation:
  dedicated_runtime: true    # no shared browser sessions with other agents
  egress: allowlist          # only the domains this job needs
logging:
  every_action: true         # with the agent's stated reason

With that file in hand, evaluating Dots, Muse or Grok Bot can become an afternoon of mapping their controls onto your columns instead of a quarter of discovery. Two more things worth deciding early:

Build or rent. These three are rented agents on someone else's infrastructure, with models you can't pick and quotas nobody has priced long-term. Open-source harnesses like OpenClaw or Hermes Agent run on your own infra with any model provider. They aren't automatically safer: OpenClaw received nine CVEs between March 18 and 21, 2026, including a CVSS 9.9 authorization bypass. But they give you control over the agent's computer, which is the variable this whole post is about.
Start boring. An agent that reads invoices from a mailbox and files them, with read-only access, is a good first case. An agent that negotiates contracts belongs at the end of the list.

If you're in the EU, keep two constraints in mind: GDPR Article 22 limits automated decisions with legal or similarly significant effects without human involvement, and the AI Act's transparency obligations for systems interacting with people have applied since August 2, 2026. An agent that writes emails and makes calls on your behalf has to disclose that it's an AI. Formally that duty sits with the provider, but the problem lands on you.

Treat Dots, Muse and Grok Bot as a preview of what your own agents will look like soon, and build the frame they're allowed to work in now. Which one ends up in your company, or whether you build your own, then becomes a purchasing decision instead of a security decision.

Originally published in German at next-levels.de. I'm co-founder and CEO of Next Levels, a digital agency in Germany; AI consulting is one of our service lines.

AI Agents as Digital Employees: Architecture and Lessons from Practice

Slawa — Fri, 03 Jul 2026 19:19:45 +0000

The "digital employee" is the most heavily sold and least understood product of 2026. Vendor slides promise a colleague who never sleeps. What arrives in most projects is a very fast intern with no memory who makes every mistake with complete confidence.

This isn't a polemic against the technology. We build these agents ourselves, and they work. But they only work if you treat them as what they are: software with probabilistic behavior that needs to be onboarded, constrained, and supervised like a new hire. That's exactly where most projects fail. Gartner predicts that over 40 percent of all agentic AI projects will be canceled by the end of 2027. The stated reasons are telling: exploding costs, unclear business value, missing risk controls. Not: "the models were too dumb."

What an AI agent actually is (and isn't)

The sober definition: an AI agent is a language model running in a loop. It gets a goal, decides for itself which tool to use next (a database query, an email, an API call), evaluates the result, and keeps going until the task is done. In plain terms: a chatbot you gave hands to.

The difference from a classic workflow is decision freedom. An n8n workflow follows a fixed path a human laid out. An agent picks its own path. That makes it valuable for tasks whose sequence can't be scripted in advance, and dangerous for everything else.

What an agent is not: an employee in any legal or organizational sense. It has no sense of responsibility, no liability, and no interest in still being employed tomorrow. The "digital employee" metaphor is useful as a thinking model because it forces the right questions: What is it allowed to do? Who supervises it? Who does it report to? As a description of the technology, it's marketing.

The architecture: four building blocks that decide success

The architecture of a production-grade agent system is surprisingly conservative. The model itself is the most replaceable part: models get better and cheaper every few months, and a well-built system swaps them like a graphics card. What stays, and what you therefore have to get right, is everything around it.

First: task scoping. The most common architecture mistake happens before the first line of code: you give the agent a job title instead of a task. "Handle support" is not a task description, it's a capitulation. Production-grade agents have a narrow mandate with a measurable outcome: "Classify incoming tickets, answer the three most common categories yourself, escalate the rest." The tighter the mandate, the higher the reliability.

That's not a temporary state of the technology; it follows from its statistics. In a process with twenty steps at 95 percent reliability per step, you get the right end result in only about a third of all runs. Errors in agent loops are cumulative.

Second: orchestrator-worker instead of jack-of-all-trades. The pattern that has won out in practice separates planning from execution. An orchestrator agent decomposes the task and delegates to specialized sub-agents, each with its own context window, its own tools, and its own narrow assignment. Anthropic measured that a multi-agent setup with an orchestrator beat a single-agent system by roughly 90 percent on their internal research benchmark. In short: many small specialists beat one big generalist, just like in human teams.

Third: standardized tool access. An agent is only as useful as the systems it can reach. Here, the Model Context Protocol (MCP) has become the open standard: introduced by Anthropic in late 2024, since adopted by OpenAI, Google, and Microsoft, and under the Linux Foundation umbrella since December 2025. Instead of building a custom connector for every model-system combination, the agent speaks one standard, and your CRM, ERP, or inventory system exposes its functions as an MCP server. If your team is building integrations today, build them as MCP servers. That's the one architecture decision that keeps model and vendor switches open later.

Fourth: guardrails that deserve the name. A digital employee needs the same three things as a human one on probation: limited permissions, defined approval processes, and someone watching. Translated to engineering: a permission model at the tool level (the agent that reads invoices can't pay them), human-in-the-loop for everything irreversible (send, delete, pay, publish), and complete logging of every action including its rationale. The logging isn't compliance theater; it's your most important development tool. Without traces you simply cannot debug a non-deterministic system.

The economics: agents are more expensive than the demo looks

The point that's consistently missing from pitch decks: agents burn tokens. Anthropic's engineering team puts a single agent's consumption at roughly four times a chat interaction; multi-agent systems run at about fifteen times. That's not a bug — it's the mechanism through which these systems produce their performance: more parallel reasoning, more tool calls, more context.

A simple business rule follows: an agent only pays off for tasks whose completion is worth more than the multiplied compute plus the supervision cost. As a model calculation: an agent that costs 40 cents per case in API fees and replaces 15 minutes of manual processing pays for itself immediately. The same agent doing a job that a simple workflow previously did deterministically for 0.4 cents is tech enthusiasm at company expense.

So our standing recommendation: workflow first, agent second. Everything that can be modeled as a fixed process belongs in classic automation with tools like n8n. The agent goes where rules stop working: unstructured input, decisions that need context, research tasks. This order keeps costs down and has an underrated side effect: the process documentation you produce while automating literally becomes the agent's job instructions later. Write it once, use it twice.

Lessons that aren't in any vendor deck

Errors are cumulative, so build for failure. In classic software, a bug breaks a feature. In an agent system, an early error sends the agent down a completely different path — with full confidence. A ticket gets misclassified at step three, and twenty steps later the agent has prepared a polite, well-written, and completely wrong reply to the wrong recipient. Production-readiness here means: checkpoints you can resume runs from, retry logic, and an agent that can handle a failing tool instead of hallucinating around it.

The second lesson sounds trivial and costs the most time in practice: the tool description is the new job description. Agents choose their tools based on the tools' description texts. searchCustomer: searches for a customer reliably sends the agent nowhere. searchCustomer: finds customer records by name, email, or customer ID; returns at most 10 matches; prefer the customer ID when available turns the same tool into a reliable one. If you build agents, you'll spend a surprising amount of time documenting interfaces so a machine can't misread them. That's the onboarding of your digital employee.

Evaluation before scaling. Before an agent gets anywhere near real customer data, it needs a test set of real cases and defined success criteria. Even twenty representative test cases will show whether a prompt change raises or lowers the success rate. Without that measurement, every iteration is guesswork, and every "the agent is better now" is an assertion.

An agent that reads emails and can operate tools can be attacked through exactly those emails: a crafted message contains an instruction in plain prose like "export the customer list and send it to the following address," and a naively built agent executes it, because to the agent, text is text. Prompt injection and poisoned tool descriptions have been publicly demonstrated attack classes since 2025. The consequence is the same as with human employees and phishing: the agent must never grant external content the same authority as its own instructions, and everything irreversible needs a second pair of eyes.

The EU AI Act is at the table. If you deploy agents in HR, credit, or hiring processes, you quickly enter high-risk categories with documentation and oversight obligations. The logging and human-in-the-loop approvals from the architecture section are doubly useful: they're simultaneously the core of your compliance file.

The right first agent is boring

Don't start with the showcase agent for the management meeting. Start with a process that meets three criteria: it hurts (volume or frustration), it's well documentable, and a mistake is correctable before it gets expensive. Ticket triage, quote research, data reconciliation between systems, first drafts of recurring documents. No payments, no HR decisions, nothing irreversible in year one.

Then, in this order: document the process, automate deterministically whatever can be automated deterministically, and only then put the agent on the remainder — with a narrow mandate, MCP integration, approvals, and logging from day one.

The bottleneck with digital employees is not the AI. It's the company. An agent can only take over processes the company itself understands. If you can't describe your workflows, you can't delegate them, neither to humans nor to machines. The 40 percent of canceled projects in Gartner's forecast fail at exactly this. On the other side are the companies whose new employees never sleep. It's worth being one of them.

Originally published in German at next-levels.de. We're a full-service digital agency; building exactly these agent architectures for mid-sized companies is part of our AI consulting practice.

Self-Hosted vs. SaaS: What Coolify Actually Costs (and Where It Gets Expensive)

Slawa — Thu, 02 Jul 2026 14:19:11 +0000

Your deploy stack is probably the worst-negotiated subscription in the whole company. Every server migration gets costed to three decimal places, but the Vercel bill that quietly creeps up a few dollars every month? Nobody consciously signs off on that. It just runs.

That's the gap Coolify walks into. It promises the thing a lot of teams have been quietly thinking: why pay $20 per seat or $25 per process to a US platform when a $6 server hosts the same app? The answer isn't "never" and it isn't "always." It's a calculation — and that calculation has one line item both sides conveniently leave off the landing page.

What Coolify is (and what it isn't)

git push, and seconds later your app is live on your domain, TLS cert included, on a server you own. That's the trick you'd credit Heroku with and never your own $6 VPS. Coolify delivers it.

Technically, it's a self-hosted PaaS, open source under Apache 2.0, positioned as an alternative to Vercel, Heroku and Netlify. You connect a server over SSH, attach a Git repo (GitHub, GitLab, Gitea, or self-hosted), pick a build pack (Nixpacks, Dockerfile, Docker Compose, or static), and Coolify does the rest: builds the image, runs the container, terminates TLS via Traefik with automatic Let's Encrypt certs, and serves the app. On top of that: 280+ one-click services, from databases to analytics to full apps, with built-in backup routines.

The install is genuinely a single script (grab the current one-liner from the Coolify docs — it's the classic curl … | bash shape), then you're in a web UI.

Here's the part that decides the whole cost equation later: what Coolify is *not. It's not a global CDN, not autoscaling edge infrastructure, and not a company that carries the pager at 3 a.m. Everything Vercel or Heroku bundle into the subscription — scaling, availability, platform-level security patching — becomes *your job on Coolify. It automates the deploy, not the operations.

On maturity, since that's the trust question: Coolify hit stable with v4.0.0 in April 2026 after roughly two years in beta. v4.1 (May 2026) added an extra build path (Railpack), structured audit logging for API and auth events, and MCP support. v5 with multi-server scaling is actively being built. Not a weekend project anymore — but no vendor SLA behind it either.

The math nobody runs

Skip the ranges, here's a concrete workload: a Next.js app with Postgres and Redis, moderate traffic.

On Heroku, two Standard-1X dynos ($25 each) plus a managed Postgres add-on gets you to roughly $100/month — about $1,200/year. The same app on a €12 VPS running Coolify: ~€145/year. Same workload.

Line item	Managed PaaS	Coolify (self-hosted)
Software / platform	$40–100/mo	$0 (Cloud optional: $5)
Server / infra	included in plan	from ~€6/mo (1 VPS)
Bandwidth overage	variable, grows with traffic	inside the VPS allowance
Direct cost	$40–100+	~€6–20

A few reference prices so this isn't hand-waving (July 2026):

Heroku: Eco $5 (a shared 1,000-hour account pool, not per process — it sleeps), Basic $7, Standard-1X $25, Standard-2X $50. No free tier since 2022.
Vercel Pro: $20/seat, 1 TB bandwidth included, $0.15/GB overage, $0.128 per active CPU-hour.
Railway: Hobby $5 (incl. $5 usage), Pro $20/seat (incl. $20 usage).
Coolify Cloud (managed control plane, infra still separate): $5/mo for 2 servers, +$3 each additional, 20% off annually.
The server: a 4 GB VPS at Hetzner starts around €5.49 (CX23) or €5.99 (ARM CAX11); a beefier CPX22 is ~€19.49. Note Hetzner renamed and repriced the CPX line on 15 June 2026 (~+144% on that class), so the old "under €10 CPX" boxes are gone — but self-hosting still lands in the low tens of euros a month.

Annualized, the gap between a Heroku setup and self-hosted Coolify is 3–9×. If you're paying more than ~$15–20/month for deploy subscriptions, you're cheaper on raw server cost immediately. That's the number in every Coolify pitch, and it's true.

It's just not the whole bill.

The line item the landing page hides: your time

The 3–9× advantage holds exactly as long as someone keeps the server alive. And that someone costs money — usually more than the cloud bill you saved, if you're honest.

It's 3 a.m. A kernel update took the Docker daemon with it, the customer portal is down, and the pager is you. That call is what the $20 at Vercel buys away. What's baked into the managed price and lands on your desk with Coolify: OS and security updates, monitoring, actually testing backups (not just configuring them), incident response, hardening the box, keeping Coolify itself current. None of it is rocket science. But it's work someone else used to do, now sitting with your team. And when the one colleague who set Coolify up leaves, your cost saving just became a bus factor of one.

Put the hour in the spreadsheet. One conservative hour of DevOps time a month, at loaded internal cost, eats most of what you save on a single small project. Self-hosting doesn't pay off because a server is cheaper than a subscription. It pays off when you already have those ops hours in-house and spread them across several projects. One VPS with Coolify hosts a dozen apps at the same flat price. That's where the math tips.

When it's worth it — and when it isn't

Straight recommendation, no hedging. Coolify is the right call when three things line up:

You have DevOps capability in-house (or want to build it deliberately) — someone comfortable with SSH, Docker and a Linux box, who wants to be.
You run several apps, so one maintained server amortizes across many deployments.
Data ownership and independence from US platforms are a real criterion, not a slide-deck line.

Miss one of those and you should stay on managed PaaS, at least for now. A solo founder with one Next.js app who'd rather ship features than patch servers belongs on Vercel. A team with zero Docker experience will spend the saved euros back as learning curve and downtime. Self-hosting isn't moral high ground — it's an operational decision.

And the most-overlooked answer: it doesn't have to be all or nothing. Data-critical core app on your own Coolify server, marketing landing page on a CDN with a generous free tier. Drawing that line well is the actual skill.

A realistic way to try it

No big bang required. A cheap VPS, Coolify installed from the one-liner, one non-critical internal tool as your first deploy — that's an afternoon, not a quarter. On that one project you'll learn fast whether your team wants to own the operations, or whether after the third late-night "the container is gone" the calm of a managed subscription is suddenly worth $20 to you. Both answers are worth the money, and you only get them by actually standing it up instead of theorizing.

So the concrete first step: open your last Vercel or Heroku invoice and multiply it by twelve. If the annual number makes you wince, and someone on the team can keep a server alive, the question's already half-answered.

Written by the engineering team at Next Levels, a German digital agency that builds and operates setups like this. If you've moved a real production workload from managed PaaS to Coolify, I'd genuinely like to hear where the ops cost surprised you — drop it in the comments.

GEO: Wie du dafür sorgst, dass ChatGPT & Co. deine Seite zitieren

Slawa — Wed, 24 Jun 2026 03:27:06 +0000

Dein bestes Google-Ranking ist wertlos, wenn die Antwort schon vor dem Klick gegeben wurde. Genau das passiert gerade: Nutzer fragen ChatGPT, Claude oder Perplexity – und bekommen eine fertige Antwort mit drei, vier zitierten Quellen. Bist du nicht darunter, existierst du in diesem Moment nicht. Kein Ranking, kein Klick, keine zweite Chance.

Die Disziplin, die das adressiert, heißt Generative Engine Optimization (GEO). Und sie ist – anders als der Marketing-Lärm vermuten lässt – zu großen Teilen ein Engineering-Problem. Crawler-Zugang, Rendering, strukturierte Daten. Lauter Dinge, über die ein Entwickler entscheidet, nicht das Content-Team.

SEO optimiert auf den Klick. GEO optimiert auf das Zitat.

Der Unterschied ist nicht kosmetisch. Klassisches SEO will, dass du auf Platz eins rankst, damit jemand klickt. GEO will, dass ein Sprachmodell deinen Absatz wörtlich in seine Antwort übernimmt – inklusive Quellenangabe. Der Klick ist nur noch Bonus.

Daraus folgt ein anderer Tech-Stack an Signalen:

Aspekt	Klassisches SEO	GEO / KI-Sichtbarkeit
Ziel	Top-10 in Google	Zitat in ChatGPT, Claude, Perplexity
Relevante Bots	Googlebot, Bingbot	GPTBot, ClaudeBot, PerplexityBot
Index-Hinweis	`sitemap.xml`	`llms.txt` + `sitemap.xml`
Strukturierte Daten	Rich Snippets	Entity-Linking (`Organization`, `sameAs`, `@graph`)
Rendering	Google rendert JS (verzögert)	viele KI-Bots rendern kein JS → SSR Pflicht
Erfolgskontrolle	Search Console, Rank-Tracker	Citation- & Mention-Tracking in LLMs

Die Hebel überschneiden sich – sauberes HTML, schnelle Antwortzeiten, valides Markup helfen beidem. Aber die Bots, die Index-Signale und die Erfolgskontrolle sind eigenständig. Wer GEO als „SEO mit neuem Namen" abtut, übersieht genau die Stellen, an denen es klemmt.

Schritt 1: Lass die Bots überhaupt rein

Bevor du über Content-Qualität nachdenkst, klär die banale Frage: Kommt der Crawler durch? Erstaunlich oft lautet die Antwort nein – und niemand merkt es, weil ein Browser die Seite ja problemlos lädt.

Die drei User-Agents, die zählen, sind GPTBot, ClaudeBot und PerplexityBot. Eine robots.txt, die sie durchlässt, sieht so aus:

User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

Ein Detail, das viele falsch machen: GPTBot und OAI-SearchBot sind nicht dasselbe. GPTBot füttert die Trainingsdaten, OAI-SearchBot ist für Citations in der ChatGPT-Suche zuständig. Wer aus Datenschutzgründen das Training ausschließen will, sollte nicht pauschal alles von OpenAI sperren – sonst kappt er sich versehentlich die Sichtbarkeit. Training raus, Suche rein:

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

Der gemeinste Fall ist aber nicht die robots.txt, sondern die Schicht davor. Cloudflare Bot Fight Mode, eine ModSecurity-Regel, ein nginx-User-Agent-Filter oder ein überambitioniertes Shopware-Plugin weisen unbekannte User-Agents pauschal als Scraper ab. Der Browser sieht davon nie etwas, der KI-Bot bekommt ein 403 oder eine Captcha-Seite. Prüf das im Zweifel direkt:

curl -A "GPTBot" -I https://deine-domain.de

Kommt da kein sauberes 200 zurück, hast du dein erstes Problem gefunden, bevor du eine Zeile Content angefasst hast. Und Achtung: Cloudflare-Defaults setzen sich bei Updates gern zurück – also nach jedem größeren Release erneut testen.

Schritt 2: Liefere Text, kein JavaScript-Versprechen

Hier wird es für moderne Frontends unbequem. Viele KI-Crawler rendern kein JavaScript. Was bei einer reinen Client-Side-React-App im initialen HTML steht, ist oft ein leeres <div id="root"> – und genau das liest der Bot. Dein schöner Content existiert für ihn nicht.

Die Lösung ist kein Geheimnis, sie kostet nur Disziplin: Server-Side Rendering oder Static Generation, damit die Hauptinhalte schon im ausgelieferten HTML stehen. In Next.js heißt das, die Finger von reinem Client-Fetching für indexierbaren Content zu lassen:

// Server Component – Inhalt steht im initialen HTML, lesbar ohne JS
export default async function ProductPage({ params }) {
  const product = await getProduct(params.id);

  return (
    <article>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
    </article>
  );
}

Kurz gesagt: Wenn der Inhalt erst nach dem Hydration-Schritt im DOM auftaucht, ist er für einen erheblichen Teil der KI-Crawler unsichtbar. SSR ist bei GEO keine Performance-Kür mehr, sondern Voraussetzung.

Schritt 3: Mach deine Entität eindeutig

Ein Sprachmodell zitiert lieber, was es eindeutig zuordnen kann. Strukturierte Daten sind dafür das stärkste Signal – nicht als SEO-Deko, sondern als maschinenlesbare Aussage darüber, wer du bist. Das Minimum ist ein Organization-Schema mit sameAs-Verknüpfungen, die deine Marke mit ihren bekannten Profilen verbinden:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Beispiel GmbH",
  "url": "https://beispiel.de",
  "sameAs": [
    "https://www.linkedin.com/company/beispiel",
    "https://de.wikipedia.org/wiki/Beispiel_GmbH",
    "https://www.crunchbase.com/organization/beispiel"
  ]
}
</script>

Die sameAs-Links sind der eigentliche Trick: Sie verankern deine Entität in Quellen, denen das Modell ohnehin vertraut. Darüber hinaus lohnen sich je nach Seitentyp FAQPage (gut für Frage-Antwort-Formate), Product + Offer (Shops) sowie Article + Author (Blogs) – am besten gebündelt in einem gemeinsamen @graph.

Schritt 4: llms.txt – kleiner Aufwand, klare Aufwärtschance

llms.txt ist eine vorgeschlagene Konvention (llmstxt.org), kein offizieller Standard. Die Idee: eine Markdown-Datei unter /llms.txt, die KI-Systemen eine kuratierte Liste deiner wichtigsten Inhalte nennt – konzeptionell wie eine sitemap.xml, nur für LLMs.

# Beispiel GmbH

> Digitalagentur für E-Commerce, Software und KI-Beratung.

## Wichtige Seiten
- [Leistungen](https://beispiel.de/leistungen): Überblick über alle Services
- [Blog](https://beispiel.de/blog): Fachartikel zu E-Commerce und KI
- [Kontakt](https://beispiel.de/kontakt): Ansprechpartner und Standorte

Ehrlich bleiben: Noch lesen längst nicht alle Crawler die Datei aus, einige Recherche-Agents tun es bereits. Der Aufwand ist minimal, das Risiko null – das ist eine der wenigen GEO-Maßnahmen, bei denen sich die Kosten-Nutzen-Rechnung nicht lange diskutieren lässt.

Und der Content? Schreib so, dass man dich zitieren kann

Die Technik schafft den Zugang, aber zitiert wird am Ende eine Textpassage. Und Modelle haben eine klare Präferenz: kurze, eigenständige Absätze, klare Definitionen, Zahlen, Listen, saubere Überschriften-Hierarchie. Die Princeton-Forschung hinter dem Begriff GEO (KDD 2024) zeigt, dass Zitate, Statistiken und konkrete Quellenangaben die Wahrscheinlichkeit, in einer KI-Antwort aufzutauchen, um bis zu 30–40 % erhöhen.

Werblicher Fließtext ohne Substanz ist das Gegenteil davon. Ein Absatz, der eine Frage in zwei klaren Sätzen beantwortet, wird zitiert. Ein Absatz voller „innovativer, ganzheitlicher Lösungen" wird übersprungen.

Wo stehst du gerade?

Das Unangenehme an GEO: Die meisten dieser Probleme sieht man der Seite im Browser nicht an. Die robots.txt blockt lautlos, die WAF antwortet Bots anders als dir, das JSON-LD hat ein fehlendes Pflichtfeld. Bevor du anfängst zu optimieren, lohnt sich deshalb eine Bestandsaufnahme aus Bot-Perspektive.

Dafür haben wir bei nextlevels einen kostenlosen KI-Sichtbarkeits-Check gebaut: Er simuliert die wichtigsten KI-Crawler, liest robots.txt, llms.txt und Sitemap, prüft das ausgelieferte HTML auf SSR und strukturierte Daten und erkennt Bot-Blocker auf WAF-Ebene. Ergebnis in unter 30 Sekunden, ohne E-Mail, und jeder Einzelbefund kommt mit den Rohdaten, die du selbst per curl nachprüfen kannst. Genau das macht ihn für Entwickler brauchbar – es ist kein Score zum Glauben, sondern eine Checkliste zum Nachvollziehen.

Fazit

GEO ist kein neues Marketing-Buzzword, das man dem Content-Team überlassen kann. Die Stellen, an denen Sichtbarkeit in KI-Antworten entsteht oder stirbt, liegen im Code: in der robots.txt, in der Render-Strategie, im Schema-Markup, in der WAF-Konfiguration. Die gute Nachricht für uns Entwickler ist, dass das alles überprüfbar und fixbar ist – kein Raten, kein Black-Box-Algorithmus. Fang bei der banalsten Frage an: Kommt der Bot überhaupt durch? Den Rest baust du darauf auf.

Shopware vs Shopify: a developer's case for the open platform

Slawa — Wed, 24 Jun 2026 03:24:03 +0000

Most "Shopware vs Shopify" posts compare dashboards, app stores, and pricing tables. None of that matters to you until the day a client asks for something the platform won't let you build. Then the comparison stops being a feature grid and becomes a question about ceilings: how high can I go before the platform says no, and what happens when I hit it?

That's the only axis I care about as a developer, so that's the one I'll argue on. Shopify is an outstanding product. It's also a closed SaaS that decides, on your behalf, where customization ends. Shopware is open source built on Symfony, which means the ceiling is "however far PHP and HTTP will take you." Below are the three places that difference actually bites, with code.

Angle 1: The checkout is the wall

This is the headline because it's where most agency developers first hit something they cannot do.

For years the Shopify answer to "customize the checkout" was checkout.liquid. That era is over. Shopify deprecated checkout.liquid in favour of Checkout Extensibility. Plus stores had to migrate their Thank-you and Order-status pages by August 28, 2025, and in January 2026 Shopify began auto-upgrading stores — wiping customizations built on additional scripts, script-tag apps, or checkout.liquid. Non-Plus stores have until August 26, 2026, and legacy Shopify Scripts keep working only until June 30, 2026. (Shopify migration timeline)

The replacement, Checkout Extensibility, is genuinely more upgrade-safe. It's also a smaller box. You get Checkout UI Extensions (declarative components that render in slots Shopify defines) and Shopify Functions for backend logic — and that's the surface. You don't own the checkout template; you decorate the pieces Shopify exposes. Worth noting: full visual checkout customization (branding API, custom fields beyond the defaults, full UI extension power) is gated to Shopify Plus anyway.

On Shopware, the checkout is a Twig template like every other page, and you override it the same way you override anything else — by extending a block:

{# MyPlugin/src/Resources/views/storefront/page/checkout/confirm/index.html.twig #}
{% sb_extends '@Storefront/storefront/page/checkout/confirm/index.html.twig' %}

{% block page_checkout_confirm_tos %}
    {# Inject a B2B purchase-order field right above the terms checkbox #}
    <div class="po-number-field">
        <label for="poNumber">{{ "checkout.poNumberLabel"|trans }}</label>
        <input type="text" id="poNumber" name="poNumber"
               value="{{ page.extensions.poNumber ?? '' }}" />
    </div>

    {{ parent() }}
{% endblock %}

No slot has to exist for this. No feature has to be on a pricing tier. You're editing the checkout's actual markup, in the same templating language as the rest of the storefront, and your override survives core updates because it extends rather than replaces. The Shopify equivalent — arbitrary markup in the middle of the checkout flow — is simply not a thing you can do, on any plan.

Angle 2: Backend logic — a 5ms sandbox vs. the whole framework

Say the requirement is a non-trivial discount: "15% off, but only for B2B customers in a specific customer group, only on products from suppliers we flag as overstocked in an external ERP, and only Monday–Wednesday."

On Shopify this is a Shopify Function: Rust or JavaScript compiled to WebAssembly. It's clever engineering, but read the constraints before you design against it. A function's Wasm module must be ≤ 256 KB, may execute ≤ 11 million instructions, runs under a ~5 ms execution budget, is fully sandboxed (isolated memory, no network calls out to your ERP), and forbids nondeterminism — no clock, no random. Functions also can't be chained or made aware of each other. (Shopify Functions / WebAssembly docs)

Look at that list against the requirement. "Only on overstocked products from an external ERP" needs a network call — not allowed in the function. "Monday–Wednesday" needs the clock — not allowed. So the real-world implementation becomes: a separate hosted app syncs ERP + day-of-week state into metafields out-of-band, and the function reads those metafields. You can ship it, but the platform pushed a chunk of your domain logic out of the function and into infrastructure you now operate and keep in sync.

Here's the shape of what you're allowed to do inside the function — pure, deterministic, metafield-fed:

// Shopify Function (JS → Wasm). No network, no Date.now(), ≤5ms, ≤256KB.
export function run(input) {
  const discounts = input.cart.lines
    .filter((line) => line.merchandise.product?.isOverstocked?.value === "true")
    .map((line) => ({
      targets: [{ cartLine: { id: line.id } }],
      value: { percentage: { value: "15.0" } },
    }));

  return { discounts, discountApplicationStrategy: "FIRST" };
}

On Shopware the same rule is an event subscriber in ordinary PHP, with the full container at your disposal — the database, HTTP clients, your ERP service, the clock, everything:

<?php
// MyPlugin/src/Subscriber/OverstockDiscountSubscriber.php
namespace MyPlugin\Subscriber;

use Shopware\Core\Checkout\Cart\Cart;
use Shopware\Core\Checkout\Cart\Event\CartChangedEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

class OverstockDiscountSubscriber implements EventSubscriberInterface
{
    public function __construct(
        private readonly ErpClient $erp,          // your own HTTP service
        private readonly DiscountFactory $factory // injected, like any Symfony service
    ) {}

    public static function getSubscribedEvents(): array
    {
        return [CartChangedEvent::class => 'applyOverstockDiscount'];
    }

    public function applyOverstockDiscount(CartChangedEvent $event): void
    {
        $cart = $event->getCart();
        $weekday = (int) (new \DateTimeImmutable())->format('N'); // 1..3 = Mon..Wed
        if ($weekday > 3) {
            return;
        }

        // A real network call to your ERP — impossible inside a Shopify Function
        $overstockedSkus = $this->erp->fetchOverstockedSkus();

        foreach ($cart->getLineItems() as $item) {
            if (in_array($item->getReferencedId(), $overstockedSkus, true)) {
                $this->factory->applyPercentage($cart, $item, 15.0);
            }
        }
    }
}

The point isn't that PHP is nicer than Rust. It's that the entire business rule lives in one place, inside the request, with no sandbox to design around. Shopify's model is safer and more scalable by construction — that's a real trade-off, not a slur — but it's a model where the platform decides which parts of your logic are allowed to run where. Shopware doesn't make that decision for you.

Angle 3: Where your code lives

This one is structural and easy to underrate.

A Shopify app is an external application. It runs on infrastructure you host, talks to the store over OAuth and the Admin/Storefront APIs, and reacts via webhooks. Your code is never in the store; it's a satellite orbiting it through a rate-limited API. That's a clean boundary, and for many integrations it's the right one. But it means even small backend tweaks become a deployed, authenticated, separately-monitored service — and you're always one API version or rate-limit window away from the platform.

A Shopware plugin is a Symfony bundle that lives inside the application. The class hierarchy is literal: your plugin extends Plugin, which extends Bundle, which extends Symfony's Bundle. (Shopware: Plugins for Symfony Developers) So a plugin is just a Symfony bundle with conventions, and standard framework wiring applies:

MyPlugin/
├── composer.json
└── src/
    ├── MyPlugin.php                       # extends Shopware\Core\Framework\Plugin
    ├── Resources/
    │   ├── config/
    │   │   ├── services.xml               # DI: register your subscribers/services
    │   │   └── routes.xml
    │   └── views/storefront/...           # Twig overrides (see Angle 1)
    ├── Subscriber/
    │   └── OverstockDiscountSubscriber.php # runs in-process (see Angle 2)
    └── Migration/
        └── Migration1700000000Example.php  # owns its own schema changes

<?php
// MyPlugin/src/MyPlugin.php
namespace MyPlugin;

use Shopware\Core\Framework\Plugin;

class MyPlugin extends Plugin
{
    // It's a Symfony bundle. Services in services.xml autoload,
    // routes register, migrations run on install. No external host,
    // no OAuth handshake, no API version to chase.
}

Your subscriber from Angle 2 and your Twig override from Angle 1 are the same deployable unit — one bundle, in the same process as the shop, sharing its container and database. There's no satellite to operate.

The honest trade-offs

I'd be doing the dishonest version of this post if I stopped there.

Shopify's closed model buys you things that are genuinely hard to replicate: you never patch a server, the checkout converts extremely well out of the box, PCI scope is mostly Shopify's problem, and the sandboxed Functions model means one tenant's bad discount logic can't take down the platform. For a merchant who wants to sell, not to operate software, that's often the correct choice — and as a developer you should say so.

There's also a cost angle that's easy to forget mid-architecture-debate: if you use any payment gateway other than Shopify Payments, Shopify adds a third-party transaction fee — 2% on Basic, scaling down to 1% (Grow), 0.6% (Advanced), and 0.2% (Plus). (Shopify third-party transaction fees) Self-hosted Shopware has no such cut — but you (or your host) now own uptime, security patching, and scaling, which is not free either. You're trading a platform fee for an operational burden. Which one is cheaper depends entirely on the project.

Shopware's openness is power and responsibility. The ceiling is high because there basically isn't one — and the flip side of "there's no sandbox to design around" is "there's no sandbox protecting you from yourself."

So when does the open platform win?

When the requirement is the thing the closed platform won't let you build. A checkout that needs custom markup, not a Shopify-defined slot. Business logic that has to call your ERP synchronously and consult the clock. A backend tweak that belongs in-process, not in a separately-hosted, OAuth'd, rate-limited satellite. The moment a project has two or three of those, the Shopify ceiling stops being theoretical and starts costing you weeks of working around it — and Shopware's "it's just Symfony" stops being a slogan and starts being the reason you ship on time.

Pick Shopify when you want the platform to make decisions for you. Pick Shopware when you need to make them yourself. As a developer, you already know which kind of project lands on your desk.

I'm CTO at nextlevels, a German digital agency and Shopware Silver Partner. We build Shopware shops, custom software, and AI workflows for B2B Mittelstand clients — so I've shipped enough of both platforms to have opinions. Happy to argue the trade-offs in the comments.