schachmat/wego: a terminal weather client with eight backends and a JSON pipe

What wego solves, and for whom

Most weather lookups cost a browser tab, a cookie banner and a rendered page. wego replaces that with one command that prints a table to stdout. The README describes it as "a weather client for the terminal", and the feature list is narrow by design: forecast for 1 to 7 days, temperature range with felt temperature, windspeed and direction, viewing distance, precipitation amount and probability, humidity. Nothing about radar, alerts or historical archives.

The audience is people who already work in a shell and want the forecast where their other tools live. That includes script authors. Because the json frontend emits JSON and the json backend reads JSON from a local file, the project documents a pipe between the two, which turns wego into a formatting step inside a larger pipeline rather than only an end-user command. The repository layout supports that reading: backends/, frontends/ and iface/ are separate top-level directories, so a new data source or a new renderer is a package, not a patch to main.go.

How the backend and frontend split works

wego separates where data comes from from how it is drawn. Backends are openweathermap, weatherapi, open-meteo, smhi, caiyun, worldweatheronline, pirateweather and json. Frontends are ascii-art-table (the default), emoji, markdown and json. The iface/ directory is where the contract between the two sides lives, and go.mod shows only small dependencies: go-colorable, go-runewidth, mango and roff for man page generation, and ingo for config handling. There is no HTTP client library in the dependency list, so requests go through the standard library.

Two backends need no key at all: open-meteo and smhi. That matters for evaluation, because you can confirm the rendering path works before signing up for anything. SMHI is geographically limited to Sweden and surrounding areas, so it is not a general substitute. Caiyun is described as China-focused with Chinese language support. Pirateweather requires a lat,lon location rather than a place name, which is a different input shape from the others.

Caching sits between the backend and the frontend. The README lists disk caching of weather data with a configurable TTL exposed as --cache-ttl. That is the mechanism that keeps repeated invocations from hammering an API, and it is worth knowing about when a forecast looks stale after you change location.

Installing wego and getting a first forecast

Distribution packaging exists, and the README points at Repology to check whether your distribution ships it. The direct route installs from GitHub into $GOPATH. The dependency is a working Go 1.20 environment, and the module file confirms go 1.20 as the language version.

go install github.com/schachmat/wego@latest

After that, run wego once with no configuration. The README is explicit that you will get an error message, and that this is the intended path: the run generates the wegorc config file under $XDG_CONFIG_HOME/wego/ or the OS-equivalent location returned by os.UserConfigDir(), which on Linux is ~/.config/wego/wegorc.

The cheapest way to a working forecast is a keyless backend. Edit wegorc and set open-meteo with a location:

backend=openmeteo
location=New York

Run wego again and the current and next few days should print as an ASCII table. If you want a different renderer for one invocation, the README gives this example:

wego --frontend emoji London

The argument order is flexible. The README states that wego 4 London and wego London 4 are equivalent, both returning the current day plus the next three. If colors interfere with a pipe or a light terminal, --monochrome disables them, monochrome=true makes that permanent in the config, and NO_COLOR=1 wego disables them for a single run without touching the file.

The config resolution order is stricter than it looks

wego resolves its config in four steps, and the order has a consequence people miss. $WEGORC wins over everything. Next comes $XDG_CONFIG_HOME/wego/wegorc if it exists. Then $HOME/.wegorc, kept for backward compatibility. Only if none of those exist does wego create a new file at $XDG_CONFIG_HOME/wego/wegorc.

The trap is the legacy path. If you have an old ~/.wegorc lying around from a previous install, it takes precedence over the XDG location, and edits to the newer file will appear to do nothing. Deleting or renaming the legacy file is the fix. The same logic applies to $WEGORC: if that variable is exported in a shell profile, the file it points at is the only one wego reads.

Config management itself is delegated to ingo, a separate project by the same author, pinned in go.mod to a 2017 pseudo-version. That is an old dependency for a tool whose most recent release is 2.4 from 2026-04-11. It does not by itself indicate a problem, but it does mean config parsing behaviour is defined outside this repository.

Where wego is the wrong tool

The forecast window is the first boundary. One to seven days is the documented range; there is no hourly breakdown and no historical lookup. If you need to know whether it rained last Tuesday, or what the next six hours look like minute by minute, wego does not do it.

Backend availability is the second. Worldweatheronline no longer offers free API keys, and the README links issue #83 for that. Anyone following an older tutorial that configures wwo-api-key will hit a wall at signup, not at runtime, which is a slower way to learn the backend is dead for free users. Most other backends require you to register and paste a key into a plaintext config file, so the config is a credential store and should be treated like one.

Terminal support is the third. The ascii-art-table and emoji frontends need a utf-8 terminal with 256 colors and a monospaced font containing all the required runes; the README names dejavu sans mono as an example. On a minimal container image or a terminal with a fallback font, the table can render as boxes. The markdown and json frontends sidestep this entirely, which is the practical reason to prefer them in scripts.

Finally, there is no homepage field on the repository. Documentation lives in the README and in the built-in man page reachable with wego --man, so offline help exists, but there is no separate docs site to consult.

wego against wttr.in

The obvious comparison is wttr.in, which also prints weather to a terminal but does so as a hosted HTTP service you query with curl. The difference in approach is where the work happens. wttr.in moves backend selection, caching and rendering to a server, so your client only needs curl, and you get the same output from any machine. wego moves all of it to your machine: you install a Go binary, you hold the API keys, and you choose the backend in a local config file.

That trade cuts both ways. wego keeps working with your own API keys and your own quota, and the json frontend lets you pipe structured output into another program without parsing a remote service's response format. It also means nothing works until you have installed the binary and configured a backend. For a one-off check on a machine you do not control, a hosted service is less setup. For a workstation you use daily, having the keys and the cache local is the point.

The related searches around wttr.in, such as wttr.in locations and wttr.in Fahrenheit, describe a different tool's interface, not wego's. In wego the equivalents are the location argument and the units setting, which accepts metric, imperial, si or metric-ms.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-01, roughly seven weeks before this writing. Release history is uneven: 2.2 in June 2023, 2.3 in August 2024, then 2.4 in April 2026. Between 2.3 and 2.4 there is a gap of about twenty months, so a user pinning a version should not assume frequent point releases. The presence of hacktoberfest in the topic list suggests the project has been open to drive-by contributions.

The licence is ISC, a short permissive licence functionally similar to MIT. For most users that means you can use, modify and redistribute the binary, including in commercial settings, provided the copyright notice and licence text are preserved. It says nothing about the weather data itself, and that is the part worth checking separately: each backend has its own terms, and openweathermap, weatherapi, caiyun, pirateweather and worldweatheronline are third-party services with their own attribution and rate-limit rules. The ISC licence on the code does not grant you rights to their data. This is not legal advice; read the terms of whichever backend you configure.

Upgrade cost is low in normal use. The config file is plain key=value, and the README's documented keys (backend, location, days, units, frontend, monochrome, the per-backend API key fields) have stayed stable across the releases listed. The main breakage risk is a backend changing its free tier, as worldweatheronline already did.

Editorial conclusion

Adopt wego if you live in a terminal and want a forecast you can read without a browser, especially on open-meteo or smhi where no key is needed. Do not adopt it if you need historical weather data, radar imagery or minute-by-minute nowcasting; the README lists only forecast display, and the JSON backend reads a file you supply rather than fetching history. Before committing, verify two things on your own machine: that your terminal font covers the runes the ascii-art-table frontend uses, and that your chosen backend still issues free keys, since worldweatheronline no longer does.

Frequently asked questions

Official sources

1. Issues
2. License: ISC
3. README
4. Releases
5. schachmat/wego on GitHub