Count the Containers, Not the Gigabytes

Picture two workstations on a factory floor with a stack of containers between them. Every so often, the person at the second station has to stop, walk over, grab a container, and carry it back before they can finish their part of the job.

If you have ever worked in a warehouse or a factory, you have watched this a thousand times and never thought about it once. But somebody has to move those containers, over and over, or the next step stalls.

Now put a humanoid robot in that gap for a full shift. It moves the containers. That is the whole job.

Everyone wants to know when Optimus will do everything a person can do: laundry, dishes, walking the dog. Farzad thinks there is a more useful question. How much valuable work can Tesla get a robot to do with hardware it can actually build at scale?

In his view, if the robot handles the container run reliably, it has a real reason to exist long before it can walk into an unfamiliar house and take care of everything. That is the engineering problem. You have a limited amount of hardware, a limited amount of energy, and a job that has to get done. The opportunity sits in the overlap between what the machine can reliably handle and what people actually need.

Efficiency was in the plan from the start

Tesla describes Optimus as a general purpose humanoid intended for unsafe, repetitive, or boring tasks. On its AI engineering page, Tesla explicitly talks about efficient inference hardware, meaning the computer that runs a model that has already been trained.

Farzad's read: efficiency belongs inside the ambition from the very beginning, because it determines how much of that ambition you can put into a physical machine.

One part of that computer matters a lot here: memory. The robot has to keep track of where it is, where the objects are, and what just happened. But in Farzad's view, buying more memory and getting more useful work are not automatically the same thing. The better question is what the job actually needs.

The workbench

Think about reaching for a cup. You do it without making a spreadsheet of the steps. A robot has to turn sensor information into movement. It has to estimate where the cup is, move its hand toward it, and respond as the situation changes.

That gives its computer several jobs at once. Some memory holds the model it is running. Some holds information being processed right now. Some may hold useful context from earlier in the task. The exact arrangement depends on the system.

Farzad's picture for this is a workbench. The bench has to be big enough for the tools and materials the current job needs. If it is too small, working faster does not help, because something important will not fit. But a much bigger empty bench does not make you a better carpenter either.

Then there is speed. How quickly can you move material onto the bench and get the results back off? That is the difference between memory capacity and memory bandwidth. Capacity is how much information you can hold. Bandwidth is how much you can move in a given amount of time.

Timing adds a layer. Nvidia describes a distinction in robot computing: immediate movement control and higher-level planning can tolerate different delays. Keeping your balance while carrying a box is one job. Deciding which room to carry it into is another. Both matter, but the first cannot wait while you think through the second. So a robot computer has to organize its work as well as hold the information.

Two modules, same bandwidth

You can see the two limits split apart in real hardware. Nvidia lists two Jetson Thor modules with different memory capacities, one with 128 GB and one with 64 GB. Its published table lists the same memory bandwidth for both.

Farzad is careful about what that means. The two modules do not have identical performance. The comparison just shows why a capacity number alone cannot tell you the whole story.

Suppose two computers can both hold the model a particular job requires. Giving one of them more capacity does not, by itself, prove it will finish that job twice as fast. Flip it around: if the model cannot fit at all, matching bandwidth will not make that problem disappear. Different limits. Engineers have to know which one they are hitting.

For Optimus specifically, Farzad says you would need workload measurements to judge any particular memory configuration. A chip announcement does not tell you the robot's success rate at picking up a slippery object, or whether it recovers when somebody moves the container. Those results come from testing the whole machine. What the distinction buys you is a better question than whether a memory number went up or down.

The 960-unit problem

Farzad's stated target is useful capability at scale. If the available memory supports more robots doing valuable work, he sees a serious opportunity. But as he puts it, a cheaper robot that constantly needs somebody to rescue it "hasn't solved the problem you're buying it to solve."

He walks through a deliberately simplified example. You have 960 units of a component to distribute, and each machine needs 96. You can equip 10 machines. If a redesign lets the same useful job run on 64 units per machine, the same supply equips 15.

He flags the limits of the toy model himself. Real memory comes in specific packages, and other parts, assembly capacity, or software can become the limit instead. The example isolates one thing: what happens when a scarce input stretches further without losing the capability you need. When it does, you get a choice. Equip more machines, keep more spare parts, or reach an acceptable cost earlier.

But if the redesign makes the robot fail at the task, those five extra machines do not deliver the benefit. That is why, in Farzad's framing, the engineering objective has to include the work delivered. A component saving is valuable when it survives the trip from the design spreadsheet to an operating machine. The number that ultimately matters is how many correctly completed tasks you get from the resources you put in.

You can't build a robot out of a forecast

You need actual parts. So Farzad sees a practical reason to build useful capability around the resources you can get, while continuing toward more capable hardware over time.

In its September 30, 2026 earnings remarks, Micron said it expected memory and storage supply demand conditions to be much tighter in calendar 2027 and 2028 than in 2026. Micron also described humanoid robotics as a potential source of growing demand.

Farzad is explicit that this is the supplier's outlook, not a measurement of Tesla's particular supply position. His point is that a robot program sits inside a wider industrial system. A brilliant design still needs manufacturable components, and more factory space for one part does not instantly create more of every other part.

His analogy is a restaurant planning 10 locations, each needing an oven. You can design the most amazing menu in the world, but if you can only get five suitable ovens, the menu has not opened the other five restaurants. You find more supply, change the design without ruining the food, or change the rollout. Robotics is far more complicated than an oven order, but the operating decision is familiar. A design that makes better use of available supply can be strategically important even when it sounds less impressive in a headline.

Boring and valuable

The idea Farzad keeps coming back to is that complexity and value are different things. A task can be repetitive and still be incredibly useful. If a robot takes a boring or dangerous job off somebody's plate, it does not need to be doing the most technically spectacular thing imaginable for that to matter.

Back to the containers. The value of automating that trip includes the interruption it removes. The person can stay with the work that actually needs their attention.

Now adjust the setup. The containers always sit in one marked area. They have handles the robot can grip. The route stays clear. The destination is easy to identify. You have made the environment easier to work in without changing the value of getting the containers delivered.

That, in his view, is the practical way to think about an early deployment. Choose an important task, then decide which parts of the environment you can make predictable. The robot still has to cope with variation, but you do not hand it every possible difficulty on day one. Repetition also makes a job easier to define and measure, so a business gets a clear before and after to compare.

Familiar is not simple

He pushes the other direction too. Something that feels simple to us is not necessarily simple for a robot.

Making a bed or cleaning dishes would be unbelievably useful, but Farzad wants to see a robot handle the actual variation before deciding a given hardware configuration is enough. A plate can be wet. A sheet can fold over itself. A cup can sit behind another cup. Human familiarity hides the difficulty.

Moving one known plate between two fixed positions is one test. Opening an unfamiliar dishwasher, identifying everything inside, and rearranging a crowded rack is a much broader assignment. Both get called "doing the dishes." They ask very different things of the system.

So instead of claiming a smaller memory budget definitely handles every household chore, he says to start with a clearly defined version of the job. Which objects? Which positions? Which lighting conditions? What happens when the first attempt fails? You do not have to solve every version of an activity before any version has value. You do have to describe what the robot can actually do. The ambition can stay broad while the first job is specific.

Count the interventions

Farzad would start with repetitive work where success is easy to recognize. Pick the thing up, put it where it belongs, do it consistently. Then make the test harder. If the robot can handle a growing range of situations without becoming impossible to build, he calls that a really interesting path for Optimus.

He would design the test with the person who normally does the work. Define what a completed task looks like. Then run the robot through ordinary variations: the object turned slightly, a container partly full, the path temporarily blocked.

You count more than successful attempts. You count how often a person intervenes, how long each task takes, and whether the machine recovers safely. A robot that finishes 90 tasks with constant assistance is a different product from one that finishes the same 90 while the operator does something else. The test also has to run long enough to show whether performance holds up. A short demo can show a promising ability. An operating record shows how often that ability survives real use.

Now configurations can be compared against the same assignment. Does the more expensive version actually reduce interventions? Does the more efficient version preserve the result? You stop arguing about which spec sounds better and start measuring what the customer receives.

Failures get the same treatment. Say the operator steps in every time a container is turned sideways. Farzad's advice is to record that as a particular failure instead of vaguely saying the robot needs more intelligence. Did it fail to recognize the handle, choose the wrong grip, or lose track of where to place the load? Those are different problems. More memory might help if the model or working information cannot fit. Better perception, a different grip, or a small change to the container might help instead. Keep the task and the failure visible, and it gets much harder to confuse a bigger component with an actual improvement.

What extra hardware has to earn

None of this makes Farzad anti-hardware. If a robot reliably creates a lot of value, paying more for the right hardware could make complete sense. The trade-off is whether the extra hardware earns its place or keeps useful robots out of more places.

Take two robots that can do the same job. One costs less to buy but needs help frequently. The other costs more and handles the assignment with fewer interruptions. The cheaper purchase may end up costing more to operate. Now reverse it. The expensive robot carries capacity this job never uses, while the cheaper one completes the work just as reliably. Then the extra hardware may not improve the customer's result at all.

So the comparison has to count the time spent supervising, maintaining, and charging the machine alongside the useful work it completes. Farzad notes you do not need to assume a robot produces millions of dollars of lifetime value to make this point. You need a job, a baseline, and a realistic account of the costs.

The baseline has a human side. If the assignment exposes somebody to danger or constant physical strain, removing it matters beyond a narrow count of tasks per hour. Farzad says that strengthens the case for pursuing the capability carefully. It does not remove the need to prove the robot itself can operate safely.

A job description that keeps growing

Farzad still thinks the long-term opportunity looks enormous. His view is that you get there by expanding the useful work a robot can do, one meaningful step at a time. More memory may open up more possibilities. Better use of memory may deliver some of them sooner.

The computer side can improve in several ways. A model can become more efficient. Software can waste less memory. Hardware can move information faster. Capacity can grow when a task genuinely benefits from more information. Nvidia's edge computing documentation gives one concrete example: reduced precision formats can shrink model weights and their working data, with accuracy trade-offs that need to be evaluated. Farzad is clear that this is a general engineering technique. It is not evidence that Tesla uses a particular implementation, or that every robot task tolerates the same change.

What interests him is the combination. Software gets better at using the machine while later machines give the software more room, and neither has to stand still while the other advances.

For a customer, progress looks like a wider range of objects handled, fewer interventions, or a longer sequence completed without help. First the machine handles one repeatable movement. Later it copes with more variation. Then it connects several movements into a complete assignment. Each step should remove a specific reason a person had to intervene.

Where the humanoid shape pays

Picture a small operation that has wanted to automate a recurring task but could never justify a bespoke installation. A machine that can learn the assignment, work with the existing tools, and move to another useful job later could change that decision.

Farzad insists on a fair comparison. If a simple fixed machine already solves the task well, a humanoid has to offer a reason to choose it. Flexibility might be that reason. Working in spaces designed for people might be that reason. Neither is an automatic win in every setting. In his view, the strongest opportunity is where the robot's shape and adaptability make useful work accessible without rebuilding the entire operation around it. Efficient onboard computing then helps turn that flexible machine into something you can produce, power, and support.

That is how the memory question connects to the larger ambition. Each engineering decision shapes which jobs make sense, which customers can use the machine, and how many machines can be supported. The effect reaches the customer through the work the robot does, not through the number printed on a component.

Back at the workstation

Go back to the two stations. Success looks quiet. The containers arrive when they are needed. The person using them no longer stops to fetch the next one. The machine handles normal variation, asks for help when necessary, and keeps the process moving.

That is the engineering bet Farzad is watching: whether Tesla can turn the hardware it can build into more reliable, useful work in the real world. Start with the repetitive, boring, and dangerous tasks. Make the capability better. Make it easier to scale. Keep widening what people can use it for.

So the next time an Optimus spec makes headlines, put the gigabytes aside for a minute. Ask how many containers moved, and how many times a person had to step in.