Why? Multi-tenant environments. First, we need to understand a few differences between environments:

• End-user UI
• Agent Runtime Environment
• LLM Server

So

• When you run Claude Code on your local MacBook, the first two are always local. The third is usually the Claude.ai server.
• When you ssh to a virtual private server (VPS) and install Claude Code there, the first two are your remote server. The third is still the Claude.ai server.
• When you run Claude RC on your virtual private server and code from your iPad using the Claude app, the end-user UI is on your iPad, the agent runtime environment is on your VPS, and the server is still Claude.ai.

Most people physically separate their tenancy, such as Claude Code, from their personal vs. work laptops. So in most cases, it's not a big deal.

But when you need multi-tenancy, it becomes super stressful. For example, say you have two different toolkits:

• personal toolkits (personal Notion, personal Sentry, personal Linear)
• workplace toolkits (company Notion, company Sentry, company Linear)

Most MCP auth states or code harnesses don't support profiles, so you can only log in to one.

So therefore... a natural evolution was to have both:

• a personal VPS with all personal toolkits set up
• a workplace VPS with all workspace toolkits set up

to physically isolate tenancies.

Now we've solved the multiple-profile issue, but the client's problems persist. Now let's get back to the environments:

• End-user UI
• Agent Runtime Environment
• LLM Server

All MCP auth or toolkit auth info should always be saved in the Agent Runtime Environment IMHO. However, a surprising number of harnesses tie them to the LLM server (such as Codex Apps or Claude.ai Plugins) or put them in the end-user UI (Claude Desktop or Codex Desktop).

Now the problem is:

• If the auth data is put on the LLM server, you cannot reuse LLM accounts across tenants
• If the auth data is put on the end-user UI, you cannot use the same app to access multi-tenants.

The only way to reliably isolate different auth information is thus:

• You ssh to a virtual private server (VPS) and run Claude Code there. Never use LLM server plugins.

Then

• End-user UI
• Agent Runtime Environment

are both isolated VPS, and

• LLM Server holds no information on the tenancy

This way, you can provide different toolkits, creating multiple dev environments.

If P=NP, then the world would be a profoundly different place than we usually assume it to be. There would be no special value in "creative leaps," no fundamental gap between solving a problem and recognizing a solution once it's found. Everyone who could appreciate a symphony would be Mozart; everyone who could follow a step-by-step argument would be Gauss. -- Scott Aaronson

Simplicity is the final achievement. After one has played a vast quantity of notes and more notes, it is simplicity that emerges as the crowning reward of art. -- Chopin

One day, I will find the right words, and they will be simple. -- Jack Kerouac

Hard to Compute, Simple to Verify

• But relaxing the definition of "hard to compute, simple to verify" lets us make some interesting analogies across different emerging technologies.
• There's public-key cryptography, which relies on things hard to compute, easy-to-verify problems like factorization of large integers, or elliptic curve cryptography
• There are also zero-knowledge proofs, which let counterparties prove that they know ng without revealing the actual secret
• Before LLMs, generating the associated image took time if you were given a prompt. A talented artist could take a few hours (minutes, days, etc.) to create a polished piece. Once created, it would be easy to verify if it fits the criteria - is this an image of a horse wearing sunglasses?
• There are no problems that are easy to compute yet hard to verify. If such a problem existed, you could just re-run the computation again.

One such thing of easy to compute yet hard to verify can be tracking the time-based hash seed, but this is only true depending on the definition of confirming. If verifying means giving input and comparing the output, yes, it is easy. It will be hard if verifying includes finding the information and comparing the production. But then again, it also falls into another hard-to-compute problem.

P: Poly-time Solvable

• Class of solvable and verifiable problems in polynomial time by a deterministic Turing machine.

NP: Nondeterministic Polynomial Time

• Class of problems that are not sure if it's solvable in polynomial time but verifiable in polynomial time.

• To prove that a problem is in NP, we need an efficient certification: a certificate (a potential solution to the problem) and a certifier (a way to verify the answer in polynomial time).

NP-Hard: Nondeterministic Polynomial Time-Hard

• It means "at least as hard as the hardest problems in NP."

• Not sure if it's solvable in poly-time.

• Not sure if it's verifiable in poly-time.

• To prove that a problem is NP-hard, we need to show that it is poly-time reducible to another NP-hard problem. That is, reduce another NP-hard problem in it.

NP-Complete

Both NP and NP-Hard.