Introduction

This question comes from TensorFlow 1.x, where sessions were explicit runtime objects. The key point is that a default session is not a special nested session. It is just the session TensorFlow will use when you call convenience methods such as tensor.eval() or op.run() without passing a session argument.

What as_default() Actually Does

When you enter with sess.as_default():, TensorFlow stores sess in the current default-session context. Inside that block, helper methods can find the session automatically.

1import tensorflow as tf
2
3tf.compat.v1.disable_eager_execution()
4
5a = tf.constant(3.0)
6b = tf.constant(4.0)
7c = a + b
8
9with tf.compat.v1.Session() as sess:
10    with sess.as_default():
11        print(c.eval())

This prints 7.0. There is still only one session object. The as_default() block only changes how TensorFlow resolves implicit execution calls.

You Usually Do Not Run a Session "Inside" Another One

If you create a second Session, that is a separate runtime with separate resource ownership. That is not what most people mean when they ask about a default session.

The common pattern is:

with tf.compat.v1.Session() as sess:
    result = sess.run(c)

or, if you want convenience methods:

with tf.compat.v1.Session() as sess:
    with sess.as_default():
        result = c.eval()

Both use the same session. The second version just relies on default-session lookup.

Pair Session Context with Graph Context

In TensorFlow 1.x, it is easy to create tensors in one graph and accidentally evaluate them in a session bound to another graph. When you work with explicit graphs, set both contexts clearly.

1import tensorflow as tf
2
3tf.compat.v1.disable_eager_execution()
4
5graph = tf.Graph()
6with graph.as_default():
7    x = tf.compat.v1.placeholder(tf.float32, shape=())
8    y = tf.compat.v1.placeholder(tf.float32, shape=())
9    z = x * y + 2.0
10
11with tf.compat.v1.Session(graph=graph) as sess:
12    with sess.as_default():
13        result = z.eval(feed_dict={x: 5.0, y: 6.0})
14        print(result)

This is the safe pattern for legacy projects that manage multiple graphs explicitly.

InteractiveSession Is a Convenience Wrapper

tf.compat.v1.InteractiveSession() creates a session and installs it as the default immediately. It was designed for shells and notebooks, where typing sess.run(...) repeatedly is awkward.

1import tensorflow as tf
2
3tf.compat.v1.disable_eager_execution()
4
5sess = tf.compat.v1.InteractiveSession()
6a = tf.constant(10)
7b = tf.constant(20)
8print((a + b).eval())
9sess.close()

This is convenient in exploratory work, but for scripts and production code, plain with tf.compat.v1.Session() blocks are usually clearer and easier to clean up correctly.

When Multiple Sessions Do Make Sense

You can create multiple sessions if you intentionally want isolated runtime state. Variables initialized in one session are not automatically initialized in another.

1import tensorflow as tf
2
3tf.compat.v1.disable_eager_execution()
4
5graph = tf.Graph()
6with graph.as_default():
7    counter = tf.compat.v1.Variable(0)
8    init = tf.compat.v1.global_variables_initializer()
9    inc = tf.compat.v1.assign_add(counter, 1)
10
11with tf.compat.v1.Session(graph=graph) as s1:
12    s1.run(init)
13    print(s1.run(inc))
14
15with tf.compat.v1.Session(graph=graph) as s2:
16    s2.run(init)
17    print(s2.run(inc))

That is valid, but it is a deliberate isolation technique, not a default-session pattern.

TensorFlow 2.x Changes the Picture

If you are writing new TensorFlow code, you usually should not use sessions at all. TensorFlow 2 executes eagerly by default.

1import tensorflow as tf
2
3a = tf.constant(3)
4b = tf.constant(4)
5print((a + b).numpy())

Session-based code belongs mainly to TensorFlow 1.x or compatibility-mode maintenance work. In TensorFlow 2, tf.compat.v1.Session() is only for legacy migration scenarios.

Common Pitfalls

One common mistake is assuming sess.as_default() creates a new nested session. It does not. It only installs an existing session as the default for the current context.

Another issue is mixing graph contexts. If a tensor belongs to one graph and the session belongs to another, evaluation fails with confusing errors.

Developers also sometimes use InteractiveSession in production-style code where an explicit context manager would be easier to reason about and clean up.

Finally, TensorFlow 2 eager execution and TensorFlow 1 session code do not mix automatically. If you are maintaining session-based code in a TensorFlow 2 runtime, use the tf.compat.v1 APIs consistently and disable eager execution when needed.

Summary

• A default session is just the session TensorFlow uses for implicit helpers like eval().
• 'with sess.as_default(): does not create a second session.'
• Keep graph context and session context aligned in TensorFlow 1.x code.
• Use multiple sessions only when you intentionally want isolated runtime state.
• For new TensorFlow 2 code, prefer eager execution and avoid sessions entirely.