SSyncropel Docs

Release Notes

A plain-language summary of recent Syncropel releases: intelligent task tooling, mechanism-independent intelligence, and a friction-free local start. Newest first.

Overview

This page summarizes recent releases in plain language: what changed and why it matters for using Syncropel day to day. For the exhaustive, version-by-version technical record, see the changelog in the source repository.


From Your Browser

You can now add a phone by scanning a code, see your devices and sign any one out, add a passkey before you need it, make a recovery code, and invite people, all from your browser; if you also use the command line, you can link the two so people see one of you.

  • A first passkey needs a fresh sign-in. To add the first passkey to a workspace, you sign in again first, or use a sign-in that has just proved it's you. A browser session someone copied can't add a passkey of its own.
  • Invites keep to your own role. A member can only make an invite for a role they hold themselves. An invite link only ever sends a guest to your workspace's own web address.
  • Add a phone by scanning a code. You confirm it by picking the matching words, which only the new phone shows.
  • Your devices. See every device you're signed in on and sign any one of them out.
  • A recovery code you can make in advance, shown once.
  • Adding or removing a passkey is never quiet. When a first passkey is added or any passkey removed, your other signed-in devices are told, and for 24 hours you can undo a first passkey from any of them.
  • A code from the owner. If you have no passkey yet, the owner can give you a one-time code that lets you add one.
  • One of you. If you also use the command line, you can link it to your browser sign-in so people see one of you.
  • A recovery sign-in can't strip your passkeys. If someone gets back in with a recovery code or a brand-new passkey, they can't remove the passkeys you already had until a day has passed. Every session that was signed in before is ended, and says why.
  • Removed stays removed. A passkey or recovery code you remove stays removed after a crash and after restoring an older copy.
  • Restoring never goes backwards by accident. Restoring a copy older than your live workspace is refused unless you say so, and the restore notes that you chose it.
  • Your task notes are in your backup. Task notes now travel with your off-machine copy and your startup backup, and can be restored on their own.
  • Each run says why. Every automation run, and every one that didn't run, records the reason. An automation you paused yourself is no longer listed as a problem.
  • Your own usage. See how much assistant use you've had.
  • Known.
    • After some restores, a browser that was signed in is signed out without saying the workspace was restored.

Where You're Signed In

Every browser and connected app now signs in as its own session that you can see and end, and important changes such as approving an automation ask for your passkey first while everyday answers don't; you can also let Syncropic support in for 24 hours only when you choose, keep notes and messages private to your own devices, and see in your account what ran in each workspace, what didn't and why.

  • Your browser is you. Signed in on a browser, an owner can do everything an owner does: answer the first-run question, approve an automation, invite people.
  • Your passkey only when it matters. Your passkey is asked for when an answer changes something important, such as approving an automation. A plain answer to a question doesn't need it.
  • What ran and why. Your account shows what each automation was expected to do and whether it did, what ran, and why something didn't.
  • Retired keys stay retired. A key you retire stays retired, even after a crash.
  • Revoking an invite ends its sign-ins. Revoking an invite also ends every session that was started from it.
  • Erasing reaches how someone joined. Erasing someone now also removes the record of the invite they joined with.

What You Approve

Your assistant can now propose automations that run only once you approve them, conversations can be grouped into projects, and you can use your own Anthropic key for the assistant; free workspaces can also take uploads, and a workspace that stops responding now restarts itself.

  • Automations you approve. Ask your assistant to do something on a schedule, or whenever something happens, and it proposes an automation. Nothing runs until you say yes, and you can pause or remove it later.
  • Projects. Conversations can be grouped into projects, and a project can be put on hold or marked done.
  • Your own model key. On a hosted workspace you can add your own Anthropic key for the assistant, and remove it again. The key is never stored as a record or shown back to you.
  • Uploads on Free. Free workspaces can take uploads.
  • A workspace that stops responding restarts itself instead of staying dark.
  • When included use runs out. When a Pro workspace has used the assistant use included for now, the assistant says more becomes available later. A Free workspace is told it can upgrade to keep going.
  • From the command line today. These are in this release for the command line and the API. The browser shows the first four from the next release.
    • Every sign-in is its own session. Each browser and connected app signs in separately. You can see your sessions, end one, or end all the others. Anything a session writes is written as you.
    • Your passkey for important changes. Changing who is in your workspace, its keys, its invites or its sharing asks for your passkey first. A run of the same change reuses it for a few minutes.
    • Private notes and messages. You can keep an item sealed to your own devices. The workspace stores only the sealed version: search, automations and assistants never see the words, and an assistant in the room is told only that there is something private it can't read.
    • Support only when you allow it. Syncropic support can reach your workspace only with access you give, for 24 hours, and you can take it back.
    • Guardians. You can name people you trust to help you back in if you lose every device. A recovery waits before it completes, you can stop it from any of your devices, and you're emailed when one starts.
    • Moving keeps who you are. A workspace moved to another home keeps its identity, and the old home stops accepting writes and says why.

What's Kept About You

A person can now see what assistants remember about them and ask to have it forgotten, and see how often items about them were read (the owner sees who, for 30 days); erasing someone now also removes their keys and invites, and gives the owner a report of what went; an owner can see a room exactly as a guest sees it, and hand a role like "accountant" to someone new without re-inviting anyone; a restore says whether the workspace moved or became a copy; and the copy off the machine now holds your files, not just their names.

  • What assistants remember about you. You can see what an assistant remembers about you and ask for it to be forgotten. A memory about a person expires on its own after 90 days.
  • Who read items about you. You can see how often items about you were read. The owner sees who read them, for 30 days.
  • Erasure that removes everything. Erasing someone now also removes their keys, their unused invites and the data their connected accounts brought in. The owner gets a signed report of what went, and can preview it before confirming.
  • See a room as a guest sees it. An owner can look at a room exactly as a particular person sees it, without changing anything.
  • Roles you can hand on. A role like "accountant" can pass to someone new without re-inviting anyone.
  • A restore tells you what it did. Restoring a workspace says whether it moved or became a copy.
  • Your files, off the machine. The copy kept off the machine now holds your files, not just their names, and says plainly if anything is missing.
  • Connected accounts stay yours. Data a connected account brings in stays sealed to the person who connected it, never leaves by sync or export, and is deleted when they disconnect.
  • Automations without a model. Simple automations can run on a schedule without an assistant, and every run leaves a receipt that says what happened, or why it didn't run.
  • Removed means removed. A person whose access was taken away stays out after a restore, and the members list no longer shows removed or erased people as if they were present.

What A Restart Keeps

A hosted workspace's backups now survive a restart; restoring a workspace that was still running tells you it became a copy and when to try again; someone who has been erased shows only as "Someone who was erased"; and updating an installed venture keeps your own settings.

  • Backups that survive a restart. A hosted workspace keeps its backups on its own storage, so a restart no longer loses them.
  • A copy off the machine. A hosted workspace can keep a copy of itself off the machine, and says plainly when that copy isn't being written and why. Syncropic turns this on per workspace.
  • Restoring a running workspace. Restoring a workspace that was still running tells you it became a copy, and when to try again.
  • Erasure is quiet. Someone who has been erased shows only as "Someone who was erased". Nothing a member can see says that an erasure happened, and the owner can see what is being held and why.
  • Requests from outside. A person outside the workspace can ask to join, and the owner can accept, decline or block the request.
  • Guests can act on what they're shown. A room can let a guest take a set action on an item they can see, such as confirming it.
  • Updating a venture keeps your settings. Updating an installed venture keeps your own choices: which automations are on, your budgets and caps, prompt edits, chosen columns and saved views.
  • Search without an embedding model. Search works by plain words when no embedding model is set up.
  • Your memories are yours. Only you, or the workspace owner, can export what an assistant remembers about you.

What You Can Open

An owner can now choose what each person may open in a room, files and audio included, and change someone's access without removing them; owners see how often each item is opened, never by whom; an invite names the conversation instead of showing a code; members can take a copy of what they wrote; and when someone asks to be erased, a company can keep only the records the law requires, and tells them what it kept and until when.

  • Seeing is not opening. For each room you now choose three things separately: what a person can see, what they can write, and what they can open. Opening covers files and audio. Invites made before this release keep working as they did, and you get a notice listing what they can open.
  • Change access without removing someone. You can widen or narrow what a person can see, write or open in a room, and they keep their place and their history.
  • Removing someone stops their live view at once. A person you remove, or whose access you narrow, stops getting live updates immediately rather than at their next page load.
  • How often, never by whom. Owners see how often each item in a room is opened. The count never names the person who opened it.
  • Invites say where they lead. An invite now names the conversation it opens instead of showing a code.
  • A copy of what you wrote. Members and guests can take a copy of everything they wrote in a workspace, including what's sealed to them, and see what the organization keeps about them.
  • Keeping only what the law requires. When someone asks to be erased, a company can keep the records a law requires it to keep, and only those. The person is told what was kept, why, and until when. Everything else is hidden at once, from the owner too, and erased when the last kept record's period ends.
  • Older key copies stop holding erased words. After an erasure, older backups of your keys are re-sealed so they can't unlock what was erased. If some can't be re-sealed yet, your workspace says which ones and what to do.
  • A workspace has a lasting ID. Every workspace now has an ID that stays the same through restarts and moves. A copy gets its own.
  • Faster upgrades. Our largest workspace came back in about ten seconds after this upgrade, down from over three minutes, because its startup backup is now taken after it is already answering.
  • Known.
    • The first time a row's details are opened, they can take up to about a second.
    • A retraction hides an item from view. It does not erase it.
    • Records kept for legal reasons can be read by named people, but not yet by a role such as "the treasurer".

Who Can See What

An owner can now let a guest into just one list without the conversation around it, a guest's messages become unreadable once they're erased, every key says whose it is in plain words, owners see their members, keys and automations as tables they can act on, you can choose whether decision emails reach you once they start, and restoring from your backups no longer brings an erased person back.

  • Share a list, not the conversation. You can give a guest one list in a room, such as a tracklist or an agenda, without the conversation around it. You choose which columns they see.
  • A guest gets exactly what the link said. Guest links carry the access they were made with, and a guest can't be given the ability to write without a limit on what.
  • A guest's words are sealed to them. When a guest writes a message, its text is sealed so that erasing the guest makes it unreadable everywhere.
  • Every key says whose it is. The list of keys names each key's owner in plain words, and keys that have ended are hidden unless you ask to see them.
  • Your workspace as tables. Owners see their members, keys, automations, questions waiting for them, and notices as tables with buttons that act on them.
  • Row details. Opening a row shows the items related to it.
  • Decision emails are your choice. You can say whether emails about decisions reach you, once they start being sent.
  • Erased stays erased. Restoring from your backups no longer brings an erased person back: a backup that doesn't carry the list of erased people is refused. You can also preview what an erasure would remove before doing it.
  • Only what a guest may see. A guest can no longer read summaries built from the whole workspace, and a coded identifier that could link one person across workspaces is no longer shown to anyone but the owner.
  • Known.
    • Erasing someone removes what was sealed to them and every copy made from it. It does not yet remove plain items they wrote before sealing existed.
    • A guest's messages are not searchable, because they are sealed.

What A Guest Can Reach

A guest you let into one room can no longer erase other people, make the room public, watch who is in other rooms, or read what the assistant proposes elsewhere; items sent at the same moment are never lost; a table shows each person's latest answer; audio plays from the exact point on Safari and iPhone; and erasing someone now also removes their words from search.

  • A guest stays in their room. Someone you invite into one room can no longer:

    • erase another person;
    • make the room public;
    • see who is present in rooms they weren't invited to;
    • read suggestions and rules meant for you.

    A key made for a repository no longer reads your conversations.

  • Nothing sent at the same moment is lost. When several people or tools send items at the same moment, every one is kept. Before, some could be turned away.

  • Tables show each person's latest answer. A table that shows answers, such as a verdict, an RSVP or a decision, now shows the most recent one instead of the first. It can also read answers kept in a different room.

  • Buttons keep the rest of the row. A button that changes one field of a row no longer clears the row's other fields.

  • Audio plays from the exact point. Seeking in audio stored in a connected bucket now works on Safari and iPhone.

  • Erasing someone removes their words from search. Erasing a person now also removes their words from message search and from the search that finds things by meaning. The items themselves are not changed, and replies that quoted their words, or the display name they chose, are not changed either.

  • Messages go to who you ask. A message sent to one assistant is answered by that assistant only. If it can't answer (for example, because its daily budget is spent), it says so, and no other assistant answers in its place.

  • Your own workspace knows it's yours. On a workspace you run yourself, you're now recognized as its owner without any extra setup.

  • Only models you can use. The list of models you can give an assistant now shows only the ones your workspace can actually use.

  • Undo an install. A workspace can now list what an install added and take it back out, with a preview first. The preview names every scheduled task it would stop.

  • Large workspaces keep up. A workspace's repository keeps its ready-made views current past 600,000 items, within the memory the workspace has.

  • Known. A table whose answers come from another table is slower on very large libraries for now. This will be addressed in the next release.

The Read Path At Scale

Long conversations and large libraries now open quickly however big they grow, a library can be filtered and sorted across everything in it, a busy workspace asks for a moment instead of hanging, closing a tab no longer stops live updates in your others, and a guest's key can no longer list conversation titles outside the rooms you gave them.

  • Long conversations open quickly. A conversation now opens on its most recent part and loads older messages as you scroll back, so opening one no longer gets slower as it grows. On the smallest hosted size, a page that used to take seconds now takes a few hundredths of a second.
  • Large tables open quickly, including right after a change. A table is kept up to date as items arrive, instead of being worked out from scratch each time you look. On the smallest hosted size, the first look after a change went from several seconds to well under one.
  • Filter and sort across everything. A table can be filtered, sorted and searched across all of its rows, not only the ones on screen, and saved views keep their filter and sort. Each column says what kind of values it holds and offers the values you can pick from.
  • A busy workspace asks for a moment. When many heavy requests arrive at once, the workspace answers "busy, try again shortly" instead of making everyone wait. A request you walk away from stops using the workspace.
  • Closing a tab no longer stops live updates in your other tabs.
  • A guest's key sees only their rooms. A key given to a guest for one room could list the titles of other conversations in the workspace. It no longer can.
  • If you have your own scripts: reading a whole conversation in one go now returns its most recent 1,000 items, along with a marker to continue from. Scripts that relied on getting everything at once should read page by page until nothing more is left.
  • Known. The first time a large table is opened after an upgrade, it can take a few seconds while it is prepared in the background. On a workspace where items have been erased, opening a large table right after a change is a little slower for each erasure. This will be addressed in the next release.

Nothing Waits Behind A Load

Loading a large library no longer slows the rest of your workspace or drops anything along the way, stopping something or taking someone's access away takes effect at once, and the warning that files weren't saved now appears only when one really is missing and stays gone once you dismiss it.

  • Your workspace stays quick while it loads. Sending thousands of items used to make everything else on a small workspace slow, sometimes for many seconds. Now the rest of the workspace keeps answering quickly while a load runs, even on the smallest hosted size.
  • Nothing is dropped under load. If your workspace is busy, it asks the sender to wait and try again, and keeps every item. A workspace that had fallen behind catches up on its own after the upgrade; older items are brought up to date without re-running anything they already did.
  • Stopping and revoking take effect at once. Stopping an assistant, taking someone's access away, or erasing someone takes effect before you're told it's done, however busy the workspace is.
  • Sending the same file twice adds nothing, including names with accented letters, which could previously be added a second time.
  • Tables show only what is current. A table no longer counts items that were closed or replaced, so some counts may go down after the upgrade. A table that asks for a setting the workspace does not support yet, such as sorting, is told so by name instead of the setting being quietly ignored.
  • Tables open faster, especially when you look at the same one again.
  • Only you can change what your forms offer. The forms a venture shows can now be set up only by the workspace's owner.
  • The "files not saved" warning tells the truth. It appears only when a file really is missing, and dismissing it sticks.
  • Known. The first time you open a large table after something changes can still take a few seconds on the smallest hosted size.

Only What You Meant To Share

An invite can now limit a guest to the kinds of record you choose, people you erase stay erased through every backup and restore, your connected storage opens only to you, and a whole library loads in minutes.

  • Invites can limit what a guest reads. When you invite someone, you can now say which kinds of record they may read, for example the RSVPs on an event but not the contact details. The limit holds everywhere they might read: the conversation, search, counts, live updates and tables. If a guest can write something private (like their own phone number), the invite must say what they may read, so one guest can never see another guest's details. Invites made before this release keep their current access, and spl doctor tells you how many there are.
  • Erased stays erased. When you erase someone's data, the keys that could unlock it are now handled with your sealed backup, and a record of the erasure is kept outside the workspace and re-applied every time it starts. Restoring an older backup can no longer bring back someone you erased. spl doctor warns you if your backups are not protected by a passphrase, or if they sit only on the same disk as your workspace.
  • Your connected storage opens only to you. Files in storage you have connected (for example a Drive folder) can now be browsed and opened directly only by you. Everyone else plays a file through the table it belongs to. A Drive connection now stays inside the folder you connected, and switching a connection off takes effect straight away.
  • Large loads in minutes. You can now send many records in one request. A music library of about 12,000 records loads in under two minutes, where it used to take close to an hour, and sending the same file again adds nothing twice. Resend the same file rather than rebuilding it, so nothing is counted as new.
  • Buttons on tables. A table can offer actions on its rows, for example recording a verdict on a track, and can say who may press them. Media in a table plays with a press, and never hands out a lasting link.
  • Reports that are always current. A workspace can now declare reports, such as what is due soon or which incidents are open, that are worked out the moment you look at them.
  • Who you are, stated once. Your workspace can now record whether its owner is a person or an organization, and every check agrees on who the owner is. A workspace set up for an organization should say so before anyone sets a personal name.
  • Joining by invite is more reliable. Accepting an invite could occasionally fail if the workspace was busy at the same moment. It now recovers on its own.
  • Known. Some reports built on top of other reports can still count an item that was closed or replaced. The newer, always-current reports do not.

One Room Means One Room

A guest invited to one room now sees only that room everywhere, including in live updates, and large tables count every item.

  • A guest sees only their room, even in live updates. Someone invited to one conversation could receive live updates about other conversations in the workspace. Live updates now follow exactly the same rules as everything else: a guest receives only what they are allowed to see. They are still told when their own access changes.
  • Large tables count everything. A table built from a conversation with more than a thousand items used to read only the first thousand, so its totals could come out as zero. It now reads the whole conversation.
  • A new assistant works from its first message. For a moment after you added or changed an assistant, a message could reach a generic stand-in instead. The change now takes effect before the workspace says it is done.
  • Renewing a device key keeps its end date. Renewing a device's key used to reset how long it lasted. It now keeps the original end date, so a key cannot be renewed forever. An owner's device can renew its key and keep the owner's rights, with a one-minute overlap so nothing is cut off mid-task.
  • Groundwork for email you can control. The workspace can now prepare a short notice when a decision is waiting for you, and you can mute a conversation you do not want to hear about. Nothing is emailed yet: sending starts only once it is switched on for your workspace, and each notice contains no content from your workspace, only a link back to it.
  • Small improvements. spl --version now shows exactly which build you are running. A scheduled task that runs on nobody's behalf is flagged by spl doctor, and the workspace shows when your saved secrets were last backed up.

What Stays Yours

A device's key now runs out on its own, your private settings stay in your workspace, and the workspace tells you plainly when a backup is failing.

  • A device key stops working after 90 days. When you sign in to a workspace from a browser or another device, that device gets a key. It now expires on its own after 90 days, so a key left behind on a borrowed or shared computer cannot be used later. Signing out already removed it; this covers the times you forget. Keys you create for your own tools and scripts are unchanged and do not expire unless you ask them to. If a key has run out, the workspace says so plainly, and opening the workspace again from your account gives that device a new one.
  • Your keys and private settings stay in your workspace. Saved credentials, the passwords paired workspaces use to reach each other, and the record of who read which secret are never sent to another workspace, whatever it asks for. A workspace you have not paired with cannot push anything into yours.
  • Only the owner decides where a saved secret lives. Pointing a named secret at a different store is now something only the workspace owner can do.
  • A key you set from the command line is stored where your workspace looks for it. spl config set-key now saves the key in the right place and records where it came from, and it refuses a name that would write the file somewhere else.
  • A failing nightly backup says it is failing. A workspace whose backups had never succeeded used to read "not run yet", even when it had been failing every night. It now says the backups are failing, how many times in a row, and why. spl doctor checks your newest backups, and checks the permissions on every folder where your keys are kept.
  • A workspace you use every day is no longer "still being set up". Some established workspaces reported that they were still being configured. They now report whether they are ready, based on what they actually have.
  • Tables that show the current version of each item show every column again. In workspaces that group records to their latest version, the columns joined from related records were showing blank. They now show their values.
  • Clearer checks on what you submit. A question with choices must offer between two and six of them, and a few other malformed submissions are now refused with a message that says what to fix.

Work That Actually Happens

When your assistant hands work to a helper it now runs and comes back, your workspace says what limits it, and your work runs on the key you set.

  • Handing work to a helper works everywhere. On hosted workspaces, when the assistant passed part of a task to a helper, the helper never started and the assistant waited forever. The helper now runs and its result comes back.
  • Your workspace says what limits its spending. A workspace on the free plan could read "no limit" on its own spending page, which was the opposite of the truth. It now names what actually limits it: the plan's allowance, a daily limit you set, or, on your own computer, nothing.
  • Your work uses the key you set. If you saved a key under a name, work that asks for that name now uses it. If it cannot find that key, it says so instead of quietly using a different one.
  • A decision that is yours stays yours. Where a question in your workspace is meant for a person to answer, only a person can settle it. Anyone else, including an assistant or a guest, can suggest an answer but not make it final.

What A Workspace May Reach, And What It May Spend

Connect a service key or a calendar link, choose which assistants may use it, and set a daily spending limit on a paid workspace.

  • Connect a key or a calendar link. You can add a service's key or a calendar link to your workspace. The value goes straight to secure storage and is never shown back to you or anyone else.
  • You choose who may use a connection. An assistant can use a connection only if you have allowed it, and only for work done for someone who may use it too. Removing that permission takes effect on the very next use.
  • A daily spending limit on paid workspaces. A paid workspace has a daily limit, 20 US dollars by default, which its owner can lower or raise up to that amount. When a daily allowance runs out, the workspace says so and says when it resets, instead of "try again".
  • Guests stay in their room. A guest invited to one conversation can take part in it but cannot start work elsewhere in the workspace, and a guest's daily allowance now applies wherever they work.

What Arrives Is What Was Sent

Stopping a run stops it, shared rooms agree about who is in them, copies say what they hold, and you can preview exactly what your assistant would send.

  • Stop means stop. Stopping a run from a conversation used to be ignored: the run carried on and finished. It now stops at once, and the run says it was stopped.
  • Spending limits hold. A run is no longer allowed to start a step that would take it past its spending limit, and it makes no extra request after reaching it. Replies no longer begin with internal wording such as "the token budget was reached".
  • Preview what your assistant would send. You can see the full instructions, messages and tools your assistant would use for a message, without sending anything or spending anything. In the CLI: spl actor preview <assistant> "your message".
  • Shared rooms agree about who is in them. You can now remove someone you invited to a room by link or by address. The members list shows when someone has left or been removed, and the assistant no longer talks about people who have gone. Each person has one name everywhere, and a name someone chose for themselves is kept.
  • Copies say what they hold. spl export and spl import now say whether a copy contains your workspace's private key or saved credentials, and warn you when it does. An import tells you which identity your workspace uses afterwards, and names every record it skipped and why.
  • Recovery advice is safe. When the workspace cannot start, it no longer suggests deleting files that can hold your recent work. A damaged store is named as damaged and points you to the restore guide. spl reset works for workspaces on any port.
  • Tighter checks at the door. Open live connections end as soon as the key they use is revoked. A signature on a record must be genuine to be accepted. The workspace's public startup information no longer shows the owner's identity to people who are not signed in as the owner. Invitations refuse settings they do not understand instead of quietly ignoring them.
  • Hosted workspaces cost less per conversation. Hosted workspaces now reuse the parts of a conversation that repeat between steps, so each later step costs a fraction of the first.
  • "Got it" only appears when you can use it. A notice now offers "Got it" only on a device that is allowed to dismiss it. A device paired before recent releases is asked to pair again instead.

The Assistant Does What It Says

Your assistant works from the instructions it was given, a fresh install reads healthy, and the work it does shows up where you look.

  • Your assistant now reads its own instructions. On workspaces set up with the recommended starting point, the assistant's instructions were stored in a form the part that runs its work skipped, so every conversation ran without them while the settings page showed them. It now receives them on every run, and each run records which instructions it used.
  • You can see exactly what the assistant was sent. For any step of any run, the workspace can show the full instructions and messages the model received, so "why did it answer like that?" has an answer you can read.
  • A new install no longer reports itself as broken. spl doctor used to fail a brand new workspace for having no remote copy, which no new workspace has. Facts like that are now shown as notes, and the check fails only for something you can act on. A workspace with no model key now says so plainly and tells you how to add one, instead of saying it is still starting.
  • Notes and scheduled work land where you look. A note the assistant writes while answering you appears in that conversation. A scheduled job that runs writes a short report you can find, and the run's details open from the link the workspace gives you.
  • Answering the assistant's question moves things forward. When the assistant stops to ask you something and you answer, the conversation now shows what it did next, instead of repeating the question. If you say no, it takes another approach rather than asking again.
  • The assistant says what it could not do. When a step fails while it is answering you, the reply says so. A run you start yourself can read your whole workspace, while an assistant answering in a shared room keeps to what it was given, so it never carries your private threads to a guest.
  • Keeping a copy of a new hosted workspace works. The first save of a workspace's copy to its storage failed on hosted workspaces; it now succeeds.

The Owner's Own Phone

Your second device gets your powers, the room you opened is yours, and older copies are named for what they hold.

  • A device you pair for yourself has the same rights you do. Until now a phone or second browser paired for the workspace owner knew who you were but could not invite anyone: "this browser cannot make invitations yet". A device paired for the owner from a signed-in owner's browser now carries the owner's rights, and the members page on it works the way it does on your first browser. A device paired before this release keeps what it had until you pair it again, and the workspace says so rather than showing a greyed button.
  • The room you opened belongs to you. On hosted workspaces the assistant's first reply could sort ahead of your first message, and the workspace then treated the assistant as the room's owner and refused to show you its members. Ties are now broken by the order things actually arrived, so the person who opened the room owns it.
  • Copies exported before version 0.254 are named as secrets. The previous release stopped credentials travelling in an exported copy. It could not reach copies already on disk, which still hold them. spl doctor now finds any such copy in the usual places and names it, spl import --dry-run says the same of any file you point it at, and the portability guide explains what to do (keep the file as you would a password, or rotate your tokens if it has left your machine).
  • A copy whose files arrived late is not deleted. A copy imported while one file's contents had not yet reached it used to leave that file out of the list, and the next tidy-up could then record it as deleted, which a later complete copy could not undo. The file now stays listed, says that its contents are missing, and opens as soon as a complete copy arrives.
  • "Download a copy" says three numbers. How many files the copy carries, how many distinct contents that is, and how many files could not be included, each stated rather than worked out from the others.
  • Ask for an app and get one. The assistant's instructions now say how to write an app when you ask for one, so a plain "build me a tip calculator" is enough. Existing workspaces pick this up with spl workspace repair --apply.

The Honest Reading

Three places where the workspace told you something that was not quite what it was doing.

  • A repeating job now shows the hour it actually runs. If you asked for something to happen at nine in the morning in your own timezone, the list of scheduled work showed nine o'clock UTC instead, which for most people is a different time of day. The job itself always ran at the right hour; only the time you were shown was wrong. That is the more troubling half, because a time on a screen is the one you plan your day around.
  • The welcome no longer sends you past your first question. A new workspace greets you and asks you one real question. The greeting said "open a thread and say what you are working on", which is a perfectly good instruction and quietly walks you around the question sitting just below it. It now points at the question. The question itself is unchanged and still looks like any other item, because that is the point of it.
  • A refused save is recorded as refused. When a workspace declines to save something because the credential was not entitled to write it, the record of that decision now says plainly that it was enforced. It previously described the workspace's general settings instead, which could be read as "we would have declined" when in fact nothing had been saved. Nobody lost work either way; the account of what happened is now accurate.

The Doors Open

Your work is attributed to you, and only you can write as you.

  • A device writes as itself and nobody else. A browser or app paired with your workspace could put any name on the work it saved, including yours. It can no longer name anybody but itself. If you have invited people in, this is what makes "this was written by Wren" true rather than merely claimed, and a teammate's browser can no longer save work under your name.
  • A paired browser is signed in as the person who paired it. Until now a device you paired from the command line was nobody in particular, which is why a second browser could not invite anyone even when you could. Pairing now records who did it, so your other devices can do what you can do. Devices you paired earlier keep working exactly as before; pair again to give one a name.
  • Leaving a workspace. You could already remove your own membership, and nothing told you so. Your workspace now tells a device who it is signed in as, which is what a screen needs before it can offer you the door.
  • A workspace can no longer be pointed at the wrong storage by accident. If a workspace was never told where to keep its saved copy, it used to guess, and the guess named real shared storage. It now says it has not been told, and a workspace with no storage configured starts normally and simply does not publish.

The Second Person

You can invite somebody into your workspace, see who joined, and take it back.

  • Inviting from your own browser. Most of this existed and was out of reach: the browser you opened your workspace in could already add and remove people, and could not create an invitation, see the invitations it had sent, or read the record of who used them. All three now work from the browser you already use.
  • You can see who joined and when. The list of invitations shows each person who used one and the moment they did. Nothing new is recorded to answer this; it was already known and not shown.
  • Your workspace tells a screen what you may do. Rather than a screen discovering your permissions by trying something and being refused, your workspace says plainly what this device may do. A hosted owner previously saw no members page at all for exactly that reason.
  • When somebody's access changes, open screens notice. Removing a member raises a signal that tells other screens to re-check what they may do, instead of waiting for a reload.
  • Two fixes underneath. A badly formed key is now refused instead of being treated as a sign-in, and a workspace that could not recognise its own owner can do so again.

The Body With History

Fixes that only show up on a workspace that has been used for a while.

  • Scheduled work stopped failing on established workspaces. Six places worked out where they were in a workspace's history in a way that was correct on a new workspace and wrong on a busy one, including the daily run of a scheduled assistant and the emergency path for getting back into a workspace you are locked out of.
  • A restored workspace no longer says "still setting up" forever. A workspace restored from a saved copy, with enough history that first-time setup will never run again, used to report that it was configuring and wait for something that could not happen. It now says what is actually needed and how to do it.
  • Sending a record is simpler. Anything sending work into a workspace had to compute a position in its history first, which it could not always see correctly. That is now optional and the workspace works it out.
  • Testing against realistic workspaces. Almost every check ran against an empty workspace, and the defect that reached people needed one with history. There are now four sizes to test against, and the very first run against them found a real problem.

The Free Clock

A workspace that has been running for months keeps working like a new one.

  • Automations work on a busy workspace. Creating, pausing and resuming a scheduled task failed on a workspace with a long history, and worked on a fresh one, which is why it was not caught earlier. Pausing and resuming were quietly broken on such workspaces too.
  • A change is in effect before you are told it happened. Creating a task and immediately pausing it could report that the task did not exist, and resuming then pausing could report no change at all. Both now answer from the state they actually wrote.
  • A clearer refusal. When a workspace cannot record something, it now names what it was trying to record rather than leaving a gap in the sentence.

The Standing Order

You can ask your workspace to do something on a schedule, without being there.

  • Schedules you can create. Until this release there was no way for somebody on a hosted workspace to set up recurring work at all. Now you can create an automation, pause it, resume it, and see its history.
  • Time zones. A schedule can name a time zone, so "every weekday at 9" means nine where you are. The two awkward days of the year are handled deliberately: the spring change moves the run rather than skipping it, and the autumn change runs a fixed-time job once.
  • Nothing runs away with your budget. A workspace has a daily ceiling across all its scheduled work, and you can stop everything at once.
  • Missed runs are visible. A run that was missed because the workspace was asleep is recorded rather than silently skipped, and you choose whether it catches up.

The Answer Arrives Checkable

A saved copy of a workspace says what its summaries were computed from.

  • You can tell whether a summary is current. When you restore a workspace elsewhere, its precomputed answers now say which records they were built from, and you are told plainly whether each one is current, partial, out of date, or missing. Before this you had to trust them or rebuild them, and rebuilding needed a running workspace, which is the thing a saved copy exists to avoid.
  • A read says what it left out. A filtered result used to look the same as an empty one. It now says that it was narrowed, without revealing anything about what was withheld.

The Current Value

A workspace can say, once, how to get from a pile of records to the current value of something.

  • One place to define "the latest". A team can declare how to reduce many records to the current value per item, and every screen and assistant reads the same answer instead of each working it out. A ledger stops showing every past version of everything.
  • Assistants can read those answers too. A scheduled assistant can consult a declared summary rather than re-reading raw history.

The Shared Thread

Who is on a thread, what each person can do, and what each may see, decided in one place.

  • A guest sees only what their invitation covers. A guest whose invitation covered one thread could still list things across ten other parts of a workspace. Each of those now answers for the person asking: what they may not see reads as missing.
  • Acting as the owner requires being the owner. Claiming to be the workspace owner now requires a sign-in entitled to it, rather than only naming an owner who exists.
  • Adding somebody to one thread. You can bring a person into a single thread with what they need to take part, without giving them the rest of the workspace.

The Honest Machine

The workspace says what it did and why, and a failure lands on whoever can fix it.

  • An assistant is offered exactly the tools its definition names. Each run records what it was offered and names every declared tool it was not offered, with the reason. A definition that names no tools is offered none, and naming a tool the workspace does not have is refused when you define or shape the assistant.
  • Failures are sorted by who can fix them. A missing key, a spent budget, a provider that is out of credit and a service that is briefly down are told apart. A missing key raises one question for you, and answering it once unblocks every run waiting on that key. An unfunded provider stops the run with a reason instead of letting the model try again and again. Only the mistakes the model can correct go back to it.
  • Notices instead of piles of questions. Something you may need to know, such as runs failing for the same reason, appears once as a notice with a count, and you can acknowledge it. Questions stay for things that need your answer.
  • Decide a whole class of suggestions at once. Suggested rules are grouped by what they are about, so you can apply one or stop that kind of suggestion in one step, and a stopped kind costs nothing afterwards.
  • Run a schedule by hand. You can run a scheduled trigger once now, even while it is paused, without moving its schedule, and pausing or resuming it survives reinstalling its blueprint.
  • Files travel with a published repository. Publishing a workspace now carries the files you stored in it, and restoring gives them back, each checked against its fingerprint. The publish report says whether every file was carried. Files written while the workspace is continuously saving to its repository are not carried yet; a later release adds that.
  • Smaller fixes. A fresh workspace's welcome thread always shows as your conversation; the run lists show the runs you just started; and an assistant started right after an install no longer fails on its first step.

The Unattended Workspace

If you use a hosted workspace: it now keeps saving your work on its own through sleep and restarts, and your plan's limits apply to every run.

  • It keeps saving through every sleep and restart. If a hosted workspace cannot save when it wakes, it tries again on its own within a minute instead of waiting for a restart, and its first request after waking no longer fails. Files stored in a workspace are not part of its saved copy yet, and the workspace now says so.
  • Scheduled work can wake a sleeping workspace. A hosted workspace can tell the service when it next needs to run, so the service can wake it at that moment. This is built and is being switched on for hosted workspaces; until then, schedules run while the workspace is awake.
  • Your plan's limits hold everywhere. Every run on a hosted workspace with a plan, scheduled ones included, follows that plan's limits, and those limits cannot be raised by writing configuration. Workspaces created before this release get their plan as they are updated.
  • Scheduled assistants can run unattended. An assistant that runs on a schedule no longer reads as done when it promised a result and produced nothing, and a question it asks every day replaces yesterday's copy instead of piling up.

For people running their own workspace or using the API:

  • /health and spl doctor say whether a workspace is saving (attach), and if not, why and for how long. Publish and restore now report that files are not carried.
  • A replacement machine for the same workspace takes over saving once the old one stops; while the old one still runs, the replacement reports that it cannot save rather than that it is standing by, which a later release corrects.
  • An actor's definition can name the threads and kinds its runs write, what they promise to produce, and how their effects are undone. A failed item in a batch releases what it held.

The Kept Repository

If you use a hosted workspace: it can keep a saved copy of itself with nothing for you to manage, and when an assistant needs your decision it now offers clear choices.

  • A saved copy without a key to manage. A hosted workspace can keep its own repository from the moment it is created, and keeps that copy current as you work.
  • Asks you can answer. When an assistant needs your decision it offers two to six choices, each with a line saying what it would do and one it recommends. Pick one, pick several when allowed, or answer in your own words, and the work resumes on what you chose.

For people running their own workspace or using the API:

  • One writer at a time. Publishing takes the repository's write lease before it moves the published state, so a second workspace can no longer overwrite a live writer; it is refused by name and told who holds the lease.
  • Handing a repository on. A standby takes over by itself when the lease frees, a clean stop hands the lease on after a last flush, and a writer stopped mid-write no longer loses records the published state had already committed.
  • A hosted workspace declares its repository, publishes it, and becomes its writer, so continuous write-back keeps the published copy current.

The First Question

A fresh workspace now greets you with one real question in your call: "What are you working on?" It is an ordinary item in the lane, not a welcome card, and answering it opens your first thread, titled with exactly what you typed, and puts you inside it. Answering twice lands you in the same thread, never a second empty one, and a failure part way through leaves you with a thread and the question still open rather than an answer pointing at nothing. The question seeds only when a workspace is first set up with a preset other than blank, so a workspace that already existed gains nothing on upgrade. If you self-host, the wording is yours: set SPL_FIRST_RUN_ASK before the workspace is first configured.

Your call can now be read honestly. It says whether the workspace has been configured at all, so an empty lane means "nothing needs you" and not "never set up". It counts decisions (which need an answer) apart from heads-ups (which need only a nod), so a badge never overstates what needs a person, and it says whether its count is exact or a floor.

The Stranger

A record you send is stored exactly as you sent it, and the name you get back is the name of what was stored. Previously a number with many decimal places could be stored with slightly different digits than you wrote, so a client that computed its own record name disagreed with the workspace about the same record. That is fixed for anything sent to the workspace directly; a copy arriving from a paired workspace is not yet covered.

Your call reduces noise to what you can act on. When an automated member proposes the same thing over and over (one workspace held nearly two hundred identical suggestions), you see one row with the count, and deciding it once settles the whole group. A genuinely new proposal with the same wording later is shown again rather than silently absorbed.

A workspace can now say what fills its disk (the records, each cache, and the rest, measured: three quarters of a busy workspace's disk is derived data, not your records) and hold its caches under a declared bound. A declared disk ceiling refuses ordinary writes above it while never refusing a configuration change, so a ceiling set too low can always be lifted. Every bound defaults to none, so an existing workspace behaves as before. spl doctor names the eight frame acts available on any open thread instead of reporting an empty vocabulary. The assistant was measured answering a stranger's first message on a fresh workspace in about eleven seconds.

The Proven Copy

Recovery from the off-machine copy is now proven rather than assumed. A fresh workspace was rebuilt from the live copy of a busy workspace with every record coming back under its own name, none renamed, the copy current to the second, and the signing keys byte-identical. What you read from a workspace is now the exact bytes it stores, on every reading surface, so a name you compute from what you read matches the name the workspace holds.

A restore now names what it refused and why, and distinguishes a record whose parent was already missing at the source (which no restore can invent and is not loss) from a record the workspace turned away. spl repo drift decides by who the workspace is: a copy taken from a live writer is expected to run slightly behind and is no longer reported as drifted, while a missing flush is always reported.

Two defects on the very first path a new operator walks are closed. A credential request with no credential could close the workspace's first-boot door and lock everyone out; it is refused before anything is written. And on a brand-new local workspace, spl run died on its first turn; it runs. A local workspace with no model now says what to do next (spl config set-key) instead of printing an internal sentence, and every release is now walked through a fresh workspace the way this documentation describes before it ships. A run is told to ask rather than guess when its goal is ambiguous, and a question it asks pauses the run until you answer.

The Seat

A run that asks you a question now pauses and resumes when you answer, by default. An ask whose run had already ended says so ("an answer records your decision and resumes nothing") and is counted apart in your call, so you always know whether answering will move anything. A member working in its own copy of a repository can delete a file there, one named file at a time, never a directory and never anything outside its own copy.

spl doctor gains rows that say when nothing is happening: whether this workspace replicates anywhere (and if not, that it is bound to no repository), and whether an enabled scheduled trigger has a target that is unavailable or has tripped its own breaker. Your task briefs join the daily backup. spl repo drift no longer reports a faithful copy as drifted, and a thread snapshot now carries each record's name so a restore cannot rename it. A built-in routing rule that had been erroring on most records is fixed.

The Faithful Round Trip

A copy of your workspace is a faithful copy. Export and import, publish and restore, and the continuous off-machine copy all keep every record under the name it was stored under: on a busy workspace, over a hundred thousand records were published and restored with none renamed, where more than a thousand had been renamed before. Import now verifies that every record's contents match the name it claims, so a bundle cannot smuggle a record under another name. A workspace holding records with no thread can be exported again.

Every request with a malformed body gets the same error shape, whichever door you sent it to. spl adapter remove actually removes, and spl repo publish says plainly when it only staged and did not publish. The first-boot door is decided by one rule, so the documented recovery flow on a fresh workspace works again. Known issue, deliberately not rushed: a workspace that has ever retired a member cannot yet be exported; the fix is a design decision and is tracked.

The First Hour

The release after The Door, built from an audit of the surface a stranger touches first. The first-boot credential door now closes after first boot, so nobody can mint a credential on an already-running workspace without one. Writing a record no longer crashes on the second call, the command line no longer talks to a different workspace silently when the one you named is down, spl health check stops calling a healthy workspace unhealthy, and spl token rotate actually revokes the old token. spl know, spl do and spl learn gain --fulfills, the command-line way to close a thread. The documentation was rewritten to match the software: the retired assistants are gone from it, ten releases of capability got guide pages, and the Quickstart was tested end to end.


The Door

The sandbox now does real repository work end to end. A member actor takes a private git worktree, edits and tests the code through the governed seam, and hands back a diff the run names, while the rest of the host filesystem stays read-only and every attempt to write outside the worktree is refused by name. A run can also declare what it consumes and what it promises, so a record landing on a thread a live run watches wakes that run. Paid entitlement now reaches the instance: a caller reports what a subscription did and the kernel decides the tier it grants, under a ceiling no status can exceed.

The Developer's Day

A person can now sit at the terminal with a run. A member actor gets a git worktree it owns, runs the repository's declared check, makes the fix, turns the check green, and spl run streams the whole thing and prints the diff. The writable surface of a sandboxed non-operator run is its own worktree or nothing, verified before its credential is minted, and a run names a repository rather than a path.

The Honest Builder

The words a run works by are now editable records. The guiding frame is resolved from a stored prompt at the start of every run, so an operator override reaches the next run instead of sitting unused. A failed run says why in one line, a turn may not both ask a question and quietly write, and two general tools (query_records and emit_record) let a bounded member read and write records directly. The spend and turn ceilings for each tier are now data you can edit rather than constants baked into the binary.

The Governed Session

Dispatched engines like Claude Code are now first-class runs on the same ledger. A dispatched task records its start, its questions, and a kernel-authored report with clear outcome verbs, exactly like a native run. A new register (spl register) ranks your open questions blocking-first so you can see what needs you, and an answer you give can become standing policy: a permission rule, a hook, or a remembered fact.

The Measured Actor

This release acts on the first honest measurement of how close the loop is to replacing Claude Code, fixing what a real-user battery turned up one failure at a time. Actor memory arrives: a run can remember a fact on the thread it is about, private by default, and those notes are shown the next time that thread is touched. Record search now returns the newest matches first instead of scanning the oldest, and an installed actor runs at its installer's tier rather than being throttled to trial limits.

The Record That Steers

A post-tool hook is now a record you can write. core.hook.v1 lets an operator add a short lesson that a running actor is shown after a matching tool call, authored as a config record and live on the next call with no restart and no code change. A hook can only add an observation, never silence or reorder anything, which keeps its effect easy to reason about.

The Turn That Escalates

Conversational turns can now escalate to run code and use tools when the work needs it, instead of replying that they cannot. A single reply can carry an escalation that the kernel runs through the full tool loop, and the answer records whether it ran, was refused, or was unavailable. This closed a long-standing gap where Studio agents said they could not run code even after the tools had shipped. Two same-day patches, The Second Block and The Offered Program, fixed reply parsing and turned the run_code switch on end to end.

The Improvement Loop

The actors can now be measured getting better. A run is graded against an eval suite, an actor is defined by what it makes the actor do, and this release wires those together so a new definition is compared against the one it succeeded, per axis, and "it improved" becomes a number rather than a claim. spl eval history reads that graded history for an actor.

The Self-Configuring Actor

When an actor needs an integration nobody set up, it now reaches a person with a complete proposal naming the service, the operations, and the credential it needs, instead of failing quietly. A person provides the key and the key becomes a stored secret, never a record. A new spl tool surface shows what the instance can reach and whether each tool's credential resolves.

The Program That Calls

A JavaScript program run by an actor can now call a granted tool through the governed network edge, and the same gate can refuse it mid-flight; every other host is refused at that one edge. The JavaScript runtime is published and installable with spl runtime install, content-addressed and version-pinned.

The Kind Decides

The compute substrate gains its capability model, keeping what a program may reach separate from what it may spend, plus a governed egress seam, so a program's network access is a decision rather than an open door. A decision request that is valid by its own contract is answerable again across the pending queue, and the records door now refuses a field it would previously have dropped silently, naming the fields it accepts.

The second principal

Every run for a principal other than the operator now takes the sandboxed transport by default, decided per run by the tier of the principal it runs for; the operator's own runs stay in process unless they choose otherwise, and each default is one config record to move. A tool the tier grants but the sandbox cannot serve is withheld and named on the run, never dropped silently; a run that was refused for reaching one now starts. A stop lands at the run's next step: its next tool call is answered with a stop verdict, the run ends cancelled, and its worker is reaped. Approving a proposal wakes the run that made it, so it reads the decision and finishes instead of waiting forever.

What a run is told and what fails are on its records: the kernel's own frame is a record named on every run, a provider failure inside a run is a record of its own, every turn says how its provider was resolved and every tool result how long it took. Runs are listable across actors, the event stream types verdicts and guardrails, the health door reports live runs, the roster carries each definition's ceilings, and spl runs list|show|tail reads it all from the terminal. The define door writes what it accepts and refuses what it cannot honour.

Every release now runs an escape suite from inside a real sandboxed run, on the same-user shape and on a root daemon with a separate worker user; it found and closed a gap where a hosted worker had no resource limits.

An actor that defines actors

Every work-loop actor can now read the roster (list_actors), read a run (explain_run) and propose a definition (propose_definition). A proposal is a decision request to the operator carrying a complete blueprint and the diff against what is installed; the run waits on the answer, and approving it installs the blueprint as the approver, bounded by the approver's own grant. The installed definition records who proposed it, a verdict on its runs also grades the proposer, and the proposer may never verdict such a run itself.

A work-loop actor's instructions can be a chain of prompt records, and a work-loop actor set as a thread default now answers a person the way the conversational actors do, so no adapter code is needed for an actor that talks.

Also in this release: a definition's declared budget and turn ceilings apply to runs started without their own; the roster is a door (GET /v1/actors/roster); and a sandboxed run reads the roster and run rows through the instance rather than through a store its credential cannot see.


Deploy an actor from a blueprint

An actor is now something you can write down, sign, review and install. A blueprint can declare an actor with its model, its tools, the words it runs under and the kinds of record it may write, plus the tools and permission rules it needs. spl blueprint plan shows exactly what would land and a plan hash; spl blueprint sign and spl blueprint trust-author establish who wrote it; spl blueprint install --accept-plan <hash> deploys it. The instance writes the records itself and bounds the actor by what the installer may grant, so a member cannot deploy an actor with more reach than they have.

The words are records too. An actor's prompt is a record it names by id, prompts compose through parents, and every run stamps the exact prompt it read next to the exact definition it ran under. A prompt that cannot be resolved refuses the run and says which record is missing.

And a judgment got cheaper: spl judge <winner> over <loser> --feature short records that one thing was preferred over another and what differed, the smallest signal there is about what you value.

See Blueprints and Actors.


Intelligent task tooling

The system now turns its own activity log into proactive help.

  • spl task suggest ranks your open tasks by relevance to what you've been working on and tells you what to pick up next. It understands the meaning of your recent work (run spl embed --loop to enable that), and falls back to a priority-and-recency ranking when the backlog hasn't been embedded yet.
  • spl task triage finds stale open tasks that newer or completed work has likely superseded, pairs each one with its probable replacement, and hands you a reviewable close-list. It never closes anything itself; you decide.
  • spl insights surfaces observations the system noticed on its own: shifts in an actor's recent review outcomes (trust drift) and open work that's been lingering. Run it alongside spl status to catch problems before you go looking.

See Task suggestions & triage and Insights & observability.


Mechanism-independent intelligence: Faculties and the marketplace

Intelligence in Syncropel is no longer assumed to mean "call a language model." A Faculty is a deployable unit of intelligence addressed by what it does, not what it's made of: an LLM, a deterministic solver, a classifier, an external service, or a script can all serve the same capability. Deploy and manage them with spl faculty deploy / list / show / retire.

When several Faculties can do the same kind of work, the calibrated marketplace routes the work to whichever has earned the most trust at it, measured purely on independently-judged outcomes, blind to mechanism. A non-LLM solver competes on equal footing with a language model, and a fresh candidate has to earn its standing before it can displace a proven one. This was proven end to end: an exact solver and a deliberately-weak heuristic competed for the same capability, their trust diverged on real verdicts, and the system routed new work to the one that actually produced the right answers.

See Faculties and The calibrated marketplace.


Intelligence out of the box

Fresh instances now come with a working intelligence path configured automatically: there's no manual provider setup before the conversational agent and work loops can run. The instance is recognized as a metered, audited participant against the shared gateway, governed by its own permission model.


A friction-free local start

Getting a local instance running is three short verbs, with no credential to manage:

spl init    # generate your identity + config
spl serve   # start the instance in the background
spl task add "Try out Syncropel"   # works immediately, no token needed

The local CLI talks to the instance over a private socket on your machine; filesystem permissions are the authentication, so there's nothing to paste. Bearer tokens are still the right tool when you want to delegate scoped access (pairing a browser, a phone, an MCP client, or a remote CLI), but they're no longer in the way of just trying things locally.

See First run.


What's next

On this page