Work mode
Work gives a model project context and a small set of scoped tools. The model can read, search and edit only what the project allows, and every permission is explicit.
What Work is
- A project folder with its own system prompt, memory, skills and runs.
- Context locations with read, write and delete permissions.
- A web permission that is off until you enable it.
- A send gate: if the tool probe fails, the project cannot quietly run tools.
- Works with a local model or OpenRouter; Compute-host tool calling is not supported yet.
Create a project
- Work → New project. Give it a name and a folder. The folder is the project's boundary.
- Write the system prompt. Say what the project is for, what the model may change and what it must not touch.
- Pick a provider. A local model is best for private files and reliable tool calls; OpenRouter works when the local model is too small.
- Add context. Point at the folders and files the project actually needs. Start read-only.
- Enable write/delete only after a read run. The permission is per location, not global.
Context and permissions
| Permission | What it allows |
|---|---|
| Read | List, search and open files under the context location. |
| Write | Create and edit files under that location. |
| Delete | Remove files under that location. Keep this off unless the task needs it. |
| Web | Fetch pages for the project. Off by default. |
Paths outside the declared context are not reachable through the project tools. The project folder itself is not a substitute for an explicit context location.
Skills
Skills are reusable instructions with a name, description and body. They can be global or overridden per project. Use them for repeatable procedures: review a dataset, prepare a model card, run a release checklist.
- The skill list shows the effective source (global or project).
- A skill can be previewed before it is used.
- Skills do not grant permissions; the project's context locations still decide what tools can touch.
The work loop
- Ask for the outcome, not the exact keystrokes. Mention constraints and files.
- The model proposes tool calls; Studio shows them and applies the permission gate.
- Review file changes in the session before accepting destructive work.
- Keep the useful decisions in the project memory so the next session starts informed.
- Use runs and the project's models folder for artifacts you want to keep.
Local or OpenRouter
| Local model | OpenRouter | |
|---|---|---|
| Privacy | Files stay on this PC | Prompt and tool results go to the provider |
| Tool reliability | Depends on the model; smaller models are weaker | Stronger models available, still model-dependent |
| Cost | Free | Per token |
| Setup | Download a model and pick it | API key and a model |
A SharpMind Compute host is currently inference-only for Chat. It does not expose Work's tool calling, so Work should use a local model or OpenRouter.
Safety
- Start with read-only context. Add write after the model has shown it understands the project.
- Leave delete off for source trees, model folders and anything under version control.
- Keep secrets out of context locations; the model can read every file it is given.
- The send gate exists to stop a broken tool probe from becoming a silent failure. Fix the probe rather than bypassing it.
- Review remote-model prompts: OpenRouter sees the conversation and any tool output you send.
Problems
| Symptom | Fix |
|---|---|
| Send is disabled | The tool probe failed. Fix the provider or model, then retry; the gate is intentional. |
| Tool says permission denied | The path is outside the declared context, or the location lacks that permission. |
| Model ignores tools | Use a tool-capable model, lower the recovery strictness, or restate the task. |
| File change missing | Check the context path and whether the model wrote to a different project folder. |
| Remote model is slow or refuses | Switch to a local model for private or tool-heavy work; OpenRouter models vary in tool support. |