DEV Community: Pushpum Vats

Qwen3.8-27B Hits Cerebras at 1,500 Tokens a Second: The Full Picture

Pushpum Vats — Sun, 06 Sep 2026 07:29:28 +0000

A Hacker News thread is circulating right now with a simple claim: Qwen3.8-27B, Alibaba's newest open-weight model, is live on Cerebras's inference cloud at roughly 1,500 tokens per second. It's fresh enough that the comment count and thread age are still moving — worth checking the live page rather than trusting any snapshot, including this one.

Before writing anything else, I checked the link the post actually points to. That's where this got interesting.

The link doesn't back the headline. The model does.

The submission points to Cerebras's general model catalog at inference-docs.cerebras.ai/models/overview. Fetch that page today and the "Available Models" table lists exactly two entries: OpenAI GPT-OSS (120B, ~3,000 tok/s) and Gemma 4 31B (31B, ~1,850 tok/s). No Qwen3.8-27B in sight.

That doesn't make the claim false — it makes the link stale. Cerebras maintains a separate, fully populated page at /models/qwen-3.8-27b, and it confirms everything the headline promises: model ID qwen-3.8-27b, a measured ~1,500 tokens/sec, live pricing, live rate limits.

The model is real and it's live. The catalog page the submitter linked simply hasn't caught up yet.

One community report from mid-August suggested Cerebras planned to swap Gemma-4-31B out of the free tier for Qwen3.8-27B during the first week of September — which is this week, and would explain the gap. Treat that as a plausible explanation, not a confirmed one; it traces back to a single forum post, not a Cerebras announcement, and I haven't found independent corroboration.

The lesson generalizes past this one thread: if you're verifying a vendor claim, don't stop at whatever link happens to be attached. Check the model's own page.

What's actually live

	Free Trial	Developer
Context window	64K tokens	128K tokens
Max output	32K tokens	40K tokens
Requests/min	5	300
Uncached tokens/min	30K	150K
Total tokens/min	90K	450K
Daily tokens	1M	No cap

Pricing is $0.99 per million input tokens, $1.49 per million output. The model is multimodal — text and image in, text out — and supports tool calling, parallel tool calling, structured outputs, streaming, and prompt caching.

Cerebras first reacted to Qwen3.8-27B back in mid-August, congratulating the Qwen team on X and promising it would land "soon" on the Shared Tier. What's live now is that promise made good: real pricing, real limits, three weeks after the initial nod. Worth separating in your head — the August tweet and this week's launch are not the same event.

One detail for anyone porting workloads over: reasoning defaults to high on Cerebras's endpoint, one notch below Qwen's own upstream default of xhigh. Simon Willison has noted that xhigh burns through context fast enough to matter on smaller setups — so Cerebras's lower default may be a deliberate choice, not an oversight.

What Qwen3.8-27B actually is

Alibaba shipped it on August 14, 2026: a 27-billion-parameter dense model, not a mixture-of-experts, under Apache 2.0. Native context runs to 262,144 tokens, extensible to 1,000,000 via YaRN — Cerebras currently exposes a fraction of that ceiling.

The architecture is a hybrid, not a plain transformer stack. Sixty-four layers arrange into 16 repeating blocks, each pairing three linear-attention (Gated DeltaNet) layers with one full-attention (Gated Attention) layer. Only 16 of the 64 layers build a conventional KV cache — the same design lineage as Qwen's 2.4-trillion-parameter flagship, tracing back to Qwen3-Next.

Some coverage, Wikipedia included, calls the 27B a distilled model. Kingy.ai's independent analysis is more careful: Alibaba hasn't published enough about the training process to say how much of the gain is distillation versus separate training on the same architecture.

It replaces Qwen3.6-27B outright, and Qwen's own benchmark card shows a sizable jump on DeepSWE 1.1 — worth pulling the primary card yourself for the exact figures rather than trusting any single writeup, this one included.

1,500 tok/s isn't a record. It's not even close.

Here's what the headline number obscures: Cerebras hit exactly 1,500 tokens per second before, with Qwen3-235B, back in July 2025. Two earlier launches beat it outright — Llama 4 Scout ran north of 2,600 tokens per second in April 2025, and Qwen3-32B hit roughly 2,400 the following month. Both figures come straight from Cerebras's own press materials.

That's not a knock on the number. A typical GPU-backed inference API tops out around 150 tokens per second, so 1,500 is still a real 10x jump for anyone building on it. It's Cerebras's wafer-scale hardware doing what it always does — this just isn't a new milestone for the company.

The benchmarks, with the footnotes attached

Qwen's own launch table, independently reviewed by Kingy.ai, has Qwen3.8-27B beating Qwen3.7-Plus on most reported metrics, with GPQA Diamond and HLE (text) cited as the exceptions.

Against the frontier comparison point in that same table — labeled "Claude Opus 4.6 Max" — Qwen3.8-27B is reported to trail by several points across GPQA, HLE, Terminal-Bench, and NL2Repo. Treat the exact gaps as approximate until you've checked Qwen's published card directly; secondhand benchmark tables are where small transcription errors like to hide.

One correction worth making explicit: Anthropic doesn't sell a product called "Opus 4.6 Max." Claude Opus 4.6 ships with four effort levels — low, medium, high, and max — and "max" is a setting, not a SKU. Qwen's chart almost certainly means Opus 4.6 run at its highest effort tier, labeled informally by whoever built the table.

If the reported gaps hold up, that's still a strong showing for a 27B dense model against a much larger closed system. But read the fine print before the leaderboard position: NL2Repo blocks package installs so models can't shortcut the answer, DeepSWE runs at 256K context specifically because that favors Claude Code's setup, and HLE uses GPT-4o as the grading judge.

Vendor tables are built to make the vendor's model look good — that's not an accusation, it's the genre.

What the thread actually cared about

The speed number barely came up. The practical questions did:

Prompt caching? Yes — Cerebras's own docs confirm it, which settles a real cost concern for agentic coding workloads.
Why not host the 2.4-trillion-parameter flagship instead of the 27B? Two theories surfaced: a wafer interconnect limit at that scale, and the more cynical read that Cerebras's inference business exists to sell hardware — so the model that fits the shared tier economically wins over the model that wins headlines.
Onboarding friction. Complaints about signup flow and support channels are a recurring feature of this kind of thread — worth noting, but treat any single complaint as one person's experience, not a pattern, unless it's corroborated elsewhere.
Speed isn't everything. A sentiment that shows up in nearly every Cerebras thread, and shows up here too.

Specific usernames, comment counts, and verbatim quotes from a live thread age out fast — check the source directly rather than trusting a snapshot from this piece.

The caveat worth keeping in mind

Cerebras made a similar throughput promise last year for Qwen3-Coder-480B on its Code plan: 2,000 tokens per second, advertised. InfoWorld's review, "Down and out with Cerebras Code," found real-world runs rarely broke 500 tokens per second, and some stayed under 100.

That's a different model on a different product tier, so it isn't evidence against today's 1,500 figure — but it's a good reminder that headline throughput numbers and what your own prompts actually get are two different measurements.

Run your own benchmark against your own workload before you build a pipeline around anyone's advertised number, Cerebras included.

Bottom line

Qwen3.8-27B on Cerebras is real, and the 1,500 tokens-per-second figure checks out — on its own model page, not on the general catalog link the Hacker News post actually pointed to. It's not a new speed record for Cerebras.

And the benchmark story is a strong one with real vendor-table caveats attached, worth verifying against Qwen's primary source rather than taking on faith from any secondary writeup.

If you need fast, cheap multimodal reasoning inside a 128K context window: test it against your own workload, and check the model-specific docs page — not the one linked in whatever post sent you here — before you commit spend.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Prompt & Rules Quality for Cursor, Windsurf, and Claude Code: The Complete Developer Guide

Pushpum Vats — Fri, 04 Sep 2026 06:48:23 +0000

AI coding agents forget everything the moment your session ends. Every new chat, every fresh terminal, every reset context window starts from zero — no memory of your linting rules, your folder conventions, or the fact that you told it three times yesterday not to use default exports.

Rules files and hooks are how you fix that. They're not a bolt-on "prompt quality" product — they're native, built-in mechanisms in Cursor, Windsurf, and Claude Code that inject persistent context before the model ever sees your prompt, and (in Claude Code's case) can deterministically gate what the agent is allowed to do.

This guide covers the real, current mechanism in each tool, with working code, plus how to keep them in sync so you're not maintaining three divergent config files by hand.

Why this matters

LLMs are stateless between completions. Without a rules mechanism, "use functional components," "no default exports," "TypeScript strict mode," and "never touch .env" all have to be retyped, every session, and the model still might not follow them consistently.

Rules files fix the first problem: they inject standing context automatically. Hooks (Claude Code only, as of this writing) fix the second problem: they give you deterministic enforcement that doesn't depend on the model remembering anything at all.

Keep that distinction in mind through the rest of this guide — rules shape what the agent knows; hooks control what the agent is allowed to do.

Cursor: Project Rules (`.mdc`)

The old single-file .cursorrules is deprecated. The current system is Project Rules — multiple .mdc (Markdown + Config) files living in .cursor/rules/, each with its own activation logic.

Rule types

Type	Location	Scope	Shared via
Project Rules	.cursor/rules/*.mdc	Current repo	Git
User Rules	Cursor Settings → Rules	All your projects	Not shared
Team Rules	Cursor dashboard	All team members	Dashboard (paid plans)
AGENTS.md	Project root/subdirs	Current repo	Git

The `.mdc` format

Each file is YAML frontmatter + Markdown body:

---
description: "TypeScript conventions for this project"
globs: "src/**/*.ts,src/**/*.tsx"
alwaysApply: false
---

# TypeScript Standards

- Use strict mode (`tsconfig` → `strict: true`)
- Prefer interfaces over type aliases for object shapes
- Use const objects instead of enums
- No default exports except for Next.js page components
- All function parameters must have explicit types
- Use early returns for error conditions

Frontmatter fields and the four activation modes

Field	Type	Effect
description	string	Summary the agent uses to decide relevance in "Agent Requested" mode
globs	string \| string[]	File patterns that auto-attach this rule when a matching file is open
alwaysApply	boolean	If true, injected into every chat regardless of context

Combining these gives you four practical modes:

<!-- 1. Always — injected into every single conversation -->
---
description: "Core project context"
alwaysApply: true
---

<!-- 2. Auto-Attached — fires only when matching files are in context -->
---
description: "Django ORM and DRF patterns"
globs: "**/backend/**/*.py"
alwaysApply: false
---

<!-- 3. Agent Requested — model reads the description and decides -->
---
description: "How to write and run integration tests in this repo"
alwaysApply: false
---

<!-- 4. Manual — only injected when explicitly @-mentioned in chat -->
---
description: "One-off migration playbook, rarely needed"
alwaysApply: false
---

A realistic rule set

.cursor/rules/
├── project-context.mdc      # alwaysApply: true
├── typescript.mdc           # globs: src/**/*.{ts,tsx}
├── testing.mdc              # globs: **/*.test.ts
├── api-error-format.mdc     # description-based, agent decides
└── db-migration-local.mdc   # manual, gitignored, personal only

.cursor/rules/testing.mdc:

---
description: "Testing conventions using Vitest"
globs: "**/*.test.ts,**/*.spec.ts"
alwaysApply: false
---

# Testing Standards

- Use Vitest, not Jest
- One `describe` block per exported function
- Mock external HTTP calls with `msw`, never with manual `fetch` stubs
- Every new API route needs at least one happy-path and one error-path test

Practical rules

Keep each .mdc file under ~500 lines — a bloated file burns context budget on every request.
Name files in kebab-case by concern (error-responses.mdc, not rules2.mdc).
Disable a rule without deleting it: set alwaysApply: false and strip the globs/description.
For personal, non-shared overrides, use a *-local.mdc naming convention and add .cursor/rules/*-local.mdc to .gitignore.
AGENTS.md is the simpler fallback for small projects that don't need glob-level scoping — and it doubles as a cross-tool format (see "Keeping rules in sync across tools" below).

Windsurf: Rules & Memories (Cascade)

Windsurf's agent, Cascade, splits persistent context into two separate systems that people often conflate:

Memories — auto-generated by Cascade during a session, or created on request ("remember this"). Workspace-scoped, free (no credit cost), not shared across projects.
Rules — explicitly authored by you, always active, applied globally or per-workspace.

Rule storage locations

Location	Scope
~/.codeium/windsurf/global_rules.md (or via Settings)	Every workspace
.windsurf/rules/*.md in the project root	Current workspace
.windsurf/rules/ in a subdirectory	That subdirectory only
.windsurfrules (legacy single file)	Current workspace, still supported

Activation modes

Mode	Behavior
Always On	Injected into every Cascade interaction
Manual	Only applied when @mentioned in the Cascade input
Model Decision	Cascade reads a natural-language description and decides relevance itself
Glob	Applied when files matching a pattern (e.g. src/*/.ts) are in context

Example: `global_rules.md`

# Global Rules

- Server Components by default in Next.js; Client Components only when
  the file needs interactivity, state, or browser-only APIs
- Never suggest `any` in TypeScript — use `unknown` and narrow it
- Prefer named exports over default exports

Example: workspace rule, glob-scoped

---
trigger: glob
globs: "*.py"
---

# Python Backend Rules

- Follow PEP 8; format with `ruff format`
- All public functions require type hints and a docstring
- Use `pydantic` models for request/response validation, not raw dicts

XML-tag style (Windsurf's alternate, model-friendly format)

Windsurf documentation also supports wrapping rules in XML-style tags, which some teams find easier for the model to parse and cite back:

<coding_guidelines>
- My project's programming language is Python
- Use early returns when possible
- Always add docstrings when creating new functions and classes
</coding_guidelines>

Practical rules

Each rule file has a hard character cap (in the low five figures — Windsurf truncates content beyond it), so split large standards into multiple focused files rather than one giant global_rules.md.
Add .windsurfrules (the legacy single-file format) to .gitignore if it holds personal preferences rather than team conventions.
Don't put project-specific facts ("we migrated the auth service last sprint") in Rules — that's what auto-generated Memories are for. Rules should hold durable policy, not session trivia.
Review Cascade's auto-generated memories periodically via the Memories panel; stale ones actively mislead the agent.

Claude Code: `CLAUDE.md` + Hooks

Claude Code splits the same problem into two genuinely different tools, and this is the part most guides gloss over: CLAUDE.md is context, hooks are control. CLAUDE.md can be ignored by a distracted model. A hook cannot.

`CLAUDE.md` hierarchy

Claude Code walks up the directory tree and merges multiple CLAUDE.md files, broadest to most specific:

Level	Location	Scope
Managed policy	/Library/Application Support/ClaudeCode/CLAUDE.md (macOS) / /etc/claude-code/CLAUDE.md (Linux)	Org-wide, enterprise-managed
User	~/.claude/CLAUDE.md	Every project, every session
Project	CLAUDE.md at repo root	This repo, committed to git
Subdirectory	<dir>/CLAUDE.md	Loaded on demand when Claude works in that folder

More specific files layer on top of (don't fully replace) broader ones — a frontend/CLAUDE.md and a backend/CLAUDE.md can carry completely different conventions in a monorepo without bloating the root file.

Example `CLAUDE.md`

# Project: Acme Billing Service

## Stack
- Node 20, TypeScript, Fastify, Postgres via Prisma
- Tests: Vitest. Run with `npm test`, not `npm run test:watch` in CI contexts.

## Conventions
- All monetary values are integer cents, never floats
- Every new endpoint needs a corresponding OpenAPI entry in `openapi.yaml`
- Do not add new npm dependencies without calling it out explicitly in your response

## Commands
- `npm run dev` — start local server on :3000
- `npm run db:migrate` — apply pending Prisma migrations
- `npm run lint:fix` — run before considering any task done

@docs/architecture.md
@~/.claude/personal-style.md

The `@import` syntax

CLAUDE.md files can pull in other files with @path/to/file:

Supports relative paths, absolute paths, and home-directory paths (@~/.claude/...)
Imports can themselves import other files, up to 5 levels deep
@ references are not evaluated inside code spans or fenced code blocks — so documenting the syntax (as above) doesn't accidentally trigger a real import

Use this to split a sprawling root file into composable pieces (@docs/architecture.md, @docs/testing-strategy.md) instead of one 2,000-line wall of text.

Hooks: deterministic quality gates

CLAUDE.md is a request, not a guarantee — the model can still skip a step under time pressure inside a long agentic run. Hooks are shell commands Claude Code fires automatically at fixed points in its execution loop, regardless of what the model "remembers."

Where hooks live:

~/.claude/settings.json          # global, all projects
.claude/settings.json            # project-level, committable
.claude/settings.local.json      # project-level, gitignored
<managed policy path>            # org-wide, admin-controlled

Key lifecycle events:

Event	Fires	Can block the action?
PreToolUse	Before a tool call executes	✅ Yes (exit code 2)
PostToolUse	After a tool call succeeds	❌ No — but can trigger follow-up (format, test, notify)
UserPromptSubmit	When you submit a prompt, before Claude processes it	✅ Yes
Stop	When Claude finishes responding	—
SessionStart	New session begins	—
PreCompact	Before context gets compacted	—
Notification	Claude sends a notification	—

Basic shape, in .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

Every hook receives structured JSON on stdin describing the event (tool_name, tool_input, etc.), and controls what happens next via its exit code:

exit 0 → continue normally
exit 2 (on PreToolUse) → block the tool call; stderr is shown to the model as the reason
Non-zero on PostToolUse → surfaced as feedback, but the action already happened

Example: block edits to `.env` and force-pushes

#!/bin/bash
# .claude/hooks/block-dangerous.sh
INPUT=$(cat)
TOOL_INPUT=$(echo "$INPUT" | jq -r '.tool_input | tojson')

if echo "$TOOL_INPUT" | jq -r '.file_path // empty' | grep -q '\.env'; then
  echo "Blocked: .env files must be edited manually, not by the agent" >&2
  exit 2
fi

if echo "$TOOL_INPUT" | jq -r '.command // empty' | grep -q 'push.*--force'; then
  echo "Blocked: force push requires human review" >&2
  exit 2
fi

exit 0

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Edit|Write",
        "hooks": [
          { "type": "command", "command": "bash .claude/hooks/block-dangerous.sh" }
        ]
      }
    ]
  }
}

Example: auto-format and auto-test after every edit

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write" }
        ]
      }
    ]
  }
}

This is the real difference from a rules file: writing "always run Prettier after editing" in CLAUDE.md is a hope. A PostToolUse hook is a guarantee — it runs every time, independent of the model's attention.

Set an explicit timeout (in seconds) on any hook that shells out to something slow, like a full test suite — default timeouts are short and have changed across releases, so don't rely on the default for long-running commands.

Side-by-side comparison

	Cursor	Windsurf	Claude Code
Context file(s)	.cursor/rules/*.mdc	.windsurf/rules/*.md, global_rules.md	CLAUDE.md (hierarchical)
Legacy single-file format	.cursorrules (deprecated)	.windsurfrules (still supported)	—
Granular scoping	Per-file, via globs	Per-file, via glob trigger	Per-directory, via nested files
Model decides relevance?	Yes (description, no alwaysApply)	Yes ("Model Decision" mode)	No — loaded by directory/hierarchy
Auto-generated memory	No	Yes (Cascade Memories)	No
Team-shared rules	Yes (paid dashboard)	Via committed .windsurf/rules/	Via committed CLAUDE.md
Can block an action outright	No	No	Yes — PreToolUse hooks
Auto-run commands after edits	No	No	Yes — PostToolUse hooks
Cross-file import	No native syntax	No native syntax	@path imports, depth 5

The takeaway: Cursor and Windsurf give you rich, granular context injection. Claude Code gives you that too (via CLAUDE.md), plus a second, independent layer of enforcement that doesn't exist in the other two as of this writing.

One rule set, three formats — a worked example

Say you want one policy — "REST handlers must validate input with Zod, and every mutation needs a test" — enforced consistently. Here's the same rule expressed natively in each tool.

Cursor — .cursor/rules/api-validation.mdc:

---
description: "Input validation and test coverage for REST handlers"
globs: "src/routes/**/*.ts"
alwaysApply: false
---
# API Validation

- Every route handler must validate `req.body` with a Zod schema before use
- Every handler that mutates state needs a corresponding test in `*.test.ts`

Windsurf — .windsurf/rules/api-validation.md:

---
trigger: glob
globs: "src/routes/**/*.ts"
---
# API Validation

- Every route handler must validate `req.body` with a Zod schema before use
- Every handler that mutates state needs a corresponding test in `*.test.ts`

Claude Code — a section inside src/routes/CLAUDE.md:

## API Validation

- Every route handler must validate `req.body` with a Zod schema before use
- Every handler that mutates state needs a corresponding test in `*.test.ts`

...and optionally backed by a hook that actually checks it, rather than trusting the model read the section:

#!/bin/bash
# .claude/hooks/check-zod-validation.sh — PostToolUse on route file edits
FILE=$(cat | jq -r '.tool_input.file_path // empty')
if [[ "$FILE" == src/routes/* ]] && ! grep -q "z\.object\|zodSchema" "$FILE"; then
  echo "Warning: $FILE has no visible Zod validation call" >&2
fi
exit 0

Notice the content is identical — only the wrapper (frontmatter keys, file location) differs. That's exactly the problem the next section solves.

Keeping rules in sync across tools

Maintaining near-duplicate content in .cursor/rules/, .windsurf/rules/, and CLAUDE.md by hand drifts fast. A small but real open-source ecosystem exists specifically to solve this — write once, generate the rest.

Ruler (`@intellectronica/ruler`)

The most established of these. One .ruler/ directory is the source of truth; ruler apply distributes it to every supported agent's native format (Claude Code, Cursor, Windsurf, Copilot, Codex CLI, Cline, Aider, and others).

npm install -g @intellectronica/ruler
cd your-project
ruler init

ruler init scaffolds:

.ruler/
├── AGENTS.md      # your canonical rules, in plain Markdown
├── ruler.toml     # which agents to target, output paths
└── mcp.json       # optional shared MCP server config

Split large rule sets into focused files — they're concatenated alphabetically:

.ruler/
├── AGENTS.md
├── coding_style.md
├── api_conventions.md
└── security_guidelines.md

Apply to every configured agent, or target specific ones:

ruler apply                          # all configured agents
ruler apply --agents cursor,claude   # only these two
ruler revert                         # undo, restores from .bak files
ruler revert --dry-run               # preview the undo first

ruler.toml controls which agents get generated and where — check ruler --help for the exact keys in the version you install, since the CLI evolves, but the shape is roughly:

default_agents = ["claude", "cursor", "windsurf", "copilot"]

[agents.cursor]
enabled = true

[agents.windsurf]
enabled = true

Each generated file gets a source marker for traceability, e.g.:

<!-- Source: .ruler/api_conventions.md -->

...so if Cursor's rule looks wrong, you know exactly which canonical file to fix.

Lighter alternatives

If you don't want a full tool, a pre-commit hook that regenerates target files from one canonical AGENTS.md accomplishes the same thing with a few lines:

# .husky/pre-commit
npx agentsync sync   # example: regenerates CLAUDE.md, .cursorrules, etc. from AGENTS.md
git add -A

The specific tool matters less than the principle: pick one canonical file, generate the rest, and never hand-edit a generated file.

Hooks as a real quality gate

Since Claude Code is the only one of the three with an enforcement layer today, it's worth showing a fuller pattern: a "quality gate" that runs lint, type-check, and tests after every batch of edits, and reports failures back to the model so it can self-correct — without you doing anything.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "bash .claude/hooks/quality-gate.sh",
            "timeout": 120
          }
        ]
      }
    ]
  }
}

#!/bin/bash
# .claude/hooks/quality-gate.sh
INPUT=$(cat)
FILE=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')

[[ "$FILE" != *.ts && "$FILE" != *.tsx ]] && exit 0

npx eslint "$FILE" --quiet 2>&1 | tee /tmp/lint-out.txt
if [ -s /tmp/lint-out.txt ]; then
  echo "ESLint found issues in $FILE — fix before continuing:" >&2
  cat /tmp/lint-out.txt >&2
  exit 1   # PostToolUse can't block, but this surfaces feedback to the model
fi

npx tsc --noEmit -p . 2>&1 | tee /tmp/tsc-out.txt
if [ -s /tmp/tsc-out.txt ]; then
  echo "Type errors present:" >&2
  cat /tmp/tsc-out.txt >&2
  exit 1
fi

exit 0

Because this is a PostToolUse hook it can't undo the edit — but a non-zero exit surfaces the lint/type output directly to the model as feedback, so in an agentic loop it typically self-corrects on the next turn instead of you catching it in review three files later.

For anything that should be prevented outright rather than corrected after the fact (touching production config, running rm -rf, editing CI secrets), use PreToolUse with exit 2 instead — that's the only exit code across either event that actually stops the action.

Common mistakes

Treating CLAUDE.md as an enforcement mechanism. It's context. If something must never happen, it needs a PreToolUse hook, not a bullet point.
One giant rules file. All three tools reward focused, single-topic files over a 2,000-line monolith — it wastes context budget and the model deprioritizes buried instructions.
Forgetting alwaysApply/trigger semantics. A Cursor rule with no globs and alwaysApply: false and a vague description may simply never fire. Test that your rule actually attaches.
Committing personal preferences. "I prefer terse commit messages" belongs in Cursor's User Rules or a gitignored local file — not in a team's shared .cursor/rules/.
No timeout on slow hooks. A hook that shells out to a full test suite without an explicit timeout can stall the agent loop.
Hand-editing generated files. If you adopt Ruler or a similar sync tool, edit the canonical source only — hand edits get silently overwritten on the next apply.

Cheat sheet

Cursor
  .cursor/rules/*.mdc        → frontmatter: description, globs, alwaysApply
  .cursor/rules/*-local.mdc  → gitignore for personal overrides

Windsurf
  global_rules.md            → all workspaces
  .windsurf/rules/*.md       → this workspace (or subdirectory)
  .windsurfrules              → legacy single-file, still works

Claude Code
  ~/.claude/CLAUDE.md         → user, all projects
  ./CLAUDE.md                 → project root
  ./**/CLAUDE.md              → subdirectory, loaded on demand
  @path/to/file.md            → import (max depth 5)
  ~/.claude/settings.json     → global hooks
  .claude/settings.json       → project hooks (commit this)
  .claude/settings.local.json → project hooks (gitignore this)

Sync tool
  npm install -g @intellectronica/ruler
  ruler init && ruler apply

FAQ

Is .cursorrules still supported? Yes, but it's deprecated — Cursor still reads it, but new projects should use .cursor/rules/*.mdc for glob scoping and per-rule activation modes.

Does Windsurf have anything like Claude Code's hooks? Not as of this writing. Windsurf's Rules and Memories shape context; they don't gate or block tool calls the way a Claude Code PreToolUse hook can.

Can a Cursor or Windsurf rule stop the agent from running a command? No — both are context-injection systems. Neither has a deterministic blocking mechanism equivalent to Claude Code's PreToolUse + exit 2.

What's the difference between Windsurf Memories and Rules? Memories are auto-generated (or on-request) facts scoped to a workspace, free to create, meant for session-specific context. Rules are explicitly authored, always-active policy. Don't put durable team conventions in Memories — they're not guaranteed to persist the way a committed rules file is.

Do I need a separate tool to keep these in sync? Not strictly — you can hand-maintain three files for a small project. Past a handful of rules, drift becomes real; a sync tool like Ruler (or a simple pre-commit script) pays for itself quickly.

Where do MCP server configs fit into this? Outside the scope of this guide, but the same tools generally handle it: Cursor uses .cursor/mcp.json, Claude Code uses .mcp.json, and Ruler can distribute a shared mcp.json alongside your rules.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Apple Just Confirmed Claude Is Coming to Your iPhone — Here's What WWDC 2026 Actually Changes

Pushpum Vats — Thu, 03 Sep 2026 08:14:12 +0000

For the last two years, "Siri" has been a slightly embarrassing word in Apple's vocabulary — the company famously paid out a quarter-billion-dollar settlement over AI features it promised and never shipped. At WWDC 2026, Apple's answer to that was to basically start over: a new assistant called Siri AI, built on what Apple calls its Foundation Models, developed in partnership with Google using Gemini's underlying technology.

That last part is the genuinely surprising bit. For a company that has spent a decade telling you everything happens "on device, on our chips," quietly admitting that its next-generation assistant leans on a rival's AI — reportedly at a cost of around a billion dollars a year — is a real shift in posture, even if Apple hasn't put a number on it publicly.

What Siri AI actually does differently

The core pitch is on-screen and cross-app awareness — Siri can now look at what's on your screen and pull from Mail, Messages, and Photos in real time, without you switching apps. The demos at the keynote showed it finding specific photos by description ("the one with everyone wearing matching shirts") and building a multi-step calendar event just from reading a text conversation, without opening the Calendar app at all.

There's also a genuine interface overhaul. Siri now lives in its own dedicated app — dark interface, a text box, a microphone toggle for voice, a paperclip for attaching files or images, basically the same shape as every other chatbot app at this point. Conversations get saved as a history and synced across your devices via iCloud, with an optional auto-expiration if you don't want a permanent log of everything you've asked it.

Getting to it is also different now. There's a new system-wide gesture — swipe down from the Dynamic Island — that opens a "Search or Ask" bar, separate from the old Notification Center swipe (which has moved to the side). And individual Apple apps are getting an "Ask Siri" button built into their menus, so you can send what you're looking at straight to the assistant along with a request.

The part everyone in the AI world actually cares about: choice

Buried under all the Siri branding is the detail that matters most for anyone who already has a favorite AI: Apple is opening Siri up to outside models through something being called Extensions. ChatGPT has technically been pluggable into Siri since iOS 26, but reporting around WWDC 2026 points to iOS 27 expanding this so you can choose between ChatGPT, Gemini, and Claude for certain requests — picking which assistant actually answers, rather than everything being routed through Apple's own model by default.

The honest caveat, and it's a big one: as of the keynote, the deepest new capabilities — the on-screen awareness, the Mail/Messages/Photos access — are reportedly siloed to Apple's own native experience for now. Whether a third-party assistant like Claude gets the same level of access to what's on your screen, or stays limited to the kind of standalone Q&A you'd get from opening the Claude app directly, is genuinely unclear at this point. If you've been hoping to point your entire phone at Claude by default, that's not confirmed — what's confirmed is the ability to choose it for specific requests.

There's a developer story here too

If you build software, the more concrete announcement might actually matter more than anything consumer-facing: Xcode 27 is getting coding agents built in from Anthropic, Google, and OpenAI directly, so you can build apps using Claude or Gemini models alongside Apple's own, inside Apple's own IDE. For a company that has historically kept its developer tools tightly closed, that's a notable opening — and it lines up with the same broader trend we've covered before on this blog: AI assistants increasingly plug into your existing tools rather than living in their own walled-off chat window.

What's confirmed vs. what's still a rumor wearing a confirmed-fact costume

It's worth being precise here, because a lot of the coverage from the last week blurs "Apple announced this" with "Bloomberg reported this is coming."

Confirmed at the keynote: the Siri AI rebrand, the standalone Siri app, on-screen/cross-app awareness for Apple's own apps, the new gesture-based "Search or Ask" interface, the Apple-Google Foundation Models partnership, and the Xcode 27 third-party coding agent integration.

Reported but not fully detailed by Apple: the exact mechanics of the Extensions system for choosing Claude/Gemini/ChatGPT for specific requests, and whether third-party assistants will ever get the same on-screen access as Siri itself.

Hardware reality check: Apple Intelligence still requires an iPhone 15 Pro or newer, and the most advanced on-device features — including the new Siri voice and updated dictation — need the newer A19 Pro chip. If you're on an older iPhone, expect a noticeably more limited version of all of this, if it works at all.

What to actually do right now

Nothing, really — and that's fine. iOS 27 is expected this fall alongside the new iPhone lineup, which is the normal Apple release rhythm. A few things worth doing in the meantime if you want to be ready on day one:

Check your hardware. If you're on an iPhone 14 or older, the headline Siri AI features likely won't be available to you at all regardless of software updates — this is a hardware-gated rollout, not just a software one.

Get comfortable with the Claude app now. If Extensions does land roughly as reported, the most likely first version is "hand this specific request to Claude" rather than a deep OS-level takeover — which means knowing how to phrase a good request to Claude directly is exactly the skill that carries over. If you haven't spent time with it yet, this is a good moment to.

Don't assume your existing automations will "just work." If you've built anything around Siri Shortcuts, the interface and gesture changes mean some of those flows may need to be rebuilt once iOS 27 actually ships — worth keeping an eye on Apple's developer documentation closer to the fall.

Why this matters beyond Apple

Step back from the iPhone specifics for a second, and this fits a pattern we've been tracking across this blog all year: AI is stopping being "an app you open" and becoming "a layer that's just present" — in your files via MCP, in your terminal via coding agents, in your photos via tools like Nano Banana, and now, apparently, in the operating system itself, with you choosing which model actually answers. The interesting fight in 2026 isn't really "which AI is smartest" anymore. It's which one you'll actually have access to from wherever you happen to be — and for the first time, on the world's most popular phone, that might genuinely be your choice.

Securing a VPS in 2026: A No-Nonsense Hardening Guide

Pushpum Vats — Sat, 22 Aug 2026 06:32:34 +0000

Every step ranked by priority — SSH, firewall, patching, backups, and TLS, with the exact configs.

A default VPS install is not a secure one. The moment it gets a public IP, automated bots start probing it for weak SSH logins, open ports, and outdated packages — often within minutes. This guide is ordered by impact: do Tier 1 before anything touches production, Tier 2 within the first week, Tier 3 if it applies to your stack, and Tier 4 on a recurring schedule forever. Written for Ubuntu 24.04 LTS / Debian 12, with notes where RHEL-based systems (AlmaLinux, Rocky) differ.

Tier 1 — Before Anything Touches Production

1. Non-Root User + SSH Key Auth

# On the server, as root
adduser deploy
usermod -aG sudo deploy

# On your local machine — generate a modern key (Ed25519, not RSA)
ssh-keygen -t ed25519 -C "you@yourdomain.com" -a 100

# Copy it to the server
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@your-server-ip

# Log in as deploy, confirm sudo works, THEN lock root
sudo passwd -l root

Ed25519 keys are smaller, faster, and free of the timing side-channels that affect RSA. Use RSA only if you're stuck supporting a legacy client, and if so use at least 4096 bits.

2. Harden sshd_config

Keep a second terminal connected while you test — don't edit this over your only session. Edit /etc/ssh/sshd_config (or drop a file into /etc/ssh/sshd_config.d/):

# Authentication
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
PermitEmptyPasswords no
MaxAuthTries 3
MaxSessions 4
LoginGraceTime 30
AllowUsers deploy

# Modern crypto only — drop legacy KEX/ciphers/MACs
KexAlgorithms mlkem768x25519-sha256,curve25519-sha256,[email protected]
HostKeyAlgorithms ssh-ed25519,ecdsa-sha2-nistp256
Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]

# Reduce attack surface
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

Notes:

mlkem768x25519-sha256 is a hybrid classical/post-quantum key exchange (ML-KEM-768, FIPS 203) and is the default negotiated exchange on OpenSSH 9.9+. It protects against "harvest now, decrypt later" interception. If anything in your fleet runs older OpenSSH, drop that entry and lead with curve25519-sha256.
Restart safely: sudo systemctl reload sshd (reload, not restart, keeps existing sessions alive if the config is bad).
Run sshd -T | less to see the effective config, and audit it externally with ssh-audit your-server-ip — it flags any weak KEX, cipher, or MAC still active.
Changing the port off 22 doesn't stop a targeted attacker, but it silences almost all automated scanner noise in your logs. Optional, not a substitute for the above.

3. Firewall: Default Deny

sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH        # or: sudo ufw allow 2222/tcp if you changed the port
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

UFW (and firewalld on RHEL-based distros) both drive nftables under the hood now — the old iptables chains are a legacy compatibility layer, not your primary interface anymore. For anything beyond simple port rules, nft directly gives finer control, but UFW covers the vast majority of single-VPS setups.

4. Automatic Security Patching

The gap between a CVE disclosure and your patch is where breaches happen — the 2024 OpenSSH "regreSSHion" RCE (CVE-2024-6387) was weaponized within days. Close that gap automatically:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

In /etc/apt/apt.conf.d/50unattended-upgrades, stick to the security pocket, blacklist anything you'd rather patch by hand, and schedule reboots for a known-quiet window:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Package-Blacklist {
    "postgresql-*";
    "linux-image-*";
};
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";
Unattended-Upgrade::Mail "you@yourdomain.com";
Unattended-Upgrade::MailReport "on-change";

Confirm the -security pocket is active in /etc/apt/apt.conf.d/20auto-upgrades, and dry-run after any edit: sudo unattended-upgrade --dry-run -v. For zero-downtime kernel patching, Canonical's Livepatch service is free for up to 5 machines.

5. Backups — Set Up Before You Need Them

Hardening reduces the odds of compromise; it doesn't make you immune, and it does nothing for hardware failure or a bad rm -rf. Follow the 3-2-1 rule: 3 copies of your data, on 2 different media, with 1 off-site.

# restic example — encrypted, deduplicated, incremental
restic init --repo s3:s3.amazonaws.com/your-backup-bucket
restic backup /etc /home /var/www --repo s3:s3.amazonaws.com/your-backup-bucket

Automate it with a systemd timer or cron, and put a restore drill on your calendar now — a backup you haven't test-restored isn't a backup.

Tier 2 — Within the First Week

6. Intrusion Banning: Fail2Ban (+ CrowdSec if you're scaling)

Fail2Ban — simple, ~15 MB RAM, the right default for one server:

sudo apt install fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Edit /etc/fail2ban/jail.local:

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 3
backend  = systemd
banaction = nftables-multiport

[sshd]
enabled = true
port    = 2222

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

CrowdSec is worth adding once you're running more than one box, or want protection against attackers before they've hit your logs — it shares crowd-sourced IP reputation across its network via lightweight "bouncers" that write directly into nftables sets. Common pattern: Fail2Ban for SSH, CrowdSec for the web-facing layer (its Nginx/Caddy bouncer integrations are solid). They coexist fine as long as they're not both managing the exact same log source.

7. Kernel Network Hardening

Create /etc/sysctl.d/99-hardening.conf:

net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv6.conf.all.accept_redirects = 0
kernel.dmesg_restrict = 1

sudo sysctl --system

8. File Permissions & Mandatory Access Control

# Sane default umask for new files
echo "umask 027" | sudo tee -a /etc/profile.d/umask.sh

# Find unexpected SUID/SGID binaries — investigate anything you don't recognize
sudo find / -xdev -perm -4000 -o -perm -2000 2>/dev/null

# Confirm AppArmor is enforcing (Ubuntu/Debian default MAC)
sudo aa-status

On RHEL-based systems, use sestatus and keep SELinux in Enforcing mode rather than switching to Permissive to make an install easier — fix the policy instead.

9. Full-Disk Encryption (LUKS)

Protects data at rest if a drive is stolen, misconfigured, or decommissioned by a third party — relevant on any VPS since the underlying storage is managed by your provider, not you. It's best enabled during the OS install; encrypting an existing root filesystem in place is disruptive and rarely worth it. For existing servers, focus on encrypting a dedicated data or backup partition instead — and note that restic/borgbackup already encrypt archives at rest, so your Tier 1 backups are covered either way.

10. Database Hardening

If you're running MySQL/MariaDB or PostgreSQL on the same box, don't expose it publicly and don't use superuser accounts for application connections:

# MySQL/MariaDB — /etc/mysql/mariadb.conf.d/50-server.cnf
[mysqld]
bind-address = 127.0.0.1

# PostgreSQL — postgresql.conf
listen_addresses = 'localhost'

-- Least-privilege app user, MySQL example
CREATE USER 'app_user'@'localhost' IDENTIFIED BY 'strong-random-password';
GRANT SELECT, INSERT, UPDATE, DELETE ON app_db.* TO 'app_user'@'localhost';
FLUSH PRIVILEGES;

Run mysql_secure_installation (or the PostgreSQL equivalent of removing default/trust auth) to kill anonymous accounts and remote root. If a second server genuinely needs DB access, restrict it by source IP in your firewall rather than binding to 0.0.0.0.

Tier 3 — If It Applies to Your Stack

11. TLS: Get an A+ Without Guessing

If you're terminating TLS on the box (Nginx, Caddy, Apache), use Let's Encrypt with auto-renewal and Mozilla's current Intermediate profile — TLS 1.2 + 1.3 only, no legacy DHE ciphers, every suite forward-secret and AEAD:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
sudo systemctl list-timers | grep certbot   # confirm the renewal timer is active

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
add_header X-Content-Type-Options nosniff always;
add_header X-Frame-Options SAMEORIGIN always;
server_tokens off;

# Basic request-rate protection against scraping/brute force at the app layer
limit_req_zone $binary_remote_addr zone=basic:10m rate=10r/s;
limit_req zone=basic burst=20 nodelay;

ssl_prefer_server_ciphers off is intentional, not an oversight — every cipher in the Intermediate list is already strong, so letting the client pick lets mobile devices without AES hardware acceleration negotiate ChaCha20 instead. Only add the HSTS preload flag if every subdomain will always serve HTTPS — removal from browser preload lists takes months.

One 2026-specific note: public CA certificate lifetimes are shortening (down to 200 days as of March 2026, and heading lower over the next few years), so make sure renewal is genuinely automated rather than a calendar reminder — verify with sudo certbot renew --dry-run.

12. SSH at Scale: Certificates and TOTP 2FA

A single-admin box is fine with one hardware or software key. Once more than one or two people need access, static keys in authorized_keys become an operational liability — nobody remembers to remove them when someone leaves.

SSH certificates replace that with short-lived, centrally-issued credentials:

# One-time: create a CA keypair, keep the private half offline
ssh-keygen -t ed25519 -f ssh-user-ca -C "internal CA"

# Sign a user's key for 24 hours, scoped to a principal
ssh-keygen -s ssh-user-ca -I alice-daily -n alice,ops -V +24h alice_id_ed25519.pub

# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca/trusted_user_ca.pub

Revoking access is then just "stop issuing certificates for that principal" instead of hunting down every server's authorized_keys file.

TOTP 2FA is the lower-cost option if hardware keys aren't practical for your team:

sudo apt install libpam-google-authenticator
google-authenticator   # run as the user; save the printed backup codes

# /etc/pam.d/sshd — replace the @include common-auth line
auth required pam_google_authenticator.so

# sshd_config
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

This forces both a valid key and a TOTP code. It's not as phishing-resistant as FIDO2, but it's a meaningful step up from key-only auth for teams that don't want to distribute hardware tokens.

Going portless entirely is worth a look once you're managing more than a couple of servers: Tailscale SSH authenticates sessions over an already-authenticated WireGuard mesh with no inbound port required at all, and AWS SSM Session Manager / GCP IAP TCP forwarding offer the same idea gated by cloud IAM instead of network exposure.

13. Docker Container Security

Run containers as a non-root user (USER directive in the Dockerfile), never --privileged.
Don't mount /var/run/docker.sock into a container unless that container's entire job is orchestration — it's root-equivalent access to the host.
Set read_only: true and mount an explicit tmpfs for anything that needs to write.
In /etc/docker/daemon.json, disable inter-container communication you don't need and consider userns-remap so container root maps to an unprivileged host UID:
```
{
  "icc": false,
  "userns-remap": "default",
  "no-new-privileges": true
}
```
Keep base images current; rebuild on a schedule so you're not shipping stale CVEs, and scan with docker scout or Trivy before deploying.
Fail2Ban doesn't play well with Docker's own iptables/nftables management — most people run it on the host watching host logs rather than trying to containerize it.

14. Systemd Sandboxing for Non-Containerized Services

If an app runs directly as a systemd unit rather than in a container, you can get most of the isolation Docker would give you for free:

[Service]
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/myapp
MemoryMax=768M
CapabilityBoundingSet=

This limits blast radius — a compromised or buggy service can't read arbitrary paths, escalate privileges, or take down the host by exhausting memory. Check what a unit is actually doing with systemd-analyze security <unit>, which scores its exposure and flags missing sandboxing directives.

Tier 4 — Ongoing, Forever

15. Logging, Auditing, and Rootkit Checks

sudo apt install auditd lynis rkhunter

# Watch the files attackers actually touch
sudo tee -a /etc/audit/rules.d/audit.rules <<'EOF'
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /root/.ssh/authorized_keys -p wa -k ssh_keys
EOF
sudo systemctl restart auditd

# Full posture audit
sudo lynis audit system

# Rootkit scan
sudo rkhunter --check

Antivirus isn't a meaningful control on a Linux server — proper hardening, patching, and log review outperform it. Skip it and spend the time here instead.

16. Maintenance Cadence

Configuration drifts. Put this on a recurring calendar block:

Weekly — review Fail2Ban/CrowdSec ban logs, confirm unattended-upgrades ran cleanly, check df -h and disk usage trends.
Monthly — audit user accounts and sudoers, review ss -tlnp for services listening that shouldn't be, run lynis audit system and act on new warnings.
Quarterly — rotate SSH keys/certificates and any long-lived credentials, re-run ssh-audit and a TLS scan (SSL Labs or testssl.sh), test a full backup restore.

Quick Checklist

Tier 1 — before production traffic:

Root login disabled, sudo user created, key-based SSH only
sshd_config hardened: modern KEX/ciphers, MaxAuthTries 3, no forwarding
Firewall default-deny, only required ports open
unattended-upgrades installed, security pocket only, tested with --dry-run
Automated, encrypted, off-site backups — restore-tested

Tier 2 — first week:

Fail2Ban (or CrowdSec) active and tested
Kernel sysctl hardening applied
AppArmor/SELinux enforcing, sane umask, SUID audit done
Full-disk or backup-archive encryption confirmed
Database bound to localhost, least-privilege app user

Tier 3 — if applicable:

TLS on Mozilla Intermediate profile, auto-renewing certs, HSTS enabled
SSH certificates or TOTP 2FA in place for multi-admin access
Docker containers non-root, no exposed socket, images kept current
systemd sandboxing applied to bare-metal services

Tier 4 — recurring:

auditd watching critical files, Lynis/rkhunter scans scheduled
Weekly/monthly/quarterly maintenance cadence on the calendar

Run Tier 1 on every new server before it touches production traffic. The rest isn't optional so much as scheduled — security is a habit you keep paying into, not a setup you finish.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

I Built a Tiny AI Agent From Scratch — Every Line Tested Before It Touched a Real API

Pushpum Vats — Sat, 22 Aug 2026 06:30:27 +0000

What an "agent" actually is, stripped of the hype

Every few weeks there's a new framework promising to make "agentic AI" easy. Most of them are wrappers around one core idea: the model doesn't just generate text — it can pause, say "I need to call this function with these arguments," wait for the result, and then keep going with that information in hand.

That's it. That's the whole trick. Anthropic calls this tool use, and it's the same mechanism powering everything from "let Claude check the weather" to multi-step coding agents.

This tutorial builds a working version of that loop from the ground up — no LangChain, no agent framework, just the Claude API and plain Python. By the end you'll have a small agent that can do arithmetic and count words by actually calling real Python functions, decide on its own when to use them, and chain them together when a question needs both.

What you'll need

Python 3.9 or newer
An Anthropic API key (from the Claude Console)
The official SDK: pip install anthropic

That's the whole list. No vector databases, no Docker, nothing else.

Step 1: Write the actual tools (just functions)

This is the part people often overcomplicate. A "tool" is just a regular Python function, plus a small JSON description telling Claude what it does and what arguments it takes.

We'll build two: a calculator and a word counter. Save this as tools.py:

"""
The actual Python functions our agent can call, plus the JSON-schema
descriptions of those tools that we hand to the Claude API.
"""

import ast
import operator

_OPS = {
    ast.Add: operator.add,
    ast.Sub: operator.sub,
    ast.Mult: operator.mul,
    ast.Div: operator.truediv,
    ast.Pow: operator.pow,
    ast.USub: operator.neg,
}

def calculate(expression: str) -> str:
    """Safely evaluate a basic arithmetic expression like '12 * (3 + 4)'."""

    def _eval(node):
        if isinstance(node, ast.Constant) and isinstance(node.value, (int, float)):
            return node.value
        if isinstance(node, ast.BinOp) and type(node.op) in _OPS:
            return _OPS[type(node.op)](_eval(node.left), _eval(node.right))
        if isinstance(node, ast.UnaryOp) and type(node.op) in _OPS:
            return _OPS[type(node.op)](_eval(node.operand))
        raise ValueError(f"Unsupported expression: {expression!r}")

    tree = ast.parse(expression, mode="eval")
    result = _eval(tree.body)
    return str(result)

def count_words(text: str) -> str:
    """Count the words in a piece of text."""
    return str(len(text.split()))

TOOLS = [
    {
        "name": "calculate",
        "description": (
            "Evaluate a basic arithmetic expression and return the numeric "
            "result as a string. Supports +, -, *, /, **, parentheses, and "
            "negative numbers. Use this any time the user asks for a "
            "calculation, even a simple one -- do not do math in your head."
        ),
        "input_schema": {
            "type": "object",
            "properties": {
                "expression": {
                    "type": "string",
                    "description": "A valid arithmetic expression, e.g. '127 * 38' or '(12 + 4) / 2'.",
                }
            },
            "required": ["expression"],
        },
    },
    {
        "name": "count_words",
        "description": (
            "Count how many words are in a given piece of text and return "
            "the count as a string. Use this when the user asks for a word "
            "count of something rather than estimating it yourself."
        ),
        "input_schema": {
            "type": "object",
            "properties": {
                "text": {
                    "type": "string",
                    "description": "The text to count words in.",
                }
            },
            "required": ["text"],
        },
    },
]

TOOL_FUNCTIONS = {
    "calculate": calculate,
    "count_words": count_words,
}

A couple of deliberate choices worth calling out. The calculate function uses Python's ast module to parse the expression into a syntax tree and walk it manually, rather than calling eval() directly — eval("import os; os.system(...)") is exactly the kind of thing you don't want an AI-controlled function anywhere near, even though ast.parse(mode="eval") would itself reject statements like import. The description fields are also longer than feels natural at first. That's intentional — Claude's tool selection quality depends heavily on how clearly each tool explains what it does and when to use it.

Step 2: The agent loop

This is the part that actually makes it "agentic." Save this as agent.py:

"""
The agent loop: send a message, check whether Claude wants to use a tool,
run that tool locally, send the result back, and repeat until Claude
gives a final text answer.
"""

from tools import TOOLS, TOOL_FUNCTIONS

def run_agent(client, user_message, model="claude-sonnet-4-6", max_iterations=5, verbose=True):
    messages = [{"role": "user", "content": user_message}]

    for step in range(max_iterations):
        response = client.messages.create(
            model=model,
            max_tokens=1024,
            tools=TOOLS,
            messages=messages,
        )

        messages.append({"role": "assistant", "content": response.content})

        if response.stop_reason != "tool_use":
            return "".join(
                block.text for block in response.content if block.type == "text"
            )

        tool_results = []
        for block in response.content:
            if block.type == "text" and verbose and block.text.strip():
                print(f"  [Claude says]: {block.text.strip()}")

            if block.type == "tool_use":
                func = TOOL_FUNCTIONS.get(block.name)
                if verbose:
                    print(f"  [tool call]: {block.name}({block.input})")

                if func is None:
                    tool_results.append({
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": f"Unknown tool: {block.name}",
                        "is_error": True,
                    })
                    continue

                try:
                    result = func(**block.input)
                    if verbose:
                        print(f"  [tool result]: {result}")
                    tool_results.append({
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": result,
                    })
                except Exception as exc:
                    tool_results.append({
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": str(exc),
                        "is_error": True,
                    })

        messages.append({"role": "user", "content": tool_results})

    return "Reached max_iterations without a final answer -- something is looping."

Three things in here are easy to get wrong, and the API will reject your request with a 400 error if you do:

The tool_result blocks have to go in a new user message, not appended to the assistant's message. The tool_result blocks must come first in that message's content array — any text from your side has to come after them. And every tool_use block in the assistant's response needs a matching tool_result with the same tool_use_id, including when a tool errors out — which is why even the error case still appends a tool_result, just with is_error: true.

Step 3: Test the loop before it ever calls the real API

Here's the part most tutorials skip, and it's the most useful part for actually trusting your code. The Claude API's tool-use responses have a documented, predictable shape — a stop_reason, and a content list of blocks that are either text or tool_use. So we can fake that shape, feed it to run_agent, and verify the loop, the tool dispatch, and the actual math/word-counting logic all work — without an API key, without spending a token.

Save this as test_agent_offline.py:

from types import SimpleNamespace
from agent import run_agent
from tools import calculate, count_words

def block(**kwargs):
    return SimpleNamespace(**kwargs)

class FakeMessages:
    def __init__(self, script):
        self.script = script
        self.calls = 0

    def create(self, **kwargs):
        response = self.script[self.calls]
        self.calls += 1
        return response

class FakeClient:
    def __init__(self, script):
        self.messages = FakeMessages(script)

def test_parallel_tool_calls():
    turn1 = SimpleNamespace(
        stop_reason="tool_use",
        content=[
            block(type="text", text="I'll do both of those."),
            block(type="tool_use", id="toolu_010", name="calculate",
                  input={"expression": "(12 + 4) / 2"}),
            block(type="tool_use", id="toolu_011", name="count_words",
                  input={"text": "the quick brown fox jumps over the lazy dog"}),
        ],
    )
    turn2 = SimpleNamespace(
        stop_reason="end_turn",
        content=[block(type="text", text="(12 + 4) / 2 is 8.0, and that sentence has 9 words.")],
    )

    client = FakeClient([turn1, turn2])
    answer = run_agent(client, "Two things for you...", verbose=True)

    assert "8.0" in answer
    assert "9 words" in answer
    print("test_parallel_tool_calls passed\n")

def test_underlying_functions_directly():
    assert calculate("127 * 38") == "4826"
    assert calculate("(12 + 4) / 2") == "8.0"
    assert calculate("-3 + 7 ** 2") == "46"
    assert count_words("the quick brown fox jumps over the lazy dog") == "9"

    try:
        calculate("import os")
        raise AssertionError("should have raised")
    except (ValueError, SyntaxError):
        pass

    print("test_underlying_functions_directly passed\n")

if __name__ == "__main__":
    test_underlying_functions_directly()
    test_parallel_tool_calls()
    print("All offline tests passed.")

Running this with python3 test_agent_offline.py produces:

test_underlying_functions_directly passed

  [Claude says]: I'll do both of those.
  [tool call]: calculate({'expression': '(12 + 4) / 2'})
  [tool result]: 8.0
  [tool call]: count_words({'text': 'the quick brown fox jumps over the lazy dog'})
  [tool result]: 9
test_parallel_tool_calls passed

All offline tests passed.

That output is from actually running the code above — not a transcript I wrote by hand. It confirms three things at once: the calculator handles operator precedence and negative numbers correctly, the agent loop correctly processes multiple tool calls in a single turn (Claude often does both calculations in parallel rather than one at a time), and the message history gets built in the shape the real API expects.

If you change anything — add a tool, change a schema, rewrite the loop — rerun this file first. It catches the majority of "why did my agent just 400" problems in seconds, with zero API cost.

Step 4: Run it for real

Once the offline tests pass, swap in the real client. Save this as run.py:

"""
Run with a real API key:

    export ANTHROPIC_API_KEY="sk-ant-..."
    pip install anthropic
    python3 run.py
"""

from anthropic import Anthropic
from agent import run_agent

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment

if __name__ == "__main__":
    question = (
        "What's 127 * 38, and how many words are in the sentence "
        "'the quick brown fox jumps over the lazy dog'?"
    )
    answer = run_agent(client, question)
    print("\nFinal answer:", answer)

Set your API key as an environment variable, install the SDK, and run it:

export ANTHROPIC_API_KEY="sk-ant-your-key-here"
pip install anthropic
python3 run.py

Because the offline test already exercised the exact same run_agent function with a response shaped the way the real API responds, what you're really testing here is just "does my API key work and does the real model behave the way the documented shape says it will" — which is a much smaller, cheaper thing to debug.

What's actually happening, step by step

For the question above, here's the real sequence:

Claude receives the question along with the two tool definitions. It decides this needs both tools, and — because Claude 4-generation models default to parallel tool calling — it can return both tool_use blocks in a single response, often with a short sentence of context first ("I'll calculate that and count the words for you").

Our loop sees stop_reason == "tool_use", runs calculate("127 * 38") and count_words(...) locally, and sends both results back in a single new user message, with the tool_result blocks first.

Claude receives those results and, now having everything it needs, responds with stop_reason == "end_turn" and a plain text answer. Our loop sees that and returns the text. Done — two API calls total, with real computation happening in real Python in between.

Things to watch out for as you extend this

Pick the right model for the job. Anthropic's own guidance is to use a larger model like Opus for tools with ambiguous inputs or many options, and a smaller model like Haiku for simple, well-defined tools — smaller models are more likely to guess at missing parameters rather than asking.

Don't skip max_iterations. If a tool's result regularly causes Claude to call the same tool again, you can end up in a loop. The cap in run_agent is a blunt but effective safety net while you're developing.

Tool descriptions are most of the work. If Claude picks the wrong tool, or the right tool with weird arguments, the fix is almost always a clearer description — what the tool does, when to use it, when not to, and what each parameter means — rather than a change to your loop logic.

For anything beyond a toy, look at the SDK's tool runner. Once you're comfortable with the manual loop above (and understand why it's shaped the way it is), Anthropic's Python, TypeScript, and Ruby SDKs include a beta "tool runner" that handles the request/response cycle and conversation state for you. It's worth learning the manual version first — it's what the tool runner is doing under the hood, and it's much easier to debug when something goes wrong.

DEV Community: Pushpum Vats

Qwen3.8-27B Hits Cerebras at 1,500 Tokens a Second: The Full Picture

The link doesn't back the headline. The model does.

What's actually live

What Qwen3.8-27B actually is

1,500 tok/s isn't a record. It's not even close.

The benchmarks, with the footnotes attached

What the thread actually cared about

The caveat worth keeping in mind

Bottom line

Prompt & Rules Quality for Cursor, Windsurf, and Claude Code: The Complete Developer Guide

Why this matters

Cursor: Project Rules (.mdc)

Rule types

The .mdc format

Frontmatter fields and the four activation modes

A realistic rule set

Practical rules

Windsurf: Rules & Memories (Cascade)

Rule storage locations

Activation modes

Example: global_rules.md

Example: workspace rule, glob-scoped

XML-tag style (Windsurf's alternate, model-friendly format)

Practical rules

Claude Code: CLAUDE.md + Hooks

CLAUDE.md hierarchy

Example CLAUDE.md

The @import syntax

Hooks: deterministic quality gates

Example: block edits to .env and force-pushes

Example: auto-format and auto-test after every edit

Side-by-side comparison

One rule set, three formats — a worked example

Keeping rules in sync across tools

Ruler (@intellectronica/ruler)

Lighter alternatives

Hooks as a real quality gate

Common mistakes

Cheat sheet

FAQ

Apple Just Confirmed Claude Is Coming to Your iPhone — Here's What WWDC 2026 Actually Changes

What Siri AI actually does differently

The part everyone in the AI world actually cares about: choice

There's a developer story here too

What's confirmed vs. what's still a rumor wearing a confirmed-fact costume

What to actually do right now

Why this matters beyond Apple

Further reading

Securing a VPS in 2026: A No-Nonsense Hardening Guide

Tier 1 — Before Anything Touches Production

1. Non-Root User + SSH Key Auth

2. Harden sshd_config

3. Firewall: Default Deny

4. Automatic Security Patching

5. Backups — Set Up Before You Need Them

Tier 2 — Within the First Week

6. Intrusion Banning: Fail2Ban (+ CrowdSec if you're scaling)

7. Kernel Network Hardening

8. File Permissions & Mandatory Access Control

9. Full-Disk Encryption (LUKS)

10. Database Hardening

Tier 3 — If It Applies to Your Stack

11. TLS: Get an A+ Without Guessing

12. SSH at Scale: Certificates and TOTP 2FA

13. Docker Container Security

14. Systemd Sandboxing for Non-Containerized Services

Tier 4 — Ongoing, Forever

15. Logging, Auditing, and Rootkit Checks

16. Maintenance Cadence

Quick Checklist

I Built a Tiny AI Agent From Scratch — Every Line Tested Before It Touched a Real API

What an "agent" actually is, stripped of the hype

What you'll need

Step 1: Write the actual tools (just functions)

Step 2: The agent loop

Step 3: Test the loop before it ever calls the real API

Step 4: Run it for real

What's actually happening, step by step

Things to watch out for as you extend this

Cursor: Project Rules (`.mdc`)

The `.mdc` format

Example: `global_rules.md`

Claude Code: `CLAUDE.md` + Hooks

`CLAUDE.md` hierarchy

Example `CLAUDE.md`

The `@import` syntax

Example: block edits to `.env` and force-pushes

Ruler (`@intellectronica/ruler`)