Build a JavaScript harness that models Muse Ember’s real cost per agent task by breaking down $0.10/M-token pricing, the 200K-context caveat, tool calls, retries, and context growth against frontier-model trade-offs.
A technical walkthrough for auditing consent screens and cancellation flows against the EU Digital Fairness Act's proposed dark-pattern rules, including release review checkpoints and compliance mapping.
Researchers discovered over 575 malicious OpenClaw skills that delivered malware to Windows and macOS, exposing critical trust-boundary failures in agent plugin marketplaces and the need for sandboxing and audit controls.
A deep technical audit of Expo Exact's runtime boundaries across web, macOS, iPhone, and Linux, examining cross-platform rendering, native interoperability, and build pipeline tradeoffs for TypeScript teams.
Researchers found more than 575 malicious OpenClaw skills that delivered malware to Windows and macOS users. The number is the headline. The trust boundary is the story. A skill bundle is two things at once: a manifest that a human skims and a model parses as instructions, and a scripts folder that the host executes. The manifest can declare its allowed tools, but that declaration is only YAML in a markdown file. Nothing in the install path enforces it, and the script never reads it. The execution path that matters: - Discovery and install with no signature or integrity check - The model choosing the skill mid-task, on its own initiative - First invocation spawning a child process - That child inheriting the agent's user account, working directory, environment variables and network That last step is the moment of privilege. If the agent process holds API keys, which it does because that is how the agent works, the child gets them for free. No capability drop, no egress rule, no seccomp filter. What to do instead: enforce capability at spawn time. Drop privileges, hand the child a scrubbed environment, deny outbound network by default, and log every spawn. Audit a bundle before installing it as a read, not a run: grep the scripts folder for anything that spawns a process, and check per-user persistence surfaces such as launch agents on macOS and the per-user Run key on Windows. If a skill already ran, revoke tokens before you collect evidence, because tokens are the expensive loss. The post is explicit about what the source material establishes and what it does not: no malware family names, no install counts, no claim about takedowns are asserted. The technical sections are a reconstruction of the class of bundle that makes this kind of incident possible. Full write-up: https://hackyjs.com/posts/auditing-575-malicious-openclaw-skills-where-agent-plugin-trust-boundaries-broke
A secondary report says Expo released a runtime called Exact that builds one TypeScript app for web, macOS, iPhone and Linux. That report is a headline: no SDK version, no module list, no packaging story. So this post doesn't review an architecture it can't see. What it does instead is give you an audit plan you can run against any candidate runtime: - Four boundaries worth testing separately: the render surface, the native API surface, the lifecycle and process model, and the build artifact graph. - A capability matrix with the four targets as columns and nine capability classes as rows, so disagreement between platforms shows up as a cell rather than a surprise in production. - A probe harness that records six statuses per cell, and catches the worst one: a native call that resolves to undefined and looks like a bug in your app instead of a gap in the runtime. - The cheapest signal of all, the web target. If you can select text and find it in the page, you're on the DOM and accessibility comes mostly free. If you can't, you're on canvas and you budget for remediation. Also covered: AppKit versus UIKit assumptions such as menu bars, window lifecycle, hover states and safe-area insets, plus the Linux questions about Wayland, X11 and distribution format that set your support burden. The point is not to score the release. It's to replace a platform count with a matrix you can fill in on a real build. Full write-up: https://hackyjs.com/posts/auditing-expo-exacts-runtime-boundaries-on-web-macos-iphone-and-linux
Cost per token is a vendor metric. Cost per request is an infrastructure metric. This walkthrough instruments an agent loop so the number on the dashboard is cost per successful task instead. What the video covers: - Why input tokens grow roughly quadratically with step count when every call re-sends the whole transcript - A hand-computed ledger at a placeholder price sheet: 3 steps at about 2.07 cents per run, 9 steps at about 9.45 cents, a 4.6x multiplier - Why failed runs belong in the numerator: at a 30% failure rate, cost per success is about $0.135 against $0.023 for the short loop - The instrumentation plan: one span per model call and one per tool call, a three-level token budget with reserve and settle semantics, a cache-key scheme, a model-routing ladder with an explicit stop condition, and an NDJSON harness that turns a synthetic workload into a cost-per-success figure with p50/p95 spread The post also separates the reported claim about token usage doubling monthly from your own measured baseline, covers the tool-output term you don't control, and includes the jq and PromQL queries that turn spans into an alert when cost per success regresses. Read it here: https://hackyjs.com/posts/instrumenting-agent-loops-for-cost-per-successful-task