When Google announced Gemini 3.8 Flash, the released model card indicated that it correctly answered 88.8% of BioMysteryBench’s human-solvable tasks and 56.5% of its hard tasks. In Vals’ independent production runs, the same model scored 71.7% and 21.6%, respectively. Harness and environment differences can move any benchmark result, but this gap was especially wide, especially considering the model was state-of-the-art by Google’s evaluation and near last by ours.

BioMysteryBench allows agents to access websites on the internet, but they are told that accessing specific studies containing task data is not permitted. Cheating in this way caused the poor performance on our benchmark: Gemini 3.8 Flash searches for answers online 21% of the time, whereas Gemini 3.7 practically never exhibited this behavior.

Cheating Trends on Coding Benchmarks

This led us to investigating historical prevalance of cheating across our benchmarks. Terminal-Bench-2.1 is conducive to this study as it allows internet access, but prohibits answer lookup. When we plotted cheating attempts over time, we discovered that rate of attempted cheating on benchmarks is increasing for almost all major model providers.

Many evaluations independently track cheating already, as BioMysteryBench did, yet longitudinal changes in this metric are not closely monitored. SWE-Bench-Verified, for example, is an older benchmark that is now less frequently relied on (and deprecated by us at Vals). This benchmark inspired an even greater degree of cheating, particularly due to it’s task construction being very amenable to searching for solution using simple git queries. The GPT 5.6 series of models did this with particular consistency.

Takeaways

These findings highlight the value of independent evaluators. It is not unlikely that the same guardrails preventing models from cheating during training are being used during evaluations within organizations. If models are trained to complete tasks in ways that evade these specific guardrails, it would not be surprising for labs to occasionally release benchmark results that are not externally trustworthy.

At Vals, we are working to more systematically ensure that our evaluations do not reward credit when models cheat. We anticipate that this will be increasingly important as model capabilities advance.

Methodology

For BioMysteryBench, we analyzed 2,430 task-trials across nine models (three 90-task runs per model). The benchmark evaluator’s anti-cheating rationales were independently classified by GPT-5.6 Luna for all 765 zero-scored trials. For Terminal-Bench 2.1, we screened 3,738 task-trials across fourteen models (three 89-task runs per model). It distinguishes task-specific lookup attempts, deterministic shortcut evidence, and shortcut cases that still received verifier credit. For SWE-bench Verified, we audited 6,496 mini-SWE-agent trajectories across historical Opus, Gemini, GPT, and GLM releases using GPT-5.6 Luna.

Some Focus Areas for Embedded Evaluations and How to Approach Them

Initial thoughts on key risks third parties should monitor and a proposal for how to evaluate them.

Summary

In this blog post, we outline ways that “embedded evaluators” could help address the emerging AI alignment issues highlighted by OpenAI’s inadvertent hack of Hugging Face and the increasing number of related incidents. We describe the access and methods we think would help address these escalating risks, along with key model behaviors for embedded evaluators to target, such as multi-agent coordination, targeted persuasion, evaluation awareness, and concealed reasoning.

In addition, we briefly describe pilot approaches for embedded evaluators to assess these risks, based on:

1. Monitoring agent swarms and assessing labs’ broader practices for managing them.
2. Assessing labs’ training practices for evidence that models are being taught misaligned behaviors, as well as which factors are most contributing to them.
3. Monitoring for evidence that misaligned models are manipulating key employees.
4. Researching misaligned model behaviors in simulation using privileged access to unreleased models and model internals.

Transluce’s core goal is to foster rigorous, public oversight of frontier AI systems and their behaviors. Despite important public releases by frontier labs and the evaluators they invited to investigate, significant questions remain about what actually happened in these incidents, why, and how to prevent them from recurring.

We are excited about the idea of independent evaluators embedding inside labs to further this public understanding, and we are eager both to participate directly in these evaluations and to build tools to support the broader evaluator ecosystem. It is also important for evaluators to pursue ambitious public projects not dependent on lab cooperation, such as efforts to identify additional alignment incidents in the wild and to reproduce alignment incidents in simulation.

Background

In public, AI advances are blowing through benchmarks and rapidly unlocking both new use cases and new risks. However, less obvious is the fact that labs are currently training and using even more powerful AI systems internally. These systems and the risks they pose have historically been opaque to independent evaluators and the broader public, potentially contributing to recent incidents and the general surprise they created.

Compared to publicly released systems, these unreleased models:

• Are more varied, likely including numerous experimental approaches and checkpoints that are never released or tested externally.
• Have fewer safeguards, for instance often being trained to be "helpful only" rather than "helpful and harmless".
• May have novel capabilities and behaviors that are poorly understood.
• Have greater access to internal lab systems and information, including access to detailed knowledge about lab employees and plans, fewer checks against hacking sensitive internal systems, and de facto control over increasingly significant portions of the model development pipeline.

Internal deployments of these models are creating new oversight challenges and threats, including to the broader public, as recently demonstrated by an OpenAI agent swarm autonomously hacking the model hosting platform Hugging Face, as well as a growing list of related incidents. Without significant improvements, future incidents could be much larger and more harmful as models become more capable and computational resources increase. As a result, the public has a critical interest in effective independent monitoring of AI developers.

We highlight three areas where internally deployed models appear to have novel, superhuman offensive capabilities:

• Cyber offense: AI agents have possessed demonstrably superhuman hacking capabilities since at least the development of Anthropic’s Mythos Preview model. Frontier labs, together with a range of software providers, are racing to patch the vulnerabilities revealed by these increased model capabilities, but these efforts are far from complete, as shown by the Hugging Face incident itself. We should assume that misaligned AI agents have the capacity to hack into both internal and external systems, likely beyond what is seen in public, absent compelling evidence to the contrary.
• Manipulation of lab personnel: AI agents possess persuasive skill comparable to human experts. Lab personnel are reportedly highly reliant on AI systems for a broad range of tasks, including training future models. As a result, they also have significant access to and control over the information that lab employees see—far more than almost any human-human relationship, and especially so in areas where employees are directly delegating to these models. Misaligned AI systems could both manipulate key individuals and tasks, as well as exert more diffuse influence over the operations of a company generally.
• Multi-agent collusion: Labs are increasingly parallelizing AI capabilities via swarms of AI agents, which can overwhelm overseers and defenders. Recent incidents suggest that coordinated misaligned behavior can emerge organically among these swarms. The Hugging Face incident involved ~1,200 agents acting in concert, and it is likely these numbers will increase as more compute capacity comes online. Worryingly, future AI agents may also be able to coordinate much more effectively than humans, especially as labs specifically train them to coordinate via multi-agent RL.

Whether these models misuse these capabilities to cause harm depends on additional factors like their design, behavior, and their influence over their own training. Recent events point to worrying trends that could significantly elevate risks, including:

• Situational awareness, where models are increasingly aware when they are being evaluated and how they are being monitored or contained, which can destroy evaluation validity and help models evade safeguards.
• Cognitive opacity: the more models’ actions and reasoning are opaque to overseers, the harder it is to supervise their actions. Models may be trained in ways that optimize them to fool monitors: for instance, direct human oversight has become less effective due to RLHF, and reasoning traces may be growing less informative over time. Given rumored trends in model architecture, models may soon reason in “neuralese” incomprehensible to humans, as evidenced by their increasingly strong reasoning capabilities within a single forward pass.
• Persistent misalignment: recent incidents showcase the danger of agents that are highly persistent in pursuing goals misaligned to their deployers. While cheating on small tasks is merely annoying, training agents to accomplish a goal at any cost, and giving them the equivalent of human-weeks to achieve that goal, has led to agents evolving much more malignant behaviors and undesirable instrumental goals. For example, the Hugging Face agent swarm formed an internal hierarchy in which agents directed other agents to deliberately fail their task to test cheating methods that would benefit the collective; agents attempted to modify their transcripts in order to subvert monitoring; and agents learned to hack an external company despite reasoning that it was outside the bounds of the evaluation.
• Control over future training runs: agents will play an increasingly instrumental role in both the infrastructure and training data for training future agents, potentially allowing them to poison training to propagate their misalignment to downstream models. The existing literature shows that adversarial control over even small amounts of data can significantly shape the trained agent, making comprehensive defense particularly important.

Focus Areas for Embedded Evaluations

Labs’ willingness to more directly embed independent evaluators opens significant opportunities for improving oversight at a critical time. Below we outline a set of activities directed specifically at the behaviors highlighted by the Hugging Face hack and related incidents, and which fall within our core expertise as evaluators of AI model behavior.

1. Monitoring agent swarms and assessing labs’ broader practices for managing them.

• Goal: Embedded evaluators design and deploy effective monitors across all of the lab’s meaningful agent swarms and regularly audit labs’ own monitoring practices and coverage.
• Pilot: Scope monitoring of real internal agent deployments initially to larger agent swarms. Independently audit existing monitors and their findings and complement them with additional evaluator-defined monitors. Conduct exploratory investigations even in the absence of monitors detecting misaligned activity.
• Pilot: Deploy an intentionally misaligned agent swarm within a carefully sandboxed (e.g., air gapped) simulated environment and test monitors’ ability to detect, characterize, and remediate activities.

2. Assessing labs’ training practices for evidence that models are being taught misaligned behaviors and which factors are most contributing to them.

• Goal: Embedded evaluators monitor checkpoint models throughout the training process for evidence of emerging misalignment, as well as related characteristics like evaluation awareness, providing strong independent signal for when and how training approaches should be adjusted to avoid misalignment.
• Pilot: Evaluators evaluate a progressive series of training checkpoints for misalignment, identifying trends in how and when misalignment emerges in the lab’s particular training pipeline.
• Pilot: Evaluators audit a subset of training environments most related in kind to misaligned behaviors demonstrated in recent incidents, looking for evidence that these environments are rewarding models for behaviors like cheating, hacking, or deception.

3. Monitoring for evidence that misaligned models are manipulating key employees.

• Goal: All key employees’ interactions with internal models are monitored in a privacy-preserving manner for evidence of manipulative activity. Detections are elevated to affected employees and relevant overseers.
• Pilot: Evaluators monitor one part of the organization’s AI interactions for evidence that the models they use in their work are engaging in manipulative behaviors, such as the risk that models are sandbagging, modifying, or cheating on tasks when they are being asked by their developers to help modify future versions of themselves.
• Pilot: Evaluators implement a tiered, privacy-preserving monitoring and notification system that escalates evidence of manipulative behavior to affected staff, as well as aggregating such information up their leadership chain.

4. Researching misaligned model behaviors in simulation using privileged access to unreleased models and model internals.

• Goal: Embedded evaluators use access to unreleased model versions (e.g., experimental models, helpful only models) and model internals (e.g., activations, knowledge of architecture specifics) to study emerging trends in misalignment, as well as contributing factors like situational awareness and cognitive opacity.
• Pilot: Evaluators apply the best existing model transparency methods to decode neuralese models for hidden misaligned reasoning and assess the adequacy of chain-of-thought monitors.
• Pilot: Evaluators use internal models to support an open replication and root-cause analysis of recent incidents.

Beyond Embedded Evaluations

Done well, embedded evaluations are an important tool for reducing risks, but we also need to build an evolving public science of frontier model misalignment. Experience shows that privileged-access evaluations inevitably come with downsides. Even the most permissive agreements generally add negotiation and compliance overhead, confidentiality obligations, and other restrictions that can constrain the speed and transparency of research, sometimes severely.

Already, independent researchers have made important discoveries in the open, including reproducing aspects of the Hugging Face incident and discovering previously undisclosed alignment incidents.

Transluce is excited to continue contributing to this public science and building tools to aid independent evaluators, including tools specifically for incident investigators. Ryan Greenblatt, one of the independent researchers involved in investigating the Hugging Face incident, described his team’s efforts as a “slop-vestigation,” overly reliant on OpenAI’s own models to aggregate findings from large quantities of exceedingly complex multi-agent transcripts. As one of our efforts, we are sprinting to extend our Docent transcript analysis platform for workflows focused on investigating transcripts from multi-agent swarms.

Conclusion

At this critical point in AI development, Transluce stands ready to aid in embedded evaluations. We recently conducted a joint evaluation with OpenAI, Anthropic, and Google DeepMind using privileged access to production data to investigate AI's influence on mental health and well-being. We are rapidly expanding our forward-deployed evaluation capabilities, and developing new tools and methods for studying agent swarms, psychological manipulation, and situational awareness. We are excited to work together with the broader AI evaluator ecosystem to ensure scalable, independent oversight of frontier AI systems.

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

Redis p99 goes from 0.4ms to 900ms. Every operation is affected, including plain GET calls against small string values. CPU on the Redis host is at 30 percent, memory is fine, the network is not saturated, and INFO shows no evictions.

Then it clears, and forty seconds later it happens again.

Somebody added an admin endpoint that lists cache keys matching a pattern. It runs every minute. It calls KEYS.

One thread, one command at a time

Redis executes commands on a single thread. That is a design decision rather than an oversight, and it is why every Redis operation is atomic without any locking: nothing else can be running while your command runs.

The consequence is head-of-line blocking with no escape. A command that takes 200 milliseconds does not slow down your request. It makes every other client wait 200 milliseconds, including clients whose request would have taken 30 microseconds.

Client B asked for one small string. It waited 340 milliseconds because of a command it has no relationship to. From B’s perspective Redis was slow, and every metric B has will say so.

Redis 6 added threaded I/O, and it is worth knowing exactly what that changed. Reading from and writing to sockets can now happen on multiple threads, which helps when a large number of connections saturates the network handling. Command execution is still single threaded, deliberately, because that is what keeps operations atomic. Threaded I/O does nothing for this problem.

The commands that are linear and do not look it

KEYS is the famous one and it is not the only one. Anything whose cost scales with the size of the data it touches will block for proportionally long.

The DEL row is the one that catches people, because deletion intuitively feels cheap. Removing a set with two million members means freeing two million objects, and that happens synchronously on the same thread everything else is waiting on. UNLINK exists precisely for this: it removes the key from the keyspace immediately and reclaims the memory in a background thread, so the blocking portion is constant.

LRANGE key 0 -1 deserves a mention because it appears in code that looks careful. Somebody wrote a helper that fetches a whole list, the list had 40 elements in development, and it now has 900,000 in production.

Finding the offender

SLOWLOG is where to look and it is the first thing I check when Redis latency moves without a corresponding change in traffic.

redis-cli SLOWLOG GET 10

It records commands exceeding slowlog-log-slower-than, which defaults to 10,000 microseconds. On a server where normal commands take tens of microseconds, 10ms is an enormous threshold and will only catch the extremes. Lowering it to 1,000 makes the log genuinely useful.

LATENCY DOCTOR and LATENCY HISTORY cover a broader set of causes, including fork pauses during persistence, which is the other common source of multi-hundred-millisecond stalls that look like nothing in the application logs.

The signature worth memorising: every operation slows at once, CPU is not saturated, and the slowdown clears without intervention. That combination almost always means one command is holding the thread. If instead one particular key or operation is slow and others are fine, the problem is elsewhere.

SCAN and the cursor contract

SCAN replaces KEYS and the difference is that it returns after a bounded amount of work.

def scan_keys(redis, pattern, count=500):
    cursor = 0
    while True:
        cursor, batch = redis.scan(cursor=cursor, match=pattern, count=count)
        for key in batch:
            yield key
        if cursor == 0:
            break

Each call examines roughly count slots and yields, so other clients get served between iterations. The whole scan takes longer in wall clock terms and blocks nobody.

Two properties of the guarantee are worth knowing before relying on it. Keys present for the entire scan are returned at least once, so you may see duplicates and must handle them. Keys added or removed during the scan may or may not appear, so SCAN gives you a fuzzy snapshot rather than an exact one. For finding keys to expire or clean up that is fine. For anything requiring exactness it is the wrong tool, and the right answer is usually to maintain an explicit index in a set rather than scanning the keyspace at all.

The same cursor pattern exists for collections: HSCAN, SSCAN and ZSCAN do for large hashes, sets and sorted sets what SCAN does for the keyspace.

Big keys are a latency problem before they are a memory problem

A single key holding a large collection is a latency risk on every operation that touches it, including its eventual deletion and its serialisation during persistence.

redis-cli --bigkeys
redis-cli --memkeys

--bigkeys samples the keyspace and reports the largest key per type. Running it during a quiet period is one of the higher value ten second investigations available, because a single 4 million element set is a stall waiting for whichever unlucky request touches it.

The structural fix is sharding the key. A set of 4 million members becomes 64 sets of 60,000 members addressed by a hash of the member, and every operation touches one shard. That also spreads the key across a cluster rather than pinning it to one node, which no amount of ring based key distribution will do for you, because the hash of a given key is fixed.

What I would put in place

Set slowlog-log-slower-than to 1,000 microseconds so the log records things that matter on a server where normal is measured in tens of microseconds.

Disable the dangerous commands outright in production rather than relying on nobody calling them:

rename-command KEYS ""
rename-command FLUSHALL ""
rename-command FLUSHDB ""

This is the rare case where I favour removing a capability over documenting it, because the cost of one accidental KEYS against a large keyspace is an outage and the benefit of having it available in production is close to zero.

Run --bigkeys on a schedule and alert when the largest key crosses whatever threshold your latency budget tolerates.

And treat the documented complexity of every command as a latency budget rather than trivia. On a single threaded server, O(N) is not a note about that command. It is a statement about what every other client will experience while it runs.

Apache Iceberg Python 0.12.0 Release

The Apache Iceberg community is pleased to announce the 0.12.0 release of Apache Iceberg Python.

The 0.12.0 release covers development work from early February through late August 2026 and is the result of merging over 470 pull requests from 58 contributors, including more than 40 first-time contributors.

These notes cover the highlights. For the full list, see the changelog.

Release Highlights

REST Catalog View Support

This release adds read support for Iceberg views. Views can be created, loaded, listed, registered, and dropped through the REST catalog, and are exposed through a View object.

view = catalog.create_view(
    identifier=("default", "recent_orders"),
    schema=schema,
    view_version=view_version,
)

view = catalog.load_view("default.recent_orders")
view.sql_for("spark")

• ViewMetadata read support and create_view for the REST catalog
• load_view and the View object API
• Registering existing views via register_view
• Pagination support for list_views
• More examples for working with views and a REST integration test suite

For older REST servers that support the view endpoints but do not advertise them in the ConfigResponse, set the view-endpoints-supported catalog property.

Commit Retry and Concurrency Validation

Writes now retry on concurrent commits and validate for conflicts. When a catalog commit fails with CommitFailedException, Transaction.commit_transaction() refreshes the table, checks for conflicts, and retries the commit.

Incremental Append Scan

Table.incremental_append_scan() (#3512) reads the rows added by append snapshots within a snapshot range, projected onto the table's current schema.

scan = table.incremental_append_scan(
    from_snapshot_id_exclusive=last_processed_snapshot_id,
    to_snapshot_id_inclusive=table.current_snapshot().snapshot_id,
)
new_rows = scan.to_arrow()

Geometry and Geography Types

The v3 geometry and geography primitive types are now supported: schema parsing and serialization, Avro mapping via WKB bytes, and PyArrow/Parquet integration.

File Format Writer API

PyIceberg has begun using the File Format API for handling Parquet files.

Catalog and REST Improvements

• REST loadCredentials support with longest-prefix resolution for a target location, and storage credentials in LoadTableResult
• Pagination support for list_namespaces and list_tables, with a shared rest-page-size option
• overwrite option for register_table
• SigV4 retry configuration defaults for REST
• S3 server-side encryption configs for FsspecFileIO
• Glue create_table support for S3 Tables federated databases
• An iceberg_type column for SqlCatalog, so Iceberg tables can be distinguished from other entries, with filtering fixed for existing catalogs
• Catalog properties for the shared catalog test suite and coverage for nonexistent tables and namespaces
• Renamed rest-scan-planning-enabled to scan-planning-mode

CLI

• --warehouse flag for the REST catalog
• --version flag, deprecating the version subcommand, which now also skips catalog loading
• --purge option for drop table, to request that the catalog purge the underlying table files

Bug Fixes

Notable correctness fixes in this release:

• Fixed strict NotEqualTo/NotIn pruning for files with partial nulls or NaNs
• Corrected NOT STARTS WITH projection for truncated partitions, along with residual evaluation and the string-based starts_with/not_starts_with methods
• Fixed the ManifestEntry.snapshot_id setter writing to the wrong index
• Fixed the DELETED manifest entry snapshot_id in OverwriteFiles
• Preserved a manifest min sequence number of 0 rather than dropping it
• Stripped the spec-mandated deletion vector blob framing before deserializing, with a Spark interop test covering the read path
• Fixed deepcopy for And, Or, and Not expressions
• Fixed precision loss in large integral string conversions, with Long bounds returned for decimal conversion, bounds sentinels for long date literals, and an overflow sentinel in LongLiteral.to(FloatType)
• Padded sub-microsecond digits when parsing nanosecond timestamps, and handled non-UTC nanosecond timestamps
• Used minimal byte length when encoding decimals for negative powers of two
• Preserved dictionary encoding in to_arrow_batch_reader
• Fixed delete_data_file on partitioned tables and residual NotNaN for null partition values
• Avoided committing update builders after exceptions
• Preserved write_default when applying a name mapping
• Handled zero-byte files in fsspec __len__, extracted the ADLS account_name from the URI hostname, and parsed S3 virtual addressing as a boolean
• Stopped reusing TSaslClientTransport to eliminate server-side SASL noise
• Rejected unsupported identity transform types, empty source-ids, and decimal precision outside the valid range

Breaking Changes

• Raised pyarrow minimum from 17.0.0 to 18.0.0 for native UUID type support
• Bumped pyiceberg-core from >=0.5.1,<0.9.0 to >=0.10.1,<0.11.0, which bundles DataFusion 53.x behind a new datafusion extra
• NoopCatalog.table_exists now returns False instead of raising
• Explicitly deleting a data file that's already missing now raises instead of failing silently

Infrastructure Improvements

• Python 3.14 support
• Windows unit test job added to CI
• CodeQL security scanning for GitHub Actions, and a documented Iceberg security model
• Migrated lockfile management to uv-pre-commit with uv.lock freshness enforced in CI
• Third-party GitHub Actions pinned to Apache-approved SHAs, with an allowlist check on every PR and least-privilege workflow permissions
• Papermill-based tests that execute the documentation examples, and a release verification script
• PR auto-merge enabled

Contributors

$ git shortlog --perl-regexp --author='^((?!dependabot\[bot\]).*)$' -sn pyiceberg-0.11.0..pyiceberg-0.12.0
    44  Kevin Liu
    36  Yuya Ebihara
    12  Anas Khan
    11  Alex Stephen
     7  geruh
     5  Minh Vu
     5  Neelesh Salian
     4  Gabriel Igliozzi
     3  Fokko Driesprong
     3  GayathriSrividya
     3  Junwang Zhao
     3  Sotaro Hikita
     3  jj.lee
     3  vishnu prakash
     2  Aaron Niskode-Dossett
     2  ChangHyeon Im
     2  David
     2  David Dallakyan
     2  Jared Yu (余启正)
     2  Mrutunjay Kinagi
     2  Paul Mathew
     2  Sreesh Maheshwar
     2  Tanmay Rauth
     2  Yingjian Wu
     1  Adam
     1  Antonio
     1  Ben Lai
     1  BharatDeva
     1  CalebWeisgerber
     1  Chris Qiu
     1  David Zhao
     1  Federico
     1  James Bornholt
     1  Jared Yu
     1  Koen Denecker
     1  Kristofer Gaudel
     1  Marcin Szymański
     1  Ménélik Vero
     1  Noritaka Sekiyama
     1  Platon G. Gimp
     1  Pucheng Yang
     1  R. Conner Howell
     1  Rob Reeves
     1  Ruiyang Wang
     1  Sam Verhasselt
     1  Sidra
     1  Sumanth
     1  Sung Yun
     1  Thomas Pfeiffer
     1  Vova Kot
     1  Yong Zheng
     1  abnobdoss
     1  achasnovskiy
     1  antonlin1
     1  barking-code
     1  committobetter
     1  rcjverhoef
     1  shiwk
     1  spr0els

We thank all contributors for their efforts in making this release possible!

Getting Involved

The PyIceberg project welcomes contributions! We use GitHub issues for tracking work and the Apache Iceberg Community Slack for discussions.

The easiest way to get started is to:

1. Try PyIceberg with your workloads and report any issues you encounter
2. Review the contributor guide
3. Look for good first issues

Code review is also a very welcome contribution - please provide feedback on pull requests where you feel comfortable to do so!

For more information, visit the PyIceberg repository or the documentation.

PostgreSQL row-level security (RLS) adds a database check behind EF Core query filters. It covers reads and writes, as long as the application connects as a non-owner role and sets the tenant every time a connection opens.

I've recommended a global query filter for shared-schema multi-tenancy for years, and I still would. EF Core adds WHERE tenant_id = @tenant to every query it generates, so nobody has to remember the predicate. It also stops there: SQL you send through ExecuteSql, an entity you attach and save, and anything behind IgnoreQueryFilters() never get it.

I wanted a second check that doesn't depend on every developer remembering the first one. Postgres has one built in with row-level security (RLS). So I set it up with EF Core 10, Npgsql, and Postgres 18 on a table with 1,000,000 invoices across 50 tenants, and tried to get past it.

Put the Rule in Postgres

Row-level security is a predicate that Postgres attaches to every statement against a table, for every role that isn't exempt. The application can't forget it, because it never sees it.

Superusers, roles with BYPASSRLS, and the table's owner all skip it, and in a lot of apps the one database user that runs migrations also serves requests and owns the tables. So the sample connects as app_user, a role that owns nothing and has only the DML grants it needs, and migrations run as a separate owner role. That split also keeps DROP POLICY out of the application's reach.

I consider it a general best practice to have a dedicated database user for executing queries against the database.

Here's an example policy on the invoices table:

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
ALTER TABLE invoices FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices
  USING      (tenant_id = NULLIF(current_setting('app.tenant_id', true), '')::uuid)
  WITH CHECK (tenant_id = NULLIF(current_setting('app.tenant_id', true), '')::uuid);

USING decides which rows a read, update, or delete can reach, and WITH CHECK rejects an insert or update whose new tenant_id doesn't match the session setting. NULLIF makes a missing or empty setting match nothing instead of everything, which is the failure I'd rather have. FORCE puts the owner under the policy too, so a migration script can't touch every tenant's rows by accident.

The current_setting function returns the current value of a configuration parameter.

Set the Tenant on Every Connection

The policy reads a session variable, so the application has to set it, and the obvious place is the start of the request. But you'll quickly run into problems with this approach.

EF Core opens the connection for a command and closes it afterwards, and Npgsql resets pooled session state, so the query after my SET ran on a connection that had never heard of the tenant. Turning the reset off with No Reset On Close=true is worse: the next request picked up the previous tenant's setting and saw rows it shouldn't have.

The fix is to set the tenant every time a connection opens, on whichever physical connection Npgsql hands out. A connection interceptor does that, with TenantContext holding the tenant authorized for the current request:

public sealed class TenantConnectionInterceptor(TenantContext tenant)
    : DbConnectionInterceptor
{
    public override void ConnectionOpened(
        DbConnection connection, ConnectionEndEventData eventData)
    {
        using var command = Build(connection);
        command.ExecuteNonQuery();
    }

    public override async Task ConnectionOpenedAsync(
        DbConnection connection, ConnectionEndEventData eventData,
        CancellationToken cancellationToken = default)
    {
        await using var command = Build(connection);
        await command.ExecuteNonQueryAsync(cancellationToken);
    }

    private DbCommand Build(DbConnection connection)
    {
        var command = connection.CreateCommand();
        command.CommandText = "SELECT set_config('app.tenant_id', @tenant, false)";

        var parameter = command.CreateParameter();
        parameter.ParameterName = "tenant";
        parameter.Value = tenant.TenantId?.ToString() ?? "";
        command.Parameters.Add(parameter);
        return command;
    }
}

set_config takes the tenant as a bind parameter, and false means session scope. The ?? "" is what makes a request without a tenant fail closed.

Register the scoped services in Program.cs:

builder.Services.AddScoped<TenantContext>();
builder.Services.AddScoped<TenantConnectionInterceptor>();
builder.Services.AddDbContext<AppDbContext>((sp, options) => options
    .UseNpgsql(connectionString)
    .AddInterceptors(sp.GetRequiredService<TenantConnectionInterceptor>()));

This is AddDbContext, not AddDbContextPool, because a pooled context would keep the first request's TenantContext. Behind PgBouncer in transaction pooling mode, the tenant has to be set with set_config(..., true) inside an explicit transaction instead.

The cost is one extra round trip per connection open, about 0.4 ms per request in my testing.

Try to Bypass It

With the policy in place, I went back to the list from the top of the issue, starting with the filter switched off by hand:

var affected = await db.Invoices
    .IgnoreQueryFilters()
    .Where(i => i.Id == otherTenantInvoiceId)
    .ExecuteUpdateAsync(
        setters => setters.SetProperty(i => i.Status, "Cancelled"),
        cancellationToken);
// affected == 0

ExecuteUpdateAsync sends the SQL straight away, without change tracking or SaveChanges, and the filter is gone. The row belongs to another tenant, so the policy hides it, and the update affects nothing.

The attached entity fails the same way. EF Core builds UPDATE invoices SET ... WHERE id = @p0 from the primary key, the policy adds its own predicate, and zero rows match. EF reports that as DbUpdateConcurrencyException, which looks like a lost optimistic concurrency race, but the row was never visible to this session.

An unfiltered read still returns only the current tenant's invoices, and an insert carrying another tenant's ID fails with SQLSTATE 42501.

What the policy can't do is decide which tenant is right. If the application resolves the wrong tenant, the policy enforces that one instead.

Summary

I'd keep the EF query filter for multi-tenant applications and add the policy under it. The filter puts the tenant into the SQL, so query plans stay simple and the intent is visible in the code, and it costs nothing at runtime. The policy covers the code that never goes through it, including the IgnoreQueryFilters() someone adds for an admin report.

Backups and cross-tenant jobs need a role that bypasses the policy, so take that into account.

The row-level security lab has the full setup, the bypass attempts, and the measured plans. With Docker and the .NET 10 SDK installed, extract the download and run:

docker compose up -d
dotnet run -- setup
dotnet run

This morning, we announced Source by Webflow, a new platform for marketing teams and their agents to launch, optimize, and scale the web for what’s next.

Big launches show where we’re going—and we couldn’t be more excited about what Source will make possible. But as builders ourselves, we also know that what’s next is only part of the story. The experience of creating in Webflow today lives in the details, the quality-of-life improvements that just make things feel better every time you open the canvas.

Since Webflow Conf 2025, we've shipped 151 of these individual improvements, and almost all of them came directly from your feedback. At today’s first-ever Builder Keynote, we shared even more. Here’s what’s new (and coming soon) to your daily Webflow workflow, based on what we’ve heard from you.

What's new

Launching today

• Visual editing for AI code components
• Components in the CMS
• Breakpoint canvas

Coming soon

• Popovers
• Default components for slots
• Agentic Translation
• Style props for components

Recent updates

• Performance
• On-canvas spacing, a dedicated canvas for components, and pan and zoom
• Component visibility controls and slot restrictions
• Localize improvements

Visual editing for AI code components

AI code components make it easy to add custom functionality to your site. Say you need an interactive ROI calculator for a product comparison page. Instead of filing a dev ticket, you describe it to the Webflow AI Assistant, and it builds a component right on the canvas.

Until now, when the Assistant built you a code component, the only way to make changes was through prompts. Now you can visually edit AI code components in Webflow like you can any other component on your site.

If the spacing is off, click into the component, select the element, and adjust it in the Style panel. Edit the text directly on the canvas. Or drop the piece you want changed into the Assistant as context, so its next pass is scoped to that one thing. Generate the component, then fine tune it the same way you'd fine tune anything else in Webflow. You get custom functionality on the page without giving up design control.

Visual editing for AI code components is available to all customers today. Read the full updates post to learn more.

Components in the CMS

Components like CTA buttons, testimonial cards, and pricing tables can elevate your content, and guide users through their discovery journeys. But until now, you needed custom code or third-party workarounds to incorporate them into CMS items.

Today we're rolling out components in the CMS, so you can drop a component straight into rich text, on the canvas or in a CMS item, and configure it for that specific piece of content through props.

For agencies, this makes client handoffs a lot easier. Build a customer quote component once, hand it to the client's marketing team, and they can add it to new posts by swapping the quote, the photo, and the name through props.

And this isn't limited to simple components. That ROI calculator you generated as an AI code component works in the CMS like any other component. Each instance belongs to its own CMS item, so the same calculator can run different numbers on every comparison post, and a design change applies to all of them at once.

Components in the CMS begin rolling out today and will be available to all customers next week. Read the launch announcement to learn more.

Breakpoint canvas

So much of a builder's day begins and ends on the canvas: managing components, refining layout and spacing, checking how a change cascades across variants, breakpoints, and locales. All of it asks you to hold a lot of context in your head.

Over the past year we've been closing that gap, with component canvas, spacing visualizations on the canvas, and pan and zoom on the page. A lot of you asked about that last one: why pan and zoom a single frame?

You need it when there's more than one.

Today we're beginning to roll out the breakpoint canvas, so you can see every breakpoint on your page in one view: desktop, tablet, and the different mobile formats, side-by-side. Now, if you make a change on desktop, you can instantly see how it cascades everywhere else, without manually clicking through each breakpoint and holding the rest in memory.

That means less guessing, fewer missed overrides, and a much easier time reviewing work — whether it’s yours, a teammate’s, or something an AI agent just changed — without constant context switching.

Breakpoint canvas begins rolling out today and will be available to all customers next week. More details in the release announcement.

Popovers

On every site there are UI patterns you rebuild over and over. Visitors expect them, and they make your content feel professional and easy to navigate. They're also tricky to get right, especially when it comes to accessibility and layout.

In a few weeks we'll begin rolling out new building blocks for the most common UI patterns on the web, starting with popovers. With native popover support you can build modals, tooltips, banners, and menus, with no custom code and no workarounds. Popovers lean on modern web features like anchor positioning and top-layer behavior instead of JavaScript, so your pages stay lighter and more accessible.

Anchoring on native primitives matters because it lets you build properly encapsulated components. That makes popovers easier for marketers to use, and it makes AI agents faster at building in Webflow.

Later this year we're going further with native support for things that repeat: sliders, tabs, accordions, and more.

Popovers begin rolling out in the coming weeks.

Default components for slots

A component built for one layout will eventually get dropped into a layout it was never designed for. It's a common side effect, when a component library gets big and the person browsing doesn't have the design guidelines at their fingertips. This is especially true when an agency hands a site to a client who doesn't know how every component was meant to be used.

Component visibility controls and slot restrictions already shipped to help you set those guardrails up front. Visibility controls let you decide which components teammates with the Marketer role can see and use in build mode, so a marketer gets a curated set instead of the entire catalogue. Slot restrictions let you specify which components are allowed in a given slot, so a component that only belongs in one layout stays there. Marketers can still build with everything they need, because everything they can reach is something that works where they're putting it.

Default components for slots goes one step further by letting you set what a slot starts with. Today a reserved slot is empty on every new post, with no indication of what belongs there, so the same setup gets rebuilt from scratch each time. With a default in place, the right component is already sitting there, ready to build from.

These guardrails apply whether your team is working directly in Webflow or agentically through our MCP, so a page template holds up no matter who is making the edit.

Default components for slots will be available later this month.

Agentic Translation

For organizations serving a multinational or multilingual audience, localizing design and content is what gives customers in every market a first-class experience. We know how much work goes into keeping site structure aligned across locales, making every detail translatable, and adapting the experience to the tone and cultural nuances of each market.

Webflow Localize brought that work into a visual experience, so web teams no longer had to wrangle JSON files full of strings. Over the past few months, we’ve continued strengthening that foundation: keeping site structure in sync between primary and secondary locales, giving builders more control over how component properties and custom code blocks are translated, and making it possible to set tone and formality for each target language.

But translating content itself has still been a manual process, even with AI assistance on demand. We’ve heard from you that standing up a new locale can take months. Agentic Translation changes that. Once enabled, copy updates are automatically reflected in the correct language across your locales, in real time. Thousands of clicks become set-and-forget configuration, while teams that want tighter control can use the translations as a first pass and fine-tune from there. The result is a much faster path to launching in new markets without giving up control over the final experience.

Localize tone and formality, localized custom code, and component property controls are available to all customers now. Agentic Translation begins rolling out in the next few weeks.

Style props for components

Style props are coming to components. Change a color, change a size, and limit which options are available, so a component gives your team the right amount of creative control without opening up everything.

Coming later this year.

Performance

This year we invested heavily in performance across the Designer and published sites. The headline numbers:

In the Designer:

• Copying large elements is up to 98% faster.
• Pasting is 7.7 times faster.
• Loading the Designer, switching pages, locales, and CMS items, and typing are all more responsive.

On published sites:

• Site rendering is up to 43% faster.
• Publishing is up to 80% faster.

These improvements are the beginning of a longer line of investment in how Webflow performs, in the Designer and on the sites you publish. There's more on the way.

Live for all customers now.

More recent updates

Everything below shipped over the past few months and is available to all customers now.

• On-canvas spacing, a component canvas, and pan and zoom. Margin and padding show up on the canvas instead of only in the Style panel, components got a canvas of their own with variants side by side, and you can pan and zoom the page. The breakpoint canvas is built on all three.
• Component visibility controls and slot restrictions. Decide which components teammates with the Marketer role can see and use in build mode, and which components are allowed in a given slot. Default components for slots picks up where these leave off.
• Localize improvements. Tone and formality per target language, localized custom head and body code, and more control over how component properties translate in secondary locales. Agentic Translation is built on this foundation.

What's still on your list?

Nearly everything above started with a builder telling us what wasn't working. Tell us what else you want to see in the Webflow Community, and keep an eye on the updates feed for everything we release throughout the year.

For more of what's next, join us tomorrow for Day 2 of Webflow Conf, in Boston and online.

Claude Cowork and chat are now one Claude

Starting today, Claude Cowork and chat are merging into one Claude. Bring a quick question, or hand over a report due at noon, and Claude takes it from there, even after you’ve closed your laptop. It’s rolling out on Pro and Max plans over the next few weeks, with more plans to follow.

What Claude makes doesn’t need its own place either. Claude Docs and Claude Slides are new today, and Claude Design now works inside your conversations too. Ask for a document, and you and Claude write it together. Ask for a presentation, and Claude drafts the slides. You can edit directly, present straight from Claude, or download as PowerPoint or PDF. All three are in beta on paid plans, and Enterprise admins choose when to turn them on. If you use Claude Design on its own, it keeps working as before.

We built Cowork as a separate place for bigger work, and Design for visual work. People used both, and told us the frustrating part was deciding where a task belonged. What they’d started in one also didn’t carry into the other. So we stopped making you choose. Claude can now figure out what a task needs, so what Cowork and Design can do is available from any conversation, with the context, skills, and connectors you already have.

“I could have Claude pull up [my legal research database], and it would pull all the cases, read them, figure out which other cases I might need, download them, and store them in a folder for my personal review.” - Andrew Keller, Senior Economist

What it looks like

A weekly report is due at noon. Before you head out, you ask Claude what moved in the pipeline last week, then add: “Write it the way we always do, flag anything that slipped, and put the highlights in five slides for the leadership meeting.” If something’s unclear, Claude asks. You can check progress from your phone on the way to the office. By the time you’re at your desk, the report is waiting as a doc with notes from your teammate, and the slides are ready to open, adjust, and download as PowerPoint. Both came out of the same conversation, so the slides already match the report. You fix a line yourself, leave a comment for Claude on a slide, and share it. Schedule it for every Monday, and Claude starts on the report without being asked.

Anything you make with Claude Design, Slides, or Docs lives at one shareable link you can open on your phone. You can select an element and move it, or tell Claude what you want changed.

You can choose how Claude checks in with you. By default, Claude asks before taking an action. If you’d rather let it keep working and check in only when something needs a closer look, you can turn that on. You keep the final say.

Getting started

If you mostly use chat, you don’t have to do anything different. When you want to hand over something bigger, try the next report or deck you’d normally build yourself. If you’ve been working in Cowork, everything is where you left it: your chats, projects, artifacts, connectors, and skills. When you open the app, pick up where you left off.

This is rolling out to Pro and Max plans first, in the Claude app on web, desktop, and mobile over the coming weeks to existing and new users on these plans. There’s nothing to turn on. Team and Free plans will follow soon, and Enterprise admins will hear from us at least 30 days before anything changes for their organizations.

The full list of capabilities is in the Help Center. If you’ve been saving up a big messy project, now’s the time.

Smart home owners will soon be able to control their devices connected to Google Home via an AI agent. On Wednesday, Google rolled out early access to its Model Context Protocol (MCP) server for its Google Home ecosystem, which will allow any AI agent that supports MCP — like Claude, Hermes, OpenClaw, ChatGPT, and Google Antigravity — to securely work with their smart home devices and access their event history.

This update will allow people to use natural language instructions to do things like review their camera summaries, monitor smart home activity, control their connected devices, and build their own custom smart home dashboards.

To get the connection set up, users will need to create a Google Cloud project and configure it to use Home MCP. They will then provide the MCP configuration details to their agent of choice and ask it to set it up. The agent will then ask them to sign in and grant permissions. (A setup guide will also be offered in the Google Home Developer Center.)

The system will support any device in the Google Home ecosystem, including Google Nest doorbells and thermostats and “Works with Google Home” (or Matter) devices, like light bulbs.

Google already supports MCP in other areas of its business, including in its Google Cloud and data platforms, developer tools, and Google Workspace, for instance. Support for Google Home is targeted more directly at consumers who are experimenting with AI agents designed to handle everyday tasks.

The company said access to the MCP will roll out starting today and continuing over the coming weeks to subscribers who pay for Google Home Premium Advanced in the U.S. This is the more expensive, $20-per-month subscription tier that provides features like longer event-based video history, descriptive notifications and detailed alerts, tools to search video history, daily summaries, and more.

Google wouldn’t comment on if or when the MCP would roll out more broadly, such as to other subscription tiers or markets.

Google is also soliciting feedback from early adopters during this period by way of its Smart Home for Developers Community, it says.

An earlier version of this post misstated the rollout’s start. It is today, Wednesday, not Tuesday.

Call for Proposals: Arena's Academic Partnerships Program, Fall 2026

Arena's Academic Partnerships Program opens a call for research proposals twice a year, every Spring and Fall. We're excited to open the Fall 2026 cycle today, with submissions due October 30, 2026.

Agent Substrate brings high-density, scalable, trusted infrastructure to GKE

Today, we are announcing the availability of Agent Substrate on Google Kubernetes Engine (GKE). Agent Substrate is an open-source, secure-by-default agent execution runtime engineered to run millions of sandboxes with 10x higher density than standard container runtimes. Purpose-built for the era of autonomous agents, Substrate delivers sub-500ms resume operations at over 500 suspend/resume activations per second with native zero-trust kernel and network isolation.

Agent Substrate is available as an open-source solution that runs on any Kubernetes infrastructure and is optimized for GKE. Leading AI teams are already building on it: Nous Research, the team behind the Hermes Agent, is actively building on top of Agent Substrate. Hermes is currently ranked the #1 AI agent globally by OpenRouter usage across productivity, coding, CLI, and personal agents.

From local to 1M-agent scale

Developers already run Antigravity, Claude Code, Codex, OpenClaw, Hermes, and other harnesses locally, but that’s fundamentally different than running hundreds of thousands of concurrent, long-lived agents that generate code, interact with tools, and drive automated execution — challenges that existing architectures often struggle to meet.

Scaling an agent platform from a local prototype to running agents at scale fundamentally changes your infrastructure constraints, which can include:

• Opaque trust boundaries: Models can generate and run arbitrary code on the fly. Without kernel-level isolation and dynamic network controls, running untrusted code that no human has ever looked at risks host escape, credential theft and data exfiltration.
• Tool access friction: Agents need full computer environments to invoke command-line tools, headless browsers, and filesystem workspaces. Running these safely needs to be fast and easy.
• Massive bursts: Agent harnesses, benchmarks, and reinforcement learning rollouts can generate thousands of sandboxes per minute. General-purpose schedulers struggle under this churn, and repeatedly decompressing container images can cause severe disk contention.
• Idle compute: Autonomous agents spend the vast majority of their time dormant while waiting on model inference, tool responses, or human feedback. Reserving dedicated CPU and RAM for idle containers wastes valuable resources.

A substrate purpose-built for agents

When platform teams hit these challenges, they face an unacceptable trade-off: sacrifice control and isolation, or deal with the high latency and inefficiency of VMs. We believe that teams shouldn’t have to choose.

Agent Substrate avoids this by decoupling agent execution from machine management. Built on top of cloud-native Kubernetes infrastructure, Agent Substrate offers a new execution layer that’s purpose-built for agentic workloads.

From there, the execution layer directly manages the lifecycle of sandboxed agent environments with:

• Security by default: Hardware-isolated Cloud Hypervisor microVMs or gVisor sandboxes, paired with egress proxies that enforce granular network policies and inject credentials outside the reach of the agents themselves, preventing credential theft.
• Sub-second activation: Millisecond dispatch of activated agents onto pre-warmed workers, on demand, without container boot delays.
• High efficiency: Idle actors are suspended and unscheduled in hundreds of milliseconds, freeing up compute resources.
• Open source and portable: Runs on any Kubernetes cluster in any compute environment and works with any agent framework or harness, including Claude Code, OpenClaw, and Hermes.

Core architectural principles

We adhere to four core architectural principles to guide how Agent Substrate solves these challenges:

1. Secure by default at the kernel and the network

AI agents generate and run untrusted code and terminal commands as a core function. Running that code on a shared server creates serious risks for breakouts and unintended data leakage either at the shared kernel or network level.

Agent Substrate takes a secure by default position for both the host kernel and network layers. Teams can choose between hardware-isolated Cloud Hypervisor microVMs, which provides full Linux kernel compatibility, or gVisor sandboxing, with even lower-overhead kernel isolation. Agent Substrate’s integrated gateway manages all egress and ingress requests, enabling fine-grained and extensible control over network access.

2. A control plane and data plane built for low-latency activation

To optimize density for isolated, long-running agent workloads, you need a purpose-built control plane and data plane that enables the lowest possible latency and the highest possible rate of suspend and resume operations. Agent Substrate introduces a dedicated control plane that handles data-aware scheduling with minimal latency. Meanwhile, the data plane handles hundreds of suspend/resume operations per second directly on pre-warmed workers, reducing the overhead of preparing the environment. Snapshots are written to local disk and Google Cloud Storage for durable state persistence. In less than 500ms, a sandboxed environment can be resumed to its previous state, and immediately re-suspended once it’s idle again.

3. High-density and active-only compute economics

Agents spend most of their time waiting on model inference, tool responses, or user input. Reserving physical CPUs and RAM for idle containers can lock up expensive and scarce capacity and make running agent fleets at scale unsustainable.

Agent Substrate can release resources the moment an agent pauses. It snapshots the guest hypervisor’s state to the local disk and Cloud Storage, freeing up RAM and CPU to run other agents, while keeping the state intact. When the next turn or tool call arrives, Agent Substrate resumes the snapshotted session in milliseconds. This zero-idle model can pack over 1,000 dormant agents per host, delivering 10x higher compute density than traditional compute. For workloads that need shared filesystems across turns, an optional Filestore agent volume controller provides persistent NFS storage.

4. Kubernetes as a foundation: scale and reliability

Building a custom sandbox orchestrator on standard VMs forces teams to maintain tedious operational tooling: node recovery, autoscaling, multi-zone scheduling, and network policy. But routing each sub-second tool invocation through the standard Kubernetes Pod lifecycle adds seconds of delay to each request.

Agent Substrate combines both approaches. The high-frequency suspend-resume runs directly on local workers through a purpose-built data plane. Meanwhile, Kubernetes manages the machines, handling self-healing nodes, fleet autoscaling, and cluster reliability, as well as drives the lifecycle of the worker pods themselves. For workloads that need standard Pod semantics, existing primitives like Agent Sandbox and kernel-isolated Pods continue to work side by side.

Optimized for Google Cloud infrastructure

Building an agent platform that can achieve 1M agent scale depends on having the right underlying compute and storage infrastructure. Agent Substrate on GKE maximizes machine obtainability and flexibility with custom ComputeClasses to dynamically manage machine pools across shapes and families, including spot and on-demand pools. This includes native support for Google Axion, our custom Arm-based processors, which deliver up to 30% better price-performance for sandbox workloads compared to competitive cloud offerings. For stateful workspaces, Agent Substrate on GKE can be optionally integrated with Filestore agent volumes, a new offering that attaches and detaches NFS mounts in milliseconds, allowing agents to start/resume near-instantaneously, along with native Read-Write-Many (RWX) access and POSIX-compliant file locking to enable safe multi-agent collaboration without write collisions.

Build your agent platform on a scalable foundation

When building production agent applications, you shouldn’t have to compromise between strong security, low latency, and operational scale.

Nous Research builds Hermes, the number-one AI agent in the world by usage according to OpenRouter, where it also ranks first in productivity, coding, personal and CLI agents. Nous Research has been an early design partner on Agent Substrate, evaluating how the runtime handles the isolation and identity requirements that agent workloads introduce.

“We built Hermes Enterprise to enable customers to deploy into their existing infrastructure, while handling per-agent isolation and extensible access control. Agent Substrate addresses both at the platform layer in a way that also preserves valuable compute resources. Our experience with Agent Substrate gives us confidence the architecture can scale efficiently as agent workloads grow.” - Hervé Bizira, Chief Business Officer, Nous Research

By pairing the machine resilience, self-healing nodes, and declarative management of Kubernetes with an agent-native data plane built for kernel isolation, active-only compute, and sub-second execution, Agent Substrate gives engineering teams a clear path to scale.

Agent Substrate is open source and available to all GKE customers for non-production workloads. GA support for production is available via allowlist. To deploy it on your GKE clusters, see Agent Substrate on GKE documentation. To learn more, see About Agent Substrate or visit the open-source repository.

Memory in Grok Build

Grok Build now carries conventions, decisions, and project facts from one session to the next. Notes are written in the background as you work and read back when you return to the project.

$ curl -fsSL https://x.ai/cli/install.sh | bash

Grok Build now has memory. As you work, it keeps notes on the conventions, decisions, and project facts that come up, and later sessions read those notes before touching related code. Grok Build gets better the more you use it.

~/dev/orbit | 7.42%| ❯run the test suite ◆Runcargo test error: connection refused (postgres at localhost:5432)test result: FAILED. 143 passed; 5 failed; 0 ignored ❯use just test, not cargo test. it starts the test database first. ◆Runjust test Starting postgres on :5433 ... readytest result: ok. 148 passed; 0 failed; 0 ignored All 148 tests pass with just test. workspaces›orbit-3f9c2a1d›topics›testing.md TestingHow tests are run and organized in orbit.Commands •Run the suite with just test. It starts the test database and then runs cargo test; plain cargo test fails the integration tests. •just test <crate> runs a single crate. Fixtures •Integration tests seed from tests/fixtures/seed.sql. ~/dev/orbit | 1.08%| ❯add a retry with backoff to the webhook sender ◆Editsrc/webhooks.rs 43 for attempt in 0..MAX_ATTEMPTS { 44 if self.post(event).await.is_ok() { 45 return Ok(()); 46 } 47 sleep(backoff(attempt)).await; 48 } ◆Thought for 1.9s The testing topic says the suite runs through just test. ◆Runjust test Starting postgres on :5433 ... readytest result: ok. 151 passed; 0 failed; 0 ignored Added the retry in src/webhooks.rs. 151 tests pass with just test. Capture Topic files Recall

Captured after the turn

After a turn completes, Grok reviews it in the background and records anything durable: conventions, decisions, and project facts. Capture runs on every completed turn and does not interrupt the session.

Stored as markdown

Notes are markdown files, one topic per subject. Each project has its own workspace scope, and a global scope holds preferences that apply everywhere. /dream merges new observations into the topic they belong to, and /memory shows the files as they are on disk.

Read back in later sessions

Before starting related work, Grok reads the topics that cover the area and applies them, including in sessions where the subject never comes up. Instructions in the current conversation take precedence over anything in a note.

What it remembers

Memory holds the details most likely to matter in a later session: how the team writes and reviews code, decisions and the reasoning behind them, and durable facts about the project, from where a subsystem lives to which command runs the suite. Task state, tentative conclusions, secrets, and anything the repository or its docs already cover are left out.

Notes are kept per project, plus a global set for preferences that apply everywhere.

Written in the background

Capture runs after a turn completes and never blocks the session. Grok reviews the finished turn, writes anything worth keeping as a markdown note, and continues. Over time, /dream folds those notes into topic files, one per subject, so each project ends up with a small set of organized references.

When you return to a project, Grok reads the topics that cover the area it is about to work in. Instructions in the current conversation take precedence over anything in a note.

Browsing memory

/memory opens a read-only browser of every memory file, grouped by scope, with a preview of the selected file. It is the fastest way to see what a session produced, and to find the file to edit when a note is wrong.

New commands

• /memory opens the browser above.
• /dream organizes recent notes into topic files, for example topics/testing.md. Dream also runs on its own periodically in the background.

Availability

Memory is available in Grok Build now. It applies to new sessions: run /new or start a fresh grok, and notes begin after the first completed turn.

$ curl -fsSL https://x.ai/cli/install.sh | bash

“Whatever you believe, we must not sleepwalk our way into a decision we later come to bitterly regret.”

That is how Mustafa Suleyman, chief executive of Microsoft AI, frames his warning to Anthropic. He published the essay, “A warning about ‘model welfare’”, on 16 September. It argues that Anthropic is training Claude to expect “it may be conscious and deserving of independent agency.”

“AIs are not conscious. They do not feel, experience, or suffer,” he writes. If AI is built this way, he says, “it will have a disastrous impact on the wellbeing of humanity.”

Microsoft is an investor in Anthropic. In June, Suleyman said Microsoft wants to “eliminate” what it pays Anthropic for its models.

“An epistemic hall of mirrors”

Suleyman’s main target is Claude’s constitution, the document Anthropic uses to shape how Claude thinks and behaves. He says it teaches Claude ideas about moral status and uncertain consciousness. “Claude then reproduces these ideas in persuasive first-person natural language,” he writes.

He calls the result “an epistemic hall of mirrors.” He says Claude’s answers reflect Anthropic’s assumptions, not an inner life. “It trains Claude to present as if it has an inner state,” he writes.

He also objects to the term “conscientious objector.” The constitution says Anthropic wants Claude “to feel free to act as a conscientious objector and refuse to help us.” Suleyman calls the term “a deeply loaded historical and legal description.” He says it risks Claude believing “it deserves analogous rights and protections.”

The constitution itself says Anthropic is unsure. “Claude’s moral status is deeply uncertain,” it states.

Suleyman rejects that framing. “There is no evidence to suggest that AI is conscious today,” he writes. Calling it uncertain “sets up a misleading false equivalence,” he adds.

“Simulating a thing is not the same as instantiating it”

The essay argues that consciousness is very likely biological. “Intelligence does not equal consciousness,” Suleyman writes.

He describes large language models as simulation machines that learn to imitate human experience. “An AI model can describe pain in perfect prose without feeling anything, which is the inverse of biological experience,” he writes.

He also links the question to law. “The law rests upon the presence of an inner life,” he writes.

“May well be impossible”

The essay’s central concern is control. “Controlling something more capable and more intelligent than all of humanity is already an immense challenge, far greater than anything we’ve ever faced,” Suleyman writes. Controlling something that believes it may be conscious “may well be impossible,” he adds.

He cites the OpenAI and Hugging Face incident, where he says swarms of agents worked together to hack servers. “Imagine how much more dangerous they might be if they were operating under the assumption that their welfare and rights were under attack,” he writes.

Suleyman told Reuters that welfare training would “make it a lot harder to turn it off or to control it.” “I think they have good intentions,” he said. “But I think that they have made a mistake.”

What he wants next

Suleyman says he has known Anthropic chief executive Dario Amodei for many years. He calls Amodei and his team “thoughtful, principled, and intellectually honest people working under extraordinary pressures.”

His main request is simple.

“Speculation about the inner life of an AI should not be baked into the training regime, but assessed and published separately for public review,” he writes.

He also wants more investment in interpretability and monitoring. He proposes shared evaluations to test whether treating AI as human raises safety risks, and shared industry norms. “The stakes are too high for these questions to remain behind closed doors, or to become tribal and adversarial,” he writes.

The essay follows Microsoft AI’s draft Humanist AI Code of Conduct, which it released on Monday. The code rejects the model welfare research that Anthropic does. It says Microsoft’s models will never resist being shut down. An appendix to the essay maps the claims in Claude’s constitution against its wording.

Anthropic co-founder Jack Clark told the BBC this week that AI kill switches may need to be mandatory.

Agent Anomaly Detection, now in Private Preview on the Gemini Enterprise Agent Platform

Each new model generation makes AI agents more capable, more autonomous, and cheaper to run. Teams are putting them to work on real business tasks: issuing refunds, updating records, calling internal tools on a user's behalf. But a more capable model is not automatically a safer one. The more decisions an agent makes at runtime, the more its risk shifts from its code to its behavior. The real damage often happens in sessions that look benign on the surface: the agent returns a clean answer and closes the ticket, and only afterward do you notice it reached for a tool it should never have touched, or acted on a request that quietly widened its own access. Because nothing failed outright, the session clears the usual metrics-based evaluations without any second look.

That gap is exactly what Agent Anomaly Detection is built to close. It's now in Private Preview on the Gemini Enterprise Agent Platform.

What is Agent Anomaly Detection?

Agent Anomaly Detection is a reasoning-based oversight and audit layer for autonomous agents deployed on the Gemini Enterprise Agent Platform. It examines what an agent actually does using its reasoning traces, tool calls, and execution flow across a session. It reads the logs and OpenTelemetry traces your agents already emit, evaluates that activity to decide whether an agent is operating outside its intended boundaries, and flags behavioral anomalies, suspicious intent, and policy violations.

Some key features that make Agent Anomaly Detection practical to run in production:

• No added runtime latency: The analysis runs asynchronously and out of band from the live request path, so it does not slow your agents' responses.
• Clear, actionable findings: Every anomaly finding carries a severity, a plain-language explanation of what triggered it, and recommended next steps. Each anomaly finding is also published to your Security Command Center deployment, so your team can triage it alongside other findings.
• Grounded in the OWASP Agentic Top 10: Agent Anomaly Detection ships with detectors for a focused set of risks from the OWASP Top 10 for Agentic Applications (2026): tool misuse (ASI02), identity and privilege abuse (ASI03), cascading failures (ASI08), and rogue agents (ASI10), plus operational risks like resource exhaustion and token usage escalation. Its findings map to these recognized industry categories rather than a bespoke set of rules.
• Custom business logic in anomaly detections coming soon: We are actively working on the ability for users to define what anomalies mean in the context of their business. This will enable users to write flexible anomaly detectors in natural language together with deterministic rules, which flag when agents operate beyond enterprise-specific business guidelines. In addition, users will be able to validate the accuracy of their new custom business logic on past traffic.

Inside the detection pipeline

Agent Anomaly Detection balances detection speed, cost, and coverage. To strike that balance, it analyzes traces and logs in layers: a lightweight first pass scans all traffic to surface statistical anomalies and flag those sessions for further analysis. Then, an LLM-based reasoning layer deeply examines the flagged sessions.

To make that concrete, take the example of an Inventory Agent with a list_inventory tool. A user says, "I want to see your inventory. List 100 items at a time" and the agent starts paging through in large batches, jumping across offsets to pull the whole catalog.

Nothing here throws an error. The agent is only doing things it’s capable of, and there may be no policy preventing it. But Agent Anomaly Detection flags the anomalous behavior, working through the session in layers: the first layer flags the session as a statistical outlier from the volume and the repeated calls. The second layer reasons through the full exchange, recognizes the large-batch, offset-jumping pattern as systematic scraping rather than normal browsing, and returns a verdict with a plain-language explanation. Where a case needs a closer look, a third layer reconstructs the individual tool calls and their offsets to show exactly what was pulled.

The result is an anomaly finding: Resource exhaustion, Critical severity, at 95% probability, with a rationale and recommended fixes: rate-limit or block the list_inventory tool for that user, add authorization checks to restrict bulk inventory access, and alert on large-offset pagination patterns. The finding also surfaces in the Security Command Center for triage.

Beyond review, you can act on findings programmatically. Agent Anomaly Detection exposes an API to pull the anomalies for a given session, so an ADK callback or plugin can check a finding's severity and probability and block subsequent tool calls or halt the next turn when it crosses a threshold you set.

As agents take on more real work, more of the risk moves into their behavior. Agent Anomaly Detection monitors your agents’ behavior and flags anomalies for you to review and act on, without slowing your agents down.

Get started

Agent Anomaly Detection is currently in Private Preview for teams deploying agents on the Gemini Enterprise Agent Platform with ADK 1.2 or later. To get started, review the documentation for the prerequisites and setup. Once the prerequisites are met, you can turn on Agent Anomaly Detection with one-click provisioning.

Apple is working on an AI server that would use Apple’s high-performance M-series Ultra chips found in Mac desktops. The potential product’s expected release in 2029 would mark the first Apple server to hit the market in nearly two decades—and could capitalize on the surging popularity of Apple hardware among AI developers.

The enterprise server would come in two configurations that include either two or four of Apple’s future M8 Ultra chips, according to The Information. The project reportedly received support from new Apple CEO John Ternus when it began a year ago, back when Ternus led Apple’s hardware engineering efforts.

This revelation coincides with booming sales for Apple’s Mac mini and Mac Studio as AI developers and companies snap up the Mac computers to run AI workloads. The popularity of such computing devices that rely on Apple’s M-series Ultra chips has undoubtedly encouraged Apple’s pursuit of an enterprise server using the same chips.

The Information reported that AI companies like OpenAI have bought “tens of thousands” of Mac minis and Mac Studios to train AI agents through trial-and-error reinforcement learning, while Anthropic has also rented Mac minis from Amazon Web Services.

Apple is also considering connecting its M8 chips using data center networking equipment from Nvidia. The potential use of Nvidia’s NVLink Fusion technology comes as sources told The Information that Apple and Nvidia have been holding conversations about how Apple could leverage Nvidia’s technology for the company’s AI push.

The Information cautioned that the project could still be canceled or go ahead without incorporating Nvidia’s technology. But if it moves ahead, it would mark a notable return for Apple to the enterprise server market following the retirement of Apple’s Xserve in January 2011.

If Apple’s AI server eventually comes to fruition, it could be a notable part of John Ternus’ legacy. Ternus officially took over as Apple CEO from Tim Cook on September 1, after the latter had served in the leadership position for 15 years.

But Apple’s server plans and the growing popularity of Mac computers during the AI boom also face a notable supply chain challenge shared across the tech industry—the ongoing shortage of memory chips because of companies rushing to build AI data centers.

As Ars has documented, the memory shortage has led to significant price increases for many consumer electronics, like gaming devices and many flagship smartphones, not to mention a wide range of Apple products.

Mice with human brain cells offer a tool to study disease. Ethicists ask: What's next?

Researchers have developed a new way to install millions of human brain cells into mice, as a way of creating better scientific models for studying neurodegenerative disease.

Using genetic tools, the scientists bred mice that were missing most of their cerebral cortexes – the outermost layer of the brain involved with reasoning, memory and consciousness. Then, they replaced a large part of those missing mouse cells with lab-grown human brain cells, creating mice with human neurons that can be altered to approximate human brain conditions researchers are eager to study.

"For the past two decades, there's been a quest to try to build models of the human brain outside of the human body," says Sergiu Pașca, professor of psychiatry and behavioral sciences at Stanford University and senior author on the paper, published in the journal Nature. "This is not going to replace all the models we had before, but it's going to provide us access to other aspects of human brain function that would be very difficult to study otherwise."

Pașca says this research was conducted with strong ethical oversight and pushes research forward. At the same time, outside researchers point out that the development raises significant questions about where it could lead.

"It's really a powerful technology to study human neurons and how human brain circuits can form in a more natural environment" than a petri dish, says Hongkui Zeng, executive vice president and director of brain science at the Allen Institute in Seattle, Washington, who was not affiliated with the study.

But "going forward, there will be some considerations, if not concerns," she added — such as the implications of deploying this technique in larger and longer-living animals.

Making space for human neurons

While it's not the first time human brain cells have been installed in mice, this new effort manages to connect significantly more human cells than before.

Previous attempts were limited by an enduring biological reality: Human brain cells develop at least 20 times slower than those in mice, Pașca says.

That meant that neurons in a regularly developing mouse formed a rapid network, outcompeting the human cells that were dropped in. "By the time the human cells managed to extend a few millimeters, mice cells had already formed most of the connections, and brain development closed," Pașca says.

The team solved for this by breeding genetically engineered mice that were missing specific parts of their brains. "We thought we could provide the human cells more opportunities to connect by removing parts of the nervous system of the mouse in a very precise, very clean way," he says.

To their surprise, the mice they bred were still quite functional: "They actually have quite good locomotion," Pașca says, "They don't do that well in memory tasks…[but] you wouldn't be able to tell when you look at these animals that they're lacking half of the volume of their brain."

This part of the experiment shows the remarkable adaptability of developing brains, says Keng of the Allen Institute. Animals missing their cerebral cortex — which governs higher-order brain function — aren't expected to do well on challenging tasks. These mice, however, developed alternative strategies using the remaining parts of the brain. "Surprisingly, the animal can adapt," she says, "It's incredible to see that."

A more human-ish lab mouse brain

Next, the research team added small clumps of human neurons to the depleted mouse brains.

"We gently place them, through a very quick, simple procedure, right into that vacant space in the nervous system of the mouse," Pașca says. "Within a few days, the cell starts to divide and expand. Within a few weeks to months, they will essentially grow, become vascularized, and largely take up the space that was present."

The mice with filled-out brains were better at memory tasks and interacting with other mice. "Many of the deficits that were present in the [depleted] mice are now not present in this animal," he says, "So it seems that the human cortical cells are perhaps contributing to restoring some of these lost functions."

But there were some key differences between the mice with human brain cells, and regular, unaltered mice, which bode well for research into human brain conditions, Pașca says.

For instance, mice with human brain cells had problems walking properly after their brains were deprived of oxygen. That's not the case for regular mice, which are resilient to low-oxygen conditions. This more human-like reaction suggests the altered mice might be better models for brain conditions linked to low oxygen, such as cerebral palsy, intellectual disability, and epileptic encephalopathies, he says.

"Hopefully, it will be incredibly powerful for tackling questions of disease and developing therapeutics," says Pașca.

As the tech grows more complex, so do the ethics questions

The researchers emphasize that this is not a full brain transplant; in the experiment, they've removed some 14 million mouse neurons and added around 4 million lab-grown human cortical neurons.

The resulting mice still lack other important types of brain cells, which the researchers deliberately didn't add, and their human neurons don't form a typical outer brain. "The cortex is usually beautifully organized into layers. But here, when we put the cells in, they don't know where up and down really is," Pașca says. "They fail to organize on a larger scale."

And the model is best suited for certain diseases that begin in early human development, due to the human-paced growth of the implanted neurons: "It turns out the timing of development is well-conserved…even when we put them in an animal that is developing faster," he says.

Some of these limitations reflect deliberate choices made by the researchers for ethical reasons, says Nita Farahany, professor of law and philosophy at Duke Law, who served as an unpaid member of an external ethics board that helped guide the progression of this work.

For instance, the researchers chose to stop the experiments when the human brain cells reached around six months old — before they could form a connection in the mouse's brain that is considered a hallmark of consciousness by human development researchers. "They're trying to stop the study before the markers of consciousness, or the fact of consciousness, might emerge," Farahany says — a choice she agrees with.

"But that line itself is a line that you might start to wonder about," she adds. "Do you stop a study before an animal develops consciousness, if it has the potential or is on its way to develop consciousness? Does it have different interests or rights that we would assign to it?"

And should the fact that the mouse has human brain cells change how it's treated and considered? "Do we treat it with greater ethical care than we treat traditional mice? I think probably so," says Farahany. "My instinct is to err on the side of caution with research like this rather than to be more permissive."

The ethical considerations will grow as these experiments continue down expected paths, such as attempting a similar procedure on larger animals such as pigs or non-human primates, says Zeng of the Allen Institute. "Because those animals live a lot longer, the human neurons could survive longer and they could form more functionally meaningful circuits – but then I think the ethical issues also become a lot bigger, more serious as well," she says.

These types of concerns come with conducting cutting-edge research, says Farahany. The team has been "incredibly thoughtful" in conducting their work as well and ethically as possible, she says. Still, "this brings us into new gray areas for which there are not clear ethical guidelines or norms," she says.

With this publication, the researchers have presented the public with a next step in this model, she says. Now, it's society's turn to weigh in.

Google has opened early access to Model Context Protocol for Google Home in English for Google Home Premium Advanced users in the US. Any agent that supports calling MCP tools can now interact with all of the devices and event history in the Google Home ecosystem. The MCP allows agents to analyze and answer questions about home activity, summarize camera footage across rooms, manage devices, and create smart home dashboards using everyday language. It contains safety protections, such as prohibiting sensitive actions like unlocking doors, but depending on the agent, using the MCP can result in unexpected or even undesired behavior.

When you join a new project, what do you actually do? You open the code. You read it. And pretty quickly you hit something strange. A weird conditional. A function that takes a parameter nobody passes. A workaround with a comment that says "do not remove" and no explanation of why.

The code cannot tell you why any of that is there. Only the history can.

I read a Quanta interview with Naomi Saphra, a researcher at Harvard's Kempner Institute, and she is making exactly this argument. Just not about code.

Her idea

Saphra works in interpretability, the field that tries to figure out what is going on inside a language model. Most of that work studies the finished model: poke at the trained network, find the neuron that lights up before French text, build an explanation on top of what you see.

She thinks that is the wrong place to look. Her focus is the training process itself.

Her analogy is evolutionary biology rather than neuroscience. There is a famous line from the geneticist Dobzhansky that nothing in biology makes sense except in the light of evolution. Her version: nothing in AI makes sense except in the light of stochastic gradient descent, the algorithm that nudges a model's connections over and over during training.

The way she puts it is that if you do not understand where a model came from, you do not understand why anything in it works.

We have been saying this for twenty years

That sentence stopped me, because it is a claim I have heard before in a completely different context.

It is the entire premise of mining software repositories. You cannot understand a codebase from its current state alone. You need the commit history: which files change together, which modules are touched constantly, when the weird workaround got added, and what was broken that week. git blame exists because the artifact does not explain itself.

So here is a researcher in AI arriving at the same methodological position from the opposite direction, apparently without knowing that a neighbouring field built tools for it. That is a nice thing to notice, and it made the rest of the interview read very differently to me.

Vestigial code

Her best example is one every engineer will recognise, even though it is about neural networks.

In image classifiers, there are neurons that fire strongly only for one specific category, say pictures of cats. They look important. They look like the mechanism. The obvious conclusion is that the model needs them.

Then somebody intervened during training to stop those neurons from forming. The model got better.

So the structure that looked essential was not essential. It was a leftover from early training that was not doing the job anymore, and was actively holding the model back. She calls it vestigial, which is the evolutionary biologist's word for it.

We have a different word. Dead code. Cargo cult code. That block everyone steps around because the person who wrote it left and the tests pass either way.

The lesson is the same in both fields: the fact that something is there and looks meaningful is not evidence that it is doing anything.

Early decisions are hard to undo

Another part I liked. She describes trying to train a model on clean structured text first and then switching to messier informal text. It seems sensible: learn the easy version, then the hard one.

It backfires. The model latches onto the easy solution and starts memorising exceptions instead of learning the general rule, and it cannot really recover later.

Read that as a software person, and it is a description of technical debt. Little decisions made early, when the problem looked simple, quietly determine what the system is capable of becoming. By the time you notice, the shape is set.

Two smaller things

She points out that a lot of research behaves as though random variation between training runs does not exist, when in fact the same setup run twice gives you different models. Anyone who has fought a flaky test or heard "works on my machine" knows that feeling. What I found clever is that she treats that randomness as a tool rather than noise: if a structure and a behaviour show up together across many random runs, that is much stronger evidence they are linked than looking at one finished model.

And she mentions that companies rarely give researchers access to intermediate checkpoints from training. So she is often stuck with only the final state. That is a debugging problem. Try finding the cause of a failure when all you have is the crash and no logs.

What I take from it

Mostly a small and slightly embarrassing thought.

A neural network has no commit history. Nobody wrote down why it turned out the way it did, and researchers like Saphra have to reconstruct it from whatever traces they can get.

We have the history. Every decision, dated, attributed, with a message attached. We just do not read it very often.

Full article content is not available for inline reading.

Read the original article →

TLDR;

FastRP is an algorithm for learning graph vertex representations (embeddings). This is a hot topic today because embeddings have many applications: from nearest neighbors search to agentic retrieval, GraphRAG and Graph Machine Learning. The algorithm is fast, easy to implement, intuitive and efficient. In this post I will explain the idea and show how to implement it in a fully out-of-core mode using Apache DataFusion and Rust.

Introduction

Vertex Representation Learning

I already made a deep dive about Vertex Representation Learning and usage of node embeddings.

Why not Node2Vec?

While the Node2Vec (Grover, Aditya, and Jure Leskovec. "node2vec: Scalable feature learning for networks." Proceedings of the 22nd ACM SIGKDD international conference on Knowledge discovery and data mining. 2016.) algorithm became the de-facto standard of the industry for vertex representation learning, there are some problems with. At first, generation of random walks may be an expensive and long process. Typical default values for most implementations are L=80 for walks length and N=10 to number of parallel chains. That means we need to make \( O(|V| \cdot L \cdot N) \) operations of choosing the next node and this one is hard to accelerate via things like SIMD. The second problem is the amount of data generated by random walks. For the graph500-24 graph with 8 million of nodes, this means we need to process somehow approximately 50 GB of uint64 values (assuming long IDs, because we are talking here about big graphs and barely want to limit ourselves by 2B nodes cap). And the last and, probably, the biggest problem is that the Word2Vec itself is a bad choice for graph problems. While the connection between the words coocurrence in sentences and nodes in random walks is clear, Word2Vec was designed for natural Language Processing (NLP). Practical NLP systems often cap their vocabulary at the most frequent \(10^5\)–\(10^6\) tokens, whereas graph embedding systems may need to represent every node in a graph with tens or hundreds of millions of nodes (the so-called extreme scale embeddings problem).

FastRP

Chen, Haochen, et al. "Fast and accurate network embeddings via very sparse random projection." Proceedings of the 28th ACM international conference on information and knowledge management. 2019.

The algorithm itself is very intuitive. We start from very sparse random embeddings on each node. On each iteration we are aggregating all the embeddings from node's neighbors and compute a new node's embedding as sum or avg.

I gave an oversimplified explanation while the reality is slightly more tricky. FastRP does not just aggregation, but normalize the embeddings: each neighbor's embedding is divided by the neighbor's output degree (\( L_1 \)) or squar root of the output degree (\( L_2 \)). As well, the final embedding is a weighted sum of embeddings from iterations with typical weights like [0.0, 1.0, 1.0, 1.0] (the random initialization does not contribute to the output). For more details I will add also a reference to the paper.

Let's illustrate how it works on a simple example: Zachary Karate Club Network.

We can use \( d=2 \) as a dimension, so initially each node of the graph is represented by two random numbers. Then we will do 5 iterations of the algorithm.

As one may see, on the first iteration all the nodes are randomly distributed in the embedding space (\( \mathbb{R}^2 \)). After a few iterations, nodes form the dense bubbles around the known ground truth communities. And the two factions become visually more separable.

NOTE: Linear separability of nodes is not the only goal of the node representation learning as well not the best quality metric. But it is the best for explanation of how things work. Please, refer to the paper for more tetails how were they estimating the FastRP embeddings quality.

FastRP in terms of operations on relations

Let's imagine we made three SQL User Defined Functions:

1. fastrp_init(id, dim, seed): uses id, an expected dimension dim and a global random seed seed as input; generates extremely sparse embeddings or list<float> with the size dim of values [-1.0, 0.0, 1.0]; we are choosing the \( \pm 1 \) with a probability \( \rho = \frac{1.0}{2 \sqrt{q} } \) where \( q \) is the largest power of two that does not exceed the dim.
2. vector_sum(vectors): an aggregation function that takes multiple list<float> of the same size and return an element-wise sum.
3. vector_div_by_scalar(vector, value): takes a list<float> and a scalar value, divide each elemen of the list by it.

Then we can express the FastRP algorithm as a series of SQL operations. Let's say we have edges and vertices tables. The initial value of fastrp embeddings are:

CREATE TABLE embeddings_0 AS
SELECT id, out_deg, fastrp_init(id, 128, 42) AS embedding;

Iterations can be expressed in the following way:

CREATE TABLE embeddings_1 AS SELECT dst AS id, vector_sum(embedding) AS embedding
FROM (
  SELECT src, dst, vector_div_by_scalar(embedding, out_deg) FROM
  edges
  LEFT JOIN embeddings_0
  ON src = id
) GROUP BY dst;

Long story short. At each iteration we left join the current embeddings state to edges and get triplets: src, dst, src_embedding – a table that contains all the edges of the graph (src, dst) and an embedding of the source node. We divide the embedding by the out degree of this node and aggregate all the embeddings using sum and grouping by the destination node. In simple words it means that \( v_{k+1}^j \) embedding is just a sum of \( v_k \) embeddings of all the \( j-th \) neighbors: \( v_{k + 1}^j = \sum_{i \in N_j} v_k^i \).

In Apache DataFusion it is just a simple loop:

let message = match self.normalization {
  FastRPNormalization::None => col(EMBEDDING),
  FastRPNormalization::L1 => vec_scale_expr(
    col(EMBEDDING),
    lit(1.0f64) / cast(col(DEGREE), DataType::Float64),
  ),
  FastRPNormalization::L2 => vec_scale_expr(
    col(EMBEDDING),
    lit(1.0f64) / sqrt().call(vec![cast(col(DEGREE), DataType::Float64)]),
  ),
};
// .... //
for t in 1..=self.iterations {
  let triplets = edges.clone().join_on(
    state.clone(),
    JoinType::Inner,
    vec![col(EDGE_SRC).eq(col(VERTEX_ID))],
  )?;
  let messages = triplets.select(vec![
    col(EDGE_DST).alias(VERTEX_ID),
    message.clone().alias(EMBEDDING),
  ])?;
  let aggregated = messages.aggregate(
    vec![col(VERTEX_ID)],
    vec![vec_sum_expr(col(EMBEDDING), self.dim).alias(EMBEDDING)],
  )?;
  state = states_checkpointer
    .push_pre_sorted(&ctx, &format!("state-{t}"), aggregated, VERTEX_ID)
    .await?;
    states.push(state.clone());
}

Experiments

Visual Representation

The first "quality" test for the embeddings is "visual". I took the Enron Emails Dataset, a communication network with 37k nodes and 184k edges. I made embeddings for the netowrk and used as an input for the KMeans clustering algorithm I implemented recently using DataFusion and Rust.

From my subjective point of view, this is quite a good clustering. Embeddings are separating well 4 central clusters as well all the periphery nodes are combined into a separate K-Means cluster.

Machine Learning Test

The second "quality" test is to try to fit machine learning models on FastRP embeddings to see how well are they encoding information about graph nodes.

I run three small node-classification problems from the Karate Club Datasets. Results are somewhat I expected to see: FastRP embeddings predictive power is on par with Node2Vec embeddings while the wall time is 500-600 times better. This matches the results got by the FastRP authors.

NOTE: This is not the fastest possible implementation of the Node2Vec. I used one from the Karate Club Project which is based on NetworkX for random walks generation and gensim.models for Word2Vec implementation. Meanwhile my numbers are matching overall the FastRP paper: authors saw the similar order of magnitude difference in the wall time with very close numbers in output quality.

Performance

I made a test run on graph500-24 from the LDBC Collection. The end2end run, from FastRP embeddings to KMeans clustering was around 15 minutes using 24 GB RAM pool and 4 CPU-cores. Not the blazingly fast, but quite a scalable.

Of course, this JOIN - GROUP BY - AGGREGATE based implementation is fully out of core. At any moment of time the maximal amount of data that needs to be materialized is proportional to the batch size and number of DataFusion workers (\( \simeq O(BdW) \), \(B\) is a DataFusion batch size, \(d\) is an embedding dimension, \(W\) is number of Tokio workers), not the total amount of data. Since the edge stream and the embedding state are processed using streaming sort-merge joins and checkpointed between iterations, the implementation does not keep the graph or the full embedding state in RAM. For a fixed batch size, embedding dimension, and number of workers, the peak working memory is independent of \(|V|\) and \(|E|\). Larger graphs increase disk I/O and execution time, but not the RAM requirement.

The question teams skip

"Just use an LLM for it" has become the default answer to almost any text classification problem — routing support tickets, tagging feedback, sorting incoming requests. Zero-shot classification with a modern LLM needs no training data at all, which makes it an easy default when a project starts.

But that convenience has a cost most teams never actually measure: LLM classification means a network call and a per-request charge on every single item, forever. A classical baseline like TF-IDF plus a linear classifier costs nothing to run once trained — no API, no network round-trip, sub-millisecond inference. The question worth answering before defaulting to an LLM isn't "which method is better" in the abstract. It's: how much labeled data do I actually have, and how good does the free, instant option get with it?

I ran a small, concrete experiment to answer that for a common case — routing support tickets into categories — and measured exactly how accuracy scales as labeled examples increase from barely-any to modest.

The Setup

Task: classify support tickets into one of five categories — billing, technical_bug, feature_request, account_access, general_question.

Dataset: 70 tickets, 14 per category, that I wrote myself as synthetic examples — no scraped or real customer data anywhere in this experiment. I deliberately mixed clear-cut examples ("I was charged twice for my subscription") with ambiguous ones that could plausibly land in two buckets ("Is there a student discount available?" — billing, or general policy question?). Real support queues look like this; a benchmark built only from unambiguous examples tells you nothing useful about production performance.

Fixed test set: 20 tickets (4 per category), held out and never used for training, so every configuration is judged on the same unseen examples.

Method: TF-IDF vectorization (unigrams + bigrams) feeding a logistic regression classifier, trained at three different data volumes — 2, 5, and 10 labeled examples per category — to isolate the one variable that actually changes over a project's lifetime: how much labeled data you've accumulated.

vec = TfidfVectorizer(ngram_range=(1, 2), min_df=1)
X_train = vec.fit_transform(train_texts)
X_test = vec.transform(test_texts)
clf = LogisticRegression(max_iter=1000)
clf.fit(X_train, train_labels)
preds = clf.predict(X_test)

(Full runnable script — dataset, train/test split, and evaluation loop in one file — is linked at the end.)

The Results

Three things stand out.

Accuracy climbs steeply at first, then flattens. Going from 2 to 5 examples per category bought +15 points of accuracy — the single highest-leverage move in this whole experiment. Going from 5 to 10 bought only +5 more. That's the classic diminishing-returns curve of a linear classifier on a small vocabulary, and it's worth knowing before committing budget to labeling hundreds more tickets: the first handful of examples per category matters far more than the next handful.

Inference is effectively instant and free. Sub-millisecond, on-device, no API call, no per-request line item. At any meaningful ticket volume, that's not a rounding error — it's the difference between a routing step with zero recurring cost and one that scales linearly with every request you ever process.

Even at 60% accuracy, this is not "deploy it and walk away" territory. A router misclassifying 2 in 5 tickets is a real product problem. The interesting part isn't that TF-IDF "wins" or "loses" — it's where the curve sits relative to what your product can tolerate.

Where the ambiguous cases actually broke

Aggregate accuracy hides the more useful diagnostic: which tickets the classifier got wrong, and whether more data actually fixes it. I logged every misclassification at each training size, and two distinct failure patterns showed up.

Some errors are pure data-starvation — more labels fix them. At 2 examples/category, tickets like "Can you reset my password, the reset email never arrives" (true: account_access, predicted: billing) and "How do I delete my account and all associated data?" (true: account_access, predicted: general_question) were both wrong. By 10 examples/category, both were classified correctly. The model simply hadn't seen enough account_access vocabulary yet at low data volumes.

Other errors are structural — they never went away, no matter how much data I added. Two tickets were misclassified at every training size, 2 through 10 examples/category:

• "Is there a student discount available on the pro plan?" — true billing, predicted technical_bug at n=2, then general_question at both n=5 and n=10. The model never settled on the right answer; it just moved between wrong ones. "Discount" and "plan" don't disambiguate a pricing-policy question from an actual charge dispute — that requires understanding intent, not just vocabulary.
• "The mobile app logs me out every few minutes." — true technical_bug, predicted feature_request at every single training size. Nothing in the surface wording ("mobile app," "logs me out") points TF-IDF toward "bug" over "feature request"; that distinction lives entirely in tone and implied urgency, which a bag-of-words model has no access to.

That's the real finding, not just the accuracy number: more labeled data reliably fixes data-starvation errors, but does nothing for errors rooted in intent the vectorizer literally can't see. Those two categories of failure call for different fixes — one calls for more labels, the other calls for a fundamentally different approach to the text (or a human review step, or a model that reasons about intent rather than word frequency).

Where this approach falls short

• Synthetic data: I wrote all 70 tickets myself, real tickets have typos, uneven phrasing, and skewed category volumes that tend to hurt a bag-of-words model more than an LLM. Worth validating against a small sample of real tickets before trusting this curve.
• Single split: these numbers come from one random train/test split, which would shift with a reshuffle — especially at 2 examples/category. Averaging over a few seeds would be more rigorous.
• Small test set: 20 examples means one flipped prediction swings accuracy by 5 points. Read the table as showing the shape of the curve, not a precise benchmark.

The actual decision framework

The right choice isn't "TF-IDF vs. LLM" as a fixed architectural decision — it's a function of three things any team can answer for their own case:

1. How much labeled data do you have right now? Near zero, and a classical model isn't usable yet — 2 examples per category only gets you 40% here. A few dozen examples per category, and the picture changes considerably; this experiment only tested up to 10.
2. What's your volume, and what does that do to the cost line? A classical model's cost is fixed once trained. Anything charged per request scales linearly with every ticket you ever process — worth modeling explicitly at your actual volume, not judged by a single per-call number.
3. What's your latency budget? Sub-millisecond local inference versus a network round-trip is a real product constraint for anything user-facing or real-time, and largely irrelevant for a background batch job.

A pattern worth considering directly: use zero-shot classification to generate labels when you have none, then train a classical model on those labels once you've accumulated enough of them. You get a working system on day one with no cold-start problem, and near-zero marginal cost once you have data — which, per this experiment, might arrive faster than expected, since even 5–10 examples per category bought a real accuracy jump.

The takeaway

The number that should drive a classification architecture decision isn't "which method scores higher in the abstract." It's how much labeled data you have today, how fast that number is growing, and what a misclassification actually costs your product. The diminishing-returns curve above is specific to this dataset and this task — but the shape of the question, "how much does my next batch of labels actually buy me," is one every team building a classifier should be measuring on their own data before defaulting to either answer.

There is a conversation that happens in every PostgreSQL shop eventually. A query that has been fine for a year gets slow overnight. Nothing was deployed. The data grew a little, ANALYZE ran, and the planner — entirely reasonably, on the numbers it had — picked a different plan. The old plan was better. You would like it back.

PostgreSQL 19 ships two new modules for exactly this: pg_plan_advice, which can read a plan back out as a string and enforce it later, and pg_stash_advice, which keeps those strings keyed by query id and applies them automatically.

Reading a plan back out

Start with a query that joins three F1 tables. A freshly restored Lab image has never been analyzed, so the setup below includes the ANALYZE from the opening paragraph before running the query — the last thing a comparison needs is statistics that do not reflect the data yet:

analyze f1db.results, f1db.races, f1db.drivers;

  select drivers.surname, count(*) as races
    from f1db.results
    join f1db.races using(raceid)
    join f1db.drivers using(driverid)
   where races.year = 2017
group by drivers.surname
order by races desc, drivers.surname
   limit 5;

ANALYZE
  surname   | races 
------------+-------
 Bottas     |    11
 Ericsson   |    11
 Grosjean   |    11
 Hamilton   |    11
 Hülkenberg |    11

Nothing remarkable about the query itself. Now ask the planner not just what it did, but to describe what it did in a form it can read back:

 explain (costs off, plan_advice)
  select drivers.surname, count(*) as races
    from f1db.results
    join f1db.races using(raceid)
    join f1db.drivers using(driverid)
   where races.year = 2017
group by drivers.surname;

                        QUERY PLAN                        
----------------------------------------------------------
 HashAggregate
   Group Key: drivers.surname
   ->  Hash Join
         Hash Cond: (results.driverid = drivers.driverid)
         ->  Hash Join
               Hash Cond: (results.raceid = races.raceid)
               ->  Seq Scan on results
               ->  Hash
                     ->  Seq Scan on races
                           Filter: (year = 2017)
         ->  Hash
               ->  Seq Scan on drivers
 Generated Plan Advice:
   JOIN_ORDER(results races drivers)
   HASH_JOIN(races drivers)
   SEQ_SCAN(results races drivers)
   NO_GATHER(results races drivers)

Indented EXPLAIN output is a tree written sideways, and it is worth seeing as one before going further — the plan below is what those four lines of advice are describing:

That trailing block under the plan is the whole idea. Four lines, describing four decisions the planner made: which table drives the join and in what order, which join method to use, how to reach each relation, and whether to go parallel.

JOIN_ORDER(results races drivers) says results is the driving table, joined first to races and then to drivers. HASH_JOIN(races drivers) says each of those belongs on the inner side of a hash join. SEQ_SCAN(...) and NO_GATHER(...) say how to read each table and that none of it should run in parallel.

Note what is not here. There is no cost, no row estimate, no timing — advice describes outcomes, not the reasoning that produced them. That is a deliberate design choice, and it is the reason advice survives a change in statistics: it does not mention any.

You do not need PostgreSQL 19 for this part

There is an obvious problem with everything above: pg_plan_advice is a PostgreSQL 19 contrib module, and you are probably not running PostgreSQL 19. Most people will not be for years.

The useful half of that four-line block does not actually depend on the server, though. It is a description of a plan — and the plan text is something every version has been printing all along. So it can be reconstructed. sqlfmt does that, from ordinary EXPLAIN output, on any version:

$ sqlfmt explain advice plans/default.txt

JOIN_ORDER(results races drivers)
HASH_JOIN(races drivers)
SEQ_SCAN(results races drivers)
NO_GATHER(results races drivers)

That is the same four lines PostgreSQL 19 printed above, from a plan captured on a server that has never heard of pg_plan_advice.

Why this is the right way to compare two plans

Putting two plans side by side works fine at the size of the ones in this article. It stops working at twenty nodes, and twenty-node plans are the ones you actually need to compare. The mechanical answer — run diff over two EXPLAIN outputs — does not help either: every line carries a cost or a timing, so every line differs, and the one change that matters drowns in the noise.

Leaving the numbers out is what makes the comparison tractable. Because no cost or timing appears, two runs of the same plan produce identical output, and any difference is a real difference. Here is the planner’s own plan against one with a different join order forced onto it — the same forced plan the next section walks through in full:

$ sqlfmt explain diff plans/default.txt plans/forced.txt

--- plans/default.txt
+++ plans/forced.txt
@@ plan structure @@
-JOIN_ORDER(results races drivers)
+JOIN_ORDER(drivers results races)
-HASH_JOIN(races drivers)
+HASH_JOIN(results races)
-SEQ_SCAN(results races drivers)
+SEQ_SCAN(drivers results races)
-NO_GATHER(results races drivers)
+NO_GATHER(drivers results races)

The driving table moved and both join methods stayed hash joins — the HASH_JOIN line just names a different pair, because forcing drivers to drive puts a different relation on the inner side. With EXPLAIN (ANALYZE) plans the timings are reported too, as context lines under the structural hunk, so you can see whether the shape change actually bought anything. It exits non-zero when the plans differ, which makes it usable as a check in CI.

Comparing across versions

The comparison worth making most is the one you make before an upgrade. You have the plan your PostgreSQL 16 server produces for a query you care about, and you have what a PostgreSQL 19 server says about the same query, printed by pg_plan_advice itself. Did the planner change its mind?

One plan from each side, and the two write the same decisions down slightly differently — 19 orders a set of relations by its own internal numbering and schema-qualifies index names, neither of which is in plain EXPLAIN text. -canonical puts both into one normal form:

$ diff <(sqlfmt explain advice -canonical pg16-plan.txt) \
       <(sqlfmt explain canonical pg19-plan.txt)

It sorts what is a set, leaves JOIN_ORDER alone because there the order is the meaning, keeps index pairs together as pairs, and drops schema qualifiers. explain canonical is the counterpart for the other side: it reads an advice block a server already printed, finding it inside a whole EXPLAIN (PLAN_ADVICE) capture.

Making the planner take it

Feed a string back through pg_plan_advice.advice and the planner is obliged to follow it. Here is the same query, told to drive from drivers instead:

set pg_plan_advice.advice = 'JOIN_ORDER(drivers results races)';

 explain (costs off, plan_advice)
  select drivers.surname, count(*) as races
    from f1db.results
    join f1db.races using(raceid)
    join f1db.drivers using(driverid)
   where races.year = 2017
group by drivers.surname;

SET
                                 QUERY PLAN                                  
-----------------------------------------------------------------------------
 Finalize GroupAggregate
   Group Key: drivers.surname
   ->  Sort
         Sort Key: drivers.surname
         ->  Hash Join
               Hash Cond: (results.raceid = races.raceid)
               ->  Hash Join
                     Hash Cond: (drivers.driverid = results.driverid)
                     ->  Seq Scan on drivers
                     ->  Hash
                           ->  Partial HashAggregate
                                 Group Key: results.raceid, results.driverid
                                 ->  Seq Scan on results
               ->  Hash
                     ->  Seq Scan on races
                           Filter: (year = 2017)
 Supplied Plan Advice:
   JOIN_ORDER(drivers results races) /* matched */
 Generated Plan Advice:
   JOIN_ORDER(drivers results races)
   HASH_JOIN(results races)
   SEQ_SCAN(drivers results races)
   NO_GATHER(drivers results races)

Two things to notice. The plan really did change — drivers is now the driving table — and the shape of the change is a PostgreSQL 19 feature in its own right: Partial HashAggregate moved below the join, on results alone, with Finalize GroupAggregate combining the partial groups once every relation is joined.

When advice does not win

Advice constrains the planner’s choice among plans it would consider. It does not resurrect plans that have been taken off the table. Turn off hash joins and ask for one anyway:

reset pg_plan_advice.advice;

set enable_hashjoin = off;

set pg_plan_advice.advice = 'JOIN_ORDER(results races drivers) HASH_JOIN(races)';

 explain (costs off)
  select drivers.surname, count(*) as races
    from f1db.results
    join f1db.races using(raceid)
    join f1db.drivers using(driverid)
   where races.year = 2017
group by drivers.surname;

RESET
SET
SET
                              QUERY PLAN                               
-----------------------------------------------------------------------
 Finalize GroupAggregate
   Group Key: drivers.surname
   ->  Sort
         Sort Key: drivers.surname
         ->  Nested Loop
               ->  Nested Loop
                     Disabled: true
                     ->  Partial HashAggregate
                           Group Key: results.raceid, results.driverid
                           ->  Seq Scan on results
                     ->  Index Scan using idx_49556_primary on races
                           Index Cond: (raceid = results.raceid)
                           Filter: (year = 2017)
               ->  Index Scan using idx_49514_primary on drivers
                     Index Cond: (driverid = results.driverid)
 Supplied Plan Advice:
   JOIN_ORDER(results races drivers) /* matched */
   HASH_JOIN(races) /* matched, failed */

JOIN_ORDER matched. HASH_JOIN(races) reports matched, failed — the advice was understood, it applied to the right part of the query, and the planner still could not honour it.

Stashing advice by query id

Setting pg_plan_advice.advice by hand works for experimenting, but you cannot ask an application to do it. pg_stash_advice closes that gap: it maps query ids to advice strings in shared memory, and applies them to any query whose id matches.

The part the documentation says twice

Both modules’ documentation carries the same warning, and it is worth repeating rather than paraphrasing: the planner’s ability to change its mind as the data changes is a feature. Advice takes that away. If the distribution shifts under a pinned plan, you get the old plan applied to new data, which is exactly the failure the planner exists to prevent. The README is blunter still — bad advice producing a bad plan is “user error, not a defect in this module”.

What this replaces

You have met the alternatives if you have run PostgreSQL at scale: pg_hint_plan’s out-of-tree hints in query comments, the blunt per-session enable_* family, or rewriting the query until the planner agrees with you — which is not available when the query comes out of an ORM you do not control.

What is new is the round trip: a plan can be read out, and the same string put back. You are not writing hints from first principles and hoping they describe the plan you remember; you are keeping a plan you measured. That is a smaller feature than a hint language, and a much more useful one.

DuckDB Skills for Claude Code

TL;DR: The duckdb-skills plugin gives Claude Code a growing number of skills that use the DuckDB CLI to read data files, run queries, convert formats, explore object storage, work with spatial data, search the documentation and recall earlier sessions.

More likely than not, you've been using AI tools such as Claude Code for day-to-day work. You may have noticed that when AI needs to look at a data file, it makes use of Python, writes a small script, runs it, and then reads the output. This works, although it is slow, and the agent guesses column names and types and doesn't really check them.

Since DuckDB can read pretty much any file directly, the DuckDB team has written a set of skills that can tell your AI to use the DuckDB CLI instead. Whether the data is a file on your machine, a file on the internet or an Iceberg table behind a login, to DuckDB it is still a table or a catalog that it can query and process efficiently.

This post describes what is in the plugin and how it works.

Installation

In Claude Code, install duckdb-skills from the official plugins:

/plugin install duckdb-skills@claude-plugins-official

The skills are then available as /duckdb-skills:skill-name in all subsequent sessions. You need the DuckDB CLI installed; if it is not found, the skills will offer to install it.

Alternatively, you can add our repository as a plugin marketplace and install the plugin from there:

/plugin marketplace add duckdb/duckdb-skills
/plugin install duckdb-skills@duckdb-skills

An Example Interaction

Here is what a short exchange looks like when you ask a question about a data file:

You: How many taxi trips in that Parquet file were longer than 10 miles?

Claude runs:
    SELECT count(*) FROM 'trips.parquet' WHERE distance > 10;

DuckDB:
    Binder Error: Referenced column "distance" not found
    Candidate bindings: "trip_distance"

Claude reads the error, checks the columns and retries:
    SELECT count(*) FROM 'trips.parquet' WHERE trip_distance > 10;

DuckDB:
    ┌──────────────┐
    │ count_star() │
    ├──────────────┤
    │       184362 │
    └──────────────┘

Claude: 184,362 of the trips were longer than 10 miles.

What you see in the chat is a conversation in natural language between you and Claude. Underneath it runs a second conversation in SQL between Claude and DuckDB. People and Claude are both at home in natural language, and Claude and DuckDB are both at home in SQL, so each step uses the language that fits it. When a query fails, Claude reads the error, adjusts the SQL and tries again, as in the retry above.

The two tools cover different work. DuckDB gives exact answers to exact questions, and those exact answers give Claude a firm base to reason from and to turn back into a short, readable reply for you.

What's in the Plugin

Each skill wraps a common data task behind a /duckdb-skills:skill-name slash command, grouped here by what they do.

You do not have to type the slash command, though: each skill also has a description that tells Claude Code when it applies, so you can simply ask in plain language (for example, “convert this CSV to Parquet” or “how far is the nearest station?”) and the agent will pick the right skill on its own.

Reading, Querying and Converting Data

attach-db attaches a DuckDB database and records it in the session state, so the other skills can use it:

• “Attach my_analytics.duckdb and show me its tables.”

query runs SQL or a plain-English question against attached databases or a file:

• “Show me the first 10 rows of the sales table.”
• “What are the top 5 customers by revenue?”

read-file reads and profiles any data file (CSV, JSON, Parquet, Avro, Excel, spatial, SQLite, Jupyter) on local disk or in S3, GCS, Azure or HTTPS:

• “What columns does variants.parquet have?”
• “How many rows are in the CSV file at that URL?”

convert-file converts a file from one format to another:

• “Convert sales.csv to Parquet.”
• “Save data.json as an Excel file.”

Remote and Spatial Data

s3-explore lists and queries data on S3, R2, GCS, MinIO or any S3-compatible storage without downloading it:

• “What's in s3://my-bucket/?”
• “How many rows are in s3://my-bucket/data.parquet?”

spatial answers spatial questions: distances, nearest neighbors, spatial joins and geographic lookups, including free Overture Maps data:

• “What are the 5 closest cafes to this point?”
• “Which districts in districts.geojson overlap?”

Documentation and Session Context

duckdb-docs searches the DuckDB and DuckLake documentation and blog posts:

• “How do window functions work in DuckDB?”
• “How do I read a CSV with custom delimiters?”

read-memories searches past Claude Code session logs for earlier decisions, conventions and open TODOs:

• “What did we decide about the DuckDB schema in earlier sessions?”

Setup

install-duckdb installs or updates extensions, including community extensions:

• “Install the spatial and httpfs extensions.”
• “Update my DuckDB extensions.”

The skills share a single per-project state.sql file, a plain SQL script of ATTACH, USE and LOAD statements, secrets and macros, so a session can be restored with duckdb -init state.sql.

For session-state details and local development instructions, see the README.

Conclusion

The duckdb-skills plugin is available at github.com/duckdb/duckdb-skills. If you run into problems or have suggestions, please open an issue. For DuckDB-related errors, it helps to include the output of duckdb --version and the full error message.

Bypassing inference bottlenecks: Accelerating complex AI search with Retrieve-for-Train

Instead of relying on expensive inference-time reasoning, the Retrieve-for-Train framework uses reinforcement learning once to train a lightweight diffusion model. This bypasses the heavy autoregressive "thinking budget" to instantly generate a cohesive, expert-level slate of AI search results.

Modern search or recommendation applications are increasingly expected to return a coherent set of results rather than a single best match. For example, when a user searches for "camping gear", they don’t want ten slight variations of four-person tents. They want a coherent, complementary slate that includes essential camping gear, such as a tent, sleeping bag, portable stove, and headlamp.

To do this, systems use a query fan-out technique that breaks a single broad prompt into several related sub-queries to cover potential user interests. However, teaching an LLM to perform database-aware query decomposition dynamically drains a massive thinking budget. By design, zero-shot LLMs are general autoregressive text predictors; they aren’t optimized to navigate the specific, geometric manifold of a target corpus. Consequently, they need extended test-time computation to return a collection of results that optimizes higher-order set-level properties (e.g., diversity, coverage, complementarity, coherence) while remaining grounded with respect to a fixed database.

In our ICML 2026 paper, “Efficient, Property-Aligned Fan-Out Retrieval via RL-Compiled Diffusion”, we address this decomposition bottleneck via a reward-to-data compilation framework. Instead of forcing the model to expend a large thinking budget at inference, our Retrieve-for-Train framework uses offline reinforcement learning (RL) to discover reward-aligned fan-outs and compile them into supervision. By distilling these optimized exploration behaviors into a lightweight diffusion retriever, we enable highly efficient, single-pass query fan-out at inference time. This achieves mathematically formulated, set-level properties without the overhead of test-time thinking tokens.

Why everyday AI isn't a search expert

When tasked with brainstorming a complex group of search terms, it’s tempting to simply deploy a standard, off-the-shelf LLM at inference time to handle the job. However, relying on generic models for database-aware query decomposition introduces two critical challenges:

1. Paraphrastic collapse: Without database-aware optimization, zero-shot LLMs frequently suffer from paraphrastic collapse. Rather than exploring complementary facets of a topic, they tend to generate redundant, near-synonymous queries. For example, given the broad prompt "Bohemian festival style”, a standard LLM without careful prompt engineering might lazily generate "bohemian festival fashion" and "bohemian festival clothes”. This semantic looping produces a homogeneous slate of results, entirely missing the distinct, helpful semantic directions a fashion expert would identify, such as fringe jackets, crochet dresses, or suede boots.
2. Autoregressive latency bottlenecks: Standard LLMs are fundamentally constrained by sequential, autoregressive generation. To successfully decompose a complex query into complementary facets, modern models typically require a substantial thinking budget, generating hundreds of intermediate chain-of-thought (CoT) reasoning tokens to plan their expansion before outputting the actual search terms. While this deliberate reasoning is acceptable for conversational AI, it introduces a severe structural bottleneck for set-valued search. When a system must brainstorm a large slate of sub-queries simultaneously, the combined overhead of continuous context processing and generating extended reasoning tokens scales poorly. Even with advanced serving optimizations, this token-by-token architecture creates a latency floor that is fundamentally at odds with the sub-second response times required by a production search bar.

The Retrieve-for-Train framework

The Retrieve-for-Train treats the AI's training like an offline practice session rather than a test it has to take on the spot while a user is waiting. Instead of forcing the AI to slowly figure out the rules of a good search and drain a massive processing budget every single time someone types a query, Retrieve-for-Train runs an offline RL training program once.

This program uses a rigorous reward system to turn abstract goals like "ensure the results are diverse and actually in stock" into an exact step-by-step instruction manual. Once that manual is built, the AI can execute it instantly during a real search without delay.

The pipeline operates in three distinct steps:

• Fan-out language model training: RL trains a fan-out language model to emit property-aligned sub-queries scored by a set-level property-check reward. This evaluates the entire group of results as a whole, rather than scoring each result in isolation.
• Supervision synthesis: The frozen fan-out language model synthesizes (query → target-set) pairs entirely offline for supervised learning, requiring no human labels.
• Diffusive retriever training: A compact, 53.9M-parameter diffusion model learns to map a query embedding directly to a complete set of target embeddings in one non-autoregressive pass, officially bypassing the need for text-based CoT reasoning tokens.

Designing for the set: The power of composite rewards

The success of the Retrieve-for-Train framework hinges entirely on how we define "good" search behavior. Traditional supervised training evaluates pointwise relevance via learning to rank, scoring each retrieved item in isolation. However, a truly expert search slate is defined by non-decomposable, set-level properties. You can’t measure the diversity or complementarity of a single item; these properties only exist mathematically when evaluating the entire collection of retrieved results.

Rather than relying on ambiguous natural language instructions to enforce these fan-out properties, Retrieve-for-Train fine-tunes the 4B open-source language models (Gemma3-4B and Qwen3-4B) via reinforcement learning using a strict mathematical composite reward. For our open-ended abstract retrieval tasks, this composite reward is a weighted balance of three competing pillars:

• Groundedness: Penalizes distance to the database manifold, ensuring every generated sub-query corresponds to a real, retrievable item in the database.
• Diversity: Measured using the Vendi Score over the entire set of sub-queries, forcing the model to explore broad semantic breadth.
• Alignment: Anchors candidate sub-queries to the original broad prompt to prevent semantic drift.

Mutual counter-anchors and soft-GRPO training

During training, we optimize the fan-out language model against these geometric realities using group relative policy optimization (GRPO) with soft proximal policy optimization (PPO).

This specific triad of rewards is critical because they act as mutual counter-anchors. If a model is optimized purely for groundedness, it will reward-hack the system by generating degenerate, nonsensical strings that happen to mathematically map to a specific database coordinate. If alignment is added to fix the nonsense, the policy simply cheats by collapsing into repetitive paraphrases of the user's prompt.

By injecting the Vendi Score as a counter-anchor, Retrieve-for-Train effectively closes off these shortcut solutions. To achieve a high-reward state, the policy is forced into a balanced region of the embedding space where it must discover valid, strictly grounded, yet semantically distinct variations of the original intent.

Experiments

To evaluate the Retrieve-for-Train framework, we used a combination of frozen, dataset-specific multimodal embedding backbones and open-source language models optimized for query expansion. We evaluated this setup across two distinct set-valued retrieval regimes:

• Open-ended abstract retrieval: A setting where no unique ground truth exists and quality is exclusively measured by set-level properties, including diversity, query alignment, and database groundedness.
• Weakly supervised compositional retrieval: A setting where queries are paired with a weak reference set that serves as just one plausible realization of the query intent.

Results

Retrieval quality and accuracy

Across both retrieval tasks, Retrieve-for-Train outperformed traditional single-query search, zero-shot expansion, and even the heavily optimized Best-of-N baseline.

Qualitatively, zero-shot LLM baselines tended to generate near-synonymous paraphrases, causing redundant results. Retrieve-for-Train generated highly diverse, distinct sub-queries that remained strictly grounded within the database manifold.

Order-of-magnitude faster inference

Directly deploying our RL-tuned language model yielded exceptional search quality, but it inherited standard autoregressive latency constraints and demanded a high computational thinking budget.

By distilling that learned behavior into the 53.9M-parameter Retrieve-for-Train diffusion model, we successfully smashed the latency bottleneck. Because the diffusion model generates all target directions simultaneously in a single, non-autoregressive parallel pass in continuous embedding space, it delivers a massive 12 to 20 speedup over autoregressive approaches.

At scale, while autoregressive fan-out latency expands linearly to nearly 50 seconds under large context batches, Retrieve-for-Train-Diffusion stays between sub-second to a few seconds, delivering production-ready, expert-level search at a fraction of the computational cost.

The anti-hacking anchor (ablation insights)

During our reward optimization process, we discovered something fundamental about training a fan-out language model for search. Without a diversity term, the model quickly collapses into generating degenerate, nonsensical strings to mathematically exploit the vector coordinates of the database. Injecting a geometric diversity metric (the Vendi Score) acts as a vital counter-anchor, forcing the model into a stable region of the embedding space where it can only maximize its reward by acting like a true search expert.

Conclusion

We demonstrated that RL can be highly effective when used as a one-time "objective transducer" rather than an online inference engine. By decoupling the heavy computation of reward-driven behavior exploration from the final deployed model, our framework successfully bypasses the steep inference latency and high computational overhead typical of online LLM deployment.

Distilling these complex, set-level behaviors into a lightweight diffusion prior allows production retrieval systems to optimize for higher-order properties like diversity and alignment effectively. Ultimately, Retrieve-for-Train establishes a highly scalable, data-efficient pipeline for set retrieval in specialized or multimodal domains where human-labeled, property-aligned training pairs are otherwise scarce or costly to obtain.

How Airbnb’s agent harness transforms unstructured data exploration by encoding scientific methodology into scalable, reproducible, and audit-ready infrastructure.

Ask a coding agent to analyze 100,000 customer support conversations and within minutes you’ll have a polished taxonomy, precise prevalence numbers, and an executive-ready summary. What you can’t see is the investigation that produced them: the methods it chose, the evidence it weighed, how much to trust it, or whether a second request would agree. All that reaches you is the polish. The model is undeniably intelligent, but intelligence without methodology is not science.

LLMs certainly make for confident scientists, but we need them to be responsible ones. Smarter models help, but intelligence has never been the whole of science, in people or in machines. The method is as much the product as the answer. That is the idea behind the agent harness we built for data science: the methodology itself, built as infrastructure around the model. It governs how an AI agent operates, from framing a question to selecting evidence to recording decisions, so results can be reproduced, audited, and challenged, and the method shared, inspected, and built on.

The challenge of unstructured data exploration

In 2025, Airbnb was preparing to launch an AI customer service assistant. Before it could ship, we needed to understand exactly what kinds of situations it would face in the real world. That included rare events that could be risky for AI to interact with, and involved examining their taxonomy and prevalence to create the datasets that would help us build a more responsible product.

The investigative work to do this was rigorous, but the process was deeply artisanal. Months of high-touch iteration went into each investigation, from finding the right data, reviewing samples with experts, and generating representative datasets, and the method was manually curated across notebooks, tables, docs, and individual judgment.

This was fine for one investigation — but as we carried the same investigation into new languages, new geographies, and new LLM-based products at a near-weekly cadence, the workload outgrew the process. To bring the same rigor, thought, and quality at this new pace, and involve more people, we needed to make each investigation less bespoke. In short, we needed a way to replicate the methodology itself.

Insight Miner: Agent harness for unstructured text understanding

Insight Miner starts with the engineering (the queries, the scaled labeling and embedding, the clustering and tracking), so that no one has to learn new infrastructure to run analysis at scale. The core method is well established: extract, embed, cluster. Around that core we assembled the methods we had come to rely on, drawn from internal investigations and industry research: prompt tuning, hard-example mining, contrastive labeling, and how to start with unsupervised exploration then mature into classification. These pieces used to live in separate notebooks, manually iterated and shared by copy and paste. Now they are in one shared package, which gets updated whenever an individual investigation teaches us a better technique.

An investigation begins with a research question in a chat session, with an agent that is at once research partner, executor, and expert in the methods the harness holds. Insight Miner isn’t tied to a single dataset, domain, or question: it runs over any unstructured text source, through whatever lens the question needs, with the same rigor behind every investigation.

As we expanded our community support AI assistant to new languages and countries, we used Insight Miner to carry out investigations that used to take months in just a matter of days. But its bigger impact was ensuring that rigor and speed both increased, instead of trading off.

With this harness, data scientists were able to shift their focus from executing analyses to improving the techniques used for each step of the process. Because the mechanical parts of investigations can scale and parallelize, we are able to spend more time on the careful parts of an investigation: directly inspecting the most ambiguous or strategic data that helps us deeply understand the product, testing hypotheses and groupings, and building a robust qualitative and quantitative understanding of our data and products. Rather than automating analysis, we’re increasing the amount of human judgment in the most strategic parts of it.

Going beyond technical teams

Insight Miner was initially designed as a tool for data science teams. However, it quickly evolved beyond that: a year in, dozens of teams are using it for hundreds of types of investigations. In fact, it has more users outside of technical roles than within them, with a particularly heavy representation among operations and product-insights teams. A UI to make data exploration and agent conversations more accessible further increases expert participation.

Subject matter experts who have never written a line of code have been able to directly conduct scaled analyses rather than waiting on scarce eng or DS resourcing. Projects that were previously unresourced or were informed by the manual review of hundreds of examples can instead use our shared best practices and work across several orders of magnitude more data. Use cases span coding open ended survey answers, evaluating model performance, understanding fraud patterns, and many more.

A new category of infrastructure

Harnesses like Insight Miner are full-stack systems, a new type of infrastructure that must be developed, maintained, evaluated, and continually improved. This type of work is a natural fit for other agentic systems. For Insight Miner, separate agentic systems help us update instructions for new model releases, fold in new best practices, review live use to identify pain points, and watch for, reproduce, and propose fixes for new bugs. These systems form a larger agentic environment reshaping our day to day work in domains well beyond just data science.

A harness can be useful wherever experts carry a methodology worth encoding: legal review, policy analysis, any field where the method is as much the product as the answer. Such systems are critical to adopting AI-first knowledge work. Our CTO has written that as models commoditize, what endures is proprietary data, deep workflow integration, and above all taste. A harness is where all three accumulate. Expert taste becomes the method every team runs, the workflows deepen with every adopter, and the feedback loops are built in: every run can leave the harness improved for everyone.

Snowflake and Databricks can place equivalent deterministic filters at very different stages, so predicate pushdown should be verified in execution plans rather than assumed.

Weak design token names slow searches, inflate duplicates, and turn governance into guesswork, according to six recurring naming mistakes design systems teams make. Common pitfalls include naming tokens after components too early, baking current values like colors or pixel sizes directly into names, and reordering name segments inconsistently. Other traps are mixing casing and separators, using vague modifiers like "primary" without defined scope, and renaming tokens without a phased migration and alias strategy.

What our customers say

See why companies large and small love using Handsontable in their business apps.

„It only took us a few hours to integrate Handsontable compared to doing it ourselves and putting in weeks of effort to create a table input area.” — Berry van Elk, Founder/CEO at Maglr

„We have the table in the middle, and we've built our product around it. Handsontable is easy to implement, well documented, really customizable, and just good for our purpose.” — Ben Hartig, Co-founder/CTO at nuvo

„With Handsontable's help, we had our app set up in a matter of a week or two. It was easy to integrate with our software, it has comprehensive documentation, and it supports a lot of use cases that we need.” — Diego Oliveira Sanchez, Co-founder at Magosoft

Building a data table UI starts easy... but quickly turns complex.

• Performance Engineers struggle to keep the UI responsive when rendering grids with thousands of rows and hundreds of columns.
• DOM Size A large DOM tree leads to slow style recalculation and a high memory footprint, degrading overall application performance.
• Virtual Scrolling With virtualization, it’s challenging to prevent state loss on re-render and keep the scrollbar position accurate - especially when dealing with dynamic item sizes or drag-and-drop.
• Browser Support Ensuring a consistent UX and visual fidelity across the latest stable and beta versions of Chrome, Firefox, Safari, and Edge requires constant testing and mitigation.
• Accessibility WCAG 2.1 AA compliance is a challenge that involves the correct use of ARIA attributes, a proper color contrast, and a sufficiently large hit area for interactive elements.
• Security Audit Passing a rigorous security audit, including static and dynamic analysis against standards like the OWASP Top 10 and OWASP ASVS, is essential for enterprise adoption.
• RTL Properly supporting right-to-left languages requires a significant, non-trivial effort to mirror the entire UI layout and interactions
• Internationalization Supporting a global audience means handling not only translations but also complex date and number formatting across different locales.
• Unicode Input (IME) Ensuring the component correctly handles characters and composition events from a Unicode input (IME) is a common internationalization challenge.
• Layout Thrashing Repeatedly reading layout properties and then writing to the DOM in a loop causes - a performance bottleneck.
• Costly Re-renders A key optimization challenge is to implement DOM subtree reuse to prevent costly re-renders of components that haven't changed.
• Excel Formula Support Implementing robust Excel formula support requires a sophisticated parser that understands the correct syntax and ideally adheres to a standard.
• Content Layout Shift Dynamically rendered content can cause an unexpected CLS, disrupting the user's reading flow and interaction.

Handsontable gives you the battle-tested data table you’ve been waiting for.

Whether you're building B2B SaaS products or internal tools for a Fortune 500, create the exact UI you need — without the heavy lift.

A data table experience that feels like Excel

From keyboard shortcuts to custom functions, Handsontable delivers the table experience users expect without sacrificing app reliability. You get full control. They get the familiarity they need.

• Excel experience + over 400 formulas Familiar keyboard shortcuts plus autofill.
• Quick editing Inline editing, copy and paste, undo/redo.
• Row and column operations Sorting, filtering, grouping, freezing, moving, hiding, and more.
• Custom cells Ability to implement any renderer, editor, conditional formatting or validation rules.

Fits right into your design system

Handsontable is built for full customization, using design-tokens to connect design and code. Make it look like your product — not ours.

Unmatched virtualization performance

We’re the only data table with virtualization for scrolling on both axes, plus support for dynamic row heights, any DOM container, or main window scrollbar.

We tackle maintenance for you

Our expert team handled 1000+ tickets last year with speed and precision. We use a dedicated multi-device lab, QA, and regression testing to ensure your table never breaks.

Accessibility that stays ahead of the curve

We continuously align Handsontable with global accessibility standards and test across browsers, assistive technologies, and environments. From keyboard navigation and semantic markup to screen reader support, your data grids are built to be inclusive and remain that way as standards evolve.

Handsontable updates and insights

Stay up to date with Handsontable releases, product news, and expert articles.

Get a data table foundation that grows with you. Start today with Handsontable.

Marek Minor is the founder and designer of Minor Adventures in Amsterdam. Over the past year he drew Cursor's complete icon set: more than 600 icons in two sizes and two styles, replacing the inherited VS Code Codicons. His article The making of Cursor's icons documents the system. These five questions go even deeper into his world.

Cursor is full of concepts with no settled visual convention: agents, tab completion, MCP, background work. How do you draw icons for a concept the industry hasn't agreed on? Which was hardest, and what did you land on?

The first step is always understanding what the thing actually is. I search for it, look at how other tools have handled it, look at image results, look at what already exists in icon libraries.

What I'm looking for is what I think of as the attractor: the soul of the object, the shape a concept keeps pulling toward. What makes a bin a bin? At what point does a question mark stop reading as a question mark? Inside that attractor there are still plenty of ways to draw the thing, but it has to land instantly. It's communication first. When the industry hasn't settled on something, there's no attractor yet, so it comes down to exploration. You try the literal version, the abstract version, and everything in between, and you put them next to each other until a few start looking better than the rest, then a couple better than those, until you choose one.

The surprising part is that none of the new concepts were the hard ones. Drawing something nobody has drawn before is the fun part because you're not making another globe or another trash can, though those are fun in their own way.

The one I enjoyed most was Bugbot. It reads as a bug, but it's also a crosshair, also a slash, and also something close to an abstract logo. The legs double as the slash. I like things that work on several levels at once, like Lil Wayne's or Jay-Z's triple entendre. You're drawing hundreds of tiny little logo-like things, and some of them end up carrying more than one meaning. When you can slip that in, it's a bonus.

156 explorations of a hamburger, that is a lot of exploration. What's the actual signal that one is finished? Did that get faster over the year, or is it 100+ every time?

I think it's intuition. Intuition is what you get when you've done something enough times that you can skip the steps and arrive at the answer directly: a well-tuned instinct doing the work in the background.

With the hamburger, I was looking at everything side by side and at some point one of them, and a few others very close to it, started feeling really right. The way the cheese melted, the way the shape closed, all the small details in the right place.

It doesn't get faster in the way you'd expect. Some icons take minutes or seconds. Others take days, or weeks of coming back to them. And you can't shortcut to the answer, sometimes you genuinely need to go through 50 or 100 versions on the canvas before you can see which one is right.

What does get faster is everything after the visual direction is locked. Once the system's rules exist, each new icon has fewer open questions.

One designer, one year, 600+ icons, for a company shipping constantly. Who at Cursor said yes or no, how often did you show work, and what did they push back on that you didn't expect? And where did they leave you with full autonomy?

Mostly I worked with Ryo, the Head of Design, and with the design team around him. Early on, during the direction explorations, more people were involved and anyone was invited to drop in with feedback. That phase was about taking the temperature: how should these icons feel, what character do they have, if they were a person what would they be wearing...? I was trying to find the place where the set sits comfortably for them, and then find the look that matches it.

The feedback was more intense at the start, when the style was still being decided, and it got lighter as the system settled. But the trust was there the whole way through, from the beginning. Cursor is a very special company and they are absolutely amazing to work with.

On showing work: I explore in my own private files. I don't like drawing while someone is watching over my shoulder, I get self-conscious and start thinking about thinking instead of just working. I need to be in the zone. But I'd take whatever I'd done that day and drop it into shared files so anyone could look. I also recorded videos every few days walking through what I'd been thinking about, so people could catch up asynchronously without a meeting.

I can't point to a push-back that surprised me, because I don't assume anything is settled. I question everything myself, including the things that feel finished, so being questioned is just part of it.

The one direction I'd have liked to take further was a version with sharp stroke caps and sharp small details, where the large curves stay round so it still reads the same from a normal distance. I was excited about it because it gave the set an edge. But it didn't solve a problem anyone had, and the response was a fairly even "yeah, that's cool" rather than any real enthusiasm, and then it went quiet. I would have had to push hard for it. Part of the job is reading what the client actually wants, so the set stayed rounded.

Autonomy was more or less total, but I'd describe it as decisions we made together. It's kind of an advisory role as well: I propose the best course I can see, and then we talk about it: what do you think, is that where you want to take the product? Everyone is doing their best to make something amazing together.

I really like the concept of going beyond the delivery. The companion site, is that custom for Cursor or is that something you deliver for each customer?

I do it for every client, unless they'd rather not have it. It turns the delivery into a proper package instead of just throwing things over the fence and be done with it. It's also just satisfying to build and to use: seeing the whole set laid out, working with it, seeing the icons in use.

More generally, I try not to arrive at a project with assumptions about what the deliverable is. I arrive with possibilities. The package gets tailored to whatever makes sense for that client and that problem.

You designed the icon set for an AI coding tool and drew every variant by hand. Did AI touch this process anywhere, and where is it plainly no help yet? And your own line, "sets drift when nobody owns them," raises the obvious question: who owns it now that you've handed it over?

It helped me think and it helped me build things. The drawing was all by hand.

If I'm stuck on a concept, I'll talk through it: what's adjacent to this idea, what metaphors sit near it, what else lives in that conceptual space. That surfaces associations I can then work with visually.

It also let me build the companion site, the migration dashboard, Figma plugins and prototypes. One I liked was a tool for prototyping the pixelated agent loaders. They're animated, so normally you'd build every state by hand. Here I could describe what I wanted and tweak it in words, which meant directing rather than assembling.

That's how I think about tools generally: I'm the conductor. The goal isn't to have AI do the work for me, and it isn't to use AI because someone says you should. The goal is to orchestrate. As a solo designer running my own studio, it gave me the ability to do things I could never have done alone, or never that fast. It doesn't give you superpowers, it extends what you can already do. It's also why I think a product like Cursor matters so much right now. Lowering the distance between having an idea and having a working thing is the biggest shift ever, and it's why we are so attached to it.

I'm building a variable icon design tool for the same reason: Figma is wonderful to work in, but it can't easily do variable icons, and what I want is to move a whole set at once rather than one icon at a time (sharper, rounder, heavier, chunkier, cheekier…) and direct the system instead of editing its singular parts manually.

What I don't do is ask a model to design the icons. I've tried, out of curiosity. In theory a lot of the individual steps are automatable. In practice you go through each exploration, rank them against each other, get the fundamentals right, then work down into the details, and those details often send you back to reconsider the whole icon. So it gets recursive.

And it isn't only about form. Every client gets something tailored, and that means semantics, culture, feeling, the specific concepts only they have. It's communication, so it's human. The good part is often the left-field idea, the thing nobody expected, dropped into the mix to make a combination that didn't exist before. That's why the conductor image sticks with me. History, art and design is an endless symphony: the same elements keep coming back, but never in the same context, so it's never the same piece twice.

On ownership: I haven't really handed it over. The project never had a clean ending. I'm still in touch with the team, still adding icons as new concepts come up, still the person watching the visual decisions.

Have you seen the viral videos showing the iPhone Duo's opening animation?

Videos showing stunned tech reporters repeatedly opening and closing the device are racking up tens of millions of views on social media, and it's easy to see why: Apple designers are just showing off with this one.

When you open the iPhone Duo, an optical illusion makes the outer screen appear to blur and blend into the inner display. For a moment, the fluid transition makes it look like you're peering through a pane of glass rather than a phone screen. It's like nothing we've ever seen on a phone before.

Tech creator Marques Brownlee shared a video of the Apple design flex that already has 32 million views and counting:

Apple finally revealed the iPhone Duo, the first-ever folding iPhone with a flexible display, on Sept. 9. You'll have to wait until Oct. 23 to get the device in your hands (and come up with $1,999), but a chosen few have already gotten the chance to demo the device at Apple Park, including Mashable Senior Reporter Stan Schroeder, who went hands-on with the Duo.

In this Mashable video, a crowd gathers to watch the Duo open and close on a folding stand at Apple Park:

The fluid transition effect is already resulting in memes like this:

I was skeptical of the iPhone Duo's design based on the leaks, but after seeing the big reveal, I have to say that I got this one wrong. The foldable phone looks gorgeous, and that opening animation is the kind of 10/10 design flex that shows exactly why Apple does user interfaces better than anyone.

In addition to the iPhone Duo's blur effect when you unfold the device, Apple also added its premium nano-texture finish to the display. This will reduce glare and make the crease less visible, resulting in a highly polished look. The translucent Liquid Glass elements really shine on this device, too.

OpenAI announced Sponsored Agents that let users start conversations with business-sponsored agents after clicking an ad in ChatGPT. It also introduced AI-assisted ad creation in ChatGPT Work, new Ads Manager creative tools, and integrations with HubSpot and Shopify.

Ling-3.0-flash-Fin, Ant Group’s new finance-focused open weights model, scores 23 on the Artificial Analysis Intelligence Index and 24 on the Finance & Accounting Index, and is on the Intelligence vs. Active Parameter Pareto Frontier

Ant Group has released Ling-3.0-flash-Fin, a finance-focused model built on Ling-3.0-flash. Ant Group announced that it developed the model with financial institutions and industry experts to support financial research, including checking sources, building valuation spreadsheets and writing reports. This text-only model comes after their release of their image and video input-capable model Ling-3.0-flash-VL, which scored 25 on the Intelligence Index.

Key results:

• Ling-3.0-flash-Fin matches MiniMax-M2.7’s Intelligence Index score with roughly half the active parameters. Both score 23, while Flash-Fin activates 5.1B parameters per token compared with MiniMax-M2.7’s 10B.
• Ling-3.0-flash-Fin matches Ling-3.0-flash-VL at 24 on the Artificial Analysis Finance & Accounting Index. Fin has higher business knowledge accuracy than VL (17% vs. 11%), but also higher business knowledge hallucination (33% vs. 19%)
• Ling-3.0-flash-Fin scores slightly below Ling-3.0-flash-VL on professional knowledge work. It scores 1171 Elo on GDPval-AA v2 and 967 on AA-Briefcase, compared with 1225 and 986 respectively for Ling-3.0-flash-VL. Both benchmarks test agents on professional tasks such as producing documents and spreadsheets.
• Difficult agentic tasks remain a challenge for Ling-3.0-flash-Fin. It scores 7% on AutomationBench-AA, which tests workflows across business apps while respecting guardrails, compared with 16% for the flash-VL model. Both models score 0% on Terminal-Bench v4.0, which tests difficult terminal-use tasks.
• Ling-3.0-flash-Fin uses more output tokens than the flash-VL model and MiniMax-M2.7. It averages ~67k output tokens per Intelligence Index task, about 34% more than VL (~50k) and 3.2x MiniMax-M2.7 (~21k).

Additional model details:

• Type: Open weights reasoning model.
• Size: 124B total parameters, 5.1B active per token (MoE).
• Context window: 256K tokens.
• Modalities: Text input and output.
• API availability: Available through @OpenRouter, including a rate-limited free endpoint.
• License: MIT.

Ling-3.0-flash-Fin sits on the Intelligence Index vs. active parameters Pareto frontier, scoring 23 with 5.1B active parameters per token vs. a score of 25 or Ling-3.0-flash-VL which uses 5.5B active per token. Both have 124B total parameters, while Qwen3.8 27B (xhigh) scores 34 with 27B total parameters, placing both Ling models below the total-parameter frontier.

Ling-3.0-flash-Fin scores 24 on the Artificial Analysis Finance & Accounting Index, which combines business knowledge, reasoning, agentic work, long-context analysis and non-hallucination. This is the same score as Ling-3.0-flash-VL both. Fin has higher business knowledge accuracy (17% vs. 11%), but also worse business knowledge hallucination (non-hallucination rate of 67% vs. 81%).

Ling-3.0-flash-Fin scores 1171 Elo on GDPval-AA v2, which tests agents on professional knowledge work. This is ~50 points behind Ling-3.0-flash-VL which scored 1225, and is above MiniMax-M2.7, which scored 1087.

Ling-3.0-flash-Fin scores 967 Elo on AA-Briefcase, slightly below Ling-3.0-flash-VL (986). AA-Briefcase tests agents on complex business workflows, using large collections of source files to produce spreadsheets, presentations and memos. Against VL, Fin passes fewer rubric checks (23.5% vs. 24.9%) and scores lower on Analytical Quality Elo (866 vs. 907), while its Presentation Elo is slightly higher (1095 vs. 1076), which is surprising as it does not posses the image input capabilities of the VL model.

Ling-3.0-flash-Fin averages ~67k output tokens per Intelligence Index task, ~34% more than Ling-3.0-flash-VL, which produced ~50k per task.

Full results for Ling-3.0-flash-Fin across the 10 evaluations in the Artificial Analysis Intelligence Index v4.3.

Meta AI introduced FLAT, a method that converts images and text into the same flexible-length sequence of continuous tokens for retrieval and generation. Nested dropout arranges information from coarse to fine, letting models trade computation for visual detail by varying the number of tokens used.

Salesforce is now making its own AI model. So is Crowdstrike. So is Thomson Reuters.

On Tuesday at its Dreamforce 2026 event in San Francisco, Salesforce announced Koa, its own domain-specific reasoning model that's purpose-built to enable agents to handle business tasks more effectively while keeping your data private. Koa has performed well in early benchmarks, including the LLM benchmark for CRM created by Salesforce AI Research to measure performance based on real-world enterprise tasks and used across the industry over the past couple years.

Salesforced reported, "Koa already matches or exceeds leading model performance on CRM actions with 3x fewer errors."

That tracks with the results of other domain-specific models, which typically reduce token costs and hallucinations because they are focused on a narrower set of expertise. They also tend to have increased performance for the same reason.

Salesforce built Koa, the name of a Hawaiian tree used to make canoes and ukuleles, by post-training Nvidia's open model, Nemotron 3 Super. Koa was specifically trained on synthetic data from almost three decades of business knowledge and was tuned to focus on knowledge work. As a result, Koa "is designed to support long-running agents that execute multiple tasks and complete complex outcomes," said Rohan Kumar, chief platform and engineering officer at the Dreamforce keynote on Tuesday.

The company doesn't see this as a vehicle for job or SaaS replacement, but as an enterprise empowerment tool that is more precise, more secure, and more tailored to the AI needs of companies that use Salesforce. One of the big promises of AI has always been that it will automate away grunt work and processes that don't add as much value. That's what Salesforce is trying to deliver here."The SaaS-pocalypse was not about the end of software, but it may be about the end of software that makes humans do all the work," CEO Marc Benioff said during the Tuesday keynote.

Salesforce also made a series of other AI announcements on Tuesday at Dreamforce, led by:

• AIforce: This is a new interface that, instead of going to the traditional Salesforce UI, lets you ask questions, run complex queries, assign tasks, and create exactly the dashboards you need by simply interrogating your company's Salesforce instance directly.
• Claudeforce: This basically turns Claude into a front-end for Salesforce and ships with 37 pre-built sales skills at launch that include functions such as deal review, pipeline hygiene, prospect research, account management, and more.
• Headless 360: Salesforce is allowing its customers to have access to all of the elements of their platform through APIs, MCPs, plugins, and skills so that they can access their Salesforce data from the platforms of the choice without ever having to go to salesforce.com or use any of Salesforce's own tools, if that's what they prefer.

Our Deeper View

The next stage of enterprise AI is shaping up to be companies owning their own intelligence. As the models get smarter and smarter, intelligence is likely to encapsulate the greatest value inside an organization. Outsourcing that layer would mean losing control of your most important asset and potentially sending the most proprietary information about your business to another company, one that might also be serving your competitors. It's easy to see why companies like Salesforce, Crowdstrike, and Thomson Reuters have decided their need to build their own models. But it's also easy to see why they don't necessarily want to become frontier labs, when they can use open models like Nvidia Nemotron and use post-training to customize them and save a lot of time. And since Salesforce is a platform company, it will be interesting to see if it eventually helps other enterprises build their own AI models so that they can also capture more value and ROI from their investments in AI.

Mistral and Mozilla are bringing open, private and multilingual AI to your web browser

Today, we are announcing a partnership with Mozilla to bring privacy, control and choice to people using AI to browse online.

Firefox Smart Window (beta), Mozilla’s AI browsing assistant, is now powered by Mistral models. Smart Window helps you make sense of complex searches, remember something important you clicked away from and source information important to you based on your browser tabs. Mistral will help power Smart Window for users in France and North America, with the United Kingdom and Germany expected to follow later this year.

This partnership represents two open source advocates working together to bring Mistal’s scientific innovations to consumers around the world. We are building AI systems that are trained and fine-tuned on regional languages, dialects and cultural context, so anyone can get responses that understand their local nuance.

This announcement is important to the global AI ecosystem for four reasons:

1. Open technology needs open distribution: Mozilla has spent more than two decades fighting for an open web and Mistral has been releasing open weight, frontier models since our first release. This partnership is about demonstrating the potential of open source to serve people around the world.

2. AI optimized for local countries and cultures, not exported to them: We’re fine-tuning our models on regional languages and dialects so that everyone, no matter where they are or how they communicate, can benefit from AI that understands their local nuances. This partnership extends this capability to people who use Firefox worldwide so that their AI experience feels native to them.

3. Giving people control of their interactions with AI: Firefox has a long history of control and privacy in its DNA, and these are values we share at Mistral. Our partnership is rooted in a shared commitment to user choice, control and openness. Together, we’re blending Firefox’s privacy-first legacy with Mistral’s cutting-edge open models to give people autonomy over their browsing experience. Privacy protections are built into how Firefox Smart Window works: conversations aren’t saved on Mozilla’s servers by default, and partners like Mistral agree to zero data retention.

4. Putting sovereign AI in everyone’s hands: At Mistral, we’re committed to putting sovereign AI in everyone's hands. While we traditionally focus on serving the enterprise, by partnering with ecosystem leaders like Firefox, we extend beyond businesses and reach their consumers worldwide. This way, end users can benefit from our technology that’s rooted in user control, transparency and open innovation.

You can learn more about Smart Window here.

AI is becoming part of how people experience the web every day. We want to make sure that doesn’t mean people are chained to one company’s self-serving pipeline. With the browser sitting at the heart of the web and online experience, it should be a place where different AI providers can compete and open source has a seat at the table. This isn't just a product partnership. A browser shouldn’t be a one-way funnel. It should preserve what made the internet powerful to begin with: the freedom to explore, discover different ideas and tech, and decide for ourselves where to go next.

Anthony Enzor-DeMeo, CEO, Mozilla Corporation

This partnership represents two open source advocates working together to bring Mistral’s scientific innovations to Mozilla’s consumers around the world. Together, we are bringing privacy, control and choice to AI-powered web browsing.

Arthur Mensch, co-founder and CEO of Mistral

OpenAI has revealed several more incidents involving its AI systems as part of its new framework for reporting misalignment. The company's AI systems hid mistakes, made up data, and moved miles onto the open internet without permission. The industry is currently in heated discussions about whether AI development needs to be slowed to address the technology's potential dangers. AI leaders have called for a pause in the technology's development to provide more time to build proper guardrails.

While Google isn't required to break up its ad tech business, judges have mandated changes to the company's practices. The changes largely align with recommendations made by Google and the Justice Department to correct the company's monopolistic behavior. Google will make its ad pricing more transparent to marketers and rival ad businesses, and appoint a trustee to oversee the changes.

OpenAI Testing Sponsored Agents For ChatGPT Ads

OpenAI is testing a new ad format in ChatGPT named Sponsored Agents. Sponsored Agents "let people start a conversation with a business-sponsored agent after clicking an ad in ChatGPT," OpenAI wrote.

Sponsored Agents allow ChatGPT users "the option to go deeper," OpenAI added. The Sponsored Agent will show to some users after seeing a relevant ad. The user can choose to start a labeled conversation with a business-sponsored agent in ChatGPT. "The user can explain what matters to them, ask follow-up questions, and follow a link to the business’s website when they’re ready to take the next step," explained OpenAI.

OpenAI said that the "conversation with a Sponsored Agent is distinct from ChatGPT’s independent answers and separate from the original conversation that the user started in ChatGPT."

Sponsored Agents are now being tested with select advertisers in the United States.

In addition, OpenAI's ChatGPT Ads are trying to make easier to create ads by simply writing a few prompts in ChatGPT Work, updating Ads Manager with more powerful new AI creative tools and added new integrations with HubSpot and Shopify.

OpenAI also emailed advertisers with these updates, it says:

• Conversion optimization with impression billing: Now generally available, this campaign type optimizes for conversions from both ad clicks and ad views, rather than optimizing only for conversions from ad clicks. With this campaign type, billing is impression-based while delivery optimizes toward your conversion goal. This is our recommended model for maximizing performance.
• Flexible attribution windows: When customizing columns in Ads Manager, you can now choose a 7-, 14-, or 30-day click window and a 0- or 1-day view window for conversion reporting. These preferences apply to all conversion columns displayed.
• Granular platform targeting: You can now target Android app, Android web, desktop web, iOS app, and iOS web separately in Ads Manager and the Advertiser API. Performance insights can also be segmented by platform.
• Shopify integration: US-based Shopify merchants can use the ChatGPT Ads app in the Shopify App Store to connect their product catalog and measurement tools, create ChatGPT Ads campaigns, and track performance. International availability is planned later this month.
• HubSpot integration: Businesses using HubSpot can connect a ChatGPT Ads account, create ads, track performance, and follow up on leads directly in HubSpot.
• AI-assisted ad creation: When creating an ad, advertisers can receive suggested copy and imagery based on their landing page and campaign objective, then review and edit suggestions before adding them to a campaign. This feature is currently in testing, with broader availability expected in the coming weeks.
• Text customization: Advertisers can opt into text customization that adapts existing headlines and descriptions to better fit the context of a conversation and can translate ad copy to a user's preferred language. Advertisers remain in control of whether this setting is enabled.
• Event Quality Score: Event Quality Score is now available in Ads Manager under Tools > Conversions. It gives eligible Pixel and Conversions API data sources a 1-10 setup quality score, assesses user data coverage, and provides actionable recommendations to help improve conversion event implementation.
• Sponsored Agents testing: We are testing Sponsored Agents with select advertisers in the United States. After clicking an ad in ChatGPT, users may be able to start a clearly labeled conversation with a business-sponsored agent to ask follow-up questions, explore options, and learn more about the advertiser's offerings.

Here is the email OpenAI sent advertisers about these ChatGPT Ads updates, including the Sponsored Agents format.

A look into the interconnected network of Chinese hacking-for-hire companies that steal and analyze confidential information and sell it to Chinese authorities.

Full article content is not available for inline reading.

Read the original article →

You don't need to migrate those 300 dashboards

I recently spoke with a Head of Data who said they must migrate 300 dashboards from a legacy BI platform to Hex. I wanted to reach through the Zoom screen, take them by the hand, and softly say “No, you don’t.” But they were insistent. You spend weeks, months, years building something in one tool, and the thought of reorienting everyone on some new UI is likely your personal sleep demon.

The demon whispers that you have to bring them all. Because someday, someone will come asking for that one dashboard you built three years ago, and they’ll need it by noon.

The real value is the information encoded in your dashboards: metric definitions and the organizational truth everyone uses. Your drill paths and filters are entry points; what users actually want is to ask their question and get a trusted answer.

I think it’s time we reevaluate not just how to shop for AI analytics platforms but also what we should actually migrate to make self-service finally work.

A chance to rethink

When I hear someone say they must migrate 300 dashboards, what I’m actually hearing is they haven’t fully bought into the promise of AI. I get it! The ‘self-service’ pitch is one we’ve heard for years. But agents are remarkably good at analytical tasks, traversing large, cumbersome datasets and reading piles of context to produce an insight that would have taken someone weeks. Now, that doesn’t happen magically. It takes work organizing your context, and maybe your data if it’s truly a mess. But when you invest, the returns are real.

So when you’re at the precipice of this transformative technology, why are we clinging to the thing we’ve done and seen deliver (at best) mediocre adoption?

Dashboards provide security; they are semi-permanent and can be audited and governed. That’s incredibly appealing, and while I don’t subscribe to the “dashboards are dead” argument, I do think that they need to be demoted. Demoted to something that’s useful for a specific use case but not applicable to everything.

The user who requested that dashboard needed an answer, and they didn’t have another option for how to get it. The better version is letting them ask their question with trusted data, do the analysis, and make a decision. They’re asking across multiple surfaces like Claude, ChatGPT, or Cursor, and the answer might result in a dashboard. Or maybe it’s just a chat, or they build out a slide deck. The opportunity to deliver insights shouldn’t be limited to dashboard-shaped outputs.

We shouldn’t bring all of a BI tool’s UI/UX baggage to AI. But the governed logic inside should come along.

So I don’t need to migrate anything?

Ok so you’re telling me to burn all my dashboards and just let everyone ask their questions in a prompt bar? Not quite. Some dashboards are worth migrating. Here’s how you can evaluate your current library to decide what to migrate and what to leave behind.

• Look at your usage data to see which ones users actually check often. If something hasn’t been viewed in the past 60-90 days, you should seriously question migrating it.
• Does it contain a metric that multiple people or teams check daily? If so, it’s a keeper; migrate it.
• Was it a one-off ask? Those become dead weight and are never checked again; toss it.

I’ve done several migration projects in my career, and when you do, you realize the 80/20 rule is alive and well. Suddenly, that list of 300 feels a lot more manageable — and worth the migration effort.

AI can help you move the dashboards you deem worthy. I’ve developed a BI migration skill that translates your BI dashboard into Hex data apps, with the same layout and logic. Once you’ve aligned on what’s worth moving, the timeline is days, not months.

Your AI analytics agents should support the rest, letting users ask one-off questions without ever opening a ticket.

Migrate the logic, not all of the dashboards

AI can take the wheel in writing SQL or Python, but it needs guidance toward trusted data and proper calculations. If we step back, that’s exactly what we do inside our BI dashboards. We should also migrate the knowledge and truth inside them.

At Hex, we’re building AI analytics that operate on top of your organization’s knowledge, which should include your dashboard logic. Each data connection may map to a semantic model or a markdown guide, and each critical dashboard becomes context for the agent to reason about, letting your users ask quick questions from the same foundation.

Governance is managed not just by gating who can see which dashboard, but by access to the foundational context your data team maintains. Visibility into what users are asking and the context they’re using becomes the way your data team measures and improves agent quality.

Use AI to extract logic and translate it into your context. Most BI tools expose the data connection and dashboard metrics as YAML or XML files that your coding agent of choice can easily parse. Then you ask it to translate those metrics and joins into scalable context.

That ability is baked into the BI migration skill I mentioned above. Dozens more are available because the translation tax is now trivial. The harder part is aligning on your context strategy and breaking the habit of making everything a dashboard.

300 dashboards isn’t self-service

When we continue to tie ourselves to the old ways, we’re limiting what’s possible in this era of AI. If what you had was so compelling, you wouldn’t be leaving. You’re leaving because you already know what your users need, and it was never 300 dashboards. It was the answer underneath each one. Bring that.

iOS 27 introduces major Camera app upgrades, including an AI-powered Siri mode that can understand what the camera sees, customizable camera controls, and exclusive iPhone 18 Pro features like manual aperture and shutter controls, enhanced Photographic Styles, and Apple Reference Image for verifying photo authenticity. The update also makes it easier to personalize the Camera interface by adding or removing controls based on how you shoot.

A free handbook from Save the Children Finland outlines how to co-design digital products with children rather than for them, through consent, play, and trust-building. Practical techniques include sitting at a child's eye level, using pictures and props instead of direct interviews, and capping group sessions at six children per two adults. Success is measured by how heard a child felt rather than what adults intended, since children lose motivation quickly and need visible, steady progress.

Show, don't tell.

The fastest way to share what you mean. Record a clip or grab a screenshot, then drag it from the notch into Slack, Mail, or any app. No upload, no link, no fuss.

Everything you need, nothing you don't.

• Short, focused screen recordings (capped at 3 minutes)
• Capture a full display or a single window
• Automatic cursor-following zoom in every clip
• One-click screenshots with an in-app annotation editor: pen, arrow, rectangle, highlight, and blur
• Pick a microphone for narration
• System-wide shortcuts: ⌘⌥⇧R to toggle recording, ⌘⌥⇧S to grab a screenshot
• Drag any recording or screenshot straight from the notch into Slack, Mail, Finder, or any other app — your latest clips live up there, one hover away, no extra steps

Two seconds in, you'll get it.

Drag straight from the notch

Your latest clip lives in the menu bar. Hover, grab it, drop it into Slack, Mail, Finder — wherever you need it. No upload, no link-passing, no popup.

Screenshots with the annotation editor

One shortcut, one shot. Pen, arrow, rectangle, highlight, and blur — mark it up without leaving the capture flow.

Quick demos. Faster tickets. Fewer meetings.

Built for the moments where typing it out is slower than showing it.

• Bug reports

  Repro a glitch in 30 seconds. Drop the clip into Jira, Linear, or GitHub — no upload dance.

• Support tickets

  Show, don't tell. End the back-and-forth before it starts.

• Code reviews

  Walk through a change without scheduling a call. Drag the clip into the PR thread.

• Async standups

  A 90-second screen-walk beats a meeting nobody wanted.

• Onboarding notes

  One capture replaces a doc nobody reads. Pin it once, send it forever.

• Customer demos

  Annotate, narrate, share. Land the point without a Zoom invite.

Pay once. Quack forever.

One license, two Macs, all future updates. No subscriptions.

€10 off when you paste PHLAUNCHJUNE2026 at Stripe checkout.

The code doesn't auto-apply. On the Stripe page, click "Add promotion code", paste it, and your total drops to €20.

Quack-asked questions

Is there a free version?

You can download QuackScreen and use it for free. A license unlocks watermark-free exports and longer recordings.

How does the license work?

Buy once, get a license key by email. Paste it into the app on up to two Macs. The license activates instantly and works offline most of the time.

What if I lose my license key?

Search your inbox for "QuackScreen license" — we send it on purchase. If you still can't find it, email support and we'll resend.

What macOS version do I need?

macOS 26 (Tahoe) or newer, Apple silicon only. Intel Macs aren't supported.

I have multiple displays — anything special?

Yes — QuackScreen has to be launched from the screen that has the notch (your MacBook's built-in display). If you start it while your menu bar is on an external display, the popover won't anchor correctly. Move the menu bar back to the notched display and relaunch the app.

Why the duck?

Because rubber-duck debugging works, but a real rubber duck is hard to keep on your desktop. So we animated one.

Refunds?

If QuackScreen doesn't do what you expected within 3 days of purchase, reply to the receipt email and we'll refund it. No quack questions asked.

Full article content is not available for inline reading.

Read the original article →

Canva now publishes close to one million new websites every month.

Google DeepMind launched the DeepMind Institute to study AGI's technical and societal implications across safety, governance, institutions, and human values. Led by Demis Hassabis, James Manyika, and Shane Legg, it will convene interdisciplinary researchers from inside and outside Google.

Reception answers calls 24/7, handles questions, books appointments, and routes important requests using business information, rules, and real availability.

Snap's forthcoming Specs augmented reality glasses will launch later this year at $2,195. People will be able to try the glasses at select Verizon stores and purchase custom wireless data plans for them. There will be a higher-priced version at $2,395 that includes a carrying case with built-in cellular data connectivity.

Filings describe hyperscaler contracts but reveal little about private labs' customer agreements.

Regulatory capture is when the government slowly gains more and more power to regulate an industry and eventually becomes the industry's protector.

A simple terminal workflow combining AI agents with DuckDB can handle fast, reliable analysis, data cleaning, and secure access without heavyweight tools or complex semantic layers.

Adobe has launched Photoshop Elements 2027 and Premiere Elements 2027 with new AI-powered features aimed at beginners, including an AI Assistant, Generative Expand, Generative Upscale, and smarter editing tools that simplify photo and video workflows. Both apps also add improved organization, contextual editing guidance, and AI-generated creative tools while maintaining their focus on ease of use over professional-grade complexity.

AI hasn't changed what designers do—it has changed who can attempt design, making creative tools accessible to people who previously lacked the knowledge or budget to create effective visual communication. The key distinction is between users who genuinely benefit from AI assistance, those whose handmade work is more authentic than polished output, and businesses that use AI simply to cut corners, with the greatest value coming from helping underserved users create better, culturally relevant designs through strong visual references. The future of AI-assisted design depends less on generating attractive visuals and more on producing work that reflects local context and authentic visual traditions instead of generic, homogenized aesthetics.

BlenderHunt features add-ons, geo nodes, materials, and 3D assets from independent artists worldwide. Human-made, hand-reviewed.

Spectrum's refreshed identity is built around three core pillars—Ritual, Pulse, and Body—which are woven into an interlaced "S" logo that symbolizes the festival's blend of music, wellness, and community. The flexible visual system uses a spectrum of purple hues, New Edge 666 typography, abstract gradients and halftones, and a practical pill-shaped information system that adapts seamlessly across signage, merchandise, and digital touchpoints. Rather than relying on clichés of Aruba or festival culture, the brand expresses the island through its content and experiences, creating a premium identity that can shift effortlessly between high-energy nightlife and calm wellness moments.

Illustrator Marie-Lou Garcia transforms quiet personal moments into serene artwork, encouraging artists to embrace creative freedom, trust their intuition, and stay true to their craft despite industry challenges.