Skip to main content
The same tools run in two places. The cloud is Eversince’s servers, reached through the hosted MCP server, the REST API and the CLI. The desktop is the Eversince app on the user’s Mac or Windows computer, which serves the same three interfaces on that machine. Where a call runs is decided by where it arrives, not by anything in the call. A call to the hosted interfaces runs on Eversince’s servers. A call through the app runs on the computer whenever the app can do the work there. Every tool has one schema and one set of rules in both places.

​
In the cloud

Work on Eversince’s servers runs the same from any host and needs nothing open on the user’s side. A slow operation returns a job and carries on after the call ends, whether the connection is still there or not; get_jobs or a webhook reports it. Generation and other model work is charged in AI credits; transcribing, reading, describing, rendering and converting are charged in cloud processing minutes, and a response that used minutes carries cloud_processing with what it used and what is left.

​
On the desktop

The app works on files where they are, and cloud processing work runs on the computer at no charge when the app can do it: reading files, transcribing, detecting beats, speakers and loudness, indexing a video, reframing, syncing recordings, drawing frames, and rendering at any length and resolution. Generation and model reads (a prompt on inspect_media, a shot log) run in the cloud wherever the call comes from. A tool’s description states the cloud fact; the desktop rule applies on top of it. A file on the disk enters the library with import_media in local mode and its absolute path. That is one call, nothing is uploaded, and the file is playable and editable at once. By default the app also syncs desktop files to the cloud while the owner’s storage has room, so members, phones and cloud agents can use them. The workspace setting sync_files_to_cloud turns that off, and a file then stays on the computer it came from. A cloud-only read (inspect_media with a prompt or in shot log mode) called through the app on a file the cloud does not hold returns what the upload and the work would cost and does nothing. The same call with upload_to_cloud: true uploads the file first and then runs. Any other cloud-only tool refuses and names the computer holding the file; the user syncs it from the app.

​
Three fields the desktop interface adds

Through the app, three fields appear on the tools that take them. They are not advertised on the hosted interfaces, where there is no computer to name, and a call that sends one there is refused with a sentence saying so.
  • run_on: "cloud" sends the call to the servers regardless, for work that should continue with the laptop closed.
  • run_on: "local" refuses rather than use cloud processing. The error is needs_cloud, and the work that needed the cloud did not run.
  • upload_to_cloud: true uploads a file that exists only on that computer before a cloud-only read runs on it.
The desktop’s own instructions, served with its tool list, carry these rules. An agent connected through the app and an agent connected to the hosted interfaces otherwise read the same tools, the same descriptions and the same costs.