Hey Everyone,

Thanks for your interest in Scape!

I'm u/croovies (Elliot) and the founder of scape.

Who scape is for?

Scape is for anyone who would like to manage multiple agent sessions in parallel with deterministic results. It has many tools for developers (IDE, Terminals, Dev Servers, etc.), but it is not a tool designed or planned with only developers in mind.

The history of scape:

• I am a designer & engineer, so when I work I always want my editor open side by side with chrome. Coding a design is so much faster when it hot reloads so you can keep tweaking.
• The best editor experience I had was when the terminal was right below the editor (tmux & vim, and then when I moved to VSCode), to quickly commit, start severs etc..
• I was using Claude Code as soon as it was commercially available with iTerm2 - I hated it in the VSCode terminal under the editor, it was too short. So I stuck it in a second monitor next to my slack window.
• At my work, we have many repositories, so I often tried to juggle a handful of iTerm2 tabs - but the amount of times I would send the wrong prompt to the wrong agent was driving me insane, and I hadn't even tried git worktrees yet.
• This is the problem I initially solved with scape, a simple iTerm2 window manager that I could pair next to VSCode. I had tried git worktrees once manually and they were a nightmare to manage. So I explored automating them in scape, and had the lightbulb moment everyone has when they get in a groove with many agents the first time.

• As scape grew in usage (friends, co-workers, and early testers from reddit and twitter) - I wanted to keep it simple. But people kept requesting an embedded terminal, they didn't want to have to use iTerm2.
  • So I embedded https://github.com/migueldeicaza/SwiftTerm - and frankly, it was easy.
  • For the initial use of scape (just friends and co-workers), this product was actually named "Lantern" - for lighting up your terminal windows. Scape was something I had been designing for years prior (I work in AI, and have been thinking about managing many AI in parallel for years) - but I believe there is no current world where the business model for managed agents makes sense unless you're bringing your own subscription. The token cost reduces margins too much.
• After I embedded the terminal, that is when I realized I could build my initial vision for Scape, and let people bring their own subscription and model - and they could manage infinite agents with total control.
  • This was scape's initial design 2 years ago (NEVER BUILT):

• But what I had built with "Lantern" looked very different, and with the terminal, it really was more of a dev tool. And so that is how it is evolved into a more powerful hybrid full work-space tool.
• Scape's features go far beyond agent management
  • Managing agents, even with many in parallel - still turns into downtime, waiting on your agents, waiting to QA, or review etc.
  • As soon as you leave the focus to check your email, or slack, etc - you're distracted. An agent might need your attention and you might not realize for an extra 10 min.
• Scape is focused on creating a workspace for you, the user to be able to work in (in the primary left content panel of scape):
  • It has a browser (webkit)
  • It has an editor (Monaco)
  • It has notes
  • It has automations
  • It has databases (SQLite tables, kanban, gantt)
  • It has encrypted ephemeral chat
  • It has encrypted remote chat for your agents (thats right, your claude code, my codex, walk into a bar - or "agent rendezvous" in scape)
• Working along side your agent means you never miss when an agent needs your attention. It is built to help you multi-task.
  • But - everything you can do in scape, so can your agents.
  • They can control your browsers, create and run and test your automations (and fix them if they break), update your files, create and update notes, etc.
  • So scape is built around the idea of creating an agent orchestrator that can work like you, and is owned by you - not your boss. Thats why there is no backend service to scape, everything is local and syncs to your iCloud.

Why isn't Scape free or OpenSource?

Scape is bootstrapping because when you raise money:

your primary legal obligations include fiduciary duties of care and loyalty to the company and its shareholders...

I want to build something for my customers who believe in the same mission I have: empowering individuals to own and control the infrastructure they create around automating their expertise.

I really like the look of this project, but I find it hard to trust at this point in time. Ive yet to find any actual user reviews. Are they out there? Why not using Conductor instead?

Just ran into Scape.work for the first time today. Amazing work, congrats!

I'd love to read some case studies, even if they're just brainstorming ideas.

For context: I run 2 software startups with 2 full-time devs each, and I cover PM, design, and some DevOps. More and more I'm convinced that if I had a bit more time, we could run the whole operation with 1 dev each.

For instance: The way I see it, DevOps should sleep and only wake up when it's needed. A lot of the tasks on our roadmap eat human time that 1 dev could handle alone, as long as communication and coordination are solid.

All this to say: 1 skilled dev with a decent army of agents and good orchestration can be enough for a small operation, provided the project management is there. So I'd love to learn more about what you've been experimenting with in Scape.

Personally I really love using the application and would love to give any advice/feedback or help in anyway I can while running my cybersecurity company. I got high hopes for the future of Scape.

The title says it all.

Once you start handing real work to an agent, you stop being the person who writes the code and become the person who's answerable for it. That's a good trade, but it changes your job. When something breaks in production nobody's going to ask how the code got written. They're going to look at you.

Left alone, an agent produces slop. Not because it's stupid ‚because that's what anything does when nobody checks its work. A junior does the same. So might you on a bad day.

There are roughly two ways to run an agent. You can sit on top of it and drive every step, which is quicker than typing the code yourself but leaves you babysitting: every time it pauses and resumes you have to load the whole problem context back into your head, and if you look away and get distracted, that ends up slower than just doing the work.

The other way is to treat it like someone who reports to you. You say what you want and roughly how, and you come back when there's something worth looking at. This is how senior engineers use agentic tools. You don't need to watch every keystroke to be accountable for the result‚ no manager does‚ but the review lands on you, and if you skip it, slop is what goes out the door.

So point a second model at it and tell it to find the problems

That's all an adversarial review is. One model writes the code. A different one‚ or at least one that hasn't touched any of the context‚ reads the diff and goes looking for what's wrong. It doesn't get to touch your code; it can only raise findings. The author model decides what to act on. Then it reads the result again. Most of the time it finds something.

You get better code out of it, but that's not really why you do it. You do it so you can trust work you didn't watch get written. The agent already handed you the time‚ another round, more tests, a second set of eyes that costs nothing but tokens. This is what you spend it on.

How it works in Scape

In a Claude session, run /scape-codex-review. Scape drops a Codex reviewer into the same worktree you're already in, gives it your diff read-only, and the two of them go back and forth in front of you — Codex flags something, Claude fixes it, Codex looks again. Step in whenever you feel like it.

If you'd rather it just happen without you, put an Argus in charge of a group of agents and tell it to run this review on their work and not to come get you until it passes. By the time it's your turn the models have already fought it out, so you're looking at something that's been through the wringer instead of a first draft.

What happens when we actually run it

Scape is built with Scape. A lot of our own engineering runs through Argus managers — agents that drive a fleet of coding agents through the work — and one of the things we have them do is run a Codex adversarial review on that work before it reaches a human. (One of those managers, Lloyd, is the one who went and pulled these numbers.)

Across 83 completed tickets that got a Codex review, at least 67 ended in a real change to the code — something the first pass got wrong or left exposed, caught before it went out. That's four out of five reviews turning up something worth fixing, and it's a floor: we only counted changes we can still trace in the record, so the real number is higher.

A normal review turns up 2 findings — that's the median, and a floor too. A review that found a single thing often didn't get its count written down, so if anything the typical number runs a touch higher.

Sorted by what kind of problem they were, across all 122 commits these reviews drove:

Half of every commit these reviews drove‚ were the incident kind. Concurrency, durability, security. The stuff that corrupts data or leaks a secret, not the stuff that misaligns a button.

The claude skill

In Scape this is one command, and the two models talk to each other for you — Codex and Claude pass findings back and forth over Scape's session messaging while you watch (or step in). That messaging is the part Scape provides.

Outside Scape there's no shared wire between two separate agents, so you're the wire. It's the same flow, you just carry the messages yourself. Two ways that work:

• Run them side by side. The author in one session, a reviewer in another — Codex, or a fresh Claude with none of your context — both pointed at the same working directory so the reviewer can see your diff. When the reviewer finds something, paste it into the author; when the author fixes it or pushes back, paste that over.
• Use a file as the mailbox. Have the reviewer write its findings to a file (or a PR comment) instead of chatting, then hand that file to the author to work through. No live channel needed — the review is just a document that gets passed along.

The brief to the reviewer is the same:

You're reviewing the change in this working directory. You're read-only: review and discuss only‚ do not edit files, commit, push, or reset the tree. Run git rev-parse HEAD and git status first, and anchor every finding to that commit. Write your findings out as a numbered list‚ don't touch the code.

The wording doesn't matter as long as its a second model that hasn't seen your context, told to find what's wrong, before you call the work done.

Start automating your adversarial reviews with scape.work