Use ReadOnlyMemory<byte> for binary data to eliminate UTF-16 transcoding by Copilot · Pull Request #1070 · modelcontextprotocol/csharp-sdk

Copilot · 2025-12-05T22:42:03Z

Plan: Fix Binary Data Representation in Protocol Types

Based on the issue analysis, I need to change how binary data is represented in the protocol types to avoid unnecessary UTF-16 transcoding. The current implementation uses string properties for base64-encoded data, which causes UTF-8 → UTF-16 → base64 decode conversions.

Changes Required:

Update BlobResourceContents.Blob property
- Changed from string to ReadOnlyMemory<byte> for zero-copy UTF-8 representation
- Added lazy Data property for decoded binary data with caching
- Updated custom JSON converter in ResourceContents.Converter
- Added cache invalidation when Blob is set
- Optimized with MemoryMarshal.TryGetArray to avoid ToArray() in common cases
- Use Base64.DecodeFromUtf8 to decode directly from UTF-8 bytes without string intermediate
Update ImageContentBlock.Data property
- Changed from string to ReadOnlyMemory<byte>
- Added lazy DecodedData property for decoded binary data with caching
- Updated custom JSON converter in ContentBlock.Converter
- Added cache invalidation when Data is set
- Optimized with MemoryMarshal.TryGetArray to avoid ToArray() in common cases
- Use Base64.DecodeFromUtf8 to decode directly from UTF-8 bytes without string intermediate
Update AudioContentBlock.Data property
- Changed from string to ReadOnlyMemory<byte>
- Added lazy DecodedData property for decoded binary data with caching
- Updated custom JSON converter in ContentBlock.Converter
- Added cache invalidation when Data is set
- Optimized with MemoryMarshal.TryGetArray to avoid ToArray() in common cases
- Use Base64.DecodeFromUtf8 to decode directly from UTF-8 bytes without string intermediate
Fixed AIContentExtensions.cs to use DecodedData properties
Fixed AIFunctionMcpServerResource.cs to convert strings to UTF-8 bytes
- Optimized with MemoryMarshal.TryGetArray for ReadOnlyMemory to avoid ToString() in common cases
- Use GetBytes overload with offset and count parameters for better performance
Fixed test servers (TestServer, TestSseServer, ConformanceServer) to use UTF-8 encoding
Update tests
- Fixed ResourceContentsTests.cs to use byte arrays and UTF-8 encoding
- Fixed ContentBlockTests.cs to use byte arrays
- Fixed all integration tests and sample code
- Updated assertions to compare UTF-8 decoded strings
Build and test all changes
- Build succeeds across all target frameworks
- All unit tests pass (protocol tests, resource tests, content block tests)
- Code review feedback addressed
- Performance optimizations applied

Summary:

Successfully converted binary data properties from string to ReadOnlyMemory<byte> to avoid UTF-16 transcoding overhead. The changes:

Use ReadOnlyMemory<byte> to store base64-encoded UTF-8 bytes directly from JSON
Provide lazy Data/DecodedData properties that decode and cache the binary data
Cache invalidation when base64-encoded data is modified
Write UTF-8 bytes directly to JSON without string allocation
All tests updated and passing
Performance optimizations using MemoryMarshal.TryGetArray to avoid unnecessary allocations
Direct base64 decoding from UTF-8 bytes using System.Buffers.Text.Base64.DecodeFromUtf8 - completely eliminates string intermediate during decoding

Performance Optimizations:

Changed #if NET6_0_OR_GREATER to #if NET for simplicity
Use MemoryMarshal.TryGetArray to extract backing array when available, avoiding ToArray() allocations
Apply same optimization for ReadOnlyMemory to avoid ToString() allocations
Use GetBytes(char[], int, int) overload to pass offset and count directly instead of checking for complete array
Use System.Buffers.Text.Base64.DecodeFromUtf8 on .NET to decode directly from UTF-8 base64 bytes to binary without creating an intermediate UTF-16 string
Allocate max buffer size, decode, then slice to actual size using ReadOnlyMemory (avoids extra allocation ~67% of time)
Falls back to optimized string-based approach for .NET Standard 2.0

End-to-End Performance Path:

Wire → JSON Reader → ReadOnlyMemory<byte>: Zero UTF-8 → UTF-16 transcoding
Base64 Decode: Direct UTF-8 bytes → binary via Base64.DecodeFromUtf8 (no string intermediate)
Cache & Return: ReadOnlyMemory<byte> with lazy decode and caching

Original prompt

This section details on the original issue you should resolve

<issue_title>Content types that represent binary data are exposing UTF16 encoded strings</issue_title>
<issue_description>

csharp-sdk/src/ModelContextProtocol.Core/Protocol/BlobResourceContents.cs

Lines 25 to 29 in 4a84412

/// <summary>

/// Gets or sets the base64-encoded string representing the binary data of the item.

/// </summary>

[JsonPropertyName("blob")]

public required string Blob { get; set; }

csharp-sdk/src/ModelContextProtocol.Core/Protocol/ContentBlock.cs

Lines 377 to 381 in 4a84412

/// <summary>

/// Gets or sets the base64-encoded image data.

/// </summary>

[JsonPropertyName("data")]

public required string Data { get; set; }

csharp-sdk/src/ModelContextProtocol.Core/Protocol/ContentBlock.cs

Lines 399 to 403 in 4a84412

/// <summary>

/// Gets or sets the base64-encoded audio data.

/// </summary>

[JsonPropertyName("data")]

public required string Data { get; set; }

Potentially more -- https://github.com/search?q=repo%3Amodelcontextprotocol%2Fcsharp-sdk%20%22base64-encoded%22&type=code

Doing this means that the UTF8 data that comes across the wire is transcoded to UTF16 just to be then base64 decoded to bytes when anyone uses it. The intermediate step to UTF16 (.NET string) is unnecessary, wastes cycles, creates garbage, and makes the API harder to use.

Instead these types should keep the data in UTF8 and then have lazy getters that will do the base64-decoding. We can tell folks to use those decoded getter properties.

https://github.com/dotnet/extensions/blob/main/src/Libraries/Microsoft.Extensions.AI.Abstractions/Contents/DataContent.cs follows a similar pattern, though it uses the Uri as it's serialized representation. It seems these MCP types should use the UTF8 encoded data as their serialized representation.

The OpenAI SDK exposes a BinaryData as its representation to deal with this problem https://github.com/openai/openai-dotnet/blob/636075222205d626a770acb1af1e5cc060abd517/src/Custom/Images/GeneratedImage.cs#L23 however that's slightly less usable since it forces the caller to decode.

The proposal here would be to have these be instead:
/// <summary> 
/// Gets or sets the base64-encoded UTF-8 byes representing the binary data of the item.
/// </summary> 
/// <remarks>
/// This is a zero-copy representation of the wire payload of this item.  Setting this value will invalidate any cached value of <see cref="Data" />.
/// </remarks>
[JsonPropertyName("blob")] 
public required ReadOnlyMemory<byte> Blob { get; set; } 

/// <summary> 
/// Gets the decoded data represented by <see cref="Blob" />.
/// </summary>
/// <remarks>
/// Accessing this member will decode the value in <see cref="Blob" /> and cache the result.
/// </remarks>
[JsonIgnore]
public byte[] Data { get; }
</issue_description>

<agent_instructions>Please find any protocol types that expose binary data as string (typically base64 encoded) and follow the cited recommendations for how to expose them differently.</agent_instructions>

Comments on the Issue (you are @copilot in this section)
@stephentoub > The proposal here would be to have these be instead:
Should Data also be a ReadOnlyMemory<byte>?

Is Data going to cache the decoded data lazily, or is it going to produce a new array on each access? If the latter, it shouldn't be a property.

what do you think about the name Blob

I'm torn. On the one hand, I agree with you. On the other hand, it's nice to keep it the same or super close to the spec. Offline you'd proposed something like Base64Blob; is that still your first choice?</comment_new>

Fixes Content types that represent binary data are exposing UTF16 encoded strings #1064

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

src/ModelContextProtocol.Core/Protocol/BlobResourceContents.cs

src/ModelContextProtocol.Core/Protocol/ContentBlock.cs

src/ModelContextProtocol.Core/Server/AIFunctionMcpServerResource.cs

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

src/ModelContextProtocol.Core/Server/AIFunctionMcpServerResource.cs

stephentoub · 2025-12-08T04:37:06Z

@ericstj, I'm not sure this will actually end up saving much end-to-end. It'd help if some of the data wasn't actually looked at, but if it ends up being looked at, it seems it'll actually make the end-to-end worse.

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

ericstj · 2025-12-08T18:22:54Z

I see this PR is still going though a string when decoding - I thought we had API that would go straight from ROS (base64 UTF8) to byte[] without an intermediate string.

stephentoub · 2025-12-08T18:29:42Z

I thought we had API that would go straight from ROS (base64 UTF8) to byte[] without an intermediate string.

We have operation status APIs that write into an existing destinatiom buffer, but no one-shot that creates the array. We do for Base64Url but we didn't square the circle for Base64.

ericstj · 2025-12-08T19:46:06Z

Can't we do Base64.GetMaxDecodedFromUtf8Length to get the size, create a byte array, then Base64.DecodeFromUtf8, followed by slice to final actual size?

stephentoub · 2025-12-08T19:59:39Z

Base64.DecodeFromUtf8

That's the operation status API I was referring to.

Can't we do Base64.GetMaxDecodedFromUtf8Length to get the size, create a byte array, then Base64.DecodeFromUtf8, followed by slice to final actual size?

I thought you'd stated you wanted the decoded data property to be a byte[]. If it is, slicing would entail allocating a whole new array unless the max happened to equal actual, which would happen only ~33% of the time.

If the destination property is a ReadOnlyMemory<byte>, then yes, it can be done that way.

ericstj · 2025-12-09T01:25:02Z

If the destination property is a ReadOnlyMemory<byte>, then yes, it can be done that way.

This is exactly what I was thinking of when mentioning:

If using ROM avoids a copy it's acceptable.

And the current implementation is already exposing as public ReadOnlyMemory<byte> DecodedData so I think we've already committed to this. Let's go ahead and remove those string intermediates. @copilot

Co-authored-by: ericstj <8918108+ericstj@users.noreply.github.com>

Copilot · 2025-12-09T01:37:48Z

If the destination property is a ReadOnlyMemory<byte>, then yes, it can be done that way.

This is exactly what I was thinking of when mentioning:
...

Implemented using Base64.DecodeFromUtf8 to decode directly from UTF-8 bytes without string intermediate in commit 39213fb. The implementation:

Uses Base64.GetMaxDecodedFromUtf8Length to allocate the buffer
Calls Base64.DecodeFromUtf8 to decode directly
Slices to actual size using ReadOnlyMemory when needed (only allocates new array ~33% of time when actual != max)
Falls back to optimized string-based approach for .NET Standard 2.0

stephentoub · 2025-12-09T01:38:19Z

What are developers that need to set the data going to do? We will do the complicated thing internally in our own use, but most devs/call sites won't. It'll end up being worse for them still, right? How are we going to mitigate that?

src/ModelContextProtocol.Core/AIContentExtensions.cs

samples/EverythingServer/Tools/AnnotatedMessageTool.cs

ericstj · 2025-12-09T02:02:45Z

Thinking about principles here:

The type should internally represent the data in the form closest to it's transit format. That ensures the existence of a high-perf, zero-overhead path in case conversion is not needed. For these MCP types that UTF8, base64 encoded bytes. For DataContent that's a data URI.
The type should have constructors/factories/properties that support multiple forms of initialization without forcing the caller to do the decoding. I imagine that would be base64-uft8-bytes, base64-string, decoded bytes. We should choose the initialization option that minimizes additional decoding in any circumstance.
We should have helpers that efficiently decode lazily and cache the result.

So in reviewing this I wouldn't want to see a ton of decoding sprinkled throughout the codebase. I would hope that we can have all the decoding surface area on the types themselves.

What are developers that need to set the data going to do? We will do the complicated thing internally in our own use, but most devs/call sites won't. It'll end up being worse for them still, right? How are we going to mitigate that?

Developers can initialize these types in the way that is most convenient to the form of data they have. We can indicate the least expensive initialization (from Base64 UTF8 bytes) but they need not initialize this way if they only have the data in a different form. They need not do the conversion - we will do it in the most efficient way. It's similar to MEAI DataContent -- though that type happens to have a very unlikely underlying format (data URI in UTF16) so it most likely will always convert when folks initialize.

Developers should avoid accessing members that require the to convert the output, and instead access the member with the data in the format they require. We'll convert to that in the most efficient way and cache the result.

Does this sound right @stephentoub

stephentoub · 2025-12-10T04:06:11Z

That sounds reasonable, but it also requires more changes / APIs to get there.

eiriktsarpalis · 2025-12-10T13:59:28Z

The type should internally represent the data in the form closest to it's transit format. That ensures the existence of a high-perf, zero-overhead path in case conversion is not needed. For these MCP types that UTF8, base64 encoded bytes. For DataContent that's a data URI.

On my tasks branch I made the decision to represent millisecond ttl properties using TimeSpan and a suitable custom converter. Should I reconsider and use int instead?

stephentoub · 2025-12-10T15:49:16Z

The type should internally represent the data in the form closest to it's transit format. That ensures the existence of a high-perf, zero-overhead path in case conversion is not needed. For these MCP types that UTF8, base64 encoded bytes. For DataContent that's a data URI.

On my tasks branch I made the decision to represent millisecond ttl properties using TimeSpan and a suitable custom converter. Should I reconsider and use int instead?

Elsewhere we use DateTimeOffset in the protocol types, e.g.

csharp-sdk/src/ModelContextProtocol.Core/Protocol/Annotations.cs

Line 38 in cd1052b

public DateTimeOffset? LastModified { get; set; }

Seems reasonable to use the .NET representation of the concept for dates, times, and time spans.

I think the concern Eric is raising is more about cases where there's a non-trivial overhead to the cost of the transformation.

ericstj · 2025-12-10T21:23:58Z

Yes, my concerns are cases where the cost of transformation is significant, or the data at rest is neither the user format nor the wire format (as was the case with UTF16 base64 string).

stephentoub · 2026-01-21T16:51:24Z

@ericstj, is this something you're still interested in pushing forward?

ericstj · 2026-01-21T17:15:00Z

Yes, thanks for the reminder. Let me refresh my memory on it and have a look this week.

ericstj · 2026-01-27T18:32:39Z

Fixing up the merge conflict.

…om data. These factories go straight from data -> base64 utf-8 encoded data without excess garbage.

…-sdk into copilot/fix-binary-data-encoding

ericstj · 2026-01-30T16:46:14Z

Test failure is #1222

ericstj · 2026-02-05T00:28:00Z

@stephentoub when you have a chance would appreciate your pass on this once more, since I'm the last committer.

stephentoub · 2026-02-05T03:10:25Z

samples/EverythingServer/Resources/SimpleResourceType.cs

            new BlobResourceContents
            {
-                Blob = resource.Description!,
+                Blob = System.Text.Encoding.UTF8.GetBytes(resource.Description!),


@copilot, we prefer to use simple rather than fully-qualified names. Can these "System.Text"s be moved instead to usings at the beginning?

stephentoub · 2026-02-05T03:15:28Z

src/ModelContextProtocol.Core/AIContentExtensions.cs

+            // gets UTF-8 bytes from UTF-16 chars without intermediate string allocations
+            fixed (char* pChars = utf16)
+            {
+                var byteCount = System.Text.Encoding.UTF8.GetByteCount(pChars, utf16.Length);
+                var bytes = new byte[byteCount];
+
+                fixed (byte* pBytes = bytes)
+                {
+                    System.Text.Encoding.UTF8.GetBytes(pChars, utf16.Length, pBytes, byteCount);
+                }
+                return bytes;
+            }


@copilot, this shouldn't require unsafe code on .NET Core... there are overloads that work with spans, so this can be e.g.

byte[] bytes = new byte[Encoding.UTF8.GetByteCount(utf16)] Encoding.UTF8.GetBytes(utf16, bytes); return bytes;

For the netstandard2.0 build, you can add polyfills for these methods in https://github.com/modelcontextprotocol/csharp-sdk/tree/main/src/Common/Polyfills/System

I had used the unsafe code to avoid the ifdef, I agree a polyfill approach should work. Thanks for suggestion.

stephentoub · 2026-02-05T03:17:48Z

src/ModelContextProtocol.Core/Protocol/BlobResourceContents.cs

+        int maxLength = Base64.GetMaxEncodedToUtf8Length(data.Length);
+        byte[] buffer = new byte[maxLength];
+        if (Base64.EncodeToUtf8(data.Span, buffer, out _, out int bytesWritten) == OperationStatus.Done)
+        {


We expect bytesWritten to always equal buffer.Length, right? Should we assert that?

stephentoub · 2026-02-05T03:18:09Z

src/ModelContextProtocol.Core/Protocol/BlobResourceContents.cs

+                    throw new FormatException("Invalid base64 data");
+                }
+            }
+            return _decodedData.Value;


Suggested change

return _decodedData.Value;

return _decodedData.Value;

stephentoub · 2026-02-05T03:20:26Z

src/ModelContextProtocol.Core/Protocol/BlobResourceContents.cs

+    /// </para>
+    /// </remarks>
+    [JsonIgnore]
+    public ReadOnlyMemory<byte> Data


@ericstj why do you call this Data here but DecodedData elsewhere like on ContentBlock?

We can change it.

The change was made here 4287694#diff-9da29ad32a17c90e9b28c79ad3ab9c4b370a757e26657c736020ea47314a60ba

I had assumed we would have liked to use Data everywhere, since that's the better name and more-likely the "useful" property for the caller. The ContentBlock types had already used Data to mean the encoded data, so we didn't change that.

I agree that consistency is better here - lets use DecodedData here. What are your thoughts on Blob vs Data for the encoded data? Should we keep those different between content and resource types (since it's preexisting discrepancy) or try to make the consistent?

Should we keep those different between content and resource types (since it's preexisting discrepancy) or try to make the consistent?

I think there's value in keeping the names of these C# properties aligned with their spec / JSON schema counterparts. I don't know why they differ in the MCP spec, but alas.

Initial plan

7dca602

Copilot AI assigned Copilot and stephentoub Dec 5, 2025

Copilot started work on behalf of stephentoub December 5, 2025 22:42 View session

Copilot AI and others added 3 commits December 5, 2025 23:00

Update protocol types to use ReadOnlyMemory<byte> for binary data

4287694

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Fix test files to work with new binary data representation

8e6fcf0

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Add cache invalidation when Blob/Data properties are set

e405dfc

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Copilot AI changed the title ~~[WIP] Fix binary data types exposing UTF16 encoded strings~~ Use ReadOnlyMemory<byte> for binary data to eliminate UTF-16 transcoding Dec 5, 2025

Copilot AI requested a review from stephentoub December 5, 2025 23:28

Copilot finished work on behalf of stephentoub December 5, 2025 23:28

stephentoub requested a review from ericstj December 8, 2025 03:42

stephentoub reviewed Dec 8, 2025

View reviewed changes

Copilot started work on behalf of stephentoub December 8, 2025 04:21 View session

Apply performance optimizations using MemoryMarshal.TryGetArray

ebe3eef

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Copilot AI requested a review from stephentoub December 8, 2025 04:31

Copilot finished work on behalf of stephentoub December 8, 2025 04:31

stephentoub reviewed Dec 8, 2025

View reviewed changes

src/ModelContextProtocol.Core/Server/AIFunctionMcpServerResource.cs Outdated Show resolved Hide resolved

Copilot started work on behalf of stephentoub December 8, 2025 04:36 View session

Use GetBytes overload with offset and count parameters

1d76c11

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Copilot AI requested a review from stephentoub December 8, 2025 04:43

Copilot finished work on behalf of stephentoub December 8, 2025 04:43

Copilot started work on behalf of ericstj December 9, 2025 01:25 View session

Use Base64.DecodeFromUtf8 to avoid string intermediate during decoding

39213fb

Co-authored-by: ericstj <8918108+ericstj@users.noreply.github.com>

Copilot finished work on behalf of ericstj December 9, 2025 01:39

ericstj reviewed Dec 9, 2025

View reviewed changes

src/ModelContextProtocol.Core/AIContentExtensions.cs Outdated Show resolved Hide resolved

ericstj reviewed Dec 9, 2025

View reviewed changes

src/ModelContextProtocol.Core/AIContentExtensions.cs Outdated Show resolved Hide resolved

ericstj reviewed Dec 9, 2025

View reviewed changes

src/ModelContextProtocol.Core/AIContentExtensions.cs Outdated Show resolved Hide resolved

ericstj reviewed Dec 9, 2025

View reviewed changes

samples/EverythingServer/Tools/AnnotatedMessageTool.cs Show resolved Hide resolved

Tyler-IN mentioned this pull request Dec 24, 2025

WIP: Reduce copies, eliminate a lot of UTF-16 transcoding #1120

Draft

9 tasks

scutuatua-crypto approved these changes Jan 10, 2026

View reviewed changes

Merge branch 'main' into copilot/fix-binary-data-encoding

a4ba4a9

ericstj added 7 commits January 27, 2026 11:17

Fix merge conflict with DebuggerDisplay

b4e4eaf

Cleanup refactoring

61f0dfa

Remove string from DataContent conversion

5de847c

Add factory methods to data backed types to efficiently initialize fr…

dc01608

…om data. These factories go straight from data -> base64 utf-8 encoded data without excess garbage.

Update some tests to use factory methods

2fc35d9

Fix test assertions in McpServerToolTests

14fedca

Merge branch 'main' of https://github.com/modelcontextprotocol/csharp…

b3eacff

…-sdk into copilot/fix-binary-data-encoding

ericstj marked this pull request as ready for review February 2, 2026 18:31

ericstj approved these changes Feb 5, 2026

View reviewed changes

stephentoub reviewed Feb 5, 2026

View reviewed changes

	/// <summary>
	/// Gets or sets the base64-encoded string representing the binary data of the item.
	/// </summary>
	[JsonPropertyName("blob")]
	public required string Blob { get; set; }

	/// <summary>
	/// Gets or sets the base64-encoded image data.
	/// </summary>
	[JsonPropertyName("data")]
	public required string Data { get; set; }

	/// <summary>
	/// Gets or sets the base64-encoded audio data.
	/// </summary>
	[JsonPropertyName("data")]
	public required string Data { get; set; }

Conversation

Copilot AI commented Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Plan: Fix Binary Data Representation in Protocol Types

Changes Required:

Summary:

Performance Optimizations:

End-to-End Performance Path:

Comments on the Issue (you are @copilot in this section)

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

stephentoub commented Dec 8, 2025

Uh oh!

ericstj commented Dec 8, 2025

Uh oh!

stephentoub commented Dec 8, 2025

Uh oh!

ericstj commented Dec 8, 2025

Uh oh!

stephentoub commented Dec 8, 2025

Uh oh!

ericstj commented Dec 9, 2025

Uh oh!

Copilot AI commented Dec 9, 2025

Uh oh!

stephentoub commented Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ericstj commented Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stephentoub commented Dec 10, 2025

Uh oh!

eiriktsarpalis commented Dec 10, 2025

Uh oh!

stephentoub commented Dec 10, 2025

Uh oh!

ericstj commented Dec 10, 2025

Uh oh!

stephentoub commented Jan 21, 2026

Uh oh!

ericstj commented Jan 21, 2026

Uh oh!

ericstj commented Jan 27, 2026

Uh oh!

ericstj commented Jan 30, 2026

Uh oh!

ericstj commented Feb 5, 2026

Uh oh!

stephentoub Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

stephentoub Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

ericstj Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

stephentoub Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

stephentoub Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

stephentoub Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

ericstj Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI commented Dec 5, 2025 •

edited

Loading

stephentoub commented Dec 9, 2025 •

edited

Loading

ericstj commented Dec 9, 2025 •

edited

Loading

ericstj Feb 5, 2026 •

edited

Loading