Introduction

In TensorFlow 1.x, a session was the object that turned a symbolic graph into real computation. You could define tensors, variables, and operations in Python, but nothing actually ran until a Session executed part of that graph and returned concrete results.

Graph Construction Versus Execution

TensorFlow 1 separated your program into two phases:

• build the graph
• run the graph in a session

That means this line:

z = x + y

did not produce a Python number. It produced a symbolic tensor node that described an addition operation. A session later evaluated that node with real values:

1import tensorflow as tf
2
3tf.compat.v1.disable_eager_execution()
4
5x = tf.compat.v1.placeholder(tf.float32)
6y = tf.compat.v1.placeholder(tf.float32)
7z = x + y
8
9with tf.compat.v1.Session() as sess:
10    result = sess.run(z, feed_dict={x: 2.0, y: 3.0})
11    print(result)

The key idea is that the graph was only a plan. The session was the runtime that executed the plan.

What a Session Managed

A TensorFlow session did more than evaluate math. It also managed:

• device placement
• runtime memory
• variable state
• execution of only the subgraph needed for the requested outputs

When you called sess.run(...), TensorFlow did not blindly run the entire graph. It computed only the dependencies required for the fetches you asked for. That selective execution was important for performance and scale.

Variable state also lived under the session-managed runtime:

1import tensorflow as tf
2
3tf.compat.v1.disable_eager_execution()
4
5counter = tf.Variable(0)
6increment = tf.compat.v1.assign(counter, counter + 1)
7
8with tf.compat.v1.Session() as sess:
9    sess.run(tf.compat.v1.global_variables_initializer())
10    for _ in range(3):
11        print(sess.run(increment))

Without the session, the variable existed only as part of the graph definition. It was not initialized or usable yet.

Feeds and Fetches Are the Best Mental Model

One of the clearest ways to understand sessions is through feeds and fetches.

• A feed is a runtime value you inject into a placeholder or another feedable tensor.
• A fetch is the tensor or operation you ask the session to compute.

This is why feed_dict existed in so many TensorFlow 1 examples. The graph was reusable, and the session let you run it repeatedly with different inputs.

That design was powerful, but it also made debugging feel indirect because your Python code described a computation instead of executing it immediately.

Why TensorFlow 2 Mostly Removed Sessions

TensorFlow 2 switched to eager execution by default. Operations now behave more like ordinary Python computations:

1import tensorflow as tf
2
3x = tf.constant(2.0)
4y = tf.constant(3.0)
5print((x + y).numpy())

There is no explicit session here. The operation runs immediately, which makes the code easier to read, debug, and integrate with normal Python control flow.

Even so, sessions still matter if you read older tutorials, maintain legacy TensorFlow 1 code, or work through tf.compat.v1 APIs.

When the Session Model Was Useful

The session model made it possible to optimize and schedule graph execution separately from Python control flow. That helped with:

• distributed execution
• graph serialization
• ahead-of-time optimization
• selective execution of large computation graphs

So sessions were not arbitrary complexity. They were a deliberate runtime design. TensorFlow 2 simply moved the default developer experience toward something more Pythonic.

Common Pitfalls

• Thinking a TensorFlow 1 tensor already contains a computed value before a session runs it.
• Forgetting to initialize variables inside the session before using them.
• Assuming sess.run() executes the whole graph instead of just the needed dependency path.
• Mixing eager TensorFlow 2 examples with session-based TensorFlow 1 code and expecting them to behave the same way.
• Confusing Python variables with TensorFlow runtime state stored in the graph and session.

Summary

• A TensorFlow 1 session was the runtime object that executed a symbolic computation graph.
• It managed feeds, fetches, variable state, memory, and device execution.
• Graph construction described work; the session actually performed it.
• TensorFlow 2 mostly removed explicit sessions by enabling eager execution by default.
• Understanding sessions is still useful when reading or maintaining legacy TensorFlow 1 code.