Product Pricing Security & data Research Publications Blog About Careers Alpha Talk to us Download alpha
Feature reference

Every capability, and what each one doesn’t do.

The complete reference for what Dart can do today. Each entry states how the feature works, what it requires, what leaves your device, the limits we know about, and which research paper measured it. Features still in development are marked as such rather than described in the present tense.

Documented20Capabilities with a full specification and a stated limitation.
Shipping16Available in the current alpha build on macOS and Windows.
In alpha3Working but incomplete. Several are off by default.
In development1Not shipped. Listed so the roadmap is checkable.
The agent

A local-first agent that reads what you read, acts within limits you set, and shows its working. Everything in this layer runs on your machine unless you point it at a cloud model.

Semantic index over tabs, history and files

A searchable index of everything you have actually read, built and stored on your device.

Shipping

Every page you visit, every bookmark, and any local PDF you open is chunked, embedded, and written to an index on your disk. The agent retrieves from this index rather than from the open web, which is why it can answer “what did that contract say about termination” without a search engine ever seeing the question.

Indexing is incremental and runs in the background during idle periods, capped so it never competes with rendering. A typical article costs about 330 ms of background compute. Chunking is structure-aware: headings, tables, and code blocks are kept with the text that explains them.

What it does not do

The index is only as good as its chunking, and untagged PDFs are the weak case — roughly 6% fall back to sentence-alignment and lose about half a point of recall. Retrieval is not perfect: expect it to miss when your query and the document use entirely different vocabulary.

Specification for Semantic index over tabs, history and files
Where it runsOn device, always
Storage~0.9 GB for 14 months of typical browsing
Query latency38 ms median at 40,000 documents
PlatformsmacOS, Windows · Linux in progress
Data leaving deviceNone
Ask us about this

Local model runtime

Detects and drives models already installed on your machine, with no cloud round trip.

Shipping

Dart auto-detects Ollama, llama.cpp, LM Studio, and MLX on Apple silicon, enumerates the models each has available, and lets you assign one to the agent. Inference happens in that runtime, on your hardware. No prompt, no page content, and no result crosses the network.

The browser measures your machine at first run and recommends a configuration rather than presenting a list. On 16 GB of unified memory it selects a 7–9B model at Q4_K_M, which our benchmarks put at the knee of the quality/memory curve.

What it does not do

Below Q4 quantisation, extraction accuracy degrades sharply while output stays fluent — we refuse to auto-select those configurations and warn if you choose one. A 14B model on 16 GB will page and become unusable; the browser will tell you before you try.

Specification for Local model runtime
RuntimesOllama, llama.cpp, LM Studio, MLX
Recommended7–9B at Q4_K_M on 16 GB unified memory
Minimum useful3B at Q4_K_M on 8 GB
Speculative decodingEnabled automatically where memory allows
Data leaving deviceNone
Ask us about this

Multi-step task execution

The agent can chain actions across tabs: navigate, extract, fill, and submit.

In alpha

A task like “find the renewal date in this contract and add it to my calendar” decomposes into retrieval, extraction, and an action. The agent plans the chain, executes each step, and stops at any step that requires a capability you have not granted.

Every action is proposed before it runs. Navigation shows the full destination URL, and any part of that URL derived from page content rather than from you is visually marked — a direct result of finding that a confirmation covering the action but not its parameters approves exfiltration attempts.

What it does not do

Multi-step execution is the newest and least mature part of the product. It is off by default in the alpha. Chained exfiltration remains the attack class with the highest residual success rate against our defences, at 11.3%.

Specification for Multi-step task execution
ActionsNavigate, extract, fill, submit, download
PlanningOn device when a local model is selected
ConfirmationPer action, with parameter provenance shown
RollbackForm fills reversible; submissions are not
AvailabilityAlpha, off by default
Ask us about this

Citations and source attribution

Every claim the agent makes links back to the passage it came from.

Shipping

Answers are assembled from retrieved passages, and each sentence carries a reference to the chunk that supports it. Clicking a citation opens the source at the right position, whether that is an open tab, a page from three weeks ago, or a local PDF.

Citation accuracy is the metric we gate model selection on, ahead of throughput. A model that produces fluent answers attributed to the wrong source is worse than a slower one that gets attribution right, and this is exactly what aggressive quantisation breaks first.

What it does not do

Citations show what the model retrieved, not proof that it reasoned correctly from the passage. A correct citation attached to a wrong inference is still possible and you should read the source when it matters.

Specification for Citations and source attribution
GranularityPer sentence
SourcesOpen tabs, history, bookmarks, local PDFs
VerificationClick-through opens the source at position
Gating metricCitation accuracy, ahead of throughput
Data leaving deviceNone
Ask us about this

Agent audit trail

A local, human-readable log of everything the agent read, skipped, and did.

Shipping

Every agent turn writes a record: which sources were retrieved, which were considered and discarded, which actions were proposed, and which you approved. The log lives on your disk in a readable format and is never transmitted.

The point is not compliance theatre. It is that when the agent produces a surprising answer, you can find out why in about ten seconds rather than guessing.

What it does not do

The log records what the agent did, not the model’s internal reasoning, which we cannot faithfully reconstruct. On Team and Enterprise tiers the log can be centralised, which is a deliberate trade your administrator makes visible to you.

Specification for Agent audit trail
FormatPlain JSON on disk, human-readable
RetentionConfigurable, 30 days by default
ExportYes, as a single file
Shared audit logTeam and Enterprise tiers
Data leaving deviceNone on Personal and Pro
Ask us about this

Capability grants and permission scoping

The agent can only do what you have explicitly allowed, scoped per domain.

Shipping

Capabilities are granted rather than detected. The agent cannot navigate, fill, submit, or download unless that capability is enabled, and grants are scoped to a domain or a session rather than granted globally.

Our injection research found that defences which work by detecting a malicious instruction can be defeated by rephrasing it, while defences that limit what the agent can do cannot. Capability gating was the single most effective defence layer we measured, and it is the one that degrades gracefully.

What it does not do

Capability limits reduce blast radius; they do not detect intent. An attack that stays within granted capabilities can still do harm, which is why egress restriction sits underneath them as a second boundary.

Specification for Capability grants and permission scoping
ScopePer domain, per session, or global
DefaultRead-only; no navigation, fill, or submit
EgressRestricted to origins already in your session
RevocationImmediate, from the agent panel
Policy managementTeam and Enterprise tiers
Ask us about this
Identity and cryptography

Keys that are generated inside your device’s security chip and cannot be exported, with post-quantum key exchange on by default rather than behind a flag.

Hardware-bound key generation

Your private key is created inside the TPM or Secure Enclave and cannot leave it.

Shipping

Identity keys are generated with the non-exportable attribute set, inside the platform security module — TPM 2.0 on Windows and Linux, the Secure Enclave on macOS. The key material is never present in system memory and cannot be read out by any software, including an administrator with full platform authorisation.

We tested this across 47 device models before shipping the claim. All 47 correctly refused every export approach we tried: direct export, null-parent duplication, administrative override, and blob extraction into a software TPM.

What it does not do

We tested software interfaces, not silicon. This says nothing about physical attacks or side channels. Four device models in our survey silently invalidated stored keys during a firmware update, which is why a recovery path is mandatory at enrolment.

Specification for Hardware-bound key generation
HardwareTPM 2.0 · Apple Secure Enclave
AlgorithmsECDSA P-256, P-384, RSA-2048/3072
ExportRefused — verified on 47 device models
Re-attestationOn every browser launch
Data leaving devicePublic key only, on enrolment
Ask us about this

Post-quantum key exchange

Hybrid X25519MLKEM768 on every new connection, on by default.

Shipping

Every TLS session negotiates a hybrid construction combining classical X25519 with ML-KEM-768, the NIST-standardised lattice KEM. Hybrid means a break of either component alone does not compromise the session.

This is on by default rather than behind a flag because harvest-now-decrypt-later is a present-tense threat: traffic captured today can be decrypted later, and for anything with a long confidentiality lifetime the correct comparison is not milliseconds against zero.

What it does not do

About 3.1% of connections incur an extra round trip because the larger ClientHello exceeds the initial congestion window — concentrated on satellite links, some corporate networks, and older mobile infrastructure, where the penalty is a median 94 ms. No device we surveyed offers in-chip post-quantum signing, so ML-DSA runs in software.

Specification for Post-quantum key exchange
Key exchangeX25519MLKEM768 hybrid
SignaturesML-DSA in software over chip-protected key material
Median cost6.8 ms over classical, measured on 1.24M handshakes
FallbackClassical, when the server does not support hybrid
DefaultOn
Ask us about this

Passwordless, hardware-attested sign-in

Sign in with a key that lives in your chip instead of a password that lives in a database.

In alpha

Enrolment creates a site-scoped key inside the security module and registers its public half. Sign-in is a challenge signed by hardware. There is no shared secret, nothing to phish, and nothing in a breach dump.

Where the site supports it, Dart can additionally present a hardware attestation proving the key really is chip-resident. Where the device’s attestation chain does not validate, the key still works — it simply cannot prove its residency, and Dart tells you so rather than failing silently.

What it does not do

Remote attestation is not dependable across the hardware population: only 31 of 47 device models we tested provided a chain we could validate, mostly because vendor certificate infrastructure decays. We treat attestation as advisory for that reason.

Specification for Passwordless, hardware-attested sign-in
ProtocolWebAuthn-compatible
Key scopePer site, non-exportable
AttestationAdvisory — validates on 66% of devices surveyed
RecoveryEstablished at enrolment, mandatory
AvailabilityAlpha
Ask us about this

Key recovery without a custodian

A recovery path that does not hand your key to a company.

In development

A non-exportable key is a liability if losing the device means losing the identity. Dart establishes a recovery path at enrolment, before the hardware key is trusted for anything, using threshold shares that you distribute rather than a custodial escrow we hold.

This is the part of the identity layer we are least finished with, and we would rather say so than imply it is solved. A preprint on the scheme is circulating for review.

What it does not do

Not shipped. The current alpha establishes a recovery path but the threshold scheme is still in review, and we do not recommend relying on hardware identity as a sole factor for anything you cannot afford to lose.

Specification for Key recovery without a custodian
ApproachThreshold shares, user-distributed
CustodyNone — we hold no recoverable material
EstablishedAt enrolment, mandatory
StatusIn development; preprint under review
AvailabilityNot in the alpha
Ask us about this

Per-site identity isolation

A separate key per site, so no two sites can correlate you by your credential.

Shipping

Every site gets its own key, derived independently inside the security module. Two sites that collude cannot determine that they are talking to the same person by comparing credentials, because there is no shared identifier between them.

This extends to the browser’s storage partitioning: cookies, cache, and storage are partitioned by top-level site, so cross-site state cannot be used to rejoin what key isolation separated.

What it does not do

Isolation prevents correlation by credential and storage. It does not prevent correlation by fingerprint — that is a separate and harder problem, addressed by the mitigations below, which reduce but do not eliminate identifying entropy.

Specification for Per-site identity isolation
Key derivationIndependent per site
Storage partitioningBy top-level site
Cross-site correlationNot possible via credential
ProfilesAdditional isolation boundary, Pro and above
DefaultOn
Ask us about this
Model choice and privacy

You own the intelligence. We charge for the browser, never proxy your inference, and send nothing about your browsing anywhere by default.

Bring your own cloud key

Paste an API key you already pay for. Traffic goes to your provider, not through us.

Shipping

Add a key from Anthropic, OpenAI, Google, or OpenRouter and the agent uses it directly. The key is validated client-side and stored in your operating system keychain — not in a Dart account, not on our servers, and not in a synced profile.

Inference requests go from your browser to your provider. We are not in the path, we cannot see the traffic, and we do not add a margin. This is a permanent design choice rather than a launch limitation, and it is the reason our pricing does not depend on how much you use the agent.

What it does not do

Cloud inference means your prompts and retrieved context reach your provider, under their terms rather than ours. Dart cannot make a cloud model private; it can only make the choice explicit and keep itself out of the path.

Specification for Bring your own cloud key
ProvidersAnthropic, OpenAI, Google, OpenRouter
Key storageOS keychain, client-side only
Our margin on inference$0
Request pathBrowser → provider, direct
Model slots1 on Personal, unlimited on Pro and above
Ask us about this

Point it at a local model

Auto-detects local runtimes. The only configuration where nothing leaves your machine.

Shipping

If Ollama, llama.cpp, LM Studio, or MLX is running, Dart finds it and lists the models it serves. Selecting one makes the agent fully offline: no key, no account, no network.

This is the configuration regulated industries actually need, and the one we optimise hardest. It is also the reason our inference research focuses on consumer hardware rather than datacentre throughput.

What it does not do

Local models are meaningfully less capable than frontier cloud models at long-context reasoning. On extraction tasks the gap is smaller than people expect; on open-ended synthesis it is larger. Choose per task rather than once.

Specification for Point it at a local model
DetectionAutomatic on launch
RuntimesOllama, llama.cpp, LM Studio, MLX
Network requiredNone
Air-gappedSupported
Data leaving deviceNone
Ask us about this

Enterprise model gateway

Your administrator supplies one endpoint; the team signs in through SSO.

Shipping

An organisation can point every Dart install at a single internal gateway URL. Users sign in with SSO and never handle a key. The gateway can be a self-hosted model, a vendor endpoint, or a policy proxy that logs and filters.

This is how regulated deployments keep inference inside a network boundary a regulator drew, without asking every employee to manage credentials.

What it does not do

The gateway is a chokepoint by design, which means whoever runs it can see what passes through. That is usually the intent, and Dart surfaces it to users rather than hiding it.

Specification for Enterprise model gateway
ConfigurationSingle gateway URL, centrally managed
AuthenticationSSO — OIDC on Team, SAML on Enterprise
Compatible withLiteLLM, Bedrock, Vertex, self-hosted
PolicyCentral management and shared audit log
TiersTeam and Enterprise
Ask us about this

No telemetry by default

A fresh install makes no analytics, usage, or personalisation request. Ever.

Shipping

Out of the box, Dart contacts our servers for exactly two things: update checks and certificate revocation. There is no analytics endpoint, no usage reporting, no crash telemetry, and no advertising identifier, and there is no setting to change because there is nothing to switch off.

We measured the four major browsers over 30 days to establish what “default” normally means. At default settings they issued between 214 and 3,140 vendor-bound requests per day, and enabling every privacy setting eliminated this in none of them.

What it does not do

Update and revocation checks are unavoidable for any browser that intends to stay patched, and they do reveal that an install exists. Air-gapped deployments can disable both and manage updates out of band.

Specification for No telemetry by default
Vendor requests at restUpdate check, certificate revocation
AnalyticsNone
Crash reportingOpt-in, per incident, with the payload shown
Advertising identifierNone
Applies toAll tiers, including Enterprise
Ask us about this

Tracker and fingerprint resistance

Mitigations that are on for everyone, always, with no configuration surface.

Shipping

Canvas and WebGL readback are perturbed, font enumeration is restricted to a fixed set, and high-resolution timing is coarsened. Known tracker origins are blocked at the network layer before a request is made.

There are no user-facing anti-fingerprinting toggles, and that is deliberate. Our measurement work found that hardened configurations increase entropy in one attribute group by 19%, because turning off features almost nobody turns off makes you distinctive. Uniformity protects people; configurability does not.

What it does not do

Fingerprinting cannot be solved by any single browser. Our own measurements put residual entropy at 13.2 bits with full mitigation, enough to distinguish roughly one user in 9,400. We report that number rather than claiming the problem is closed.

Specification for Tracker and fingerprint resistance
Canvas / WebGLPerturbed readback
FontsFixed enumeration set
TimingCoarsened
Tracker blockingNetwork layer, before request
User togglesNone — by design
Ask us about this

Index-only sync

Opt-in sync that replicates index structure, never page content.

In alpha

If you turn sync on, what replicates is the structure of the semantic index — not URLs, not page text, not your agent conversations. A second device can find that a relevant document exists and where it came from, and re-fetches the content locally.

Sync is off by default. This is the one feature where we move any browsing-derived data off your machine, so it is opt-in, scoped, and documented in full rather than buried.

What it does not do

Index structure is not content, but it is not nothing either — a sufficiently determined analysis of structure alone could infer topics. We consider this the weakest privacy claim we make and would rather state it plainly than round it to zero.

Specification for Index-only sync
DefaultOff
ReplicatedIndex structure only
Not replicatedURLs, page text, agent conversations
EncryptionEnd-to-end, key derived on device
TiersPro and above
Ask us about this
Browser fundamentals

It still has to be a good browser. Chromium underneath, with the surveillance infrastructure removed and the web compatibility kept.

Chromium compatibility

Built on Chromium, so the web works. Google services removed, patch inventory published.

Shipping

Dart tracks upstream Chromium closely and carries a patch set that removes Google service integrations: sync, safe-browsing-as-implemented, field trials, metrics, and the component updater’s telemetry surface. Rendering, V8, and the sandbox are untouched.

We publish the full patch inventory — every patch we carry, what it removes, and the web-compatibility cost of each — because “de-Googled” is a claim that means nothing without a list.

What it does not do

A fork carries maintenance cost and a rebase lag behind upstream security releases, typically under 72 hours. Purity that breaks the web serves no one, so a small number of Google-origin services remain where removing them would break sites.

Specification for Chromium compatibility
BaseChromium, tracked closely to upstream
RemovedSync, field trials, metrics, telemetry surface
UntouchedRendering, V8, sandbox
Patch inventoryPublished as a technical note
ExtensionsChrome Web Store extensions supported
Ask us about this

Profiles and per-domain rules

Separate identities, models, and agent permissions per context.

Shipping

A profile bundles an identity set, a model selection, and a capability policy. Work and personal browsing can use different models, different keys, and different agent permissions without signing out of anything.

Per-domain rules sit inside a profile: you can grant the agent form-fill on your issue tracker and read-only everywhere else, and the rule follows the domain rather than the session.

What it does not do

Profiles isolate state, not hardware. Fingerprinting surface is shared across profiles on the same machine, so profiles are not an anonymity boundary and we do not present them as one.

Specification for Profiles and per-domain rules
IsolationIdentity, storage, model, capability policy
Per-domain rulesCapability grants scoped by origin
SwitchingWithout sign-out
Central policyTeam and Enterprise
TiersPro and above
Ask us about this

Air-gapped deployment

A build that makes no outbound connection at all, for networks that require it.

Shipping

Enterprise deployments can run a build with update checks and revocation disabled, a local model, and no configured gateway. In this configuration the browser makes no outbound connection except to the sites you visit.

Updates are managed out of band by the administrator, which is how these environments handle every other piece of software.

What it does not do

Disabling revocation checking is a real security trade, not a free win. Air-gapped deployments must have a process for distributing revocation data, and we will not ship this configuration to an organisation that does not.

Specification for Air-gapped deployment
Outbound connectionsNone beyond sites you visit
UpdatesOut of band, administrator-managed
ModelLocal runtime, mandatory
AttestationLocal only
TierEnterprise
Ask us about this
Missing something?

Ask us what it actually does.

If a capability you need is not listed, it does not exist yet — we do not keep an unlisted feature set. Tell us what you need and we will say whether it is planned, possible, or something we have decided against.