Flatten SF — интерактивный инструмент, который рассчитывает оптимальные пешеходные и велосипедные маршруты по Сан-Франциско, балансируя между длиной пути и набором высоты. Он использует данные USGS 1‑метровой лидарной съёмки высоты и граф улиц из Overture и OpenStreetMap, обрабатывая более 160 000 сегментов улиц прямо в браузере. Пользователь может перемещать ползунок между «кратчайшим» и «самым плоским» маршрутом: каждый промежуточный вариант представляет собой парето-оптимальное решение — ни один другой маршрут не одновременно короче и менее крутой. Стоимость подъёма задаётся как 200 футов ходьбы за каждый фут набора высоты; за этим порогом маршруты перестают считаться практически полезными. При движении ползунка вправо маршрут никогда не становится короче и не увеличивает набор высоты — только наоборот или остаётся прежним.

Набор высоты считается как суммарный подъём (cumulative gain), а не как разница между начальной и конечной точками — это важно для холмистого рельефа Сан-Франциско. Лестницы учитываются для пешеходов, но исключаются для велосипедистов. Для велосипедистов есть дополнительная опция «prefer calm streets», которая корректирует «комфортную длину»: участки с защищённой велосипедной полосой или дорожкой (по данным SFMTA) учитываются как 0,8 от реальной длины, тихие улицы — как 1,0, а оживлённые arterials без полосы — как 1,4–2,0. Это позволяет выбирать не только короткие и плоские, но и комфортные для езды маршруты. На карте faint lines показывают альтернативные маршруты, рассматриваемые в процессе оптимизации. Поиск по адресам, пересечениям и местам работает офлайн — все данные для Сан-Франциско встроены в страницу. Исходный код, данные и полное описание метода доступны на GitHub.

Обсуждение подтверждает полезность FlattenSF, но выявляет проблемы с точностью маршрутов, неудобным UI и недостаточной атрибуцией данных. Пользователи хвалят чистый дизайн и интерактивный профиль высот, отмечая, что визуализация делает планирование приятным. Однако сообщаются неточные рекомендации: вместо ровной 23‐й авеню сервис предлагает подниматься по 25‐й, что указывает на ошибки в расчётах. В районе Mission (22‐я улица и San Jose) инструмент иногда выбирает нелогичный «захват» назад, а также вызывает вопросы по расположению цветовой шкалы и меток высоты. Пользователи предлагают добавить опцию минимизации среднего уклона (grade) вместо суммарного подъёма для более комфортных велосипедных трасс. Также предлагается интегрировать Valhalla для пошаговых указаний, хотя текущая резолюция 30 м ограничивает точность. Запрошены новые режимы: «самый крутой» для тренировок, поддержка автотранспорта с ручной коробкой передач и пользовательские кривые стоимости маршрута. Отмечена необходимость корректного указания источника данных OSM, так как отсутствие атрибуции нарушает лицензию. Интересуются переносом сервиса в другие города (Иstanbul, Сиэтл, Сидней), где также есть значительные перепады высот. Некоторые советуют использовать альтернативные инструменты (brouter.de, собственный проект steepless) для сравнения профилей высот. Несколько комментариев подчёркивают, что текущий UI позволяет в реальном времени менять баланс между длиной и подъёмом, что считается удобным.

Проект "How Did I Get Here" от Hack Club демонстрирует путь, который пакеты данных проходят от вашего устройства до сервера. С помощью самописного трейсера ktr, работающего по протоколу ICMP с использованием поля TTL, проект в реальном времени отслеживает каждый узел маршрута. Интересно, что сайт работает даже без JavaScript — сервер последовательно отправляет обновленную HTML-разметку, создавая иллюзию плавной загрузки трейсера.

Важно отметить, что показанный маршрут является "обратным" — от сервера к вашему устройству, а не наоборот, что может незначительно отличаться от реального пути из-за асимметрии маршрутизации. Каждый "сеть" в маршруте на самом деле представляет собой автономную систему (AS) — коллекцию маршрутизаторов, принадлежащую одной компании. Статья вскрывает, что интернет — это не свободная сеть, а скорее совокупность корпоративных сетей, связанных финансовыми соглашениями и бюрократическими процедурами.

• Обсуждение охватывает различные аспекты traceroute и его ограничений, включая то, что AS-путь может быть нестабилен, а фактические точки пиринга могут сильно различаться.
• Участники обсуждают, что traceroute может не отображать обратный путь, особенно если сеть использует асимметричное маршрутизирование.
• Обсуждается, что веб-сайт может не работать из-за блокировки ICMP или из-за того, что маршрутизаторы не отвечают на ICMP запросы.
• Участники также обсуждают, что traceroute может не отображать правильный путь, если используются различные стратегии маршрутизации, такие как source routing или loose source routing.
• Участники также обсуждают, что traceroute может не отображать правильный путь, если используются различные стратегии маршрутизации, такие как source routing или loose source routing.

Анализ трёх недавних проблем

С 17 сентября 2025 года

В период с августа по начало сентября три ошибки в инфраструктуре периодически снижали качество ответов Claude. Мы устранили эти проблемы и хотим объяснить, что произошло.

В начале августа пользователи начали сообщать о снижении качества ответов. Изначально эти сообщения было сложно отличить от обычных колебаний обратной связи. К концу августа участившиеся жалобы побудили нас начать расследование, которое выявило три отдельные инфраструктурные ошибки.

Мы никогда не снижаем качество модели из-за спроса, времени суток или нагрузки на серверы. Проблемы были вызваны исключительно ошибками инфраструктуры.

Хронология событий

Наложение этих ошибок значительно усложнило диагностику. Первая ошибка появилась 5 августа, затронув около 0,8% запросов к Sonnet 4. Две другие возникли 25-26 августа.

Изменение балансировки нагрузки 29 августа увеличило количество затронутых запросов, что привело к противоречивым отчетам пользователей.

Три перекрывающиеся проблемы

1. Ошибка маршрутизации контекстного окна

5 августа некоторые запросы Sonnet 4 перенаправлялись на серверы, настроенные для контекстного окна в 1 млн токенов. Изначально ошибка затрагивала 0,8% запросов, но к 31 августа эта доля выросла до 16%.

Около 30% пользователей Claude Code столкнулись с ухудшением ответов. На Amazon Bedrock пик затронутых запросов составил 0,18%, на Google Cloud Vertex AI — менее 0,0004%.

Решение: Исправлена логика маршрутизации. Фикс развернут 4 сентября, к 16 сентября распространен на основные платформы.

2. Повреждение вывода

25 августа ошибка конфигурации на серверах TPU вызвала сбой при генерации токенов. Это приводило к появлению неожиданных символов (например, тайских или китайских в ответ на английские запросы) или синтаксических ошибок в коде.

Проблема затрагивала Opus 4.1/4 (25-28 августа) и Sonnet 4 (25 августа - 2 сентября). Сторонние платформы не пострадали.

Решение: Выявлена и откатана ошибочная конфигурация.

• Критика отсутствия юнит-тестов и акцент на использовании эвалов для тестирования моделей.
• Удивление способностью Anthropic влиять на инфраструктуру AWS Bedrock, что противоречит обязательствам AWS.
• Обсуждение технических сбоев: ошибки маршрутизации запросов, коррупция вывода и баг компилятора XLA, повлиявшие на качество Claude.
• Высокое количество инцидентов, отмеченных на статусной странице Claude, и призывы к улучшению качества и надежности сервиса.
• Критика недостаточной прозрачности отчета Anthropic, включая отсутствие данных о степени деградации и компенсаций для пользователей.
• Обсуждение проблем недетерминированности в LLM и сложностей обеспечения воспроизводимости результатов.
• Спекуляции о причинах использования разных аппаратных платформ (TPU, AWS) и их влиянии на пользовательский опыт.