blogProduct

Why GIDE Is the Best AI Code Editor for Enterprise Teams

AI coding is moving from seat plans to per-token bills. Here's why GIDE lets enterprise teams run most of that work on the Macs they already own, and keep frontier models for the hard parts.

10 min read

For two years, AI coding in most companies looked like any other SaaS line item: a fixed price per seat, renewed once a year, easy to forecast. That era is ending. Between late 2025 and mid 2026 the major AI vendors moved their enterprise contracts from flat seat fees to metered token billing. The seat now buys access. The work itself is billed per token, at API rates.

That one change turns a question most teams never had to ask into a budget question: which of those tokens actually need a frontier model?

The answer is “far fewer than you’d think,” and the hardware to handle the rest is already sitting on your developers’ desks. This post walks through why, using real numbers, and where GIDE fits.

Why GIDE, in short

  • Runs the volume on the Macs you already own, with unlimited local inference
  • Frontier models on your own key for the hard turns, one @ away, same conversation
  • The same gates, audit log and memory for every model, local or online
  • Enterprise controls: air-gapped deployment, SSO/SAML, compliance reporting

What an agent actually spends tokens on

A recent Kernel Brief video asked whether a gaming PC could replace a $200 a month AI coding plan. The most useful part of it wasn’t about graphics cards at all. It was a breakdown of where a coding agent’s tokens go, based on SemiAnalysis measurements of real agent workloads:

  • About 96.6% are re-reads. A model remembers nothing between requests, so every time the agent takes a step it resends the whole conversation: your files, its instructions, every earlier turn.
  • About 3% are fresh reads. A file it opens for the first time, a test result, a stack trace.
  • About 0.3% are writes. The code and text the model actually produces.

Using Anthropic’s published figures for what developers at companies typically spend, the video puts a normal active day at around $13 of usage at API prices, with nine in ten developers under $30. In that mix, $13 is roughly 32 million tokens: about 950,000 fresh tokens read and about 95,000 written. Everything else is the agent reading what it has already read.

On a metered bill, all of it is a line item. Multiply $13 to $30 per active day by a working month and you are looking at very roughly $270 to $630 per developer, before the seat fee, on a line that moves with how hard people worked. Some companies have already found the edge of that: one widely reported case had a large tech company use up its full-year AI budget in four months and then cap spend per employee per tool.

Under a seat plan, local was a hobby. Under API billing, it’s a strategy.

The video ends on a line we like: rent the brains, own the volume. A frontier model is far better at hard problems. On the newest version of Terminal Bench, a test of coding agents doing realistic work in a terminal, the frontier model it cites solved 59.6% of tasks and a strong open 27B model solved 5.6%. That is not a gap you engineer around.

But most of an agent’s tokens aren’t hard problems. They are re-reads, small edits, test loops and the long tail of “run it again and fix the import.” That is volume, and volume is what a local model is good at.

Under a flat plan, moving that volume to your own hardware saved you nothing at the margin. You’d already paid for the warehouse. Under per-token billing there is no warehouse. Every token you keep local is a token that isn’t on the invoice.

Why the Mac, not a GPU

The video tested gaming graphics cards because that’s what enthusiasts own. Enterprises don’t hand out RTX cards. They hand out MacBook Pros. Apple’s share of US business PCs has been climbing steadily, and CIO surveys this year point the same way, with AI capability now one of the reasons companies give for choosing Macs. Developers were already over-represented on Macs before that.

The video judged every card on three jobs. Here is how a current Mac does on each.

Job 1: fitting the model and its memory

Locally, re-reads are almost free. The inference engine keeps a cache of everything the model has already processed, and when the next request starts with the same text it reuses that cache instead of reading it again. The catch is that the cache has to fit in memory next to the model.

This is where the video’s graphics cards struggled. A 27B coding model at 4-bit is about 17.5 GB, and an agent’s conversation is long before you type anything: system instructions and tool descriptions alone run from several thousand to over 30,000 tokens. The 8 GB card couldn’t hold the model at all. The 12 GB card had less room for context than one popular agent’s instructions.

Apple Silicon uses unified memory: the GPU works out of the same pool as the rest of the system. So the “VRAM” on a MacBook Pro is 24 to 128 GB. A 48 GB or 64 GB Mac holds the 27B model with a long context and room to spare. A 128 GB M5 Max holds more model and more context than any consumer NVIDIA card. On the job that matters most by token count, the Mac on the desk wins.

Job 2: reading new material

Processing a fresh prompt is a compute job, and here the honest answer is that Macs are slower than a top desktop GPU. On the standard llama.cpp benchmark, an M5 Max processes prompts several times slower than an RTX 5090. On a 27B model, one engine measured an M5 Max reading a 7,000 token prompt at roughly 500 tokens a second.

That sounds worse than it is, because fresh reads are only about 3% of an agent’s tokens. At 500 tokens a second, a typical day’s 950,000 fresh tokens is around half an hour of machine time, spread across a working day.

Job 3: writing

Writing one token means reading every weight of the model out of memory, so the speed limit is memory bandwidth divided by model size. Apple publishes the bandwidth:

Chip Memory bandwidth Ceiling, 27B at 4-bit Ceiling, 9B at 4-bit
M5 153 GB/s ~9 tok/s ~29 tok/s
M5 Pro 307 GB/s ~17 tok/s ~59 tok/s
M5 Max (40-core GPU) 614 GB/s ~35 tok/s ~118 tok/s

Real machines land under their ceiling. Plain decoding of the 27B on an M5 Max has been measured around 18 to 20 tokens a second. With multi-token prediction switched on, where the model drafts several tokens and checks them in one pass, community measurements on the same chip reach roughly 55 to 70.

Put the day together on an M5 Max: about 95,000 tokens to write at 19 tokens a second is under an hour and a half; with multi-token prediction, under half an hour. Add the half hour of reading and a typical developer day’s volume is one to two hours of work for the laptop, during an eight hour day. A heavy day takes longer, and an M5 Pro takes roughly twice as long on the 27B, but both fit in the day.

Every MacBook that meets GIDE’s floor (Apple Silicon M2 or newer, 16 GB) runs a 9B-class model. The 27B tier wants a 36 GB or larger Pro or Max.

These figures are arithmetic from published per-machine measurements and the video’s workload mix, not GIDE benchmarks. Your numbers will depend on the model, context length and engine.

Hardware isn’t the hard part. The workflow is.

If the Mac can carry the volume, why isn’t every team already doing this? Because “a model on my laptop” and “a coding agent I’d let edit a production repo” are different things. Run a local model in a bare chat window and you’re back to copying code. Run two separate tools, one local and one frontier, and every switch loses the context, the conventions and the history.

That’s the gap GIDE is built for.

One editor, both kinds of model

GIDE runs local models on your Mac, frontier models on your own API key (Anthropic, OpenAI, Google), and models on a server you control, in the same editor. Local inference is unlimited on every plan. Keys stay in your system keychain and go only to the provider you choose; GIDE never proxies your prompts. When memory allows, two local models stay loaded, and you can @ mention any local or online model for a single message without changing your default. The model you address sees the whole conversation.

That makes “rent the brains, own the volume” a daily habit instead of a slide:

  1. Ask a frontier model on your key to plan the hard turn: the tricky refactor, the migration, the bug nobody understands.
  2. Approve the plan at the Plan Gate.
  3. Let the local model on your Mac carry out the edits, run the tests and fix what breaks.
  4. @ the frontier model again to review the result.

You pay per token for steps 1 and 4. The volume in step 3 runs on hardware the company already owns. The developer chooses the model for each turn; GIDE doesn’t route silently behind your back, which is also what makes the spend explainable.

Context that doesn’t reset when the model changes

Memory, history and project conventions in GIDE are local files that whichever model answers can read. When you hand a task from a frontier model to a local one, the local model starts from the same context, not from zero. On Business and Enterprise, the Context Memory Server keeps architecture decisions and conventions across sessions, and the shared workspace gives a team the same project memory.

The same controls on every model

The harness belongs to the workspace, not to the model. Whether the answer came from a frontier API or a 9B model on a MacBook Air, it goes through the same gates: the Plan Gate before any change, the Write Gate on every file write, the Command Gate on every shell command and MCP tool call, Folder Trust and the Path Gate before anything reaches outside the project. An edit judge, post-edit verification and a dependency guard check the work. Every plan, write and rejection lands in a local JSONL audit log.

For a security team, that means one review of one tool, not one review per model.

Built for how enterprises actually buy

  • No new hardware procurement. The local tier runs on the Macs already in your fleet.
  • A shared box when you want one. VPS & Private Servers connects GIDE to a model on a machine you control, such as a high-memory Mac Studio or a GPU server inside your network, so smaller laptops can use a bigger model without anything leaving the network.
  • Your gateway, your rules. Custom Endpoints connect any OpenAI- or Anthropic-compatible endpoint, including a corporate AI gateway that already enforces budgets and logging.
  • Enterprise controls. Air-gapped deployment with offline license activation, SSO/SAML with Okta or Azure AD, custom compliance reporting, custom integrations, dedicated onboarding and volume seat licensing. Enterprise builds can include or leave out online models depending on what your policy allows.

When this might not be right for you

  • Your hardest work is all frontier work. If most of your tokens go to novel, difficult problems, a local model won’t carry them, and the savings shrink. The local tier is for the long tail.
  • Your fleet is mostly 16 GB machines. They run 9B-class models well, which is plenty for small edits and test loops, but the 27B tier needs a 36 GB+ Pro or Max, or a shared server.
  • You need parallel agents on one laptop. A local model answers one request at a time; sub-agents queue.
  • You want automatic routing. GIDE keeps the developer in charge of which model answers. If you want a black box that decides for you, this isn’t that.
  • You need a compliance certification from the tool. GIDE gives you control over where code and prompts go and a record of what the agent did. Whether a setup meets a specific standard is a decision for your compliance team.

FAQ

Why does per-token billing change the case for local models?

Under a seat plan, usage you didn’t consume was already paid for, so moving work local saved nothing at the margin. Under per-token billing every token is billed, and most of an agent’s tokens are high-volume, low-difficulty work a local model handles well.

Can a MacBook really run a useful coding model?

Yes. Every Apple Silicon Mac with an M2 or newer and 16 GB runs a 9B-class model, and a 36 GB or larger M-series Pro or Max runs 27B-class models with long context, thanks to unified memory. Hard problems still belong to a frontier model.

Is a Mac as fast as an NVIDIA GPU for local AI?

Not on raw speed. A top desktop GPU processes prompts much faster. But a Mac holds larger models and longer contexts than consumer cards, and since most agent tokens are cached re-reads, a current Pro or Max handles a typical developer day’s volume in one to a few hours of machine time.

Does GIDE automatically decide when to use the frontier model?

No. The developer picks the model per turn, or @ mentions one for a single message. That keeps spend predictable and every frontier call deliberate.

Can we keep all code inside our network?

Yes. Use local models on the Mac or a model on your own server. With local models your code stays on the machine. On Enterprise, air-gapped deployment works with no sign-in and no network at all.

Try it

Your company has already paid for a fleet of machines with tens of gigabytes of fast unified memory. Under per-token billing, letting that sit idle while every re-read goes on the invoice is the expensive choice.

Every GIDE plan starts with a 30-day free trial, no credit card needed. Download GIDE, read how multi-model works in practice, or talk to us about Enterprise.