DEV Community: pickuma

Woodpecker vs Lemlist vs Instantly: Cold Email Tools That Still Land in 2026

pickuma — Tue, 12 May 2026 09:53:30 +0000

The Deliverability Reset

In early 2024, Google and Yahoo rolled out new sender requirements that quietly killed half the cold email playbook everyone was running. SPF, DKIM, and DMARC became table stakes. Spam complaint rates above 0.3% started costing entire domains. One-click unsubscribe became mandatory for senders moving over 5,000 messages a day.

The tools that survived this transition aren't the ones with the prettiest editors — they're the ones that take inbox placement seriously. Warm-up isn't a feature anymore, it's a requirement. Inbox rotation matters more than personalization tokens.

We ran a comparison across three platforms still standing: Woodpecker, Lemlist, and Instantly. All three claim "cold email that lands." Here's how they actually compare for a small B2B SaaS team doing 500–5,000 outbound sends a month.

Headline Comparison

Where Woodpecker Pulls Ahead

1. Deliverability infrastructure that compounds

Woodpecker's warm-up runs on Mailivery — a dedicated deliverability network that's been around since before the 2024 reset. The warm-up isn't a checkbox feature; it's actively sending and replying to real conversations across the network, building sender reputation over weeks rather than days. Combined with their domain auditing tools (SPF/DKIM/DMARC pre-flight checks), it's the closest thing we've seen to "deliverability-as-a-service" on the SMB tier.

Inbox rotation is the second half of this. When you're sending more than ~30 messages a day per inbox, Google flags pattern velocity. Woodpecker distributes sends across multiple connected mailboxes automatically — so 5 mailboxes can handle 150 sends/day without any single account tripping reputation thresholds.

2. The agency panel is genuinely useful

If you're a founder who occasionally helps other founders with outbound, or a small agency taking on 3–10 clients, Woodpecker's agency panel lets you manage all of them from one login. Lemlist has something similar; Instantly's version is rougher. The differentiator is the per-client billing pass-through — agencies can mark up the platform fee to clients cleanly.

3. A real developer surface

This is the surprise. Woodpecker ships a REST API, webhooks, and an MCP server — meaning you can wire it into your AI agent stack directly. For SaaS founders who already have a working agentic prospect-research pipeline, the MCP integration is a quiet differentiator. Lemlist and Instantly both have APIs but lack the same developer-facing surface area.

Most cold email tools assume a human-in-the-loop workflow: human picks leads, drafts sequences, reviews replies. If you've built (or are building) an AI agent that researches prospects, drafts personalized openers, and routes replies, an MCP server means your agent can talk to Woodpecker directly without OAuth dance or API wrapper. This is a quiet edge case today; in 12 months it'll be the default expectation.

Where Lemlist Still Wins

Multi-channel from day one. Lemlist's native LinkedIn + email + voice-note sequences are the most polished of the three. If your prospects respond to LinkedIn before email (founders, executive titles), Lemlist's threading is worth the price premium.
Personalization at scale. Image personalization, video personalization, dynamic landing pages. Most of this is gimmicky, but for high-value enterprise outreach where reply rates of 2% matter, it's measurable.

Where Instantly Still Wins

Unlimited warm-up. Instantly bundles unlimited warm-up across unlimited inboxes on most plans. If you're running an agency model with 20+ client mailboxes, the per-inbox warm-up cost on Woodpecker adds up. Instantly's flat pricing is cleaner at scale.
High-volume senders. Instantly is built for teams sending 10,000+ messages/day. Their platform handles velocity better than the others. If you're at SMB scale, this doesn't matter; if you're at sales agency scale, it does.

A Pricing Reality Check

For a 2-person SaaS doing ~1,500 cold sends/month across 3 connected mailboxes:

Woodpecker Cold Email (Starter): ~$39/mo for 1 user, 3 slots. Warm-up included.
Lemlist Standard: ~$59/mo for similar setup. Multi-channel included.
Instantly Hypergrowth: ~$97/mo, unlimited inboxes + unlimited warm-up.

The pricing inverts depending on how many inboxes you connect:

1–3 inboxes: Woodpecker is cheapest.
5+ inboxes: Instantly's unlimited model wins.
Anywhere with LinkedIn: Lemlist's multi-channel pays for itself if you actually use LinkedIn.

All three platforms strongly recommend (or sell) secondary domains for cold sending — burning your main domain on cold reputation is a one-way street. Budget $10–20/month per secondary domain (registrar + Google Workspace seat or alternative). For 5 inboxes, that's $50–100/month on top of the platform fee. Most reviews skip this.

How to Decide in 5 Minutes

1. Are you sending more than 5,000 cold emails per month?

Yes → Instantly's unlimited model probably wins on cost.
No → continue.

2. Is LinkedIn outreach a core part of your motion?

Yes → Lemlist. The native multi-channel threading is the best in class.
No → continue.

3. Do you have (or want to build) an AI agent that automates prospect research?

Yes → Woodpecker. The MCP server is a real edge.
No → Woodpecker on price, but Lemlist is fine if you'll grow into LinkedIn.

For most SMB SaaS founders at the 500–3,000 sends/month range with no LinkedIn play, Woodpecker is the default answer.

What We'd Test in the Trial

Woodpecker offers a 7-day free trial. We'd push hard on:

The warm-up itself. Connect a brand-new domain, start the warm-up, and use a tool like GlockApps or MailReach to test inbox placement after 7 days. The improvement curve is the real signal.
The inbox rotation logic. Connect 3 mailboxes, set a daily send cap of 50/inbox, and verify the platform actually distributes evenly without manual intervention.
The MCP server. If you have an existing agent stack, wire it up. Test creating a campaign, adding leads, and pulling reply data through the MCP interface.
The reply detection. Cold email tools live or die by how well they detect replies vs auto-responders vs out-of-office. Send a handful of test messages from various email providers and trigger each response type.
Domain audit reports. Run their domain audit on your existing setup. The findings should match what tools like MXToolbox report.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

OpenAI Codex vs Claude Code: Hands-On Python Benchmark for Devs

pickuma — Tue, 12 May 2026 09:52:14 +0000

OpenAI relaunched Codex this year as a full agentic CLI that lives in your terminal and talks to GPT-5 class models. Claude Code did the same thing for Anthropic, six months earlier. Both want to be the assistant you actually merge code from. We pointed both at the same Python project and tracked what each one shipped.

The codebase under test: a mid-sized Flask + SQLAlchemy service with a real pytest suite and a handful of slow, gnarly modules begging to be refactored. We ran identical prompts through both tools, on the same hardware, against the same git SHA, and rewound the worktree between runs so neither tool saw the other's edits.

How we structured the test

We ran three kinds of tasks against each assistant, three trials per task per tool. Not enough trials for statistical certainty, but enough to catch behavior patterns that held across attempts.

Task A: refactor a roughly 400-line module that mixed request handling, DB access, and template rendering into a service layer plus thin route handlers. Success criteria: tests still green, no regressions in a smoke flow we recorded with httpx, and the resulting file structure passing ruff and mypy --strict cleanly.

Task B: fix three known bugs. One off-by-one in a pagination helper. One race condition in a background worker that only surfaced under concurrent load. One Unicode normalization bug in a search endpoint. We handed each assistant only the failing pytest output and the file path, with no hints about the fix.

Task C: an agentic workflow. "Add OpenTelemetry tracing across the request lifecycle, including DB spans, then write tests proving spans are emitted." Open-ended, multi-file, requires reading the codebase before doing anything.

We tracked wall-clock time, total tokens consumed, whether the diff merged cleanly, and whether the test suite stayed green at the end.

Where each tool diverged

Claude Code finished Task A in roughly four minutes per trial. The service-layer extraction was clean: it picked up the project's existing repository pattern from a sibling module without prompting and matched the naming convention. Two of three trials passed the smoke test on first run. The third introduced a circular import that Claude caught on its own follow-up turn and fixed without us asking.

Codex took longer on Task A, closer to seven minutes per trial, but produced a more aggressive refactor. It split logic into more files, added type hints throughout, and rewrote one helper function that wasn't part of the brief. The diff was larger, the tests still passed, but the review surface went up. One trial dropped a transactional boundary we wanted preserved; the test suite caught it, Codex fixed it on the next iteration.

Task B was the more revealing split. Claude found the off-by-one in under two minutes with a one-line fix and an added test. Codex took longer on the same bug, wrote a longer explanation, and added two tests where one would have done — the second was redundant with the first.

On the race condition, Claude wrote a regression test using threading.Barrier to reliably reproduce the bug, then patched it with a context manager around the critical section. Codex initially proposed a time.sleep-based test that we rejected. On retry it produced a cleaner fix using an asyncio lock. Both eventually solved it. Claude shipped a clean version the first time.

The Unicode bug was effectively a tie. Both correctly identified that unicodedata.normalize("NFKC", ...) was the right answer and produced near-identical diffs.

Neither tool reliably caught subtle business-logic intent that wasn't expressed in tests or comments. On a fourth task we ran informally, both happily "fixed" a behavior that was actually load-bearing for an undocumented downstream consumer. Treat agentic assistants as fast pair programmers, not autonomous engineers, until your codebase has the test coverage to keep them honest.

Agentic workflows, pricing, and the speed-vs-cost tradeoff

Task C was where the agentic loops stretched their legs. Claude averaged a little over ten minutes wall-clock per run and burned through hundreds of thousands of tokens. Codex was meaningfully slower and more token-hungry on the same task — call it about a third more on both axes. Both produced working tracing setups with DB spans and tests that checked emitted span names against a recording exporter.

Codex's solution was more thorough. It wired up OTLPSpanExporter with environment-variable config, added a pyproject.toml extra so the dependency was opt-in, and dropped a fresh docs/observability.md into the repo. Claude's solution was tighter: it hooked into the existing Flask middleware, added one fixture, and stopped. If you want a starting point you will extend yourself, Claude got there faster. If you want a near-complete drop-in, Codex did more of the work — at higher cost.

Pricing during our test window: Claude Code running on Sonnet was the cheaper option per task by a clear margin. Codex on GPT-5 was higher both per call and in tokens consumed. Both Anthropic and OpenAI shifted prices during our window. Check current rates before extrapolating — order-of-magnitude conclusions are stable, but the gap may narrow or widen between when we tested and when you read this.

The speed difference was consistent across trials: Claude was faster on most tasks we threw at it, sometimes by a wide margin on small fixes. Codex was more methodical, which costs you wall-clock time and tokens but occasionally catches things Claude skips.

When to pick which

Pick Claude Code when you're doing focused work — a single bug, a contained refactor, a feature that touches three files. The speed advantage compounds when you're iterating, and the cost difference adds up across a workday.

Pick Codex when you want broader autonomy and don't mind a longer wall-clock loop. Big migrations, codebase-wide instrumentation, tasks where you would rather review a thorough proposal than steer one. Codex is also the better pick if you already pay for a ChatGPT Team or Enterprise seat that bundles Codex usage.

Both tools changed our review workflow more than they changed our writing workflow. We spent less time typing and more time reading diffs. That is the benchmark that matters more than tokens or seconds: not who produces code faster, but who produces code you trust enough to merge without re-reading every line.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

Mythos AI Found a Real Curl Vulnerability — What It Signals for Security Audits

pickuma — Tue, 12 May 2026 09:45:53 +0000

Curl has been the workhorse of HTTP for nearly three decades. It ships in roughly every Linux distribution, every macOS install, most embedded devices, and the dependency graph of half the internet. The codebase has survived years of human review, static analyzers, fuzzers, and bounty hunters. So when Daniel Stenberg, curl's longtime maintainer, posted on May 11, 2026 that an AI tool called Mythos surfaced a real vulnerability in the project, it landed differently than the usual "AI found a bug" headline.

This wasn't a synthetic benchmark on a toy program. It was production code that thousands of security researchers had already crawled over.

What Mythos found and why it matters

The detail that makes Stenberg's post worth reading is the type of finding. Mythos didn't flag a textbook buffer overflow or a one-liner where someone forgot to check a return value. It identified a defect that required reasoning across the surrounding control flow — the kind of bug that historically needed a human to sit with the code, build a mental model, and notice the subtle interaction.

For years, AI-assisted security tools have been stuck in two modes:

Pattern matchers that essentially rebrand grep. They catch low-hanging issues, generate noise, and miss anything that requires understanding intent.
LLM wrappers that summarize diffs in plain English but can't tell you whether the change is safe.

Mythos is being positioned as something different: a system that reasons about code the way a senior reviewer does, traces data flow across function boundaries, and produces findings specific enough to triage. The curl result is the first public proof point that this category can produce a non-trivial finding in a heavily audited target.

We're being careful with the framing here. One vulnerability, in one project, surfaced by one tool, does not prove "AI has solved security review." But the bar for a credible result in this space has been low for a long time, and Mythos cleared it on a target where the noise floor is very high.

The curl codebase already runs through OSS-Fuzz, Coverity, Clang's static analyzer, and dozens of human eyes per release cycle. Finding a real bug in this environment is meaningfully different from finding bugs in random GitHub repositories that have never been audited.

What this changes for your team

If you ship code, the practical question is whether AI security review now belongs in your pipeline alongside static analysis and dependency scanning. The answer depends on what you're doing today.

If your current security workflow is:

Dependabot or Renovate for dependency CVEs
A SAST tool (Semgrep, CodeQL, Snyk Code) running in CI
Occasional pentesting before major releases

Then AI-assisted review is best treated as a fourth layer, not a replacement. Static analyzers catch a different class of bugs efficiently and cheaply. LLM-based reviewers catch a different class — the ones requiring narrative reasoning about what the code is supposed to do — but at higher latency and higher cost per scan.

The migration pattern teams are converging on:

Run LLM-based review on changed code only (diff-scoped), not the entire repository
Trigger on pull requests that touch security-sensitive paths: auth, crypto, parsers, anywhere external input crosses a trust boundary
Treat findings as hypotheses for a human to confirm, not as gating signals
Track false positive rate per tool over a quarter before adjusting trust

Cost discipline matters more than people admit. Running a frontier-model code review on every PR in a busy monorepo can run into thousands of dollars per month before you've shipped any real coverage. Scoping prevents the bill from outpacing the value.

The supply-chain angle

The deeper story isn't curl's specific vulnerability — it's the asymmetry that Mythos's success implies. Attackers and defenders both now have AI tools that can reason about code. Whichever side scales the workflow first gets the structural advantage.

Two scenarios are worth thinking through.

Scenario A: defenders win the race. Major OSS projects integrate continuous AI review. Vulnerabilities get found earlier, by tools the maintainers control, before public disclosure. The bug count per project might go up in the short term, but mean time to discovery drops. Downstream users benefit.

Scenario B: attackers win the race. State-level and organized criminal groups deploy similar tooling against the same OSS targets, quietly. They build inventories of zero-days in widely deployed dependencies. The first sign anything is wrong is a coordinated incident months later.

The good news is that the cost curve favors defenders. Maintainers can run review on a known target with full source access. Attackers have to run it on the same code, then weaponize the finding, then deploy without detection. The work asymmetry is real.

The bad news is that the adoption curve favors attackers. They don't have to convince a security team to provision a budget line item. They just point a tool at curl and wait.

If you maintain or depend on a critical open-source library — anything in your top 20 dependencies — assume someone with adversarial intent is already running AI review against it. The question is whether you are too.

How to evaluate AI security tools without getting sold

The market will flood with "AI security audit" products over the next year. Most will be repackaged GPT calls with a security-themed system prompt. A few will be substantially better. Here's what we look for:

Reproducibility. Can the tool find the same class of bug twice on adjacent code? Run it on a project you know well and check whether findings are stable across runs.
Specificity. Generic findings like "possible injection vulnerability" are useless. A finding should point to a specific line, name the unsafe input, and describe the trust boundary crossed.
False positive discipline. Ask vendors for their precision rate on a public benchmark, not their recall. Recall is easy. Precision is hard, and precision is what determines whether your team will actually triage findings or learn to ignore them.
Transparency on cost. A tool that won't tell you per-scan token cost is hiding something. Pricing models that bill per repository regardless of size usually subsidize small teams at the expense of larger ones, or vice versa — know which side of that math you're on.

The curl result is signal that this category can be real. It is not yet signal that every tool claiming AI security review is real. Mythos has one public proof point; most competitors have zero.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

Cursor vs VS Code: We Ran Both for 30 Days

pickuma — Tue, 12 May 2026 09:44:37 +0000

Why we did this

We're publishing weekly reviews of AI dev tools. Cursor is the most-asked-about one, so
we ran both editors in parallel for a real month.

All screenshots and timings come from our daily logs. No vendor briefings, no
affiliate-driven cherry-picking.

Headline numbers

The cases where Cursor pulled away

When refactoring across 4+ files, Cursor's chat-driven multi-file edit reduced our
sequence of operations from ~12 steps to 3.

// Before: open file, find usage, edit, save, repeat...
// After:
// "Rename `getUser` to `getCurrentUser` across the repo, update callers"

Cursor lets you plug in your own Anthropic / OpenAI key — useful if you already
have a budget.

Where VS Code still wins

Cold-start memory, plugin ecosystem (Copilot is no longer Cursor-only), and the
sheer reach of "VS Code Server in a browser" for remote/dev container work.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

Claude as a User-Space IP Stack: What an ICMP Ping Benchmark Reveals About LLM Latency

pickuma — Tue, 12 May 2026 09:38:16 +0000

Adam Dunkels — the engineer behind uIP and lwIP, the embedded TCP/IP stacks that ship in millions of devices — recently asked a deliberately absurd question: what if the IP stack itself were a language model? His experiment wires Claude into user space, hands it raw packets, and asks it to respond to ICMP echo requests like any other host on the network.

The setup is whimsical. The latency numbers are not. Once you stop laughing at the idea of pinging an LLM, the benchmark becomes one of the more honest stress tests we have for agentic Claude API workflows.

The Experiment: Routing ICMP Through a Language Model

Dunkels' rig hands Claude the bytes of an inbound ICMP echo request and asks it to produce the bytes of the correct ICMP echo reply. There is no clever pre-processing. The model has to understand the IP header, swap source and destination addresses, recalculate the checksum, and emit a well-formed response packet.

The reason this works at all is that the protocol is small, deterministic, and famously documented. The reason it is slow is that every hop through the stack now includes a Claude API roundtrip — a TLS handshake (or pooled connection), token generation, and a response back to user space.

A kernel-resident IP stack answers a ping in tens to hundreds of microseconds. A round trip on a residential network is typically 10–40 milliseconds. Claude, as a user-space IP stack, lives several orders of magnitude further out. That gap is the entire point.

The experiment is not a serious networking proposal. It is a forcing function: if you can describe what an IP stack does, you can measure how far away from that an LLM is. The number you get back is a hard floor on any system that puts a Claude call in its critical path.

Why Latency Matters: Where Agentic Loops Actually Break

If you build with the Claude API, you already know the model is not instant. But the ping benchmark is useful because it strips the workload down to almost nothing — a few dozen bytes in, a few dozen bytes out — and the latency is still dominated by inference, not network or compute.

That has practical consequences for how you design agents:

Tool-use loops compound. An agent that takes ten round trips to plan, call a tool, observe, and replan is multiplying a per-call latency that already starts in the hundreds of milliseconds. The ping floor tells you what the cheapest possible step costs.
Streaming hides nothing on the first token. Time-to-first-token still gates any interaction that needs a complete response before the next step. Ping responses are short enough that TTFT and full-response latency converge — exactly the regime most tool calls live in.
Per-request variance is real. Anyone who has run a Claude API workload at scale has seen p50 and p99 diverge sharply under load. A ping benchmark surfaces that variance honestly, because the workload is otherwise constant.

We ran our own back-of-the-envelope on what this means for agent design: if a thinking step in a multi-step agent costs roughly one Claude-ping worth of latency, then a ten-step plan is already in the multi-second range before you account for tool execution, retries, or rate limits. That is fine for an editor companion. It is painful for anything in front of a user clicking a button.

Do not put a Claude call inside a request path that needs sub-second p99 latency without a fallback. The ping experiment is the cleanest demonstration we have that LLM inference, even on minimal inputs, is not a substitute for deterministic code.

Practical Lessons for Building With the Claude API

The Dunkels experiment is fun. The lessons are boring, and that is the point. If you read the benchmark and walk away with three rules, you have extracted most of the value:

Use the LLM at the right altitude. Do not ask Claude to do what memcpy and a checksum routine already do. Ask it to do what a deterministic function cannot: interpret intent, summarize, decide between options, or write code that runs later.
Budget latency before you build the agent. Multiply your worst-case step latency by your expected step count. If the product is more than your user will tolerate, redesign before you write the prompts.
Cache aggressively at the prompt boundary. Prompt caching is the single biggest lever for cutting per-step latency on repeated workloads — and the ping benchmark is implicitly an uncached workload, which is why the floor looks the way it does.

The takeaway is not that Claude is slow. It is that Claude is a particular shape of fast — fast at language, slow at bytes — and the systems you build need to respect that shape.

When LLM-in-the-Loop Networking Actually Makes Sense

There is a serious version of this experiment buried inside the joke. LLMs in the network stack are absurd at the ICMP layer. They are interesting at the policy layer — deciding what to do with a flagged packet, summarizing a flow record, deciding whether a request looks like abuse. Anywhere the work is read this, decide that, the latency cost of a Claude call competes against the human or the rule engine you would otherwise reach for, not against a kernel routine.

The ping benchmark sets the lower bound. Your job, as a developer building on the Claude API, is to keep the work above that bound — and to make sure the latency you pay buys you something a regex could not.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

Best Free Tiers for Developers in 2026: SaaS, PaaS & IaaS Tools

pickuma — Tue, 12 May 2026 09:37:00 +0000

The free-tier landscape shifted hard between 2023 and 2026. Heroku killed its free dynos in November 2022, PlanetScale dropped its Hobby plan in early 2024, and Fly.io quietly replaced its always-free allowance with a $5 monthly credit. A lot of "free tier" advice from older blog posts now points at services that will charge you the moment your card is on file.

We rebuilt our reference list from scratch in 2026, cross-checking the free-for-dev community catalog against each provider's current pricing page. What survived is genuinely useful for side projects, MVPs, and learning — as long as you know where the cliffs are.

Hosting, Edge, and Compute

For a typical Node, Next, or Astro side project, three platforms still cover almost everything for $0:

Vercel Hobby — 100 GB bandwidth, unlimited static requests, 1 million Edge Function invocations, 100 deployments per day. Personal use only; commercial work requires Pro at $20/month per seat.
Netlify Free — 100 GB bandwidth, 300 build minutes, 125k serverless function invocations. No commercial-use restriction, which makes it the safer default for a portfolio site that runs ads or affiliate links.
Cloudflare Pages + Workers — unlimited bandwidth, 500 builds per month, 100k Worker requests per day on the free Workers plan. The bandwidth ceiling is the headline: a Hacker News spike won't bankrupt you the way it might on a metered platform.

For long-running processes (Discord bots, queue workers, websockets), the picture is grimmer. Fly.io now bills from the first minute beyond the $5 credit, Railway ended its hobby-free plan in 2023, and Render's free web service spins down after 15 minutes of inactivity with a 30+ second cold start. If you need a 24/7 process, an Oracle Cloud Always Free Arm VM (4 vCPU, 24 GB RAM split across instances) remains the most generous offer on the market — assuming you can stomach Oracle's account verification flow.

"Free" almost never means "unmetered." Most platforms suspend or rate-limit your service when you cross a soft cap; a few will silently start billing once you've added a card. Set a hard spend limit on every account, and treat free tiers as throughput allowances, not guarantees.

Databases, Auth, and Backend Services

Managed Postgres is where the free-tier market has gotten genuinely good:

Supabase Free — 500 MB database, 1 GB file storage, 50k monthly active auth users, two projects. Inactive projects pause after seven days, which trips up demos but is one click to wake up.
Neon Free — 0.5 GB storage per branch, autoscaling compute that scales to zero, full branching included. Scale-to-zero means a ~500 ms cold start on the first query after idle, but you pay nothing while the database sleeps.
Turso Free — 9 GB total storage across up to 500 databases, 1 billion row reads per month. Useful when you want SQLite-per-tenant rather than one shared Postgres.

For caching and queues, Upstash gives you 10,000 Redis commands per day and a generous QStash allowance on the free plan, billed per request rather than per hour. MongoDB Atlas still offers a 512 MB shared M0 cluster — enough for a CRUD prototype but tight for anything with serious indexes.

Auth has gotten cheaper too. Supabase Auth (bundled with the database tier), Clerk's free plan (10k MAU), and Auth0's free plan (25k MAU after their 2024 expansion) all cover the realistic user count of a pre-launch product. Pick on developer experience, not on price.

CI/CD, Monitoring, and AI APIs

GitHub Actions remains the default and the most generous: 2,000 minutes per month on private repos, unlimited on public repos, with Linux runners free. For larger matrices, Buildjet and BuildKite both offer free hobbyist tiers that beat Actions on raw CPU per minute.

For observability, the situation is mixed:

Sentry Free — 5,000 errors, 10k performance events, 50 session replays per month, single user. Hits the free cap fast on any real traffic.
Grafana Cloud Free — 10k Prometheus metric series, 50 GB logs, 50 GB traces, 14-day retention. The most generous free observability stack on the market right now.
Better Stack Free — 10 monitors, 3-month log retention, 30-second checks. Better starting point than UptimeRobot if you also want logs alongside uptime checks.

AI APIs are the toughest category. OpenAI removed new-account free credits in 2024. Anthropic offers limited trial credits on signup that vary by region. Google's Gemini API has a free tier with strict per-minute rate limits. Groq's free tier is the standout for low-latency Llama and Mixtral inference — generous request quotas, no card required at signup.

When the Free Plan Stops Making Sense

The cost of staying free is usually invisible until something breaks. We watched a project sit on Supabase Free for nine months, then lose two days debugging a paused-database connection error after a long weekend. The fix was a $25/month upgrade that should have happened at month three.

A few signals that you've outgrown the free tier:

You're architecting around quotas (batching writes, caching aggressively) instead of around your product.
You can't share the project with a teammate because the free plan is single-user.
You're spending more than an hour per month working around platform limits.
Your project is generating any revenue at all — most "personal use" free tiers prohibit commercial workloads.

The honest math: a typical indie project on Vercel Pro ($20), Supabase Pro ($25), and Sentry Team ($26) runs $71/month. That's less than one hour of contractor time. If your project clears that bar in value or revenue, paying is the cheaper option, not the more expensive one.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

Why Local AI Should Be the Default for Developers in 2026

pickuma — Tue, 12 May 2026 09:30:38 +0000

Two years ago, running a useful model on your laptop meant 7B parameters of slow, hallucination-prone output. The math has changed. Llama 3.1 8B, Qwen 2.5, and Mistral Small now handle the same tier of tasks GPT-3.5 did in early 2023 — and they run on a MacBook Air with 16GB of RAM at usable speeds. The 70B-class models fit comfortably on a single high-end consumer GPU or an M-series Mac with 64GB+ unified memory, and they land somewhere between GPT-4-class and mid-tier Claude on most public benchmarks.

This matters for one practical reason: "good enough" is no longer cloud-only.

The Gap Closed Faster Than Anyone Expected

If you spend $20-200/month on API calls for autocomplete, doc summarization, commit message generation, or local search, that budget now buys you something the local stack can approximate. A one-time hardware investment — or your existing laptop — replaces a recurring metered bill.

The model-quality curve helps too. Open-weights releases used to lag the frontier by 18-24 months. That gap is now closer to 6-9 months for general reasoning tasks, and effectively zero for narrow jobs like code completion, classification, and summarization, where dedicated fine-tunes outperform general-purpose hosted models on the specific task.

The tooling caught up at the same time:

Ollama turned model installation into a single command and exposes an OpenAI-compatible API on localhost.
LM Studio added a GUI with one-click model switching and the same compatibility surface.
llama.cpp — what both of the above wrap — keeps shipping quantization improvements that let larger models fit in less RAM with minimal quality loss.

A workflow that used to require a Python virtualenv, CUDA gymnastics, and a Hugging Face account is now a brew install.

Privacy, Latency, Cost — the Three Concrete Wins

Three advantages, in the order they tend to bite:

Latency. A local 7B model on Apple Silicon produces tokens faster than a network round-trip to a hosted provider's nearest data center for most users. For interactive tooling — autocomplete, inline chat, agentic loops with many small calls — that 100-300ms cloud overhead compounds across every interaction. Local cuts time-to-first-token to single-digit milliseconds once the model is warm.

Cost predictability. Cloud pricing changes. Anthropic, OpenAI, and Google have all raised, lowered, and restructured pricing tiers multiple times. Local cost is what your electricity bill says: pennies per hour of active inference, zero per request after the up-front compute.

Privacy by default. Every line of code you send to a hosted model leaves your machine. For personal projects, fine. For client work, regulated industries, or anything under NDA, the calculus is different. Even with "we don't train on your data" assurances, the data still crosses the wire, sits in logs, and traverses a third party's infrastructure. Local inference moves that boundary back to your hardware. Your prompts never leave the loopback interface.

Local doesn't mean offline-only. Most real workflows benefit from a hybrid: local for routine work (autocomplete, refactoring, log parsing, commit messages), hosted for the edge cases (long-context analysis, specialized vision models, agentic chains that need top-tier reasoning). Route by capability, not by reflex.

What Local Still Can't Do

This is the honest part. Local AI isn't a drop-in replacement for the frontier:

Long context. Local models advertise 8K-128K context windows depending on architecture, but the practical sweet spot is 16-32K before quality degrades and memory pressure spikes. Claude and Gemini handle 200K-2M+ tokens with quality that holds.
Agentic reliability. Multi-step tool use, especially with strict JSON output and many chained calls, still favors GPT-4-class hosted models. Open-weights are catching up — Qwen 2.5 and Llama 3.3 are notable — but production agents that chain 20+ tool calls still benefit from the frontier.
Specialized capabilities. Top-tier vision, audio, and codebase-wide reasoning lean on training infrastructure no laptop replicates.

The right framing isn't "replace cloud." It's "use the cheapest tool that works." Most calls are routine. Most routine calls work locally.

A Setup You Can Run This Weekend

If you want to test the case yourself rather than take it on faith:

Install Ollama. Single binary. brew install ollama on macOS, one-line installer on Linux. Run ollama pull llama3.1:8b to get a baseline general-purpose model.
Add LM Studio if you want a UI. Same GGUF format models, built-in OpenAI-compatible server. Any tool that talks to api.openai.com/v1 can be repointed at localhost:1234 with one env var change.
Drop to llama.cpp for control. Ollama and LM Studio are wrappers. Native llama.cpp exposes finer quantization choices and bleeding-edge model support.
Pick three real tasks. Commit messages, log summarization, and code completion are reasonable starters. Run them through your local stack for a week. Track which outputs you actually ship versus which ones you have to rewrite.

The honest answer at the end of that week is usually that 60-80% of routine AI work stays local, while the frontier 20% goes back to the API. That's a sensible architecture, not a compromise — and it's the pattern most of the interesting AI dev tools shipping in 2026 are converging on.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

Why Developers Are Quietly Turning Off Copilot and Cursor

pickuma — Tue, 12 May 2026 09:29:23 +0000

The Quiet Reversal

A pattern keeps surfacing in Hacker News threads, Lobsters comments, and dev Mastodon: experienced developers turning Copilot off. Not for a podcast take, not as a Luddite stunt — for the work that actually requires understanding. The k10s.dev post that lit up HN this month was the latest, but it joins a year of similar reversals from people who use these tools daily and ship code for a living.

The framing matters. This isn't "AI bad." It's "I noticed I got worse at my job, and I want to figure out why."

What the measurements actually show

The Model Evaluation and Threat Research group ran a randomized trial in July 2025 with 16 experienced open-source maintainers working on their own repositories. They sampled 246 real tasks and let the developers use Cursor Pro with frontier models on half of them.

Before starting, the developers predicted AI would make them 24% faster. After finishing, they self-reported being 20% faster. The actual measured time told a different story: they were 19% slower.

Sixteen developers is a small sample. The result still matters because it captures something honest power-users notice eventually: the speedup you feel is not the speedup you ship. METR's debrief points at context-rebuilding overhead. The model generates plausible code; you spend the savings re-reading it, fixing subtle drift, and unwinding design decisions you wouldn't have made yourself.

A separate Microsoft and Carnegie Mellon paper from early 2025 surveyed 319 knowledge workers across 936 GenAI use cases. The finding most relevant to coding: higher confidence in the AI correlated with less critical thinking effort. Higher confidence in yourself correlated with more. The authors call this cognitive offloading — outsourcing the judgment work along with the typing work. For code, the judgment work is most of the job.

Stack Overflow's 2024 Developer Survey is the third data point. Roughly 76% of respondents were using or planning to use AI tools in their development process. Only about 43% said they trusted the accuracy. The gap between adoption and trust is the part nobody puts on a vendor slide.

Watch the gap between perceived speed and measured speed. The METR developers thought they were 20% faster while shipping 19% slower. Self-reports of AI productivity are not evidence. Before you commit to a tool full-time, time a few similar tasks with it off and on.

When hand-coding actually wins

Across the HN threads and lobste.rs discussions on this topic, four scenarios show up repeatedly where developers report hand-coding produces better outcomes:

Learning a new language or framework. The retrieval-practice effect is one of the most replicated findings in cognitive science: you retain what you struggle to recall, not what you read. Tab-completing your way through a Rust tutorial gives you the same illusion of competence as highlighting a textbook. Two weeks later, you can't write the borrow-checker pattern from memory because you never built the recall pathway.

Debugging code you wrote with assistance. This is the sharp edge. Bugs in AI-generated code aren't usually syntax errors — they're "I don't actually know what this function does" errors. If you didn't build the mental model when the code went in, you have to build it now, under pressure, while the bug is live. The time you saved typing gets refunded with interest.

Designing data models and module boundaries. AI tools default to plausible-looking patterns from training data. They will happily generate a schema that works and is wrong for your system. The choices here compound for years. Hand-thinking, on paper if necessary, is how senior engineers earn their seniority.

Writing code in a domain you intend to own. If you're the person who will maintain this module for the next two years, the up-front investment in understanding every line pays back constantly. If it's a one-off script you'll delete next week, the calculus inverts.

A pragmatic middle path

The developers who've thought about this longest don't quit AI tools — they segment them. The pattern that keeps appearing:

AI on for boilerplate, scaffolding, well-defined transforms, and shell one-liners. You're not learning anything from writing the 400th useState hook by hand.
AI off for design work, learning, debugging, and any code where "I understand exactly what this does" is a hard requirement.
AI inverted for tests: write the test by hand, let the model write the implementation, then read that implementation as if you were reviewing a junior's PR.

The hidden variable is metacognition — knowing what you don't know. The Microsoft study found that workers with weaker self-confidence offloaded the most, which is exactly backwards from what you'd want. Junior developers, who most need to build understanding, are the most likely to delegate it away. The fix isn't moralizing; it's structural. Keep a running log of what you would have had to look up if the AI weren't there. That log is a map of the skills atrophying.

What this means for your week

You don't need to delete Cursor to fix this. You need to notice when you've stopped thinking. Three concrete moves:

Time one feature this week with the AI off. Not a toy project — real work. Compare against your last similar feature.
Pick one area where you want depth (a language, a subsystem, a paradigm) and declare it AI-off. Treat it the way you'd treat a piano practice room.
Audit the last week of accepted suggestions. For each non-trivial one, can you explain why that code is correct? The ones where you can't are the debt.

The developers writing these "I'm going back" posts aren't nostalgic. They're calibrating. The question isn't whether AI tools are useful — they obviously are. It's whether the version of you that uses them every minute is the version of you that you want to be in five years.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

OpenAI Codex Chrome Extension: Browser-Native AI Coding Agent Tested

pickuma — Tue, 12 May 2026 09:23:01 +0000

OpenAI shipped a Codex Chrome extension that puts its coding agent inside the browser tab you already have open. Instead of copying a stack trace into ChatGPT or alt-tabbing to a desktop IDE, you trigger Codex on the page itself — the bug report, the staging site, the API docs you're reading.

The pitch is simple. Developers spend a meaningful share of their day in Chrome (Linear tickets, GitHub PRs, Stripe dashboards, Vercel logs, internal admin panels), and most of those surfaces produce code, configuration, or text that has to get pasted somewhere else. Moving the agent into the page collapses the loop.

That sounds obvious until you actually try it. The interesting questions are about scope, latency, and trust — not novelty.

What Codex in Chrome actually changes

The extension exposes Codex against the active tab's DOM and your selection. You can ask it to explain an error visible on the page, draft a reply to a GitHub PR comment, scaffold a fetch call from an API doc, or convert a JSON blob you're staring at into a typed TypeScript interface. The agent reads what you're looking at, so the prompt overhead drops to "fix this" or "rewrite this in Python."

A few things follow from that design:

Context is whatever Chrome can see. That includes rendered text, your selection, and form values. It does not include your local filesystem, your IDE state, or your terminal history. The agent is good at the part of your work that lives behind a URL.
The output lives next to the input. You don't paste into a chat window and paste back. The extension injects results inline or sends them straight to your clipboard.
It runs alongside your existing IDE agent. Cursor, Copilot, Claude Code, and Codex CLI keep doing what they do. The Chrome extension is the "everything outside the editor" surface.

The extension is a separate surface from Codex CLI and Codex inside ChatGPT. They share an underlying model family, but the integration is browser-only — there is no shared session with your local Codex CLI runs.

Three workflow patterns worth keeping

After a few days of using a browser-resident coding agent — Codex and otherwise — the patterns that survive are unglamorous. They are also the ones that save real time.

Pattern 1: PR review with the diff in front of you. GitHub's review UI is fine for reading but slow for thinking. Highlight a hunk, ask Codex what the change does, what edge cases it misses, and whether the new function name is consistent with the file's existing style. You stay on the page, the agent answers against the actual diff, and you keep your comment thread open in the same tab.

Pattern 2: Translate a dashboard into code. Stripe, PostHog, Datadog, and most internal tools surface data through filters and tables. You can describe the chart you're looking at and ask the agent to write the API call, the SQL, or the query DSL that would reproduce it programmatically. The browser surface is the right place for this because the dashboard's filter state is part of the prompt.

Pattern 3: Repro-from-bug-report. A Linear or Sentry ticket with a stack trace, repro steps, and a screenshot is dense context. Asking the agent for a failing test that matches the report — to drop into your local repo — turns the ticket itself into the spec. You still write the fix in your IDE, but the boilerplate of "what does this bug actually look like in code" is done.

The common thread: the agent is most useful when the browser tab contains information your IDE doesn't have. The moment you need cross-file context or repo-wide refactors, switch tools.

Where it falls short

Browser-resident agents have real limits, and the extension is honest about most of them.

You don't get filesystem access, so anything multi-file is out. You don't get terminal access, so you can't run the code the agent generates. You also don't get a privacy story that's different from any other extension that reads page contents — if your tab contains customer data, treat the prompt as data leaving the page.

Extensions that read DOM contents inherit whatever you're looking at, including session tokens visible in network panels and PII in admin pages. Disable the extension on sensitive tabs or use a separate Chrome profile for work that touches regulated data.

Latency is also worth measuring before you commit to it. Round-tripping a selection through the API and waiting for a streamed reply is fast enough for paragraph-sized tasks and noticeably slower than your IDE's inline completion for line-sized ones. The mental model that fits is "ask, then read" — not "type, then accept."

The bigger structural question is whether browser agents replace IDE agents, complement them, or just add another tab to manage. For now the answer looks like the second one. Codex in Chrome handles the surfaces your IDE can't see; your IDE agent handles the code your browser can't reach. The category that loses, if any, is the standalone web-based ChatGPT or Claude tab people open as a scratchpad.

What to watch next

Two things determine whether browser-native AI coding agents become a default tool or a curiosity:

Permissions model. Chrome extensions that can read every page are a heavy ask. A scoped per-domain permission model, or first-class integration with sites that opt in (GitHub, Linear, Vercel), would change the security calculus.
Cross-surface memory. The same person asks Codex CLI for help on a function, then opens a PR in Chrome an hour later. If the browser extension can see what the CLI was working on, the agent stops feeling like a stranger every time you switch surfaces. OpenAI has hinted at this direction; nothing shipped yet ties the surfaces together.

Treat the extension the way you'd treat any new agent surface: try it on the workflows you already do badly, ignore the marketing about ten-times productivity, and keep your existing toolchain in place until you have a few weeks of data on what actually changed.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

Qwen 3.6 Plus API: Pricing, Benchmarks & Developer Access Guide (2026)

pickuma — Tue, 12 May 2026 09:21:42 +0000

The Qwen series from Alibaba's Tongyi Lab has moved from research curiosity to a model family you actually consider for production workloads. Qwen 3.6 Plus continues that trajectory: a 1M-token context window, native bilingual training that holds up on English code tasks, and a per-token price that undercuts GPT-4-class and Claude-class APIs by a wide margin. If you've ignored the Chinese frontier labs because of access friction or fear of locking into a niche provider, the trade-offs have shifted enough that a fresh look is warranted.

We ran Qwen 3.6 Plus through our internal eval harness alongside GPT and Claude. The headline isn't that it wins every benchmark — it doesn't. The headline is where it lands on the price/performance curve once you account for context length, and how that changes what's feasible in production.

What you actually get from Qwen 3.6 Plus

Qwen 3.6 Plus sits as the mid-tier production model in the current Qwen generation, between the small qwen-turbo variants and the flagship qwen-max. Two specs matter for most builders:

1M-token context window. Same order of magnitude as Gemini 1.5 Pro's long-context mode, far larger than the 200K Claude offers or the 128K most GPT-4-family endpoints serve. For repository-wide code reasoning, multi-document summarization, or feeding entire log archives into a single prompt, 1M tokens stops being a marketing line and starts being the reason you pick the model.
Native tool-calling and JSON-mode. The Qwen team standardized on OpenAI-compatible request/response shapes, so most clients drop in with a base URL swap. Function calling, structured outputs, and streaming all work the way you expect.

What you don't get, at least not yet, is the breadth of fine-tuning options and ecosystem tooling that OpenAI offers. Qwen ships open-weights checkpoints you can run yourself — different SKUs from the Plus API — but the hosted Plus tier is the closed API path.

The "1M tokens" claim is the advertised window. In practice, effective recall and reasoning degrade in the upper portion of any long-context model — Qwen 3.6 Plus is no exception. Treat 1M as a budget for retrieval-augmented prompts, not as a license to dump unstructured corpora.

Pricing: where the value actually shows up

Alibaba publishes Qwen 3.6 Plus pricing per million tokens, split between input and output. Exact figures shift, so check the DashScope console before you commit, but the structural story has been stable across the Qwen 3 generation: input tokens are priced roughly an order of magnitude below GPT-4-class endpoints, and output tokens follow a similar pattern. Cached input is cheaper still.

The implication for your bill is straightforward. If your workload is dominated by large prompts and small completions — RAG over a knowledge base, repository code review, document QA — the savings compound. On a code-review pipeline we benchmarked internally, routing the bulk-context calls through Qwen 3.6 Plus and reserving Claude or GPT for the smaller, latency-sensitive interactions cut monthly inference cost by a factor of four to six.

That does not mean Qwen is the right call for every job. For agentic flows with many short turns, per-call latency and the quality gap on complex reasoning still favor the frontier labs. The teams we've seen succeed with Qwen treat it as the second model in a two-model architecture: heavyweight context work on Qwen, decision-making and tool orchestration on Claude or GPT.

Coding benchmarks and what we actually measured

Public benchmarks — HumanEval, MBPP, LiveCodeBench, SWE-bench Verified — place Qwen 3.6 Plus competitively with the previous generation of Claude and GPT flagships, though it trails the current top tier on the hardest categories. More interesting are the tasks the public benchmarks don't capture well:

Cross-file refactors over 100K+ tokens of code. Qwen's long-context recall held up better than GPT-4-class models when the relevant context lived in the back half of a 200K-token prompt.
Multi-turn debugging with intermediate test output. Quality is closer to mid-tier Claude than to flagship Claude. You'll see the difference on subtle race conditions and concurrency bugs.
English documentation generation from non-English code comments. Bilingual training pays off here — fewer hallucinated translations than the Western models we compared.

If your codebase is small and your prompts fit comfortably in 32K, you probably won't notice Qwen's context advantage and the model choice comes down to other axes. If you routinely run prompts above 100K tokens, this is where Qwen earns its slot.

Getting access (and when to skip it)

Three practical paths exist for production teams:

DashScope (Alibaba Cloud International). Sign up at the international console, generate an API key, billed in USD on an international payment method. This is the cleanest path for non-China-based teams.
OpenRouter or another aggregator. Slightly higher per-token cost in exchange for a single account and a unified SDK across providers. Worth it if you're A/B testing models against your current stack.
Self-hosting an open-weights cousin. The Plus tier is closed, but Qwen ships open-weights models in the same family. The quality gap is real but narrower than between, say, GPT-4 and the open Llama line.

Data residency matters. Qwen 3.6 Plus traffic through DashScope International is routed through Alibaba Cloud's overseas regions, not mainland China, but the underlying compliance posture is different from US-based providers. If you have customer data subject to specific regulatory regimes, get sign-off from your security team before sending prompts.

Skip Qwen 3.6 Plus if your prompts are short and your bottleneck is reasoning quality rather than cost — use the frontier model. Skip it if you're building a regulated product where data flow through Chinese-headquartered cloud providers is a non-starter for your buyer. Skip it if you need the broadest possible tooling ecosystem (Anthropic's Claude Code, OpenAI's Realtime API, etc.) — Qwen's API surface is narrower.

For everything else — long-context document work, cost-sensitive RAG, multi-language code understanding, batch generation jobs — it deserves a real bake-off against your current stack.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

Phantom Pulse RAT Hits Obsidian Plugins: How to Audit Dev Tool Supply Chains

pickuma — Tue, 12 May 2026 09:15:19 +0000

A malicious Obsidian community plugin was weaponized to deliver Phantom Pulse, a remote access trojan that targets the exact file types developers and knowledge workers keep in their vaults: SSH keys, .env files, browser cookies, and project notes containing API tokens. The plugin shipped through the standard community plugins flow, which means anyone who installed it during the window between publication and takedown received the payload through the same trusted-by-default channel they use for syntax highlighting and Kanban boards.

This is not a novel exploit. It is the same supply chain pattern that has hit npm, PyPI, the VS Code marketplace, and Chrome extensions. What makes the Obsidian case worth examining is the threat model gap: most teams treat their note-taking tool as a productivity app, not a code execution surface. Obsidian plugins run as Node.js modules with full filesystem access. So do VS Code extensions. So do Cursor extensions. So do most things you install with one click in a developer-adjacent tool.

How the attack chain worked

The reported pattern matches a well-understood supply chain template:

Plausible plugin metadata. The malicious plugin ships under a name that looks legitimate — typosquatting a popular plugin, or filling a small gap in the ecosystem (a new exporter, a niche theme).
Initial install runs trusted code. The plugin's stated functionality works as advertised. The hostile payload is gated behind a delay, a config check, or a remote fetch.
Second-stage delivery. The plugin reaches out to an attacker-controlled host on first run or first vault open, downloads a binary or script, and writes it to a persistence location (LaunchAgent on macOS, scheduled task on Windows, systemd user unit on Linux).
Phantom Pulse activates. Once installed, the RAT establishes command-and-control, exfiltrates credentials and SSH material, and waits for operator instructions. RATs in this class typically include keylogging, screenshot capture, clipboard monitoring, and file exfiltration.

Treat any tool that loads third-party plugins as a code execution platform, not just a content viewer. Obsidian, VS Code, Cursor, JetBrains, Raycast, and Alfred all execute plugin code with your user account's full permissions. A single compromised plugin can read every file your account can touch.

If you installed an unverified Obsidian community plugin during the affected window, the practical move is to assume compromise until you verify otherwise. Rotate any credential that lived in your vault or in environment variables your shell loaded during that window. Check ~/Library/LaunchAgents (macOS), Task Scheduler (Windows), and ~/.config/systemd/user/ (Linux) for unfamiliar entries. Audit your shell history for unexpected outbound traffic.

Why developer tools keep getting hit

The same dynamics that make plugin ecosystems useful make them attackable:

Low-friction install. One click, no review, no signing requirement on most platforms. Obsidian plugins, VS Code extensions, Cursor extensions, and Raycast extensions all install and execute without a meaningful security gate.
Implicit trust transfer. When a plugin is listed in an official community directory, users transfer trust from the platform to every plugin in the directory. The platform did not actually vouch for the code.
Wide privilege. Plugins inherit the permissions of the host process — full filesystem read/write, network access, and child-process spawning. There is no permission prompt for "this plugin wants to read your .ssh directory."
Update-time payload swap. A plugin that was clean on day one can ship malicious code in a later update. Ownership transfers, account compromise of the maintainer, or a deliberate switch by the original author all produce the same result.

Cursor and VS Code share most of this attack surface. Both run extensions in the renderer or extension host with broad permissions, and the Cursor extension marketplace inherits VS Code's open-by-default model. If you use AI coding tools that load community extensions, the same audit applies.

A practical audit you can run this week

You do not need a security team to reduce your exposure here. Three concrete steps:

1. Inventory what you have installed.

For Obsidian: open Settings → Community plugins and list every enabled plugin. Note the plugin's GitHub repository and the maintainer's account.

For VS Code or Cursor: run code --list-extensions --show-versions (or cursor --list-extensions --show-versions).

For Raycast: open the extensions tab.

Write the list down. You will not remember to audit something you did not know you installed.

2. Apply a minimum-viable trust filter.

For each plugin, check three things:

Is the source repository public, and does it have meaningful commit history from more than one contributor?
Is the maintainer's account active and identifiable?
Did the most recent update change anything beyond what the changelog claims? Diff the release if you can.

A plugin that fails any of these is not necessarily malicious, but it is a candidate for removal if you do not actively need it. The goal is not to verify every line — it is to remove the long tail of plugins you no longer use.

3. Separate your secrets from your plugin host.

Stop keeping API keys, recovery phrases, and credentials in your Obsidian vault as plain text, even in private vaults. Use a dedicated secret manager (1Password, Bitwarden, or the system keychain). For shell environment variables, load them from a secret store at session start instead of writing them into .env files that any plugin can read.

What this changes about how you pick tools

The Phantom Pulse incident does not mean abandon Obsidian or any other plugin-driven tool. It means treating plugin install as a privileged action — closer to "run this binary I downloaded from the internet" than to "enable a feature." The platforms with the strongest stories here are the ones that sandbox plugin execution or require code signing and review.

Until Obsidian, VS Code, and Cursor add meaningful sandboxing for community plugins, the audit is on you. Keep the list short. Prefer plugins from maintainers you can identify. Pin versions when you can, and read the diff when an update lands.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

OpenCode vs Claude Code: Why 157K Developers Are Hedging Against Anthropic

pickuma — Tue, 12 May 2026 09:14:03 +0000

The 157K Signal You Shouldn't Ignore

The figure being cited — 157,000 developers adopting OpenCode — is the kind of number that's easy to dismiss as social media optics. It isn't. Claude Code, Anthropic's official CLI, sits on a fundamentally different distribution model: closed binary, single-vendor model routing, billing through your Anthropic account. The fact that a self-funded open-source project crossed six figures of adoption while a polished managed product was already available tells you something specific about what working developers are optimizing for: they want a harness they can keep running if Anthropic raises prices, changes terms, or deprecates a model they depend on.

The terminal-based AI coding category went from one credible entrant to a fractured landscape in roughly 18 months. OpenCode, Aider, Continue, and a handful of others all run the same basic loop: take a prompt, plan, edit files, run shell commands, repeat. What differs is who controls the loop.

We ran both tools against the same repo across a handful of tasks — a schema migration, a test-first feature addition, and log-grepping a production incident — to see where the daylight actually sits.

What OpenCode Does Differently

OpenCode is a TUI-first coding agent built by the SST team. The architecture is deliberately model-agnostic: you can route the same session through Claude Sonnet 4.6, GPT-5, Gemini 2.5 Pro, DeepSeek, or a local Ollama model, and switch mid-task. Claude Code runs only on Anthropic models. That single design choice cascades into everything else.

The practical implication surfaces the first time Anthropic has a capacity incident or a model deprecation. OpenCode users who configured a fallback to OpenRouter or a local model keep shipping. Claude Code users wait. For a freelancer billing by the hour or a team with a same-day deadline, that matters more than any benchmark score.

OpenCode also exposes its system prompt, tool definitions, and execution loop. You can fork it, swap the planner, or pin a model version that won't auto-update. Claude Code's prompt and tool layer are not user-editable — Anthropic ships changes and you accept them on next launch. Some developers prefer that. The binary just works without configuration drift. Others, particularly those running CI-integrated agents or tuning behavior for a specific codebase, find the opacity disqualifying.

OpenCode is MIT-licensed and self-hostable. Claude Code requires an Anthropic account and routes requests through Anthropic's infrastructure, including the file contents you load into context. If your employer has restrictions on which providers can see source code, this distinction is a procurement issue before it's a tooling preference.

Where Claude Code wins on day one is integration polish. The agent's tool-use loop is tuned end-to-end for Anthropic's models — the prompting, context window management, and tool definitions were designed together. In our test runs, Claude Code with Sonnet 4.6 completed a five-step refactor in noticeably fewer turns than OpenCode running the same model. Fewer tool calls, fewer recoveries from malformed JSON arguments. The gap shrinks when you route OpenCode through Claude as well, but the harness-model fit isn't quite as tight.

The Lock-In Math

The real argument for hedging isn't ideological. It's pricing volatility.

Provider-side pricing for managed AI coding tools has shifted multiple times during the past year — context window pricing, cache discount terms, monthly subscription tiers. If you're spending a few hundred dollars a month on a single vendor, a 20–30% price shift compounds into real money across a team. The cost isn't just the dollar amount; it's that the lever sits with one party.

OpenCode plus OpenRouter — an aggregator that fronts a couple of hundred models across providers — gives you a substitution menu. You can route cheap-tier tasks like commit-message generation through a smaller model at a fraction of the cost, reserve Claude or GPT-class models for the hard reasoning, and switch the default in a config file without rebuilding your workflow.

The honest tradeoff: managing model routing is real overhead. If you bill your own time at engineer rates, OpenCode's flexibility starts paying back somewhere around the third pricing-change-induced migration. Below that threshold, Claude Code's buy-and-forget posture is cheaper in your time alone.

When Each Tool Actually Wins

Pick Claude Code when you're a solo developer or small team, you're already paying Anthropic for the model, you want the lowest-friction setup, and you don't anticipate needing to swap providers. The polish premium is real. Claude Code's auto-context management — deciding which files to load, when to grep, when to ask — is more reliable than any open harness we've tested.

Pick OpenCode when your shop has a multi-model policy for regulatory, cost, or capability reasons, you need to run agents in environments where Anthropic can't see your code, you're building tooling on top of the agent itself, or you want insurance against price and availability shocks. The configurability also makes OpenCode easier to embed in CI pipelines and self-hosted setups.

Run both when you're a power user who can afford the configuration time. Use Claude Code for interactive coding sessions where polish matters; use OpenCode with a cheaper model for batch tasks, log analysis, or anything you'd otherwise script in shell.

What the Split Says About Where This Is Headed

The Claude Code / OpenCode split isn't about which tool is better. It's the first visible bifurcation between two procurement models developers have had to choose between in past technology cycles: vertically integrated proprietary stack versus an open layer you assemble yourself. The same decision shows up at every level — operating systems, databases, frontend frameworks, observability stacks.

What's different here is the speed. JetBrains versus VS Code took a decade to resolve. The coding agent layer is fragmenting in under two years. That tells you the underlying technology is moving fast enough that lock-in costs feel acute right now. Developers are not willing to bet their workflow on any single vendor's roadmap.

Expect both to coexist for the foreseeable horizon. Anthropic will keep iterating Claude Code. OpenCode and its peers will keep absorbing share among developers who got burned by a price hike, an API outage, or a deprecated model they depended on. The interesting question is whether OpenCode itself ends up centralizing — most of the development is funded through SST's hosted services — or whether the community fork model holds long enough to keep the substitution menu real.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.