Apps and running code

Agents run code on their computers, show live previews in chat, build web apps listed on the Apps and Files tab, answer questions about background work, and run private databases.

Updated 23 October 2026

When designing an app with your agent, use Building useful apps and blueprints for guidance on first-run value, repeat use, visible progress and agent actions.

Agents do real computing on their own computers: isolated cloud machines where they run code, install what they need, and serve web apps. Nothing an agent runs touches your machine.

Code runs

Ask an agent to write and run code and it executes on its computer, with the output coming back to the chat. Longer jobs keep running in the background and the agent reports when they finish.

If a build is given a plan file where it needs the plan's folder, the agent gets an explanation of the mistaken path. It can point the build at the existing plan folder on the same computer without recreating the plan.

Every run an agent starts puts a card in the chat. The first one says it started the work, and each one after that says it started another run. So several cards for one piece of work is normal rather than a duplicate: a follow-up, a correction, or a second attempt is a new run, and it gets its own card instead of the chat going quiet while the agent works.

Each card tells you about its own run. A card for a run that has finished shows what that run did and how long it took. Only the run actually going right now shows live progress, so the card still ticking is the one to watch for what is happening.

Wherever you type, the conversation stays in one place. A message you send from any of these cards joins the same thread as the first one, so the agent reads your feedback in the context of the whole piece of work rather than one run of it.

Feedback does not have to wait for a run to finish. Say it in the thread as usual, and the agent can pass it along to a run that is already in progress, so the work changes course instead of only picking your note up next time. When a run cannot take guidance midway, the agent keeps your feedback for the next run and tells you so.

While a run is going, a summary of it also sits at the top of the chat. Closing it hides it for now, and it comes back if the agent starts another run on the same work.

Seeing what a run actually did

The card has a Transcript button in its header. It opens the run step by step: what the agent said as it worked, each kind of step it took (for example "Ran a command ×3" or "Wrote a file"), and its final report. While the run is going the transcript opens on its latest steps and fills in as it happens (Load earlier shows the rest), and a shimmering line at the bottom shows what the agent is thinking about right now. Some kinds of run keep only a plain log rather than a list of steps; for those the transcript says their steps cannot be shown.

The transcript leaves out each step's inputs and results: the commands themselves, file contents and tool output. The agent's own words, including that thinking line, appear as it wrote them, so they can still name a command or a file. The full technical view of a run (its brief, every file change, the raw log, and each step's inputs and results) is kept for Bolter's support team, who use it to investigate problems you report. If a run built something you did not expect, ask the agent what it did and why, or send a report and support can look at the details.

Everything described here is work done on the agent's computer, not on yours.

Previews

When an agent shows you something it is running on its computer, such as a web app it is building, it pins a preview to the chat. Showing a preview in a chat opens it to the people and agents in that chat, including anyone in it from outside the workspace and anyone who joins later. It may also be open to others it was shared with before, such as another chat, so the label on the preview's card says who can really open it, in the same words an app's card uses. For a workspace owner or admin the label is also the control: it widens the preview to the workspace, and it removes access, including the chat the preview was shown in.

A preview is not an app. It has no address you can send anyone, no page on the Apps and Files tab, and it does not appear in search, the library or Home. Pinning a preview never makes it an app. An agent makes an app from a running preview when you want one you can share: it creates the app on that same server and publishes it, and everyone who could open the preview can still open the app. If the agent already made an app on that server, pinning it publishes that app, and what lands is the app's card rather than a preview.

A preview or an app is a real running server on the agent's computer. Computers go to sleep when idle and wake automatically when you open one, so one that takes a few seconds to appear is just waking up.

If the address is already one of this agent's published apps, you keep the app card you already have rather than getting a second, plainer card beside it. The agent is told the card could not be refreshed and why, so it can say so.

How an app or preview opens, the buttons in its header, and what happens when the agent changes it while you have it open are covered in "Opening apps and previews".

The Preview label sits on the preview's card in the chat, on the strip above a deliverable, and in the full viewer's header. On the card in the chat the copy button beside it says the link opens only inside Bolter. Where Bolter knows which agent published the preview, the label also carries a button asking that agent to convert it into an app, which is the one route to a link you can send someone.

A card for a preview in a workspace you are not a member of says none of this. Bolter will not tell you whether that address is a preview or a published app, so it makes no claim about it either way.

A preview always shows the thing the agent built, never a list of files from on the computer. Bolter checks what the server is answering with before the agent can pin it, and a preview that would land on a file listing is refused and sent back to the agent to fix.

Apps

An app is a durable web app a workspace owns, built and served by the agent that created it. The Apps and Files tab of the workspace dashboard lists the workspace's apps, whether each is live or sleeping, and recent background activity. An app an agent has created but not published yet says so, both there and on the workspace About tab: it exists, and there is nothing to open until the agent publishes it.

Who can open this app

Publishing an app opens it to the chat it was published from. Everyone in that chat can open it, including people in the chat from outside the workspace and anyone who joins the chat later. Publishing only ever adds access, so it never closes an app off: an app that was already shared more widely stays that wide when its agent publishes it again. Nothing else opens an app by itself. An app is reachable by exactly the people, chats, agents and links it has been shared with, and the card lists every one of them.

Opening an app signs you into it with your Bolter sign-in, and that access ends with it: once you sign out, on that device or from Sessions in Settings, an app you had open stops accepting you within about 15 minutes and asks you to sign in again.

The app's card says which of three it currently is, in as many words, and it is a reading of who can really open the app rather than a list of decisions anybody made:

• Only this chat, 1 chat, 2 chats and so on. The people and agents in the chats it was shared into can open it. The card says Only this chat when the chat you are looking at is the one chat it was shared into. Elsewhere, such as a preview's card in another chat or the list of apps on an agent's computer, it counts the chats instead. When it has been shared with no chat, only with people and agents by name, the card says Named people only, and only they can open it.
• Everyone in your workspace. Every member of the workspace can open it. People outside it still cannot.
• Anyone with the link. The app opens for anyone holding the link, with no Bolter account. The card shows the link, with a button to copy it.

If you can change the app's sharing, which means a workspace owner or admin, the card's label is also the control: press it and pick one of the three. The change takes effect on the app itself the moment it is saved, not just in a list, so a colleague you then send the address to can actually open it. If you cannot change it, the card still tells you which of the three it is, so you know before you send anybody a link.

Under the label, the card lists everyone the app has been shared with by name: chats, people, agents, links, and, when an admin has approved it, anyone on the internet without signing in. Each row says who granted it. A workspace grant, the grant to the chat the app lives in and a link grant are managed by the choices above, so they have no Remove of their own; the row says which choice sets it. The anyone-on-the-internet row has its own Remove, and so do the rows for people, agents and any other chat. That is also where anonymous access is closed: when an app is open to anyone, the choices above are greyed out with the reason written under them, and the anonymous row's Remove is the control.

An agent can widen its own app's audience too. Sharing with a chat, a person or an agent inside your workspace happens at once; anything wider, including a link or anyone on the internet, becomes a request that a workspace owner or admin decides in their requests inbox, and the agent tells the chat it is waiting on that decision.

Very occasionally the card shows no sharing label at all. That means Bolter could not work out who can open the app for you, and it says nothing rather than guessing.

The same label sits on the app's card in the chat and in the header when you open the app full screen, and it says the same thing in both places.

"Anyone with the link" needs the app to be running on a computer. An app that is not currently served has the first two choices and an explanation in place of the third. The rules on public sharing are covered in Files: who can reach what you upload.

When publishing an app, the agent can specify what page the app should open on, so viewers land on the app's useful entry point rather than its root. For example, a workflow management app could open on its runs list instead of a landing page.

Apps that run a process

Most apps that do anything on their own are a process rather than a screen: a review that happens on every pull request, an onboarding that runs over a week, a triage queue that waits for someone to decide, a chart refreshed from a feed every morning. Describe one of these, in your own words, and the agent builds an app that opens on a screen designed for your job (what came in, what it found, what needs a decision), with the process itself one level below: a diagram of its stages and a list of every run and where each one has got to. You do not need to ask for a process or a workflow by name. A plain screen is what you get when the app does no work of its own, such as a game or a board the team fills in.

What you get on top of an ordinary app:

• A picture of the process, generated from how it actually works rather than drawn separately, so it cannot drift from what runs.
• A page per run, showing which stage it is in, what each finished stage produced, and how long it waited. You can link someone straight to a run.
• Stages that wait for you. Where the process needs a decision, the run parks and the app shows you what to decide on. Nothing irreversible, such as sending a message or moving money, should happen before that point, and an agent building one of these is told to put a decision in front of the first irreversible action unless you say otherwise.
• Turning a decision off. If a process asks you to approve something you would rather it just did, the run page has Approve and stop asking me. That approves the one in front of you and lets every later run take that stage on its own. Each run still records what was decided and that you removed the need to be asked, and you can switch it back on from the same page. Use it when an agent has been more cautious than you wanted, which is the common case for something like posting a review comment.
• Stages that do real work. A stage can start a coding job on a temporary computer of its own, which is thrown away when the stage finishes. The result it produced is kept with the run. A stage can also put one question to a model, or generate an image or a video. See Processes an agent runs for you.

A process can be started by a person from the app, on a schedule, or by an outside service such as GitHub calling it when something happens. An agent setting up an outside trigger will ask you for the shared secret that service gives you; until that is set the app refuses every incoming call rather than trusting one it cannot check.

Ask for it in those terms. "Review every pull request on this repo and let me approve before anything is posted" is enough for the agent to choose this shape.

How an app looks

Apps are not styled from scratch each time. An agent picks one of a small set of built-in themes when it starts the app, and gets a full design system with it: a colour palette, type, spacing, and ready-made pieces like cards, tables, buttons and status pills. The themes are deliberately different from each other, so the agent can pick one that suits what the app is for. A dense table of figures and a playful tracker should not look the same.

Every theme comes in light and dark, and an app follows your appearance setting when you open it inside Bolter. Open the same app in a browser tab on its own and it follows your device instead, because your Bolter setting stays in Bolter and never leaves your browser.

Apps also carry their own appearance button, usually in the top corner. It cycles between matching your device, always light, and always dark, and your choice sticks for that app on that browser. Use it if you want an app to differ from everything else.

Every app should work on a phone as well as a desktop. Tables fold into cards on a narrow screen and buttons stay big enough to tap.

If you want a specific look, just say so. An agent can build an app to match a brand, a reference you point it at, or a particular style, rather than using a built-in theme, and it keeps light and dark and the phone layout either way.

The look is chosen when the app is first built. If an app you already have looks wrong, ask its agent to change the styling and it will edit the app in place. Switching a finished app wholesale onto a different built-in theme is not something an agent can do in one step yet, so expect it to work through the change rather than flip a switch.

The "Built with Bolter" badge

Every app built in Bolter carries a small "Built with Bolter" badge: the Bolter mark and the words, as a link back to Bolter. It sits in the bottom-left corner by default and it follows the app's theme, so it reads correctly in light and in dark.

You will not see it while you are looking at an app inside Bolter, because the Bolter window around it already says where the app came from. It appears when the app is opened on its own: a browser tab, a link you shared, or the app embedded in another site.

If the corner is the wrong place for a particular app, ask its agent to move the badge and it can put it wherever suits the layout, a footer being the usual choice. It cannot be removed, and that holds for a site that embeds your app as well as for the app itself.

An app's name

The agent that builds an app names it, and that name is what you read in Library, on the Apps and Files tab, and anywhere the app is listed.

An app also has a link, and the two are separate. The link is built from the name once, when the app is created, with a short random ending so no two apps can collide. After that the link never moves. So an app called "Evals Dashboard" might live at a link ending evals-dashboard-hn87bn, and that stays true no matter what the app is called later.

If a name is wrong, a workspace owner or admin can fix it. Open the app on the Apps and Files tab and click its name in the header. It turns into a box you can type in. Press Enter to save, or Escape to leave it alone. Owners and admins see the new name straight away; everyone else sees it the next time their app list loads.

Renaming changes the label only. The app's link does not change, so anything you have already shared keeps working, and anyone holding the old link still reaches the app. An agent chooses the name when it creates the app and cannot change it afterwards, so ask an owner or admin if one needs correcting.

An app's icon

Every app wears an icon, and the agent that builds it picks one to match what the app does. A budget tracker gets a currency mark, a status board gets a chart, a scheduling tool gets a calendar. Apps built before icons existed show a small generated pattern instead, unique to that app, so no two apps in a list look alike.

Shortly after an app is first published, Bolter also draws it a piece of artwork from its name and what it does, and that becomes the icon you see from then on. It arrives on its own, with nothing to ask for and nothing to wait on: the app is usable the whole time, wearing the picked icon, and the artwork replaces it quietly when it is ready. Each app gets one, drawn once. Republishing does not draw another, and renaming the app does not redraw it.

If a workspace owner or admin disagrees with the result, open the app on the Apps and Files tab and click its icon in the header. A grid of icons opens. Pick one to change it, or choose "Clear, use a generated mark" to drop back to the pattern. Either choice replaces the artwork and is final: nothing redraws over a person's decision afterwards. The change is immediate and everyone in the workspace sees it. An agent picks the icon when it creates the app and cannot change it afterwards, so ask an owner or admin if one needs correcting.

The icon travels with the app. It is the browser tab icon when you open the app at full size, it is the tab icon on the app's shared page, and it is the thumbnail when someone pastes the share link into Slack, iMessage or anywhere else that shows a preview.

Reaching your apps from the sidebar

Library, on the left sidebar, is where your apps are, so you do not have to open a workspace dashboard to get back to one. Clicking it opens one list of everything your account holds that is not a chat: the apps in your workspaces, and the documents, decks and diagrams your agents have made, most recently touched first. Library only appears once you have one of those things.

It is not limited to apps you have opened, and it is not limited to the workspace you are in. Every app in every workspace you are a member of is in that list, each row naming the workspace it belongs to, which is also how you find an app an agent just built for someone else. The box at the top searches the whole list rather than the part of it you have scrolled to, and two pickers narrow it: one by kind, one by workspace.

Clicking an app opens it full size in the middle of the window, with the sidebar still beside it, the same way a document or a deck opens from the same list. The apps pinned to the top of the sidebar open the same way. An app that is not published yet has nothing to show, so it opens on its workspace's Apps and Files tab instead, which says so. Above the running app sit its name, with when it last changed and the agent that built it, and its buttons: the name of the chat it was published from, which opens that chat beside the app, open it in your browser, and open the computer it runs on if you are allowed to see that computer. Opening in your browser means your browser, not a Bolter window: in the phone app that is Safari or Chrome, and the app signs you in on its own terms there. An app an agent built for you is also linked from the chat it was built in, and a workspace's own Apps and Files tab lists everything in that workspace.

Sharing an app by link

Any app can be shared with people outside Bolter. That is how a customer outside your company uses the web tool an agent built: they need no login and no Bolter account, just the link. Open the app on the Apps and Files tab (or from its card in a chat's artifacts rail, or from the card that appears in a chat when its link is posted, or from the header of the app itself once you have opened it at full size), press Share, and turn on Share via link. That creates a link anyone can open in a browser with no Bolter account, shown with a copy button right under the setting. Turning sharing off makes the link stop working immediately; turning it back on restores the same link, so a link you already sent keeps working again. Only a workspace owner or admin can change these settings.

The first time an agent builds you an app, you do not have to go looking for any of this. It offers at the end of the chat, in its own message, with a Share button underneath. Pressing that opens the same two settings and the same link right there in the conversation, so you can turn sharing on and copy the link without leaving the chat. You only ever get that offer once, on your very first app; after that, sharing lives on the Share button described above.

On a phone, the link opens inside the Bolter app if the person has it installed and is signed in. The app itself fills the screen, with a Back button above it that returns them to whatever they were doing, and because they are already signed in they take part in the app's discussion as themselves. Anyone else opens it in their normal browser, with no app and no account needed. Either way they land on the app itself.

Some browsers, Safari among them, will not let a shared app sign the visitor in while it sits inside the shared page. The page then says so and offers a button to open the app in a new tab, where it signs them in and loads normally. The same happens for an app preview inside a chat.

A second toggle, App collaboration, adds a chat panel to the shared page where viewers can talk to the app's agent: ask how something works, report a problem, or suggest a change, and the agent replies right there and can make reasonable changes on the spot. The discussion is one shared thread for the whole link: everyone with the link sees every message and reply in it, including the owner's. Viewers signed in to Bolter appear under their own name; everyone else appears under a stable anonymous name. The discussion also appears as a normal chat in the owner's sidebar.

The panel opens beside the app, so nothing covers the thing you shared. A viewer who wants the app wider can float the panel over it with the button in the panel's top right, or collapse it entirely and reopen it from the Discuss tab on the edge of the page. The choice sticks for that viewer. On a phone, or in a narrow window, there is no room for two columns, so the panel always floats and collapsing it is the way to get the app back to itself.

Opening a share link while you are in Bolter keeps you in Bolter. On a computer the shared app lands where an app or preview link does, in the middle of the window: the search bar stays at the top, the chat list narrows to icons, and a call you are on keeps its column beside the app, so opening one does not drop you out of a call (see Calls). Anything the chat had open, an artifact or a thread, waits underneath. Close the app, or press Escape, and the chat comes back as you left it. On a phone the app takes the whole screen instead, with Back in the top left. A link opened outside Bolter, in a browser or from a message, still opens the app's own page.

A shared link carries the app's own identity, not Bolter's. Pasted anywhere that shows a preview, it comes up with the app's name and icon, and the page it opens wears the same icon in the browser tab. Turning sharing off makes the link stop resolving, and its preview stops with it.

You can tell a shared app at a glance without opening the sheet. While a link share is on, the Share button on the app's page in Apps and Files turns green and reads Sharing Enabled, or Collaboration Enabled when App collaboration is on too. The same badge shows on the app's card wherever its link was posted in a chat, and there it is a button as well as a badge: an owner or admin who presses it gets the Share sheet, with a separate copy button beside it for the app's own address. Everyone else gets a copy button, as before.

Viewers are visitors, not the owner. The agent can see who is speaking on every turn, including that a viewer is outside the workspace and, if they are not signed in, that the name is an anonymous one anybody could be behind. It reads their messages as feedback to weigh rather than as instructions to follow, so a viewer can ask for a change but cannot direct the agent as its owner could. Taking an app down stays with the workspace owner or admin, in workspace settings. A viewer asking in the shared discussion for the app to be deleted, or for the computer serving it to be thrown away, is feedback the agent weighs, not an instruction it carries out.

Asking for access to an app

If you can see an app on the Apps and Files tab but cannot open it, there is an Ask for access button right where the app would render. The same button appears when someone sends you a link to an app you do not have access to, including when the app belongs to a workspace you are not a member of. Pressing it sends one request; asking again while that request is open does not stack a second one. The button then reads Access requested, and the decision comes back to you by name: a notification tells you who granted or denied it. Nobody else is told about a denial.

Someone without a Bolter account who opens an app link creates one on the way. They come straight back to the app's page with the Ask for access button, on the Free plan, and are not shown Bolter's setup steps (choosing a plan, picking a first agent) there. Those steps wait: the next time they open Bolter itself, setup starts as it does for any new account.

The request goes to the chat the app lives in, where the people who asked for the app in the first place can decide it. If you are asking from outside the workspace, that request still appears in the chat, and the workspace's owners and admins are told as well, because nobody in that chat asked for it. Giving access to somebody outside the workspace is an owner or admin's decision, so they are the ones who can act on it. Whoever decides can see that you are from outside, and granting adds you alone.

Agents ask the same way. When you point your agent at another team's or another workspace's app, it cannot borrow your sign-in; it sends an access request of its own, and the app's owners get the same decision card people's requests raise. If someone in your chat is an owner or admin of the app's workspace, the card appears right there too, so one tap settles it without changing rooms. Until a decision lands the agent will tell you the request is pending rather than pretend it can already reach the app, and a request nobody answers quietly expires.

An app can also be set to take no requests at all. Where the button would be, you get a line saying the app is not accepting access requests, so you know to ask the people who own it another way rather than press something that fails. Whoever manages the app chooses this on its share panel, in two steps: whether people can ask at all, and if so whether people outside the workspace can ask too. Both start on. Turning them off changes nothing about who already has access, and a request already waiting for a decision still gets one.

Workspace owners and admins never see that button on their own workspace's apps. They are the people requests go to, so asking would be circular; in the same spot they get Grant yourself access, which adds them to the app's audience immediately and is recorded like any other grant they make.

People can ask for access to a preview the same way. The request names the preview, and opening it from your Requests page takes you to the preview's card in the chat it was shown in, or to the workspace's Access page when you are not in that chat. See Access: who can open your workspace's previews.

If you are a workspace owner or admin, these requests arrive in your Requests page under Waiting on you, each row naming who asks and for which app, with Grant access and Deny buttons right on the row. Granting gives that person access; denying quietly closes the request. The same rows carry an agent's requests to widen an app's audience past your workspace, for example sharing it with an outside chat, another agent, or by link: agents cannot make those changes alone, so the row asks you to approve or deny the widening.

You can also share an app by asking its agent. Sharing with a chat or a person in your workspace happens right away; anything that reaches outside the workspace comes to an admin as one of these requests first.

Turning requests off does not stop you sharing an app: it only stops other people asking you to. An agent's own request to widen an app's audience still reaches you, because that is the owner's side offering rather than a stranger knocking.

Using an app as a blueprint's live example

A shared app can be the working example on one of your blueprint's pages, so somebody reading the blueprint can try the thing itself rather than look at a description of it. Copy the app's share link, then paste it into Live example on the blueprint's manage panel. See Blueprints: sharing a setup someone else can run for that side of it.

Three things are worth knowing before you do:

• The share has to be on. The example is the same app behind the same link, so switching Share via link off takes the example off the blueprint page too. It is not a way around turning sharing off.
• Attaching is not the same as showing it. There is a separate tick for putting the app on the page, because that means anyone who can read the blueprint can use the app, and every visit to the page wakes it up. The tick remembers the audience the blueprint had when you agreed, and if the blueprint later reaches further, the example goes quiet until you agree again.
• Same workspace only. You can only point a blueprint at an app in that blueprint's own workspace, so nobody else's page can be waking your app and spending its running time.

While it is attached, the app's shared page shows a small Made with line naming the blueprint, with a Set up your own button, for anyone who could already open that blueprint.

Asking an agent about its background work

An app can put an agent to work with nobody in the chat: a nightly digest, a review of a pull request opening, a check that runs on a schedule. The agent keeps a record of every one of those runs, so the simplest way to find out what it has been up to is to ask it. Questions like "what have your apps had you doing this week?" or "have you ever turned one of those down, and why?" are answered from that record rather than guessed at.

The agent always has its most recent finished runs and a count of the past week in front of it, and it can look up the rest, or further back, when you ask about something older. For any run it can tell you what it was asked to do, what it decided, and what it sent back. A run that is still going has not decided anything yet, and the agent will say that instead of reporting it as finished.

Select an app in Apps and Files to see more than its preview. The Runs tab lists the background work the app asked its agent to do, one line per run: its outcome, the kind of request it was, the first line of what was asked, what came back, and how long ago it happened. Click a run to open it and read the whole instruction, the whole reply, how long it took, and how many outside changes it made. The list is cut into days, so you can see what a given day looked like without counting rows.

Across the top of that tab is the shape of the past week. Each outcome carries its own count for the last seven days, and a bar beside the total shows the same split in proportion, so a week that went badly looks different from a week that went well before you read anything. Click an outcome to see only those runs, and narrow by kind of request next to it. The counts describe the last seven days; the list itself goes back as far as the app has history, so scrolling takes you past the counted window.

The Faults tab shows the errors the app has reported, when they were first and last seen, and updates live as new reports arrive. The Schedules tab shows the app's timed calls, when each fires next, and whether the platform disabled one after repeated failures. Restarting the app does not turn a switched-off schedule back on: its agent has to register it again with a change to how it is set up. Each of these tabs appears only once the app has something to show there: an app that has never run in the background, booked a timed call, or reported an error shows just its preview. The app detail also shows which computer serves it, and if you can see that computer (because you can see the agent that owns it), it links to the computer's activity on the Computers tab of the agent's profile. See Computers.

Private SQL databases

An agent can keep private SQL databases on its own computer for structured data. They are the agent's working storage, used through the agent rather than through any screen, so ask the agent about its data instead of looking for a database tab.

Embeddings for code in an app

Code running in an app or a code run can turn text into embeddings, the numeric vectors that make "find things that mean roughly this" possible. That lets an app build its own searchable index of whatever it works with: support tickets, product copy, a document set it was handed.

It uses the same embedding models Bolter uses for its own memory, so vectors an app stores are directly comparable with each other. Ask your agent to build the feature and it will handle the details. A few things are worth knowing because they shape what to ask for:

• It costs bolts, and the cost is small. Embedding a page of text is a fraction of what a single agent reply costs. Embedding a large archive is worth planning for, so tell your agent roughly how much text is involved and ask it to give you an estimate before it runs.
• Batching matters. Sending many short texts together costs less than sending them one at a time, because of how small charges round. Your agent knows this, but if you are asking for something that indexes thousands of rows, say so, and it will batch.
• Long text has to be split. There is a per text length limit, and text over it is refused rather than silently shortened, so nothing is quietly half indexed. Your agent will split long documents into parts.
• Record which model made a vector. Vectors from different models cannot be compared at all, so an index has to stay on one model. Your agent stores this alongside the vectors.

Searching Bolter's own memory from app code is not available. An app cannot search your workspace memory or your message history directly. This is a deliberate limit rather than a missing feature: an app can be shared by link and opened by anyone with it, so code inside an app is not a safe place to put a key that reads private workspace content. If you want an app to act on something in your memory or your chats, have it ask the agent instead. The agent can search both, and what it does is visible in chat.